Updates to LDP for IPv6
updates
Extracted elements (28)
A 32-bit LSR Id is used even for IPv6-only deployments because it must be globally unique within the MPLS network regardless of address family. In IPv6-only networks the value need not map to any IPv4 address; it must be derived by means guaranteeing global uniqueness, analogous to the BGP Identifier and OSPFv3 router Id. The value 0.0.0.0 is reserved and prohibited.
IPv4-mapped IPv6 addresses are prohibited in LDP address and label databases because the 6MAN and V6OPS working groups reached consensus against promoting them in routing tables, and RFC 4038 Section 4.2 recommends they never appear on the wire.
The Dual-Stack capability is encoded as a new TLV rather than a flag bit in the Hello message because a flag bit would appear in all Single-stack IPv6 LDP networks and persist indefinitely. The TLV approach limits overhead to deployments that actually use Dual-stack LDP.
Legacy RFC 5036-compliant IPv4-only LSRs may abort processing an entire Label Mapping message if it contains IPv6 FEC-labels, discarding even valid IPv4 FEC-labels. The Dual-Stack capability TLV detection mechanism in Section 7 prevents IPv6 bindings from being sent to such peers, enabling incremental LDPv6 deployment in existing networks.
Some RFC 5036 implementations may non-compliantly tear down the LDP session upon receiving an IPv6 address family in an Address message, rather than gracefully ignoring it per Section 3.5.5.1. The Dual-Stack capability TLV detection in Sections 6 and 7 prevents IPv6 address advertisements from being sent to such peers.
A Dual-stack LSR MUST convey the same transport connection preference (TR field value) in all link and targeted Hellos that advertise the same label space to the same peer and/or on the same interface, ensuring consistent active/passive role determination across multiple Hello adjacencies.
A Dual-stack LSR MUST include the Dual-Stack capability TLV in all of its LDP Hellos and MUST set the TR field to announce its transport connection preference. If the remote preference does not match the local preference, the LSR MUST discard the Hello message and, if a session was already established, MUST send a fatal Notification with status code 'Transport Connection Mismatch' (0x00000032) and reset the session.
A Dual-stack LSR MUST NOT initiate or accept a TCP connection for a new LDP session if it already has an LDPoIPv4 or LDPoIPv6 session for the same LDP Identifier established with the remote LSR, ensuring only one transport connection exists regardless of Hello adjacencies.
A Dual-stack LSR SHOULD prefer establishing an LDPoIPv6 session over an LDPoIPv4 session with a remote Dual-stack LSR. IPv6 LDP Link Hellos SHOULD be transmitted before IPv4 LDP Link Hellos when an interface comes into service or is reconfigured.
An IPv6-enabled LSR (with or without dual-stacking) MUST use a 32-bit (unsigned non-zero integer) LSR Id. For a given address family, an LSR MUST advertise the same transport address in all Hellos that advertise the same label space. The same LDP Identifier (LSR Id and label space id) MUST be used for both IPv4 and IPv6 address families.
An LSR MUST NOT advertise (via an Address message) any IPv4-mapped IPv6 addresses and MUST ignore such addresses if received. An LSR MUST NOT allocate or advertise FEC-label bindings for link-local or IPv4-mapped IPv6 addresses, and MUST ignore such bindings if received.
An LSR MUST NOT send a Hello message containing both IPv4 and IPv6 Transport Address optional objects; there MUST be at most one Transport Address optional object in a Hello, and it MUST match the address family of the IP packet carrying the Hello.
An LSR MUST use a global unicast IPv6 address in the IPv6 Transport Address optional object of outgoing targeted Hellos and MUST discard incoming targeted Hellos that do not contain a global unicast IPv6 address. For Link Hellos, the LSR MUST prefer a global unicast IPv6 address over unique-local or link-local addresses when choosing.
For the Extended Discovery mechanism, link-local IPv6 addresses MUST NOT be used as the source or destination address of targeted LDP Hello packets.
GTSM (RFC 6720) is mandated for LDP Link Hello packets over IPv6, with IPv6 Hop Limit set to 255. GTSM is also recommended for LDPoIPv6 TCP transport connections. This applies only to single-hop LDP peering sessions; multi-hop sessions must statically or dynamically disable GTSM.
If a Dual-stack LSR enabled for a peer does not find the Dual-Stack capability TLV in incoming IPv4 LDP Hello messages, it MUST NOT advertise its local IPv6 addresses or IPv6 FEC-label bindings to that peer, preventing session disruption on legacy IPv4-only LSRs.
If a Dual-stack LSR finds the Dual-Stack capability TLV in the incoming LDP Hello messages, it MUST advertise both IPv4 and IPv6 addresses (via Address message) and FEC-label bindings for both address families to that peer.
If an LSR is configured to change an interface or peer from Single-stack LDP to Dual-stack LDP, it SHOULD use Typed Wildcard FEC procedures (RFC 5918) to request label bindings for the newly enabled address family without resetting the session.
If Dual-stack LDP is enabled on an interface, the LSR MUST transmit both IPv6 and IPv4 LDP Link Hellos using the same LDP Identifier. If Single-stack LDP is enabled, the LSR MUST transmit only Hellos for the enabled address family.
IPv6 LDP Link Hello packets MUST use ff02:0:0:0:0:0:0:2 (link-local scope) as the destination multicast address. Hellos received on other IPv6 all-routers multicast addresses MUST be dropped. The link-local IPv6 address MUST be used as the source IP address.
LDP Link Hello packets over IPv6 MUST have their IPv6 Hop Limit set to 255 and MUST be checked for the same upon receipt before any LDP-specific processing, implementing built-in GTSM per RFC 5082 to protect against off-link attacks.
The LSP mapping rule for IPv6 is updated: if a packet must traverse a particular egress router and there is an LSP with an Address Prefix FEC element that is an IPv4 or IPv6 address of that router, the packet is mapped to that LSP. The original RFC 5036 rule incorrectly required a /32 address, which does not apply to IPv6.
Two LSRs MUST maintain a single LDP session regardless of the number of Link or targeted Hello adjacencies. If the last Hello adjacency for the address family used for the transport connection goes down, the LDP session MUST be reset; otherwise the session MUST stay intact.
To handle duplicate link-local IPv6 next-hop addresses used by multiple peers, the LDP peer mapping logic is extended to use both the IP routing next-hop address (via the LDP peer address database from Address messages) and the IP routing next-hop interface (via the Hello adjacency/interface database from Hello messages) to uniquely identify LDP peers.
Three new IANA allocations are made: (1) 'Dual-Stack capability' TLV code point 0x0701 in the LDP 'TLV Type Name Space' registry; (2) 'Transport Connection Mismatch' status code 0x00000032 with E bit=1 in the 'Status Code Name Space' registry; (3) 'Dual-Stack Noncompliance' status code 0x00000033 with E bit=1 in the same registry.
This document reduces the chances of off-link attacks on IPv6 LDP by mandating GTSM for LDP Link Hellos and recommending it for LDPoIPv6 TCP sessions. IPsec (RFC 4301) may also be used for IPv6 LDP protection per RFC 7321 and RFC 5920. No new security procedures beyond RFC 5036 are introduced.
If the Dual-Stack capability TLV is absent and only IPv4 Hellos are received, the neighbor is treated as a legacy IPv4-only LSR and LDPoIPv4 is established; if IPv6 Hellos subsequently arrive, the session is reset with 'Dual-Stack Noncompliance' (0x00000033). If only IPv6 Hellos are received, LDPoIPv6 is established; later IPv4 Hellos also trigger noncompliance reset. If both IPv4 and IPv6 Hellos arrive without the TLV, the neighbor is noncompliant and no session is allowed.
The Dual-Stack capability TLV is a new 32-bit optional Hello parameter with code point 0x0701. Bits 0-1 are U=1 and F=0. The TR (Transport Connection Preference) field is 4 bits: 0100 for LDPoIPv4, 0110 for LDPoIPv6 (default). Remaining bits are Reserved/MBZ.