Skip to main content

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
May 2015
++ Progress draft-ietf-mpls-ldp-ipv6 for publication to publication
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]