draft-ietf-mpls-ldp-ipv6-09.txt   draft-ietf-mpls-ldp-ipv6-10.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: January 15, 2014 Hewlett-Packard, Inc. Expires: June 8, 2014 Hewlett-Packard, Inc.
Rajiv Papneja Rajiv Papneja
Huawei Huawei
Carlos Pignataro Carlos Pignataro
Cisco Cisco
July 15, 2013 December 8, 2013
Updates to LDP for IPv6 Updates to LDP for IPv6
draft-ietf-mpls-ldp-ipv6-09 draft-ietf-mpls-ldp-ipv6-10
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 January 15, 20134. This Internet-Draft will expire on June 8, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 32
2. Specification Language.........................................5 2. Specification Language.........................................5
3. LSP Mapping....................................................6 3. LSP Mapping....................................................6
4. LDP Identifiers................................................6 4. LDP Identifiers................................................6
5. Peer Discovery.................................................7 5. Peer Discovery.................................................7
5.1. Basic Discovery Mechanism.................................7 5.1. Basic Discovery Mechanism.................................7
5.2. Extended Discovery Mechanism..............................8 5.2. Extended Discovery Mechanism..............................8
6. LDP Session Establishment and Maintenance......................8 6. LDP Session Establishment and Maintenance......................8
6.1. Transport connection establishment........................9 6.1. Transport connection establishment........................9
6.2. Maintaining Hello Adjacencies............................10 6.2. Maintaining Hello Adjacencies............................10
6.3. Maintaining LDP Sessions.................................11 6.3. Maintaining LDP Sessions.................................11
7. Label Distribution............................................11 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......................................13 11. Security Considerations......................................14
12. Acknowledgments..............................................14 12. Acknowledgments..............................................14
13. Additional Contributors......................................14 13. Additional Contributors......................................14
14. References...................................................15 14. References...................................................16
14.1. Normative References....................................15 14.1. Normative References....................................16
14.2. Informative References..................................15 14.2. Informative References..................................16
Author's Addresses...............................................16 15. Appendix.....................................................17
15.1. A.1.....................................................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 6, line 5 skipping to change at page 5, line 46
TLV - Type Length Value TLV - Type Length Value
LSR - Label Switch Router LSR - Label Switch Router
LSP - Label Switched Path LSP - Label Switched Path
LSPv4 - IPv4-signaled Label Switched Path [RFC4798] LSPv4 - IPv4-signaled Label Switched Path [RFC4798]
LSPv6 - IPv6-signaled Label Switched Path [RFC4798] LSPv6 - IPv6-signaled Label Switched Path [RFC4798]
AFI - Address Family Identifier
3. LSP Mapping 3. LSP Mapping
Section 2.1 of [RFC5036] specifies the procedure for mapping a Section 2.1 of [RFC5036] specifies the procedure for mapping a
particular packet to a particular LSP using three rules. Quoting the particular packet to a particular LSP using three rules. Quoting the
3rd rule from RFC5036: 3rd rule from RFC5036:
"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 a /32 address of that router, then the packet is mapped to that is a /32 address of that router, then the packet is mapped to
that LSP." that LSP."
skipping to change at page 7, line 10 skipping to change at page 7, line 12
address in an IPv6 only LSR (i.e., single stack), nor would there address in an IPv6 only LSR (i.e., single stack), nor would there
be an expectation of it being DNS-resolvable. In IPv4 deployments, be an expectation of it being DNS-resolvable. In IPv4 deployments,
the LSR Id is typically derived from an IPv4 address, generally the LSR Id is typically derived from an IPv4 address, generally
assigned to a loopback interface. In IPv6 only deployments, this assigned to a loopback interface. In IPv6 only deployments, this
32-bit LSR Id must be derived by some other means that guarantees 32-bit LSR Id must be derived by some other means that guarantees
global uniqueness within the MPLS network, similar to that of BGP global uniqueness within the MPLS network, similar to that of BGP
Identifier [RFC6286]. Identifier [RFC6286].
This document qualifies the first sentence of last paragraph of This document 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: "For a given address family updates that sentence to the following: "For a given address family,
over which a Hello is sent, and a given label space, an LSR MUST an LSR MUST advertise the same transport address in all Hellos that
advertise the same transport address." This rightly enables the per- advertise the same label space." This rightly enables the per-
platform label space to be shared between IPv4 and IPv6. platform label space to be shared between IPv4 and IPv6.
In summary, this document not only allows the usage of a common LDP In summary, this document not only allows the usage of a common LDP
identifier i.e. same LSR-Id (aka LDP Router-Id), but also the common identifier i.e. same LSR-Id (aka LDP Router-Id), but also the common
Label space id for both IPv4 and IPv6 on a dual-stack LSR. Label space id for both IPv4 and IPv6 on a dual-stack LSR.
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. usage.
5. Peer Discovery 5. Peer Discovery
skipping to change at page 8, line 14 skipping to change at page 8, line 15
IPv6 address MUST be used as the source IP address in IPv6 LDP Link IPv6 address MUST be used as the source IP address in IPv6 LDP Link
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, and be checked for the same upon receipt before any further to 255, and be checked for the same upon receipt before any further
processing, as specified in Generalized TTL Security Mechanism processing, as specified in Generalized TTL Security Mechanism
(GTSM)[RFC5082]. The built-in inclusion of GTSM automatically (GTSM)[RFC5082]. The built-in inclusion of GTSM automatically
protects IPv6 LDP from off-link attacks. protects IPv6 LDP from off-link 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 IPv4 and IPv6 LDP), then the LSR must (e.g. enabled with both IPv6 and IPv4 LDP), then the LSR must
periodically send both IPv4 and IPv6 LDP Link Hellos (using the same periodically send both IPv6 and IPv4 LDP Link Hellos (using the same
LDP Identifier per section 4) and must separately maintain the Hello LDP Identifier per section 4) on that interface and be able to
adjacency for IPv4 and IPv6 on that interface. receive them. This facilitates discovery of IPv6-only, IPv4-only and
dual-stack peers on the interface's subnet.
In summary, the IPv4 and IPv6 LDP Link Hellos must carry the same An implementation should prefer sending IPv6 LDP link Hellos
LDP identifier (assuming per-platform label space usage). before sending IPv4 LDP Link Hellos on a dual-stack interface, if
possible.
Lastly, the IPv6 and IPv4 LDP Link Hellos must carry the same LDP
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
destination IPv6 addresses in extended discovery. destination IPv6 addresses in extended discovery.
skipping to change at page 9, line 36 skipping to change at page 9, line 40
2. An LSR SHOULD accept the Hello message that contains both IPv4 2. An LSR SHOULD accept the Hello message that contains both IPv4
and IPv6 transport address optional objects, but MUST use only and IPv6 transport address optional objects, but MUST use only
the transport address whose address family is the same as that the transport address whose address family is the same as that
of the IP packet carrying Hello. An LSR SHOULD accept only the of the IP packet carrying Hello. An LSR SHOULD accept only the
first transport object for a given Address family in the first transport object for a given Address family in the
received Hello message, and ignore the rest, if the LSR received Hello message, and ignore the rest, if the LSR
receives more than one transport object. receives more than one transport object.
3. An LSR MUST send separate Hellos (each containing either IPv4 3. An LSR MUST send separate Hellos (each containing either IPv4
or IPv6 transport address optional object) for each IP address or IPv6 transport address optional object) for each IP address
family, if LDP was enabled for both IP address-families. family, if LDP was enabled for both IP address families.
4. An LSR MUST use a global unicast IPv6 address in IPv6 transport 4. An LSR MUST use a global unicast IPv6 address in IPv6 transport
address optional object of outgoing targeted hellos, and check address optional object of outgoing targeted hellos, and check
for the same in incoming targeted hellos (i.e. MUST discard the for the same in incoming targeted hellos (i.e. MUST discard the
hello, if it failed the check). hello, if it failed the check).
5. An LSR MUST prefer using global unicast IPv6 address for an LDP 5. An LSR MUST prefer using global unicast IPv6 address for an LDP
session with a remote LSR, if it had to choose between global session with a remote LSR, if it had to choose between global
unicast IPv6 address and unique-local or link-local IPv6 unicast IPv6 address and unique-local or link-local IPv6
address (pertaining to the same LDP Identifier) for the address (pertaining to the same LDP Identifier) for the
transport connection. transport connection.
6. An LSR SHOULD NOT create (or honor the request for creating) a 6. An LSR SHOULD NOT create (or honor the request for creating) a
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,
even if there are two Hello adjacencies (one for IPv4 and regardless of one or two Hello adjacencies (one for IPv4 and
another for IPv6). This is independent of whether the Hello another for IPv6) are created & maintained over a single
Adjacencies are created over a single interface (scenario 1 in interface (scenario 1 in section 1.1) or multiple interfaces
section 1.1) or multiple interfaces (scenario 2 in section 1.1) (scenario 2 in section 1.1) 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 has both IPv4 and IPv6 LDP session with a remote LSR, if it has both IPv4 and IPv6
hello adjacencies for the same LDP Identifier (over a dual- hello adjacencies for the same (peer) LDP Identifier (over a
stack interface, or two or more single-stack IPv4 and IPv6 dual-stack interface, or two or more single-stack IPv4 and IPv6
interfaces). This applies to the section 2.5.2 of RFC5036. interfaces). This applies to the section 2.5.2 of RFC5036.
Each LSR, assuming an active role for whichever address Each LSR, assuming an active role for whichever address
family(s), should enforce this LDP/TCP connection over IPv6 family(s), should enforce this LDP/TCP connection over IPv6
preference for a time-period (default value is 15 seconds), preference for a time-period (default value is 15 seconds),
after which LDP/TCP connection over IPv4 should be attempted. after which LDP/TCP connection over IPv4 should be attempted.
This enforcement is independent of whether the LSR is assuming This enforcement is independent of whether the LSR is assuming
the active role for IPv4 This timer is started upon receiving the active role for IPv4. This timer is started upon receiving
the first hello from the neighbor. the first hello from the neighbor.
8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new
LDP session with a remote LSR, if they attempted two TCP LDP session with a remote LSR, if they attempted two TCP
connections using IPv4 and IPv6 transport addresses connections using different transport address families (IPv4
simultaneously. and IPv6) simultaneously.
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.
6.2. Maintaining Hello Adjacencies 6.2. Maintaining Hello Adjacencies
As outlined in 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
IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and IPv6 and IPv4 LDP, then the LSR must periodically send and receive
IPv6 LDP Link Hellos and must separately maintain the Hello both IPv6 and IPv4 LDP Link Hellos.
adjacency for IPv4 and IPv6 on that interface.
This ensures successful labeled IPv4 and labeled IPv6 traffic This ensures successful LDP discovery and subsequent peering using
forwarding on a dual-stacked interface, as well as successful LDP the appropriate (address family) transport on a multi-access or
peering using the appropriate transport on a multi-access broadcast interface (even if there are IPv6-only, IPv4-only and
interface (even if there are IPv4-only, IPv6-only and dual-stack dual-stack LSRs connected to that interface).
LSRs connected to that multi-access interface).
This document allows an LSR to maintain Rx-side Link Hello adjacency
for only one address family that has been used for the establishment
of the LDP session.
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 35 skipping to change at page 15, line 4
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
Cisco Systems, Inc. Cisco Systems, Inc.
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
Email: apelleti@cisco.com
14. References 14. References
14.1. Normative References 14.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.
 End of changes. 21 change blocks. 
40 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/