draft-ietf-bfd-v4v6-1hop-02.txt		draft-ietf-bfd-v4v6-1hop-03.txt
	Network Working Group D. Katz		Network Working Group D. Katz
	Internet Draft Juniper Networks		Internet Draft Juniper Networks
	D. Ward		D. Ward
	Cisco Systems		Cisco Systems
	Expires: September, 2005 March, 2005		Expires: January, 2006 July, 2005
	BFD for IPv4 and IPv6 (Single Hop)		BFD for IPv4 and IPv6 (Single Hop)
	draft-ietf-bfd-v4v6-1hop-02.txt		draft-ietf-bfd-v4v6-1hop-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	or will be disclosed, and any of which I become aware will be		have been or will be disclosed, and any of which he or she becomes
	disclosed, in accordance with RFC 3668.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	skipping to change at page 9, line 33		skipping to change at page 9, line 33
	A number of mechanisms are available to tunnel IPv4 and IPv6 over		A number of mechanisms are available to tunnel IPv4 and IPv6 over
	arbitrary topologies. If the tunnel mechanism does not decrement the		arbitrary topologies. If the tunnel mechanism does not decrement the
	TTL or hop count of the network protocol carried within, the		TTL or hop count of the network protocol carried within, the
	mechanism described in this document may be used to provide liveness		mechanism described in this document may be used to provide liveness
	detection for the tunnel. The BFD Authentication mechanism SHOULD be		detection for the tunnel. The BFD Authentication mechanism SHOULD be
	used and is strongly encouraged.		used and is strongly encouraged.
	Normative References		Normative References
	[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",		[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
	draft-ietf-bfd-base-02.txt, March, 2005.		draft-ietf-bfd-base-03.txt, July, 2005.
	[BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft-		[BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft-
	ietf-bfd-multihop-02.txt, March, 2005.		ietf-bfd-multihop-03.txt, July, 2005.
	[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism		[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism
	(GTSM)", RFC 3682, February 2004.		(GTSM)", RFC 3682, February 2004.
	[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual		[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
	environments", RFC 1195, December 1990.		environments", RFC 1195, December 1990.
	[ISIS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for IS-		[ISIS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for IS-
	IS", RFC 3847, July 2004.		IS", RFC 3847, July 2004.
	skipping to change at page 10, line 31		skipping to change at page 10, line 31
	The security implications of the use of BFD Authentication are		The security implications of the use of BFD Authentication are
	discussed in [BFD].		discussed in [BFD].
	The use of the TTL=255 check simultaneously with BFD Authentication		The use of the TTL=255 check simultaneously with BFD Authentication
	provides a low overhead mechanism for discarding a class of		provides a low overhead mechanism for discarding a class of
	unauthorized packets and may be useful in implementations in which		unauthorized packets and may be useful in implementations in which
	cryptographic checksum use is susceptable to denial of service		cryptographic checksum use is susceptable to denial of service
	attacks. The use or non-use of this mechanism does not impact		attacks. The use or non-use of this mechanism does not impact
	interoperability.		interoperability.
			IANA Considerations
			This document has no actions for IANA.
	Authors' Addresses		Authors' Addresses
	Dave Katz		Dave Katz
	Juniper Networks		Juniper Networks
	1194 N. Mathilda Ave.		1194 N. Mathilda Ave.
	Sunnyvale, California 94089-1206 USA		Sunnyvale, California 94089-1206 USA
	Phone: +1-408-745-2000		Phone: +1-408-745-2000
	Email: dkatz@juniper.net		Email: dkatz@juniper.net
	Dave Ward		Dave Ward
	Cisco Systems		Cisco Systems
	170 W. Tasman Dr.		170 W. Tasman Dr.
	San Jose, CA 95134 USA		San Jose, CA 95134 USA
	Phone: +1-408-526-4000		Phone: +1-408-526-4000
	Email: dward@cisco.com		Email: dward@cisco.com
	Changes from the previous draft		Changes from the previous draft
	The only substantive changes are to allow the TTL=255 check to be		All changes are editorial in nature.
	optional when authentication is in use, and to specify that the
	destination address in BFD Control packets does not change even if
	the source address of the neighbor's packets changes (which is
	allowed on unnumbered links.)
	Explicatory language on the issues of interaction with multiprotocol		IPR Disclaimer
	routing protocols was added.
	All other changes are editorial.		The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
			Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at ietf-
			ipr@ietf.org.
	Full Copyright Notice		Full Copyright Notice
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2005).
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
	This document expires in September, 2005.		This document expires in January, 2006.
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/