draft-ietf-bfd-multihop-02.txt		draft-ietf-bfd-multihop-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 Multihop Paths		BFD for Multihop Paths
	draft-ietf-bfd-multihop-02.txt		draft-ietf-bfd-multihop-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 4, line 36		skipping to change at page 4, line 36
	In the Passive role, by definition, the Unidirectional Receiver does		In the Passive role, by definition, the Unidirectional Receiver does
	not transmit any BFD Control packets until it learns the		not transmit any BFD Control packets until it learns the
	discriminator value in use by the other system (upon receipt of the		discriminator value in use by the other system (upon receipt of the
	first BFD Control packet.) The Unidirectional Receiver demultiplexes		first BFD Control packet.) The Unidirectional Receiver demultiplexes
	the first packet to the proper BFD session based on the physical or		the first packet to the proper BFD session based on the physical or
	logical link over which was received. This allows the receiver to		logical link over which was received. This allows the receiver to
	learn the remote discriminator value, which it then echoes back to		learn the remote discriminator value, which it then echoes back to
	the sender in its own (arbitrarily routed) BFD Control packet, after		the sender in its own (arbitrarily routed) BFD Control packet, after
	which time all packets are demultiplexed solely by discriminator.		which time all packets are demultiplexed solely by discriminator.
	4. Authentication		4. Encapsulation
			The encapsulation of BFD Control packets for multihop application in
			IPv4 and IPv6 is identical to that defined in [BFD-1HOP], except that
			the UDP destination port MUST have a value of <TBD>. This can aid in
			the demultiplexing and internal routing of incoming BFD packets.
			5. Authentication
	By their nature, multihop paths expose BFD to spoofing.		By their nature, multihop paths expose BFD to spoofing.
	Implementations of BFD SHOULD utilize authentication over multihop		Implementations of BFD SHOULD utilize authentication over multihop
	paths to help mitigate denial-of-service attacks.		paths to help mitigate denial-of-service attacks.
	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-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single		[BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single
	Hop)", draft-ietf-bfd-v4v6-1hop-02.txt, March, 2005.		Hop)", draft-ietf-bfd-v4v6-1hop-03.txt, July, 2005.
	[BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs",		[BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs",
	draft-ietf-bfd-mpls-01.txt, February, 2005.		draft-ietf-bfd-mpls-01.txt, February, 2005.
	[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate		[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.		[OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
	[OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999.		[OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999.
	Security Considerations		Security Considerations
	No additional security issues are raised in this document beyond		No additional security issues are raised in this document beyond
	those that exist in the referenced BFD documents.		those that exist in the referenced BFD documents.
			IANA Considerations
			An additional UDP port number needs to be allocated for use with
			multihop BFD.
	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
	No changes were made other than updating references.		The only substantive change was the requirement for a new UDP port
			number for use with multihop BFD. All other changes were editorial
			in nature.
			IPR Disclaimer
			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/