< draft-ietf-mpls-ldp-ipv6-12.txt   draft-ietf-mpls-ldp-ipv6-13.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: August 2014 Expires: January 2015 Hewlett-Packard, Inc.
Hewlett-Packard, Inc.
Rajiv Papneja Rajiv Papneja
Huawei Huawei
Carlos Pignataro Carlos Pignataro
Cisco Cisco
February 5, 2014 July 3, 2014
Updates to LDP for IPv6 Updates to LDP for IPv6
draft-ietf-mpls-ldp-ipv6-12 draft-ietf-mpls-ldp-ipv6-13
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 August 5, 2014. This Internet-Draft will expire on January 3, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 31
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
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Scope.....................................................4 1.1. Topology Scenarios for Dual-Stack Environment.............4
1.1.1. Topology Scenarios...................................4 1.2. Single-hop vs. Multi-hop LDP Peering......................5
1.1.2. LDP TTL Security.....................................5
2. Specification Language.........................................6 2. Specification Language.........................................6
3. LSP Mapping....................................................6 3. LSP Mapping....................................................6
4. LDP Identifiers................................................7 4. LDP Identifiers................................................7
5. Peer Discovery.................................................7 5. Neighbor Discovery.............................................7
5.1. Basic Discovery Mechanism.................................8 5.1. Basic Discovery Mechanism.................................8
5.1.1. Maintaining Hello Adjacencies........................9 5.1.1. Maintaining Hello Adjacencies........................9
5.2. Extended Discovery Mechanism..............................9 5.2. Extended Discovery Mechanism..............................9
6. LDP Session Establishment and Maintenance......................9 6. LDP Session Establishment and Maintenance......................9
6.1. Transport connection establishment........................9 6.1. Transport connection establishment........................9
6.2. LDP Sessions Maintenance.................................11 6.1.1. Determining Transport connection Roles..............11
7. Label Distribution............................................12 6.2. LDP Sessions Maintenance.................................13
8. LDP Identifiers and Next Hop Addresses........................12 7. Address Distribution..........................................14
9. LDP TTL Security..............................................13 8. Label Distribution............................................14
10. IANA Considerations..........................................14 9. LDP Identifiers and Duplicate Next Hop Addresses..............15
11. Security Considerations......................................14 10. LDP TTL Security.............................................16
12. Acknowledgments..............................................14 11. IANA Considerations..........................................16
13. Additional Contributors......................................14 12. Security Considerations......................................16
14. References...................................................16 13. Acknowledgments..............................................17
14.1. Normative References....................................16 14. Additional Contributors......................................17
14.2. Informative References..................................16 15. References...................................................18
Appendix A.......................................................18 15.1. Normative References....................................18
A.1. LDPv6 and LDPv4 Interoperability Safety Net..............18 15.2. Informative References..................................18
A.2. Why 32-bit value even for IPv6 LDP Router ID.............18 Appendix A.......................................................20
Author's Addresses...............................................19 A.1. LDPv6 and LDPv4 Interoperability Safety Net..............20
A.2. Why 32-bit value even for IPv6 LDP Router ID.............20
A.3. Why prohibit IPv4-mapped IPv6 addresses in LDP...........20
Author's Addresses...............................................22
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 deficiency (or
regards to IPv6 usage: lacks details) in regards to IPv6 usage (with or without IPv4):
1) LSP Mapping: No rule defined for mapping a particular packet to a 1) LSP Mapping: No rule for mapping a particular packet to a
particular LSP that has an Address Prefix FEC element containing particular LSP that has an Address Prefix FEC element containing
IPv6 address of the egress router IPv6 address of the egress router
2) LDP Identifier: No details specific to IPv6 usage 2) LDP Identifier: No details specific to IPv6 usage
3) LDP Discovery: No details for using a particular IPv6 destination 3) LDP Discovery: No details for using a particular IPv6 destination
(multicast) address or the source address (with or without IPv4 (multicast) address or the source address (with or without IPv4
co-existence) co-existence)
4) LDP Session establishment: No rule for handling both IPv4 and 4) LDP Session establishment: No rule for handling both IPv4 and
IPv6 transport address optional objects in a Hello message, and IPv6 transport address optional objects in a Hello message, and
subsequently two IPv4 and IPv6 transport connections subsequently two IPv4 and IPv6 transport connections
5) LDP Label Distribution: No rule for advertising IPv4 or/and IPv6 5) LDP Address Distribution: No rule for advertising IPv4 or/and
FEC-label bindings over an LDP session, and denying the co- IPv6 FEC-Address bindings over an LDP session
6) LDP Label Distribution: No rule for advertising IPv4 or/and IPv6
FEC-label bindings over an LDP session, and for handling the co-
existence of IPv4 and IPv6 FEC Elements in the same FEC TLV existence of IPv4 and IPv6 FEC Elements in the same FEC TLV
6) Next Hop Address & LDP Identifier: No rule for accommodating the 7) Next Hop Address Resolution: No rule for accommodating the usage
usage of duplicate link-local IPv6 addresses of duplicate link-local IPv6 addresses
7) LDP TTL Security: No rule for built-in Generalized TTL Security 8) LDP TTL Security: No rule for built-in Generalized TTL Security
Mechanism (GTSM) in LDP Mechanism (GTSM) in LDP with IPv6 (this is a deficiency in
RFC6720)
This document addresses the above deficiencies by specifying the This document addresses the above deficiencies by specifying the
desired behavior/rules/details for using LDP in IPv6 enabled desired behavior/rules/details for using LDP in IPv6 enabled
networks (IPv6-only or Dual-stack networks). networks (IPv6-only or Dual-stack networks).
Note that this document updates RFC5036. Note that this document updates RFC5036 and RFC6720.
1.1. Scope
1.1.1. Topology Scenarios 1.1. Topology Scenarios for Dual-Stack Environment
Two LSRs may involve basic and/or extended LDP discovery in IPv6 Two LSRs may involve basic and/or extended LDP discovery in IPv6
and/or IPv4 address-families in various topology scenarios. and/or IPv4 address-families in various topology scenarios.
This document addresses the following 3 topology scenarios in which This document addresses the following 3 topology scenarios in which
the LSRs may be connected via one or more dual-stack interfaces the LSRs may be connected via one or more dual-stack interfaces
(figure 1), or one or more single-stack interfaces (figure 2 and (figure 1), or one or more single-stack interfaces (figure 2 and
figure 3): figure 3):
R1------------------R2 R1------------------R2
skipping to change at page 5, line 30 skipping to change at page 5, line 30
This document also addresses the scenario in which the LSRs do This document also addresses the scenario in which the LSRs do
extended discovery in IPv6 and/or IPv4 address-families: extended discovery in IPv6 and/or IPv4 address-families:
IPv4 IPv4
R1-------------------R2 R1-------------------R2
IPv6 IPv6
Figure 4 LSRs involving IPv4 and IPv6 address-families Figure 4 LSRs involving IPv4 and IPv6 address-families
1.1.2. LDP TTL Security 1.2. Single-hop vs. Multi-hop LDP Peering
LDP TTL Security mechanism specified by this document applies only LDP TTL Security mechanism specified by this document applies only
to single-hop LDP peering sessions, but not to multi-hop LDP peering to single-hop LDP peering sessions, but not to multi-hop LDP peering
sessions, in line with Section 5.5 of [RFC5082] that describes sessions, in line with Section 5.5 of [RFC5082] that describes
Generalized TTL Security Mechanism (GTSM). Generalized TTL Security Mechanism (GTSM).
As a consequence, any LDP feature that relies on multi-hop LDP As a consequence, any LDP feature that relies on multi-hop LDP
peering session would not work with GTSM and will warrant peering session would not work with GTSM and will warrant
(statically or dynamically) disabling GTSM. Please see section 8. (statically or dynamically) disabling GTSM. Please see section 10.
2. Specification Language 2. Specification Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Abbreviations: Abbreviations:
LDP - Label Distribution Protocol LDP - Label Distribution Protocol
skipping to change at page 7, line 17 skipping to change at page 7, line 17
length) address. Hence, it is reasonable to say IPv4 or IPv6 address length) address. Hence, it is reasonable to say IPv4 or IPv6 address
instead of /32 or /128 addresses as shown below in the updated rule: instead of /32 or /128 addresses as shown below in the updated rule:
"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 an IPv4 or IPv6 address of that router, then the packet is that is an IPv4 or IPv6 address of that router, then the packet is
mapped to that LSP." mapped to that LSP."
4. LDP Identifiers 4. LDP Identifiers
Section 2.2.2 of [RFC5036] specifies formulating at least one LDP In line with section 2.2.2 of [RFC5036], this document specifies the
Identifier, however, it doesn't provide any consideration in case of usage of 32-bit (unsigned non-zero integer) LSR Id on an IPv6
IPv6 (with or without dual-stacking). enabled LSR (with or without dual-stacking).
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. Hence, this document preserves the
usage of 32-bit (unsigned non-zero integer) LSR Id on an IPv6 only
LSR.
This document also qualifies the first sentence of last paragraph of This document also 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: updates that sentence to the following:
"For a given address family, an LSR MUST advertise the same "For a given address family, an LSR MUST advertise the same
transport address in all Hellos that advertise the same label transport address in all Hellos that advertise the same label
space." space."
This rightly enables the per-platform label space to be shared This rightly enables the per-platform label space to be shared
between IPv4 and IPv6. between IPv4 and IPv6.
In summary, this document allows the usage of a common LDP In summary, this document mandates the usage of a common LDP
identifier (same LSR Id aka LDP Router Id as well as a common Label identifier (same LSR Id aka LDP Router Id as well as a common Label
space id) for both IPv4 and IPv6 on a dual-stack LSR. space id) for both IPv4 and IPv6 address families on a dual-stack
LSR.
5. Peer Discovery 5. Neighbor Discovery
If an LSR is enabled with both IPv4 and IPv6 LDP, then the LSR MUST If an LSR is enabled with dual-stack LDP (e.g. LDP enabled in both
include the same LDP Identifier (assuming per-platform label space IPv6 and IPv4 address families), then the LSR MUST advertise both
usage) in both IPv6 and IPv4 LDP Link or targeted Hellos. IPv6 and IPv4 LDP Link or targeted Hellos and include the same LDP
Identifier (assuming per-platform label space usage) in them.
If an LSR is enabled with single-stack LDP (e.g. LDP enabled in
either IPv6 or IPv4 address family), then the LSR MUST advertise
either IPv6 or IPv4 LDP Link or targeted Hellos respectively.
5.1. Basic Discovery Mechanism 5.1. Basic Discovery Mechanism
Section 2.4.1 of [RFC5036] defines the Basic Discovery mechanism for Section 2.4.1 of [RFC5036] defines the Basic Discovery mechanism for
directly connected LSRs. Following this mechanism, LSRs periodically directly connected LSRs. Following this mechanism, LSRs periodically
send LDP Link Hellos destined to "all routers on this subnet" group send LDP Link Hellos destined to "all routers on this subnet" group
multicast IP address. multicast IP address.
Interesting enough, per the IPv6 addressing architecture [RFC4291], Interesting enough, per the IPv6 addressing architecture [RFC4291],
IPv6 has three "all routers on this subnet" multicast addresses: IPv6 has three "all routers on this subnet" multicast addresses:
skipping to change at page 8, line 40 skipping to change at page 8, line 40
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, be checked for the same upon receipt (before any LDP to 255, be checked for the same upon receipt (before any LDP
specific processing) and be handled as specified in Generalized TTL specific processing) and be handled as specified in Generalized TTL
Security Mechanism (GTSM) section 3 of [RFC5082]. The built-in Security Mechanism (GTSM) section 3 of [RFC5082]. The built-in
inclusion of GTSM automatically protects IPv6 LDP from off-link inclusion of GTSM automatically protects IPv6 LDP from off-link
attacks. 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 IPv6 and IPv4 LDP), then the LSR MUST (e.g. LDP enabled in both IPv6 and IPv4 address families), then the
periodically send both IPv6 and IPv4 LDP Link Hellos (using the same LSR MUST periodically send both IPv6 and IPv4 LDP Link Hellos (using
LDP Identifier per section 4) on that interface and be able to the same LDP Identifier per section 4) on that interface and be able
receive them. This facilitates discovery of IPv6-only, IPv4-only and to receive them. This facilitates discovery of IPv6-only, IPv4-only
dual-stack peers on the interface's subnet and ensures successful and dual-stack peers on the interface's subnet and ensures
subsequent peering using the appropriate (address family) transport successful subsequent peering using the appropriate (address family)
on a multi-access or broadcast interface. transport on a multi-access or broadcast interface.
An implementation MUST send IPv6 LDP link Hellos before sending IPv4 An implementation MUST send IPv6 LDP link Hellos before sending IPv4
LDP Link Hellos on a dual-stack interface. LDP Link Hellos on a dual-stack interface.
5.1.1. Maintaining Hello Adjacencies 5.1.1. Maintaining Hello Adjacencies
In case of dual-stack LDP interface, the LSR SHOULD maintain link In case of dual-stack LDP interface (e.g. LDP enabled in both IPv6
Hello adjacencies for both IPv4 and IPv6 address families. This and IPv4 address families), the LSR SHOULD maintain link Hello
document, however, allows an LSR to maintain Rx-side Link Hello adjacencies for both IPv4 and IPv6 address families. This document,
adjacency for the address family that has been used for the however, allows an LSR to maintain Rx-side Link Hello adjacency for
establishment of the LDP session (either IPv4 or IPv6). the address family that has been used for the establishment of the
LDP session (either IPv4 or IPv6).
5.2. Extended Discovery Mechanism 5.2. Extended Discovery Mechanism
The extended discovery mechanism (defined in section 2.4.2 of The extended discovery mechanism (defined in section 2.4.2 of
[RFC5036]), in which the targeted LDP Hellos are sent to a pre- [RFC5036]), in which the targeted LDP Hellos are sent to a pre-
configured (unicast) destination IPv6 address, requires only one configured (unicast) destination IPv6 address, requires only one
IPv6 specific consideration: the link-local IPv6 addresses MUST NOT IPv6 specific consideration: the link-local IPv6 addresses MUST NOT
be used as the targeted LDP hello packet's source or destination be used as the targeted LDP hello packet's source or destination
addresses. addresses.
skipping to change at page 11, line 4 skipping to change at page 11, line 4
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
regardless of IPv6 or/and IPv4 Hello adjacencies presence regardless of IPv6 or/and IPv4 Hello adjacencies presence
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 is able to determine the LDP session with a remote LSR, if it is able to determine the
dual-stack presence (e.g. they have both IPv4 and IPv6 Hello IPv6 presence (e.g. IPv6 Hello adjacency), by following the
adjacencies). This applies to the section 2.5.2 of RFC5036. 'transport connection role' determination logic in section
6.1.1.
Each LSR, assuming an active role for whichever address 6.1.1. Determining Transport connection Roles
family(s), SHOULD enforce the LDP/TCP connection over IPv6
preference for a time-period (default value is 5 seconds), Section 2.5.2 of [RFC5036] specifies the rules for determining
after which LDP/TCP connection over IPv4 SHOULD be attempted. active/passive roles in setting up TCP connection. These rules are
This enforcement is independent of whether the LSR is assuming clear for a single-stack (IPv4 or IPv6) LDP, but not for a dual-
the active role for IPv4. This timer is started upon receiving stack (IPv4 and IPv6) LDP, in which an LSR may assume different
the first (IPv4 or IPv6) Hello from the neighbor. roles for different address families, causing LDP session to not get
established.
To ensure deterministic transport connection (active/passive) role
for dual-stack LDP peering, this document specifies that the LSR
convey its transport connection preference in every LDP Hello
message. A new optional parameter, encoded as a TLV, (section 3.5.2
of RFC5036) is defined as follows (for Hello Message):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| IPv4orIPv6 Preference | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TR | Reserved | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 IPv4 or IPv6 Transport Preference TLV
Where:
U and F bits: 1 and 0 (as specified by RFC5036)
IPv4orIPv6 Preference: TLV code point for IPv4 or IPv6 Preference
(to be assigned by IANA).
TR, Transport Preference
00: IPv4
01: IPv6 (default value)
Reserved
This field is reserved. It MUST be set to zero on
transmission and ignored on receipt.
A dual-stack LDP enabled LSR (capable of supporting both IPv4 and
IPv6 transports for LDP) MUST include "IPv4orIPv6 Transport
Preference" optional parameter in all of its LDP Hellos, and MUST
set the "TR" field to announce its preference for either IPv4 or
IPv6 transport connection. The default preference is IPv6.
Upon receiving the hello message with this TLV, a dual-stack capable
receiving LSR MUST do the following:
1. If it understands the TLV, and if neighbor's preference does
not match with the local preference, then it discards the hello
(and no adjacency is formed) and logs an error.
2. If it understands the TLV, and if neighbor's preference matches
with the local preference, then:
a) If TR=0 (IPv4), then determine the active/passive roles
for TCP connection using IPv4 transport address as defined
in section 2.5.2 of RFC 5036.
b) If TR=1 (IPv6), then determine the active/passive roles
for TCP connection by comparing the LSR Id part of the LDP
Identifiers of LSRs.
The LSR with higher LSR Id MUST assume the active role and
other LSR MUST assume the passive role for the IPv6 TCP
connection.
3. If it does not understand the TLV, then it MUST silently
discard this TLV and process the rest of the Hello message.
If an LSR receives the hello message without the "IPv4orIPv6
Transport Preference" TLV, then it MUST proceed with session
establishment using single-stack rules, as per section 2.5.2 of RFC
5036.
An LSR MUST convey the same transport connection preference ("TR"
field) in all (link and targeted) Hellos that advertise the same
label space to the same peer and/or on same interface. This ensures
that two LSRs linked by multiple Hello adjacencies using the same
label spaces play the same connection establishment role for each
adjacency.
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.
Note - An alternative to Capability TLV could be a new Flag value in
LDP Hello message, however, it will get used even in a single-stack
IPv6 scenarios and linger on forever, even though dual-stack will
not. Hence, this alternative is discarded.
6.2. LDP Sessions Maintenance 6.2. LDP Sessions Maintenance
This document specifies that two LSRs maintain a single LDP session This document specifies that two LSRs maintain a single LDP session
regardless of number of Link or Targeted Hello adjacencies between regardless of number of Link or Targeted Hello adjacencies between
them, as described in section 6.1. This is independent of whether: them, as described in section 6.1. This is independent of whether:
- they are connected via a dual-stack LDP enabled interface or via - they are connected via a dual-stack LDP enabled interface(s) or
two single-stack LDP enabled interfaces; via two (or more) single-stack LDP enabled interfaces;
- a single-stack interface is converted to a dual-stack interface - a single-stack LDP enabled interface is converted to a dual-stack
(e.g. figure 1) on either LSR; LDP enabled interface (e.g. figure 1) on either LSR;
- an additional single-stack or dual-stack interface is added or - an additional single-stack or dual-stack LDP enabled interface is
removed between two LSRs (e.g. figure 2). added or removed between two LSRs (e.g. figure 2).
The procedures defined in section 6.1 SHOULD result in preferring The procedures defined in section 6.1 SHOULD result in preferring
LDPoIPv6 session only after the loss of an existing LDP session LDPoIPv6 session only after the loss of an existing LDP session
(because of link failure, node failure, reboot etc.). (because of link failure, node failure, reboot etc.).
If the last hello adjacency for a given address family goes down If the last hello adjacency for a given address family goes down
(e.g. due to dual-stack interfaces being converted into a single- (e.g. due to dual-stack LDP enabled interfaces being converted into
stack interfaces on one LSR etc.), and that address family is the a single-stack LDP enabled interfaces on one LSR etc.), and that
same as the one used in the transport connection, then the transport address family is the same as the one used in the transport
connection (LDP session) SHOULD be reset. Otherwise, the LDP session connection, then the transport connection (LDP session) SHOULD be
SHOULD stay intact. reset. Otherwise, the LDP session SHOULD stay intact.
If the LDP session is torn down for whatever reason (LDP disabled If the LDP session is torn down for whatever reason (LDP disabled
for the corresponding transport, hello adjacency expiry etc.), then for the corresponding transport, hello adjacency expiry etc.), then
the LSRs SHOULD initiate establishing a new LDP session as per the the LSRs SHOULD initiate establishing a new LDP session as per the
procedures described in section 6.1 of this document along with procedures described in section 6.1 of this document.
RFC5036.
7. Label Distribution 7. Address Distribution
If an LSR is enabled with dual-stack LDP (i.e. LDP in both IPv4 and
IPv6 address families) for any (discovered or targeted) peer, then
it MUST advertise (via ADDRESS message) its local IPv4 and IPv6
addresses to that peer by default, independent of the transport
connection (address family) used for that peering.
If an LSR, compliant with this specification, is enabled with
single-stack LDP (i.e. LDP in either IPv6 or IPv4 address family)
for any (discovered or targeted) peer, then it MUST advertise (via
ADDRESS message) its local IP addresses as per the enabled address
family by default, and SHOULD accept a received Address message
containing both IPv4 and IPv6 addresses.
8. Label Distribution
An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings
for link-local IPv6 address, and ignore such bindings, if ever for link-local or IPv4-mapped IPv6 addresses (defined in section
received. An LSR MUST treat the IPv4-mapped IPv6 address, defined in 2.5.5.2 of [RFC4291]), and ignore such bindings, if ever received.
section 2.5.5.2 of [RFC4291], the same as that of a global IPv6 Please see Appendix A.3.
address and not mix it with the 'corresponding' IPv4 address.
Additionally, to ensure backward compatibility (and interoperability Additionally, to ensure backward compatibility (and interoperability
with IPv4-only LDP implementations) in light of section 3.4.1.1 of with IPv4-only LDP implementations) in light of section 3.4.1.1 of
RFC5036, as rationalized in the Appendix section A.1 later, this RFC5036, as rationalized in the Appendix section A.1 later, this
document specifies that - document specifies that -
1. An LSR MUST NOT send a label mapping message with a FEC TLV 1. An LSR MUST NOT send a label mapping message with a FEC TLV
containing two or more Prefix FEC Elements of different address containing two or more Prefix FEC Elements of different address
families. This means that a FEC TLV in the label mapping families. This means that a FEC TLV in the label mapping
message must contain all the Prefix FEC Elements belonging to message must contain all the Prefix FEC Elements belonging to
IPv6 address family or IPv4 address family, but not both. IPv6 address family or IPv4 address family, but not both.
An LSR may constrain the advertisement of FEC-label bindings for a If an LSR is enabled with dual-stack LDP (i.e. LDP in both IPv4 and
particular address family by negotiating the IP Capability for a IPv6 address families) for any peer, then it MUST advertise the FEC-
given AFI, as specified in [IPPWCap] document. This allows an LSR Label bindings for both IPv4 and IPv6 address families to that peer.
pair to neither advertise nor receive the undesired FEC-label However, an LSR MAY constrain the advertisement of FEC-label
bindings on a per AFI basis. 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.
8. LDP Identifiers and Next Hop Addresses If an LSR is configured to move an interface or peer from single-
stack (IPv6 or IPv4 address family) to dual-stack LDP (IPv6 and IPv4
address families), then an LSR SHOULD use Typed Wildcard FEC
procedures [RFC5918] to request the FEC-label bindings for the
enabled address family. This helps to relearn the FEC-label bindings
that may have been discarded before without resetting the peering.
9. LDP Identifiers and Duplicate Next Hop Addresses
RFC5036 section 2.7 specifies the logic for mapping the IP routing 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 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 label entry for that FEC. The logic involves using the IP routing
next-hop address as an index into the (peer Address) database (which next-hop address as an index into the (peer Address) database (which
is populated by the Address message containing mapping between each is populated by the Address message containing mapping between each
peer's local addresses and its LDP Identifier) to determine the LDP peer's local addresses and its LDP Identifier) to determine the LDP
peer. peer.
However, this logic is insufficient to deal with duplicate IPv6 However, this logic is insufficient to deal with duplicate IPv6
skipping to change at page 13, line 25 skipping to change at page 16, line 5
This extension solves the problem of two or more peers using the This extension solves the problem of two or more peers using the
same link-local IPv6 address (in other words, duplicate peer same link-local IPv6 address (in other words, duplicate peer
addresses) as the IP routing next-hops. addresses) as the IP routing next-hops.
Lastly, for better scale and optimization, an LSR may advertise only Lastly, for better scale and optimization, an LSR may advertise only
the link-local IPv6 addresses in the Address message, assuming that the link-local IPv6 addresses in the Address message, assuming that
the peer uses only the link-local IPv6 addresses as static and/or the peer uses only the link-local IPv6 addresses as static and/or
dynamic IP routing next-hops. dynamic IP routing next-hops.
9. LDP TTL Security 10. LDP TTL Security
This document recommends enabling Generalized TTL Security Mechanism This document recommends enabling Generalized TTL Security Mechanism
(GTSM) for LDP, as specified in [RFC6720], for the LDP/TCP transport (GTSM) for LDP, as specified in [RFC6720], for the LDP/TCP transport
connection over IPv6 (i.e. LDPoIPv6). The GTSM inclusion is intended connection over IPv6 (i.e. LDPoIPv6). The GTSM inclusion is intended
to automatically protect IPv6 LDP peering session from off-link to automatically protect IPv6 LDP peering session from off-link
attacks. attacks.
[RFC6720] allows for the implementation to statically [RFC6720] allows for the implementation to statically
(configuration) and/or dynamically override the default behavior (configuration) and/or dynamically override the default behavior
(enable/disable GTSM) on a per-peer basis. Suffice to say that such (enable/disable GTSM) on a per-peer basis. Suffice to say that such
an option could be set on either LSR (since GTSM negotiation would an option could be set on either LSR (since GTSM negotiation would
ultimately disable GTSM between LSR and its peer(s)). ultimately disable GTSM between LSR and its peer(s)).
LDP Link Hello packets MUST have their IPv6 Hop Limit set to 255, LDP Link Hello packets MUST have their IPv6 Hop Limit set to 255,
and be checked for the same upon receipt before any further and be checked for the same upon receipt before any further
processing, as per section 3 of [RFC5082]. processing, as per section 3 of [RFC5082].
10. IANA Considerations 11. IANA Considerations
None. This document defines a new optional parameter for the LDP Hello
Message. The type code needs to be assigned by IANA.
11. Security Considerations 12. Security Considerations
The extensions defined in this document only clarify the behavior of The extensions defined in this document only clarify the behavior of
LDP, they do not define any new protocol procedures. Hence, this LDP, they do not define any new protocol procedures. Hence, this
document does not add any new security issues to LDP. document does not add any new security issues to LDP.
While the security issues relevant for the [RFC5036] are relevant While the security issues relevant for the [RFC5036] are relevant
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]. Please see section 9 for LDP TTL use of GTSM procedures [RFC5082]. Please see section 9 for LDP TTL
Security details. Security details.
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 13. Acknowledgments
We acknowledge the authors of [RFC5036], since some 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. document early on.
Many thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach Chen, Shane Many thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach Chen, Shane
Amante, Pranjal Dutta, Mustapha Aissaoui, Matthew Bocci, Mark Tinka, Amante, Pranjal Dutta, Mustapha Aissaoui, Matthew Bocci, Mark Tinka,
Tom Petch, Kishore Tiruveedhula, Manoj Dutta, Vividh Siddha, Qin Wu, Tom Petch, Kishore Tiruveedhula, Manoj Dutta, Vividh Siddha, Qin Wu,
and Loa Andersson for thoroughly reviewing this document, and Simon Perreault, Brian E Carpenter, and Loa Andersson for thoroughly
providing insightful comments and multiple improvements. reviewing this document, and providing insightful comments and
multiple improvements.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
13. Additional Contributors 14. 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 5 skipping to change at page 18, line 5
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 Andre Pelletier
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, ON K2K-3E8, Canada Kanata, ON K2K-3E8, Canada
Email: apelleti@cisco.com Email: apelleti@cisco.com
14. References 15. References
14.1. Normative References 15.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.
[RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC5082] Pignataro, C., Gill, V., Heasley, J., Meyer, D., and [RFC5082] Pignataro, C., Gill, V., Heasley, J., Meyer, D., and
Savola, P., "The Generalized TTL Security Mechanism Savola, P., "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
14.2. Informative References [RFC5918] Asati, R., Minei, I., and Thomas, B., "Label Distribution
Protocol (LDP) 'Typed Wildcard Forward Equivalence Class
(FEC)", RFC 5918, October 2010.
15.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet [RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation [RFC4835] Manral, V., "Cryptographic Algorithm Implementation
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.
skipping to change at page 18, line 5 skipping to change at page 19, line 12
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[RFC6286] E. Chen, and J. Yuan, "Autonomous-System-Wide Unique BGP [RFC6286] E. Chen, and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, June 2011. Identifier for BGP-4", RFC 6286, June 2011.
[RFC6720] R. Asati, and C. Pignataro, "The Generalized TTL Security [RFC6720] R. Asati, and C. Pignataro, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol Mechanism (GTSM) for the Label Distribution Protocol
(LDP)", RFC 6720, August 2012. (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.
Appendix A. Appendix A.
A.1. LDPv6 and LDPv4 Interoperability Safety Net A.1. LDPv6 and LDPv4 Interoperability Safety Net
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.
skipping to change at page 18, line 26 skipping to change at page 20, line 26
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.
The change proposed in section 7 of this document provides a good The change proposed in section 7 of this document provides a good
safety net and makes LDPv6 incrementally deployable without making safety net and makes LDPv6 incrementally deployable without making
any such assumption on the routers' support for IPv6 FEC processing any such assumption on the routers' support for IPv6 FEC processing
in current production networks. in current production networks.
A.2. Why 32-bit value even for IPv6 LDP Router ID A.2. 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- 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 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 an expectation of it being IP routable, nor DNS-resolvable. In IPv4
deployments, the LSR Id is typically derived from an IPv4 address, deployments, the LSR Id is typically derived from an IPv4 address,
generally assigned to a loopback interface. In IPv6 only generally assigned to a loopback interface. In IPv6 only
deployments, this 32-bit LSR Id must be derived by some other means deployments, this 32-bit LSR Id must be derived by some other means
that guarantees global uniqueness within the MPLS network, similar that guarantees global uniqueness within the MPLS network, similar
to that of BGP Identifier [RFC6286] and OSPF router ID [RFC5340]. 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 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 usage with IPv6, in line with OSPF router Id in OSPF version 3
[RFC5340]. [RFC5340].
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.
Author's Addresses Author's Addresses
Vishwas Manral Vishwas Manral
Hewlet-Packard, Inc. Hewlet-Packard, Inc.
19111 Pruneridge Ave., Cupertino, CA, 95014 19111 Pruneridge Ave., Cupertino, CA, 95014
Phone: 408-447-1497 Phone: 408-447-1497
Email: vishwas.manral@hp.com Email: vishwas.manral@hp.com
Rajiv Papneja Rajiv Papneja
Huawei Technologies Huawei Technologies
 End of changes. 46 change blocks. 
111 lines changed or deleted 244 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/