draft-ietf-bfd-v4v6-1hop-09.txt		draft-ietf-bfd-v4v6-1hop-10.txt
	Network Working Group D. Katz		Network Working Group D. Katz
	Internet Draft Juniper Networks		Internet Draft Juniper Networks
	Intended status: Proposed Standard D. Ward		Intended status: Proposed Standard D. Ward
	Cisco Systems		Cisco Systems
	Expires: August, 2009 February 5, 2009		Expires: April, 2010 October 16, 2009
	BFD for IPv4 and IPv6 (Single Hop)		BFD for IPv4 and IPv6 (Single Hop)
	draft-ietf-bfd-v4v6-1hop-09.txt		draft-ietf-bfd-v4v6-1hop-10.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and 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.
	skipping to change at page 1, line 43		skipping to change at page 1, line 43
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document.		to this document. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the BSD License.
	Abstract		Abstract
	This document describes the use of the Bidirectional Forwarding		This document describes the use of the Bidirectional Forwarding
	Detection protocol over IPv4 and IPv6 for single IP hops.		Detection protocol over IPv4 and IPv6 for single IP hops.
	Conventions used in this document		Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	skipping to change at page 3, line 31		skipping to change at page 3, line 31
	two systems over a given interface (logical or physical) for a		two systems over a given interface (logical or physical) for a
	particular protocol. The BFD session must be bound to this		particular protocol. The BFD session must be bound to this
	interface. As such, both sides of a session MUST take the "Active"		interface. As such, both sides of a session MUST take the "Active"
	role (sending initial BFD Control packets with a zero value of Your		role (sending initial BFD Control packets with a zero value of Your
	Discriminator) and any BFD packet from the remote machine with a zero		Discriminator) and any BFD packet from the remote machine with a zero
	value of Your Discriminator MUST be associated with the session bound		value of Your Discriminator MUST be associated with the session bound
	to the remote system, interface, and protocol.		to the remote system, interface, and protocol.
	4. Encapsulation		4. Encapsulation
	4.1. BFD for IPv4		BFD Control packets MUST be transmitted in UDP packets with
			destination port 3784, within an IPv4 or IPv6 packet. The source
	In the case of IPv4, BFD Control packets MUST be transmitted in UDP		port MUST be in the range 49152 through 65535. The same UDP source
	packets with destination port 3784, within an IPv4 packet. The		port number MUST be used for all BFD Control packets associated with
	source port MUST be in the range 49152 through 65535. The same UDP		a particular session. The source port number SHOULD be unique among
	source port number MUST be used for all BFD Control packets		all BFD sessions on the system. If more than 16384 BFD sessions are
	associated with a particular session. The source port number SHOULD		simultaneously active, UDP source port numbers MAY be reused on
	be unique among all BFD sessions on the system. If more than 16384		multiple sessions, but the number of distinct uses of the same UDP
	BFD sessions are simultaneously active, UDP source port numbers MAY		source port number SHOULD be minimized. An implementation MAY use
	be reused on multiple sessions, but the number of distinct uses of		the UDP port source number to aid in demultiplexing incoming BFD
	the same UDP source port number SHOULD be minimized. An		Control packets, but ultimately the mechanisms in [BFD] MUST be used
	implementation MAY use the UDP port source number to aid in		to demultiplex incoming packets to the proper session.
	demultiplexing incoming BFD Control packets, but ultimately the
	mechanisms in [BFD] MUST be used to demultiplex incoming packets to
	the proper session.
	BFD Echo packets MUST be transmitted in UDP packets with destination		BFD Echo packets MUST be transmitted in UDP packets with destination
	UDP port 3785 in an IPv4 packet. The setting of the UDP source port		UDP port 3785 in an IPv4 or IPv6 packet. The setting of the UDP
	is outside the scope of this specification. The destination address		source port is outside the scope of this specification. The
	MUST be chosen in such a way as to cause the remote system to forward		destination address MUST be chosen in such a way as to cause the
	the packet back to the local system. The source address MUST be		remote system to forward the packet back to the local system. The
	chosen in such a way as to preclude the remote system from generating		source address MUST be chosen in such a way as to preclude the remote
	ICMP Redirect messages. In particular, the source address SHOULD NOT		system from generating ICMP or Neighbor Discovery Redirect messages.
	be part of the subnet bound to the interface over which the BFD Echo		In particular, the source address SHOULD NOT be part of the subnet
	packet is being transmitted, unless it is known by other means that		bound to the interface over which the BFD Echo packet is being
	the remote system will not send Redirects.		transmitted, and it SHOULD NOT be an IPv6 link-local address, unless
			it is known by other means that the remote system will not send
	4.2. BFD for IPv6		Redirects.
	In the case of IPv6, BFD Control packets MUST be transmitted in UDP		BFD Echo packets MUST be transmitted in such a way as to ensure that
	packets with destination port 3784, within an IPv6 packet. The		they are received by the remote system. On multiaccess media, for
	source port MUST be in the range 49152 through 65535. The same UDP		example, this requires that the destination datalink address
	source port number MUST be used for all BFD Control packets		corresponds to the remote system.
	associated with a particular session. The source port number SHOULD
	be unique among all BFD sessions on the system. If more than 16384
	BFD sessions are simultaneously active, UDP source port numbers MAY
	be reused on multiple sessions, but the number of distinct uses of
	the same UDP source port number SHOULD be minimized. An
	implementation MAY use the UDP port source number to aid in
	demultiplexing incoming BFD Control packets, but ultimately the
	mechanisms in [BFD] MUST be used to demultiplex incoming packets to
	the proper session.
	BFD Echo packets MUST be transmitted in UDP packets with destination		The above requirements may require the bypassing of some common IP
	UDP port 3785 in an IPv6 packet. The setting of the UDP source port		layer functionality, particularly in host implementations.
	is outside the scope of this specification. The source and
	destination addresses MUST both be associated with the local system.
	The destination address MUST be chosen in such a way as to cause the
	remote system to forward the packet back to the local system.
	5. TTL/Hop Limit Issues		5. TTL/Hop Limit Issues
	If BFD authentication is not in use on a session, all BFD Control		If BFD authentication is not in use on a session, all BFD Control
	packets for the session MUST be sent with a TTL or Hop Limit value of		packets for the session MUST be sent with a TTL or Hop Limit value of
	255. All received BFD Control packets that are demultiplexed to the		255. All received BFD Control packets that are demultiplexed to the
	session MUST be discarded if the received TTL or Hop Limit is not		session MUST be discarded if the received TTL or Hop Limit is not
	equal to 255. A discussion of this mechanism can be found in [GTSM].		equal to 255. A discussion of this mechanism can be found in [GTSM].
	If BFD authentication is in use on a session, all BFD Control packets		If BFD authentication is in use on a session, all BFD Control packets
	skipping to change at page 6, line 16		skipping to change at page 6, line 7
	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 Limit of the network protocol carried within, the		TTL or Hop Limit 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.
	8. IANA Considerations		8. IANA Considerations
	This document has no actions for IANA.		Ports 3784 and 3875 were assigned by IANA for use with this protocol.
	9. Security Considerations		9. Security Considerations
	In this application, the use of TTL=255 on transmit and receive,		In this application, the use of TTL=255 on transmit and receive,
	coupled with an association to an incoming interface, is viewed as		coupled with an association to an incoming interface, is viewed as
	supplying equivalent security characteristics to other protocols used		supplying equivalent security characteristics to other protocols used
	in the infrastructure, as it is not trivially spoofable. The		in the infrastructure, as it is not trivially spoofable. The
	security implications of this mechanism are further discussed in		security implications of this mechanism are further discussed in
	[GTSM].		[GTSM].
	skipping to change at page 7, line 10		skipping to change at page 6, line 33
	unauthorized packets and may be useful in implementations in which		unauthorized packets and may be useful in implementations in which
	cryptographic checksum use is susceptible to denial of service		cryptographic checksum use is susceptible 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.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",		[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
	draft-ietf-bfd-base-09.txt, February, 2009.		draft-ietf-bfd-base-10.txt, October, 2009.
	[BFD-GENERIC] Katz, D., and Ward, D., "Generic Application of BFD",		[BFD-GENERIC] Katz, D., and Ward, D., "Generic Application of BFD",
	draft-ietf-bfd-generic-05.txt, February, 2009.		draft-ietf-bfd-generic-05.txt, February, 2009.
	[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism		[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism
	(GTSM)", RFC 5082, October, 2007.		(GTSM)", RFC 5082, October, 2007.
	[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.
	skipping to change at page 8, line 7		skipping to change at page 7, line 29
	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
	Only minor editorial changes were made.		The Encapsulation section was reorganized, and the details of Echo
			packet encapsulation and transmission were expanded. The IANA
			Considerations section was updated to include the port number
			assignments.
	This document expires in August, 2009.		This document expires in April, 2010.
End of changes. 11 change blocks.
	51 lines changed or deleted		41 lines changed or added
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/