< draft-ietf-mpls-ldp-ipv6-10.txt		draft-ietf-mpls-ldp-ipv6-11.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: June 8, 2014 Hewlett-Packard, Inc.		Expires: June 28, 2014 Hewlett-Packard, Inc.
	Rajiv Papneja		Rajiv Papneja
	Huawei		Huawei
	Carlos Pignataro		Carlos Pignataro
	Cisco		Cisco
	December 8, 2013		December 28, 2013
	Updates to LDP for IPv6		Updates to LDP for IPv6
	draft-ietf-mpls-ldp-ipv6-10		draft-ietf-mpls-ldp-ipv6-11
	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/.
	skipping to change at page 2, line 8 ¶		skipping to change at page 2, line 8 ¶
	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		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	warranty as described in the Simplified BSD License.		warranty as described in the Simplified BSD License.
			This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Abstract		Abstract
	The Label Distribution Protocol (LDP) specification defines		The Label Distribution Protocol (LDP) specification defines
	procedures to exchange label bindings over either IPv4, or IPv6 or		procedures to exchange label bindings over either IPv4, or IPv6 or
	both networks. This document corrects and clarifies the LDP behavior		both networks. This document corrects and clarifies the LDP behavior
	when IPv6 network is used (with or without IPv4). This document		when IPv6 network is used (with or without IPv4). This document
	updates RFC 5036.		updates RFC 5036.
	Table of Contents		Table of Contents
	skipping to change at page 2, line 42 ¶		skipping to change at page 2, line 54 ¶
	7. Label Distribution............................................12		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......................................14		11. Security Considerations......................................14
	12. Acknowledgments..............................................14		12. Acknowledgments..............................................14
	13. Additional Contributors......................................14		13. Additional Contributors......................................14
	14. References...................................................16		14. References...................................................16
	14.1. Normative References....................................16		14.1. Normative References....................................16
	14.2. Informative References..................................16		14.2. Informative References..................................16
	15. Appendix.....................................................17		Appendix.........................................................17
	15.1. A.1.....................................................17
	Author's Addresses...............................................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 8, line 25 ¶		skipping to change at page 8, line 25 ¶
	(e.g. enabled with both IPv6 and IPv4 LDP), then the LSR must		(e.g. enabled with both IPv6 and IPv4 LDP), then the LSR must
	periodically send both IPv6 and IPv4 LDP Link Hellos (using the same		periodically send both IPv6 and IPv4 LDP Link Hellos (using the same
	LDP Identifier per section 4) on that interface and be able to		LDP Identifier per section 4) on that interface and be able to
	receive them. This facilitates discovery of IPv6-only, IPv4-only and		receive them. This facilitates discovery of IPv6-only, IPv4-only and
	dual-stack peers on the interface's subnet.		dual-stack peers on the interface's subnet.
	An implementation should prefer sending IPv6 LDP link Hellos		An implementation should prefer sending IPv6 LDP link Hellos
	before sending IPv4 LDP Link Hellos on a dual-stack interface, if		before sending IPv4 LDP Link Hellos on a dual-stack interface, if
	possible.		possible.
	Lastly, the IPv6 and IPv4 LDP Link Hellos must carry the same LDP		Lastly, the IPv6 and IPv4 LDP Link Hellos MUST carry the same LDP
	identifier (assuming per-platform label space usage).		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
	skipping to change at page 11, line 12 ¶		skipping to change at page 11, line 12 ¶
	In line with the 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
	IPv6 and IPv4 LDP, then the LSR must periodically send and receive		IPv6 and IPv4 LDP, then the LSR must periodically send and receive
	both IPv6 and IPv4 LDP Link Hellos.		both IPv6 and IPv4 LDP Link Hellos.
	This ensures successful LDP discovery and subsequent peering using		This ensures successful LDP discovery and subsequent peering using
	the appropriate (address family) transport on a multi-access or		the appropriate (address family) transport on a multi-access or
	broadcast interface (even if there are IPv6-only, IPv4-only and		broadcast interface (even if there are IPv6-only, IPv4-only and
	dual-stack LSRs connected to that interface).		dual-stack LSRs connected to that interface).
	This document allows an LSR to maintain Rx-side Link Hello adjacency		While the LSR receives both IPv4 and IPv6 LDP Link Hello messages on
	for only one address family that has been used for the establishment		the interface, this document however allows an LSR to maintain
	of the LDP session.		Rx-side Link Hello adjacency for the address family that has been
			used for the establishment of the LDP session (either IPv4 or IPv6),
			or to maintain Rx-side Link Hellp adjacency for both IPv4 and IPv6
			address families.
	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 22 ¶		skipping to change at page 14, line 22 ¶
	for this document as well, this document reduces the chances of off-		for this document as well, this document reduces the chances of off-
	link attacks when using IPv6 transport connection by including the		link attacks when using IPv6 transport connection by including the
	use of GTSM procedures [RFC5082].		use of GTSM procedures [RFC5082].
	Moreover, this document allows the use of IPsec [RFC4301] for IPv6		Moreover, this document allows the use of IPsec [RFC4301] for IPv6
	protection, hence, LDP can benefit from the additional security as		protection, hence, LDP can benefit from the additional security as
	specified in [RFC4835] as well as [RFC5920].		specified in [RFC4835] as well as [RFC5920].
	12. Acknowledgments		12. Acknowledgments
	We acknowledge the authors of [RFC5036], since the text in this		We acknowledge the authors of [RFC5036], since some text in this
	document is borrowed from [RFC5036].		document is borrowed from [RFC5036].
	Thanks to Bob Thomas for providing critical feedback to improve this		Thanks to Bob Thomas for providing critical feedback to improve this
	document early on. Thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach		document early on.
	Chen, Shane Amante, Pranjal Dutta, Mustapha Aissaoui, Mark Tinka,
	Tom Petch and Kishore Tiruveedhula for reviewing this document. The		Many thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach Chen, Shane
	authors also acknowledge the help of Manoj Dutta and Vividh Siddha.		Amante, Pranjal Dutta, Mustapha Aissaoui, Matthew Bocci, Mark Tinka,
			Tom Petch, Kishore Tiruveedhula, Manoj Dutta, Vividh Siddha, Qin Wu,
			and Loa Andersson for thoroughly reviewing this document, and
			providing insightful comments and multiple improvements.
	Also, thanks to Andre Pelletier (who brought up the issue about		Also, thanks to Andre Pelletier (who brought up the issue about
	active/passive determination, and helped us craft the appropriate		active/passive determination, and helped us craft the appropriate
	solutions).		solutions).
	This document was prepared using 2-Word-v2.0.template.dot.
	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
	skipping to change at page 16, line 38 ¶		skipping to change at page 16, line 38 ¶
	Requirements for Encapsulating Security Payload (ESP) and		Requirements for Encapsulating Security Payload (ESP) and
	Authentication Header (AH)", RFC 4835, April 2007.		Authentication Header (AH)", RFC 4835, April 2007.
	[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS		[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
	Networks", RFC 5920, July 2010.		Networks", RFC 5920, July 2010.
	[RFC4798] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS		[RFC4798] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS
	Using IPv6 Provider Edge Routers (6PE)", RFC 4798,		Using IPv6 Provider Edge Routers (6PE)", RFC 4798,
	February 2007.		February 2007.
			[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
			Mechanism (GTSM) for the Label Distribution Protocol
			(LDP)", RFC 6720, August 2012
			[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
			Identifier for BGP-4", RFC 6286, June 2011.
	[IPPWCap] Raza, K., "LDP IP and PW Capability", draft-ietf-mpls-ldp-		[IPPWCap] Raza, K., "LDP IP and PW Capability", draft-ietf-mpls-ldp-
	ip-pw-capability, June 2011.		ip-pw-capability, June 2011.
	15. Appendix		Appendix
	15.1. A.1
	It is naive to assume that RFC5036 compliant implementations have		It is naive to assume that RFC5036 compliant implementations have
	supported IPv6 address family (IPv6 FEC processing, in particular)		supported IPv6 address family (IPv6 FEC processing, in particular)
	in label advertisement all along. And if that assumption turned out		in label advertisement all along. And if that assumption turned out
	to be not true, then section 3.4.1.1 of RFC5036 would cause LSRs to		to be not true, then section 3.4.1.1 of RFC5036 would cause LSRs to
	abort processing the entire label mapping message and generate an		abort processing the entire label mapping message and generate an
	error.		error.
	This would result in LDPv6 to be somewhat undeployable in existing		This would result in LDPv6 to be somewhat undeployable in existing
	production networks.		production networks.
End of changes. 12 change blocks.
	19 lines changed or deleted		39 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/