Updates to LDP for IPv6
draft-ietf-mpls-ldp-ipv6-16
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7552.
|
|
---|---|---|---|
Authors | Rajiv Asati , Carlos Pignataro , Vishwas Manral , Rajiv Papneja | ||
Last updated | 2015-02-11 | ||
Replaces | draft-manral-mpls-ldp-ipv6 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Associated WG milestone |
|
||
Document shepherd | Loa Andersson | ||
Shepherd write-up | Show Last changed 2014-12-04 | ||
IESG | IESG state | Became RFC 7552 (Proposed Standard) | |
Consensus boilerplate | Yes | ||
Telechat date |
(None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass. |
||
Responsible AD | Adrian Farrel | ||
Send notices to | mpls-chairs@ietf.org, draft-ietf-mpls-ldp-ipv6@ietf.org, vishwas@ionosnetworks.com | ||
IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-mpls-ldp-ipv6-16
This last point helps to maintain forward compatibility (no need to require this TLV in case of IPv6 Single-stack LDP). 7.2. Label Distribution An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings for link-local or IPv4-mapped IPv6 addresses (defined in section 2.5.5.2 of [RFC4291]), and ignore such bindings, if ever received. Please see Appendix A.3. If an LSR is enabled with Single-stack LDP for any peer, then it MUST advertise (via Label Mapping message) FEC-Label bindings for the enabled address family to that peer, and process received FEC- Label bindings for the enabled address family from that peer. If an LSR is enabled with Dual-stack LDP for a peer and 1. Is NOT able to find the Dual-stack capability TLV in the incoming IPv4 LDP hello messages from that peer, then the LSR MUST NOT advertise IPv6 FEC-label bindings to the peer (even if IP capability negotiation for IPv6 address family was done). 2. Is able to find the Dual-stack capability in the incoming IPv4 (or IPv6) LDP Hello messages from that peer, then it MUST advertise FEC-Label bindings for both IPv4 and IPv6 address families to that peer. 3. Is NOT able to find the Dual-stack capability in the incoming IPv6 LDP Hello messages, then it MUST advertise FEC-Label bindings for IPv6 address families to that peer. This last point helps to maintain forward compatibility (no need to require this TLV for IPv6 Single-stack LDP). An LSR MAY further constrain the advertisement of FEC-label bindings for a particular address family by negotiating the IP Capability for a given address family, as specified in [IPPWCap] document. This allows an LSR pair to neither advertise nor receive the undesired FEC-label bindings on a per address family basis to a peer. If an LSR is configured to change an interface or peer from Single- stack LDP to Dual-stack LDP, then an LSR SHOULD use Typed Wildcard FEC procedures [RFC5918] to request the label bindings for the enabled address family. This helps to relearn the label bindings that may have been discarded before without resetting the session. Asati, et. al Expires August 11, 2015 [Page 16] Internet-Draft draft-ietf-mpls-ldp-ipv6 February 11, 2015 8. LDP Identifiers and Duplicate Next Hop Addresses RFC5036 section 2.7 specifies the logic for mapping the IP routing next-hop (of a given FEC) to an LDP peer so as to find the correct label entry for that FEC. The logic involves using the IP routing next-hop address as an index into the (peer Address) database (which is populated by the Address message containing mapping between each peer's local addresses and its LDP Identifier) to determine the LDP peer. However, this logic is insufficient to deal with duplicate IPv6 (link-local) next-hop addresses used by two or more peers. The reason is that all interior IPv6 routing protocols (can) use link- local IPv6 addresses as the IP routing next-hops, and 'IPv6 Addressing Architecture [RFC4291]' allows a link-local IPv6 address to be used on more than one links. Hence, this logic is extended by this specification to use not only the IP routing next-hop address, but also the IP routing next-hop interface to uniquely determine the LDP peer(s). The next-hop address-based LDP peer mapping is to be done through LDP peer address database (populated by Address messages received from the LDP peers), whereas next-hop interface-based LDP peer mapping is to be done through LDP hello adjacency/interface database (populated by hello messages received from the LDP peers). This extension solves the problem of two or more peers using the same link-local IPv6 address (in other words, duplicate peer addresses) as the IP routing next-hops. Lastly, for better scale and optimization, an LSR may advertise only the link-local IPv6 addresses in the Address message, assuming that the peer uses only the link-local IPv6 addresses as static and/or dynamic IP routing next-hops. 9. LDP TTL Security This document recommends enabling Generalized TTL Security Mechanism (GTSM) for LDP, as specified in [RFC6720], for the LDP/TCP transport connection over IPv6 (i.e. LDPoIPv6). The GTSM inclusion is intended to automatically protect IPv6 LDP peering session from off-link attacks. Asati, et. al Expires August 11, 2015 [Page 17] Internet-Draft draft-ietf-mpls-ldp-ipv6 February 11, 2015 [RFC6720] allows for the implementation to statically (configuration) and/or dynamically override the default behavior (enable/disable GTSM) on a per-peer basis. Such a configuration an option could be set on either LSR (since GTSM negotiation would ultimately disable GTSM between LSR and its peer(s)). LDP Link Hello packets MUST have their IPv6 Hop Limit set to 255, and be checked for the same upon receipt before any further processing, as per section 3 of [RFC5082]. 10. IANA Considerations This document defines a new optional parameter for the LDP Hello Message and two new status codes for the LDP Notification Message. The 'Dual-Stack capability' parameter requires a code point from the TLV Type Name Space. IANA is requested to allocated a code point from the IETF Consensus range 0x0700-0x07ff for the 'Dual-Stack capability' TLV. The 'Transport Connection Mismatch' status code requires a code point from the Status Code Name Space. IANA is requested to allocate a code point from the IETF Consensus range and mark the E bit column with a '1'. The 'Dual-Stack Non-Compliance' status code requires a code point from the Status Code Name Space. IANA is requested to allocate a code point from the IETF Consensus range and mark the E bit column with a '1'. 11. Security Considerations The extensions defined in this document only clarify the behavior of LDP, they do not define any new protocol procedures. Hence, this document does not add any new security issues to LDP. While the security issues relevant for the [RFC5036] are relevant for this document as well, this document reduces the chances of off- link attacks when using IPv6 transport connection by including the use of GTSM procedures [RFC5082]. Please see section 9 for LDP TTL Security details. Asati, et. al Expires August 11, 2015 [Page 18] Internet-Draft draft-ietf-mpls-ldp-ipv6 February 11, 2015 Moreover, this document allows the use of IPsec [RFC4301] for IPv6 protection, hence, LDP can benefit from the additional security as specified in [RFC7321] as well as [RFC5920]. 12. Acknowledgments We acknowledge the authors of [RFC5036], since some text in this document is borrowed from [RFC5036]. Thanks to Bob Thomas for providing critical feedback to improve this document early on. Many thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach Chen, Shane Amante, Pranjal Dutta, Mustapha Aissaoui, Matthew Bocci, Mark Tinka, Tom Petch, Kishore Tiruveedhula, Manoj Dutta, Vividh Siddha, Qin Wu, Simon Perreault, Brian E Carpenter, Santosh Esale, Danial Johari and Loa Andersson for thoroughly reviewing this document, and providing insightful comments and multiple improvements. This document was prepared using 2-Word-v2.0.template.dot. 13. Additional Contributors The following individuals contributed to this document: Kamran Raza Cisco Systems, Inc. 2000 Innovation Drive Kanata, ON K2K-3E8, Canada Email: skraza@cisco.com Nagendra Kumar Cisco Systems, Inc. SEZ Unit, Cessna Business Park, Bangalore, KT, India Email: naikumar@cisco.com Asati, et. al Expires August 11, 2015 [Page 19] Internet-Draft draft-ietf-mpls-ldp-ipv6 February 11, 2015 Andre Pelletier Cisco Systems, Inc. 2000 Innovation Drive Kanata, ON K2K-3E8, Canada Email: apelleti@cisco.com Asati, et. al Expires August 11, 2015 [Page 20] Internet-Draft draft-ietf-mpls-ldp-ipv6 February 11, 2015 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 4291, February 2006. [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP Specification", RFC 5036, October 2007. [RFC5082] Pignataro, C., Gill, V., Heasley, J., Meyer, D., and Savola, P., "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. [RFC5918] Asati, R., Minei, I., and Thomas, B., "Label Distribution Protocol (LDP) 'Typed Wildcard Forward Equivalence Class (FEC)", RFC 5918, October 2010. 14.2. Informative References [RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet Protocol", RFC 4301, December 2005. [RFC7321] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 7321, April 2007. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC4798] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007. [IPPWCap] Raza, K., "LDP IP and PW Capability", draft-ietf-mpls-ldp- ip-pw-capability, October 2014. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. Asati, et. al Expires August 11, 2015 [Page 21] Internet-Draft draft-ietf-mpls-ldp-ipv6 February 11, 2015 [RFC6286] E. Chen, and J. Yuan, "Autonomous-System-Wide Unique BGP Identifier for BGP-4", RFC 6286, June 2011. [RFC6720] R. Asati, and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)", RFC 6720, August 2012. [RFC4038] M-K. Shin, Y-G. Hong, J. Hagino, P. Savola, and E. M. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005. [RFC7439] W. George, and C. Pignataro, "Gap Analysis for Operating IPv6-Only MPLS Networks", RFC 7439, January 2015. Asati, et. al Expires August 11, 2015 [Page 22] Internet-Draft draft-ietf-mpls-ldp-ipv6 February 11, 2015 Appendix A. A.1. LDPv6 and LDPv4 Interoperability Safety Net It is not safe to assume that RFC5036 compliant implementations have supported handling IPv6 address family (IPv6 FEC label) in Label Mapping message all along. If a router upgraded with this specification advertised both IPv4 and IPv6 FECs in the same label mapping message, then an IPv4-only peer (not knowing how to process such a message) may abort processing the entire label mapping message (thereby discarding even the IPv4 label FECs), as per the section 3.4.1.1 of RFC5036. This would result in LDPv6 to be somewhat undeployable in existing production networks. The change proposed in section 7 of this document provides a good safety net and makes LDPv6 incrementally deployable without making any such assumption on the routers' support for IPv6 FEC processing in current production networks. A.2. Accommodating Non-RFC5036-compliant implementations It is not safe to assume that implementations have been RFC5036 compliant in gracefully handling IPv6 address family (IPv6 Address List TLV) in Address message all along. If a router upgraded with this specification advertised IPv6 addresses (with or without IPv4 addresses) in Address message, then an IPv4-only peer (not knowing how to process such a message) may not follow section 3.5.5.1 of RFC5036, and tear down the LDP session. This would result in LDPv6 to be somewhat undeployable in existing production networks. The changes proposed in section 6 and 7 of this document provides a good safety net and makes LDPv6 incrementally deployable without making any such assumption on the routers' support for IPv6 FEC processing in current production networks. Asati, et. al Expires August 11, 2015 [Page 23] Internet-Draft draft-ietf-mpls-ldp-ipv6 February 11, 2015 A.3. Why prohibit IPv4-mapped IPv6 addresses in LDP Per discussion with 6MAN and V6OPS working groups, the overwhelming consensus was to not promote IPv4-mapped IPv6 addresses appear in the routing table, as well as in LDP (address and label) databases. Also, [RFC4038] section 4.2 suggests that IPv4-mapped IPv6 addressed packets should never appear on the wire. A.4. Why 32-bit value even for IPv6 LDP Router ID The first four octets of the LDP identifier, the 32-bit LSR Id (e.g. (i.e. LDP Router Id), identify the LSR and is a globally unique value within the MPLS network. This is regardless of the address family used for the LDP session. Please note that 32-bit LSR Id value would not map to any IPv4- address in an IPv6 only LSR (i.e., single stack), nor would there be an expectation of it being IP routable, nor DNS-resolvable. In IPv4 deployments, the LSR Id is typically derived from an IPv4 address, generally assigned to a loopback interface. In IPv6 only deployments, this 32-bit LSR Id must be derived by some other means that guarantees global uniqueness within the MPLS network, similar to that of BGP Identifier [RFC6286] and OSPF router ID [RFC5340]. This document reserves 0.0.0.0 as the LSR Id, and prohibits its usage with IPv6, in line with OSPF router Id in OSPF version 3 [RFC5340]. Asati, et. al Expires August 11, 2015 [Page 24] Internet-Draft draft-ietf-mpls-ldp-ipv6 February 11, 2015 Author's Addresses Vishwas Manral Hewlet-Packard, Inc. 19111 Pruneridge Ave., Cupertino, CA, 95014 Phone: 408-447-1497 Email: vishwas.manral@hp.com Rajiv Papneja Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 Phone: +1 571 926 8593 EMail: rajiv.papneja@huawei.com Rajiv Asati Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709-4987 Email: rajiva@cisco.com Carlos Pignataro Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709-4987 Email: cpignata@cisco.com Asati, et. al Expires August 11, 2015 [Page 25]