< draft-ietf-mpls-ldp-ipv6-09.txt		draft-ietf-mpls-ldp-ipv6-10.txt >
	MPLS Working Group Rajiv Asati		MPLS Working Group Rajiv Asati
	Internet Draft Cisco		Internet Draft Cisco
	Updates: 5036 (if approved)		Updates: 5036 (if approved)
	Intended status: Standards Track Vishwas Manral		Intended status: Standards Track Vishwas Manral
	Expires: January 15, 2014 Hewlett-Packard, Inc.		Expires: June 8, 2014 Hewlett-Packard, Inc.
	Rajiv Papneja		Rajiv Papneja
	Huawei		Huawei
	Carlos Pignataro		Carlos Pignataro
	Cisco		Cisco
	July 15, 2013		December 8, 2013
	Updates to LDP for IPv6		Updates to LDP for IPv6
	draft-ietf-mpls-ldp-ipv6-09		draft-ietf-mpls-ldp-ipv6-10
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 15, 20134.		This Internet-Draft will expire on June 8, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	2. Specification Language.........................................5		2. Specification Language.........................................5
	3. LSP Mapping....................................................6		3. LSP Mapping....................................................6
	4. LDP Identifiers................................................6		4. LDP Identifiers................................................6
	5. Peer Discovery.................................................7		5. Peer Discovery.................................................7
	5.1. Basic Discovery Mechanism.................................7		5.1. Basic Discovery Mechanism.................................7
	5.2. Extended Discovery Mechanism..............................8		5.2. Extended Discovery Mechanism..............................8
	6. LDP Session Establishment and Maintenance......................8		6. LDP Session Establishment and Maintenance......................8
	6.1. Transport connection establishment........................9		6.1. Transport connection establishment........................9
	6.2. Maintaining Hello Adjacencies............................10		6.2. Maintaining Hello Adjacencies............................10
	6.3. Maintaining LDP Sessions.................................11		6.3. Maintaining LDP Sessions.................................11
	7. Label Distribution............................................11		7. Label Distribution............................................12
	8. LDP Identifiers and Next Hop Addresses........................12		8. LDP Identifiers and Next Hop Addresses........................12
	9. LDP TTL Security..............................................13		9. LDP TTL Security..............................................13
	10. IANA Considerations..........................................13		10. IANA Considerations..........................................13
	11. Security Considerations......................................13		11. Security Considerations......................................14
	12. Acknowledgments..............................................14		12. Acknowledgments..............................................14
	13. Additional Contributors......................................14		13. Additional Contributors......................................14
	14. References...................................................15		14. References...................................................16
	14.1. Normative References....................................15		14.1. Normative References....................................16
	14.2. Informative References..................................15		14.2. Informative References..................................16
	Author's Addresses...............................................16		15. Appendix.....................................................17
			15.1. A.1.....................................................17
			Author's Addresses...............................................17
	1. Introduction		1. Introduction
	The LDP [RFC5036] specification defines procedures and messages for		The LDP [RFC5036] specification defines procedures and messages for
	exchanging FEC-label bindings over either IPv4 or IPv6 or both (e.g.		exchanging FEC-label bindings over either IPv4 or IPv6 or both (e.g.
	dual-stack) networks.		dual-stack) networks.
	However, RFC5036 specification has the following deficiencies in		However, RFC5036 specification has the following deficiencies in
	regards to IPv6 usage:		regards to IPv6 usage:
	skipping to change at page 6, line 5 ¶		skipping to change at page 5, line 46 ¶
	TLV - Type Length Value		TLV - Type Length Value
	LSR - Label Switch Router		LSR - Label Switch Router
	LSP - Label Switched Path		LSP - Label Switched Path
	LSPv4 - IPv4-signaled Label Switched Path [RFC4798]		LSPv4 - IPv4-signaled Label Switched Path [RFC4798]
	LSPv6 - IPv6-signaled Label Switched Path [RFC4798]		LSPv6 - IPv6-signaled Label Switched Path [RFC4798]
			AFI - Address Family Identifier
	3. LSP Mapping		3. LSP Mapping
	Section 2.1 of [RFC5036] specifies the procedure for mapping a		Section 2.1 of [RFC5036] specifies the procedure for mapping a
	particular packet to a particular LSP using three rules. Quoting the		particular packet to a particular LSP using three rules. Quoting the
	3rd rule from RFC5036:		3rd rule from RFC5036:
	"If it is known that a packet must traverse a particular egress		"If it is known that a packet must traverse a particular egress
	router, and there is an LSP that has an Address Prefix FEC element		router, and there is an LSP that has an Address Prefix FEC element
	that is a /32 address of that router, then the packet is mapped to		that is a /32 address of that router, then the packet is mapped to
	that LSP."		that LSP."
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 12 ¶
	address in an IPv6 only LSR (i.e., single stack), nor would there		address in an IPv6 only LSR (i.e., single stack), nor would there
	be an expectation of it being DNS-resolvable. In IPv4 deployments,		be an expectation of it being DNS-resolvable. In IPv4 deployments,
	the LSR Id is typically derived from an IPv4 address, generally		the LSR Id is typically derived from an IPv4 address, generally
	assigned to a loopback interface. In IPv6 only deployments, this		assigned to a loopback interface. In IPv6 only deployments, this
	32-bit LSR Id must be derived by some other means that guarantees		32-bit LSR Id must be derived by some other means that guarantees
	global uniqueness within the MPLS network, similar to that of BGP		global uniqueness within the MPLS network, similar to that of BGP
	Identifier [RFC6286].		Identifier [RFC6286].
	This document qualifies the first sentence of last paragraph of		This document qualifies the first sentence of last paragraph of
	Section 2.5.2 of [RFC5036] to be per address family and therefore		Section 2.5.2 of [RFC5036] to be per address family and therefore
	updates that sentence to the following: "For a given address family		updates that sentence to the following: "For a given address family,
	over which a Hello is sent, and a given label space, an LSR MUST		an LSR MUST advertise the same transport address in all Hellos that
	advertise the same transport address." This rightly enables the per-		advertise the same label space." This rightly enables the per-
	platform label space to be shared between IPv4 and IPv6.		platform label space to be shared between IPv4 and IPv6.
	In summary, this document not only allows the usage of a common LDP		In summary, this document not only allows the usage of a common LDP
	identifier i.e. same LSR-Id (aka LDP Router-Id), but also the common		identifier i.e. same LSR-Id (aka LDP Router-Id), but also the common
	Label space id for both IPv4 and IPv6 on a dual-stack LSR.		Label space id for both IPv4 and IPv6 on a dual-stack LSR.
	This document reserves 0.0.0.0 as the LSR-Id, and prohibits its		This document reserves 0.0.0.0 as the LSR-Id, and prohibits its
	usage.		usage.
	5. Peer Discovery		5. Peer Discovery
	skipping to change at page 8, line 14 ¶		skipping to change at page 8, line 15 ¶
	IPv6 address MUST be used as the source IP address in IPv6 LDP Link		IPv6 address MUST be used as the source IP address in IPv6 LDP Link
	Hellos.		Hellos.
	Also, the LDP Link Hello packets must have their IPv6 Hop Limit set		Also, the LDP Link Hello packets must have their IPv6 Hop Limit set
	to 255, and be checked for the same upon receipt before any further		to 255, and be checked for the same upon receipt before any further
	processing, as specified in Generalized TTL Security Mechanism		processing, as specified in Generalized TTL Security Mechanism
	(GTSM)[RFC5082]. The built-in inclusion of GTSM automatically		(GTSM)[RFC5082]. The built-in inclusion of GTSM automatically
	protects IPv6 LDP from off-link attacks.		protects IPv6 LDP from off-link attacks.
	More importantly, if an interface is a dual-stack LDP interface		More importantly, if an interface is a dual-stack LDP interface
	(e.g. enabled with both IPv4 and IPv6 LDP), then the LSR must		(e.g. enabled with both IPv6 and IPv4 LDP), then the LSR must
	periodically send both IPv4 and IPv6 LDP Link Hellos (using the same		periodically send both IPv6 and IPv4 LDP Link Hellos (using the same
	LDP Identifier per section 4) and must separately maintain the Hello		LDP Identifier per section 4) on that interface and be able to
	adjacency for IPv4 and IPv6 on that interface.		receive them. This facilitates discovery of IPv6-only, IPv4-only and
			dual-stack peers on the interface's subnet.
	In summary, the IPv4 and IPv6 LDP Link Hellos must carry the same		An implementation should prefer sending IPv6 LDP link Hellos
	LDP identifier (assuming per-platform label space usage).		before sending IPv4 LDP Link Hellos on a dual-stack interface, if
			possible.
			Lastly, the IPv6 and IPv4 LDP Link Hellos must carry the same LDP
			identifier (assuming per-platform label space usage).
	5.2. Extended Discovery Mechanism		5.2. Extended Discovery Mechanism
	Suffice to say, the extended discovery mechanism (defined in section		Suffice to say, the extended discovery mechanism (defined in section
	2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific		2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific
	consideration, since the targeted LDP Hellos are sent to a pre-		consideration, since the targeted LDP Hellos are sent to a pre-
	configured (unicast) destination IPv6 address.		configured (unicast) destination IPv6 address.
	The link-local IP addresses MUST NOT be used as the source or		The link-local IP addresses MUST NOT be used as the source or
	destination IPv6 addresses in extended discovery.		destination IPv6 addresses in extended discovery.
	skipping to change at page 9, line 36 ¶		skipping to change at page 9, line 40 ¶
	2. An LSR SHOULD accept the Hello message that contains both IPv4		2. An LSR SHOULD accept the Hello message that contains both IPv4
	and IPv6 transport address optional objects, but MUST use only		and IPv6 transport address optional objects, but MUST use only
	the transport address whose address family is the same as that		the transport address whose address family is the same as that
	of the IP packet carrying Hello. An LSR SHOULD accept only the		of the IP packet carrying Hello. An LSR SHOULD accept only the
	first transport object for a given Address family in the		first transport object for a given Address family in the
	received Hello message, and ignore the rest, if the LSR		received Hello message, and ignore the rest, if the LSR
	receives more than one transport object.		receives more than one transport object.
	3. An LSR MUST send separate Hellos (each containing either IPv4		3. An LSR MUST send separate Hellos (each containing either IPv4
	or IPv6 transport address optional object) for each IP address		or IPv6 transport address optional object) for each IP address
	family, if LDP was enabled for both IP address-families.		family, if LDP was enabled for both IP address families.
	4. An LSR MUST use a global unicast IPv6 address in IPv6 transport		4. An LSR MUST use a global unicast IPv6 address in IPv6 transport
	address optional object of outgoing targeted hellos, and check		address optional object of outgoing targeted hellos, and check
	for the same in incoming targeted hellos (i.e. MUST discard the		for the same in incoming targeted hellos (i.e. MUST discard the
	hello, if it failed the check).		hello, if it failed the check).
	5. An LSR MUST prefer using global unicast IPv6 address for an LDP		5. An LSR MUST prefer using global unicast IPv6 address for an LDP
	session with a remote LSR, if it had to choose between global		session with a remote LSR, if it had to choose between global
	unicast IPv6 address and unique-local or link-local IPv6		unicast IPv6 address and unique-local or link-local IPv6
	address (pertaining to the same LDP Identifier) for the		address (pertaining to the same LDP Identifier) for the
	transport connection.		transport connection.
	6. An LSR SHOULD NOT create (or honor the request for creating) a		6. An LSR SHOULD NOT create (or honor the request for creating) a
	TCP connection for a new LDP session with a remote LSR, if they		TCP connection for a new LDP session with a remote LSR, if they
	already have an LDP session (for the same LDP Identifier)		already have an LDP session (for the same LDP Identifier)
	established over whatever IP version transport.		established over whatever IP version transport.
	This means that only one transport connection is established,		This means that only one transport connection is established,
	even if there are two Hello adjacencies (one for IPv4 and		regardless of one or two Hello adjacencies (one for IPv4 and
	another for IPv6). This is independent of whether the Hello		another for IPv6) are created & maintained over a single
	Adjacencies are created over a single interface (scenario 1 in		interface (scenario 1 in section 1.1) or multiple interfaces
	section 1.1) or multiple interfaces (scenario 2 in section 1.1)		(scenario 2 in section 1.1) between two LSRs.
	between two LSRs.
	7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new		7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new
	LDP session with a remote LSR, if it has both IPv4 and IPv6		LDP session with a remote LSR, if it has both IPv4 and IPv6
	hello adjacencies for the same LDP Identifier (over a dual-		hello adjacencies for the same (peer) LDP Identifier (over a
	stack interface, or two or more single-stack IPv4 and IPv6		dual-stack interface, or two or more single-stack IPv4 and IPv6
	interfaces). This applies to the section 2.5.2 of RFC5036.		interfaces). This applies to the section 2.5.2 of RFC5036.
	Each LSR, assuming an active role for whichever address		Each LSR, assuming an active role for whichever address
	family(s), should enforce this LDP/TCP connection over IPv6		family(s), should enforce this LDP/TCP connection over IPv6
	preference for a time-period (default value is 15 seconds),		preference for a time-period (default value is 15 seconds),
	after which LDP/TCP connection over IPv4 should be attempted.		after which LDP/TCP connection over IPv4 should be attempted.
	This enforcement is independent of whether the LSR is assuming		This enforcement is independent of whether the LSR is assuming
	the active role for IPv4 This timer is started upon receiving		the active role for IPv4. This timer is started upon receiving
	the first hello from the neighbor.		the first hello from the neighbor.
	8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new		8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new
	LDP session with a remote LSR, if they attempted two TCP		LDP session with a remote LSR, if they attempted two TCP
	connections using IPv4 and IPv6 transport addresses		connections using different transport address families (IPv4
	simultaneously.		and IPv6) simultaneously.
	An implementation may provide an option to favor one AFI (IPv4, say)		An implementation may provide an option to favor one AFI (IPv4, say)
	over another AFI (IPv6, say) for the TCP transport connection, so as		over another AFI (IPv6, say) for the TCP transport connection, so as
	to use the favored IP version for the LDP session, and force		to use the favored IP version for the LDP session, and force
	deterministic active/passive roles.		deterministic active/passive roles.
	6.2. Maintaining Hello Adjacencies		6.2. Maintaining Hello Adjacencies
	As outlined in section 2.5.5 of RFC5036, this draft describes that		In line with the section 2.5.5 of RFC5036, this draft describes that
	if an LSR has a dual-stack interface, which is enabled with both		if an LSR has a dual-stack interface, which is enabled with both
	IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and		IPv6 and IPv4 LDP, then the LSR must periodically send and receive
	IPv6 LDP Link Hellos and must separately maintain the Hello		both IPv6 and IPv4 LDP Link Hellos.
	adjacency for IPv4 and IPv6 on that interface.
	This ensures successful labeled IPv4 and labeled IPv6 traffic		This ensures successful LDP discovery and subsequent peering using
	forwarding on a dual-stacked interface, as well as successful LDP		the appropriate (address family) transport on a multi-access or
	peering using the appropriate transport on a multi-access		broadcast interface (even if there are IPv6-only, IPv4-only and
	interface (even if there are IPv4-only, IPv6-only and dual-stack		dual-stack LSRs connected to that interface).
	LSRs connected to that multi-access interface).
			This document allows an LSR to maintain Rx-side Link Hello adjacency
			for only one address family that has been used for the establishment
			of the LDP session.
	6.3. Maintaining LDP Sessions		6.3. Maintaining LDP Sessions
	Two LSRs maintain a single LDP session between them (i.e. not tear		Two LSRs maintain a single LDP session between them (i.e. not tear
	down an existing session), as described in section 6.1, whether		down an existing session), as described in section 6.1, whether
	- they are connected via a dual-stack LDP enabled interface or via		- they are connected via a dual-stack LDP enabled interface or via
	two single-stack LDP enabled interfaces;		two single-stack LDP enabled interfaces;
	- a single-stack interface is converted to a dual-stack interface		- a single-stack interface is converted to a dual-stack interface
	(e.g. figure 1) on either LSR;		(e.g. figure 1) on either LSR;
	skipping to change at page 14, line 35 ¶		skipping to change at page 15, line 4 ¶
	13. Additional Contributors		13. Additional Contributors
	The following individuals contributed to this document:		The following individuals contributed to this document:
	Kamran Raza		Kamran Raza
	Cisco Systems, Inc.		Cisco Systems, Inc.
	2000 Innovation Drive		2000 Innovation Drive
	Kanata, ON K2K-3E8, Canada		Kanata, ON K2K-3E8, Canada
	Email: skraza@cisco.com		Email: skraza@cisco.com
	Nagendra Kumar		Nagendra Kumar
	Cisco Systems, Inc.		Cisco Systems, Inc.
	SEZ Unit, Cessna Business Park,		SEZ Unit, Cessna Business Park,
	Bangalore, KT, India		Bangalore, KT, India
	Email: naikumar@cisco.com		Email: naikumar@cisco.com
			Andre Pelletier
			Email: apelleti@cisco.com
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6		[RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6
	(IPv6) Addressing Architecture", RFC 4291, February 2006.		(IPv6) Addressing Architecture", RFC 4291, February 2006.
End of changes. 21 change blocks.
	40 lines changed or deleted		52 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/