draft-ietf-mpls-ldp-ipv6-00.txt   draft-ietf-mpls-ldp-ipv6-01.txt 
MPLS Working Group Vishwas Manral MPLS Working Group Vishwas Manral
Internet Draft IPInfusion Inc. Internet Draft IPInfusion Inc.
Intended status: Standards Track Intended status: Standards Track (updates RFC5036)
Expires: May 2011 Rajiv Papneja Expires: April 2011 Rajiv Papneja
Isocore Isocore
Rajiv Asati Rajiv Asati
Cisco Systems Cisco Systems
November 8, 2010 March 13, 2011
Updates to LDP for IPv6 Updates to LDP for IPv6
draft-ietf-mpls-ldp-ipv6-00 draft-ietf-mpls-ldp-ipv6-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 8, 2010. This Internet-Draft will expire on April 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 22 skipping to change at page 2, line 25
Abstract Abstract
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. when IPv6 network is used.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Specification Language.........................................3 1.1. Topology Scenarios........................................3
3. LSP Mapping....................................................4 2. Specification Language.........................................4
4. LDP Identifiers................................................4 3. LSP Mapping....................................................5
5. Peer Discovery.................................................5 4. LDP Identifiers................................................6
5.1. Basic Discovery Mechanism.................................5 5. Peer Discovery.................................................6
5.2. Extended Discovery Mechanism..............................5 5.1. Basic Discovery Mechanism.................................6
6. LDP Session Establishment......................................6 5.2. Extended Discovery Mechanism..............................7
6.1. Transport connection establishment........................6 6. LDP Session Establishment and Maintenance......................7
6.2. Session initialization....................................7 6.1. Transport connection establishment........................7
7. IANA Considerations............................................7 6.2. Maintaining Hello Adjacencies.............................9
8. Security Considerations........................................7 6.3. Maintaining LDP Sessions..................................9
9. Acknowledgments................................................7 7. Label Distribution.............................................9
10. References....................................................8 8. IANA Considerations...........................................10
10.1. Normative References.....................................8 9. Security Considerations.......................................10
10.2. Informative References...................................8 10. Acknowledgments..............................................10
Author's Addresses................................................9 11. References...................................................11
11.1. Normative References....................................11
11.2. Informative References..................................11
Author's Addresses...............................................12
1. Introduction 1. Introduction
The LDP [RFC5036] specification defines procedures and messages for The LDP [RFC5036] specification defines procedures and messages for
exchanging label bindings over either IPv4 or IPv6 or both (e.g. exchanging 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:
1) LSP mapping: No rule defined for mapping a particular packet to a 1) LSP mapping: No rule defined 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 multicast 3) LDP discovery: No details for using a particular IPv6 multicast
address (with or without IPv4 co-existence) address (with or without IPv4 co-existence)
4) LDP Session establishment: No prescription for handling both IPv4 4) LDP Session establishment: No rule for handling both IPv4 and
and IPv6 transport address optional objects in a Hello message, IPv6 transport address optional objects in a Hello message, and
and subsequently two IPv4 and IPv6 transport connections. subsequently two IPv4 and IPv6 transport connections.
5) LDP Label exchange: No rule for advertising IPv4 or/and IPv6
label bindings over an LDP session
This document addresses the above deficiencies by specifying the This document addresses the above deficiencies by specifying the
desired behavior. desired behavior/rules/details. It also clarifies the topology
scenarios in section 1.1.
Note that this document updates RFC5036. Note that this document updates RFC5036.
1.1. Topology Scenarios
The following scenarios in which the LSRs may be inter-connected via
one or more dual-stack interfaces (figure 1), or two or more single-
stack interfaces (figure 2 and figure 3) become quite relevant to
consider while addressing the deficiencies highlighted in section 1.
R1------------------R2
IPv4+IPv6
Figure 1 LSRs connected via a Dual-stack Interface
IPv4
R1=================R2
IPv6
Figure 2 LSRs connected via two single-stack Interfaces
R1------------------R2---------------R3
IPv4 IPv6
Figure 3 LSRs connected via a single-stack Interface
The topology scenario illustrated in figure 1 also covers the case
of a single-stack interface (IPv4, say) being converted to a dual-
stacked interface by enabling IPv6 as well as IPv6 LDP, even though
the IPv4 LDP session may already be established between the LSRs.
The topology scenario illustrated in figure 2 also covers the case
of two routers getting connected via an additional single-stack
interface (IPv6, say), even though the IPv4 LDP session may already
be established between the LSRs over the existing interface.
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].
LDP - Label Distribution Protocol LDP - Label Distribution Protocol
FEC - Forwarding Equivalence Class FEC - Forwarding Equivalence Class
TLV - Type Length Value TLV - Type Length Value
LSR - Label Switch Router LSR - Label Switch Router
LSP - Label Switched Path LSP - Label Switched Path
3. LSP Mapping 3. LSP Mapping
skipping to change at page 4, line 29 skipping to change at page 5, line 36
This document proposes to modify this rule by also including a /128 This document proposes to modify this rule by also including a /128
address (for IPv6). In fact, it should be reasonable to just say address (for IPv6). In fact, it should be reasonable to just say
IPv4 or IPv6 address instead of /32 or /128 addresses as shown below IPv4 or IPv6 address instead of /32 or /128 addresses as shown below
in the updated rule: 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."
While the above rule mentions 'Address Prefix FEC', it is also
applicable to 'Typed WildCard prefix FEC' [RFC5918].
Additionally, it is desirable that a packet is forwarded to an LSP
of an egress router, only if LSP's address-family matches with that
of the LDP hello adjacency on the next-hop interface.
4. LDP Identifiers 4. LDP Identifiers
Section 2.2.2 of [RFC5036] specifies formulating at least one LDP Section 2.2.2 of [RFC5036] specifies formulating at least one LDP
Identifier, however, it doesn't provide any consideration in case of Identifier, however, it doesn't provide any consideration in case of
IPv6 (with or without dual-stacking). IPv6 (with or without dual-stacking).
This document preserves the usage of 32-bit LSR Id on an IPv6 only This document preserves the usage of 32-bit LSR Id on an IPv6 only
LSR and allows the usage of a common LDP identifier i.e. same LSR-Id LSR and allows the usage of a common LDP identifier i.e. same LSR-Id
and same Label space id for IPv4 and IPv6 on a dual-stack LSR. This and same Label space id for IPv4 and IPv6 on a dual-stack LSR. This
rightly enables the per-platform label space to be shared between rightly enables the per-platform label space to be shared between
skipping to change at page 5, line 35 skipping to change at page 7, line 9
Hellos. Hellos.
This document specifies the usage of link-local scope e.g. This document specifies the usage of link-local scope e.g.
FF02:0:0:0:0:0:0:2 as the destination multicast IP address for IPv6 FF02:0:0:0:0:0:0:2 as the destination multicast IP address for IPv6
LDP Link Hellos. An LDP Hello packet received on any of the other LDP Link Hellos. An LDP Hello packet received on any of the other
addresses should be dropped. Also, the LDP Link Hello packets must addresses should be dropped. Also, the LDP Link Hello packets must
have their IPv6 Hop Limit set to 1. have their IPv6 Hop Limit set to 1.
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 IPv4 and IPv6 LDP), then the LSR must
periodically send both IPv4 and IPv6 LDP Link Hellos and must periodically send both IPv4 and IPv6 LDP Link Hellos (using the same
separately maintain the Hello adjacency for IPv4 and IPv6. This LDP Identifier per section 4) and must separately maintain the Hello
ensures labeled IPv4 and labeled IPv6 traffic forwarding on a dual- adjacency for IPv4 and IPv6 on that interface.
stacked interface, as well as the LDP peerings using the appropriate
transport can be established on a multi-access interface (even if Needless to say, the IPv4 and IPv6 LDP Link Hellos must carry the
there are IPv4-only, IPv6-only and dual-stack routers on that multi- same LDP identifier (assuming per-platform label space usage).
access segment). Needless to say, the IPv4 and IPv6 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 destination IP address. configured destination IP address.
6. LDP Session Establishment 6. LDP Session Establishment and Maintenance
Section 2.5.1 of [RFC5036] defines a two-step process for LDP Section 2.5.1 of [RFC5036] defines a two-step process for LDP
session establishment: session establishment, once the peer discovery has completed (LDP
Hellos have been exchanged):
1. Transport connection establishment 1. Transport connection establishment
2. Session initialization 2. Session initialization
Next two sections discuss the LDP consideration for IPv6 and/or The forthcoming sub-sections discuss the LDP consideration for IPv6
dual-stacking. and/or dual-stacking in the context of session establishment and
maintenance.
6.1. Transport connection establishment 6.1. Transport connection establishment
Section 2.5.2 of [RFC5036] specifies the use of an optional Section 2.5.2 of [RFC5036] specifies the use of an optional
transport address object (TLV) in LDP Link Hello message to convey transport address object (TLV) in LDP Link Hello message to convey
the transport (IP) address, however, it does not specify the the transport (IP) address, however, it does not specify the
behavior of LDP if both IPv4 and IPv6 transport address objects behavior of LDP if both IPv4 and IPv6 transport address objects
(TLV) are sent in a Hello message. Moreover, it does not specify (TLV) are sent in a Hello message or separate Hello messages. More
whether both IPv4 and IPv6 transport connections should be allowed, importantly, it does not specify whether both IPv4 and IPv6
if there were Hello adjacencies for both IPv4 and IPv6. transport connections should be allowed, if there were Hello
adjacencies for both IPv4 and IPv6 whether over a single interface
or multiple interfaces.
This document specifies that: This document specifies that:
- An LSR should not send a Hello containing both IPv4 and IPv6 - An LSR should not send a Hello containing both IPv4 and IPv6
transport address optional objects. In other words, there transport address optional objects. In other words, there
should be at most one optional Transport Address object in a should be at most one optional Transport Address object in a
Hello message. An LSR should include only the transport address Hello message. An LSR should include only the transport address
whose address family is the same as that of the IP packet whose address family is the same as that of the IP packet
carrying Hello. carrying Hello.
- An LSR should accept the Hello message that contains both IPv4 - An LSR should accept the Hello message that contains both IPv4
and IPv6 transport address optional objects, but use only the and IPv6 transport address optional objects, but use only the
transport address whose address family is the same as that of transport address whose address family is the same as that of
the IP packet carrying Hello. the IP packet carrying Hello.
- An LSR must send separate Hellos (each containing either IPv4
or IPv6 transport address optional object) for each IP
transport, if LDP was enabled for both IP transports.
- An LSR should not create (or honor the request for creating) a - 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 label spaces) already have an LDP session (for the same LDP Identifier)
established using whatever IP version. This means that only one established using whatever IP version transport. This means
transport connection should be established, even if there are that only one transport connection should be established, even
two Hello adjacencies (one for IPv4 and another for IPv6). if there are two Hello adjacencies (one for IPv4 and another
for IPv6). This is independent of whether the Hello Adjacencies
are created over a single interface (scenarios 1 in section
1.1) or multiple interfaces (scenario 2 in section 1.1).
- An LSR should prefer the TCP connection over IPv6 for a new LDP - An LSR should prefer the LDP/TCP connection over IPv6 for a new
session with a remote LSR, if they attempted two TCP LDP session with a remote LSR, if it has both IPv4 and IPv6
hello adjacencies for the same LDP Identifier (over a dual-
stack interface, or two or more single-stack IPv4 and IPv6
interfaces).
- An LSR should prefer the LDP/TCP connection over IPv6 for a new
LDP session with a remote LSR, if they attempted two TCP
connections using IPv4 and IPv6 transports simultaneously. connections using IPv4 and IPv6 transports simultaneously.
6.2. Session initialization This document allows an implementation to provide a configuration to
override the above stated preference from IPv6 to IPv4. Suffice to
say that, such preference must be set on both LSRs, whether on a
per-peer granularity or not.
No additional consideration needed. 6.2. Maintaining Hello Adjacencies
7. IANA Considerations As outlined in section 2.5.5 of RFC5036, this draft suggests that 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
LDP Link Hellos and must separately maintain the Hello adjacency for
IPv4 and IPv6 on that interface.
This ensures successful labeled IPv4 and labeled IPv6 traffic
forwarding on a dual-stacked interface, as well as successful LDP
peerings using the appropriate transport on a multi-access
interface (even if there are IPv4-only, IPv6-only and dual-stack
LSRs connected to that multi-access interface).
6.3. Maintaining LDP Sessions
Two LSRs maintain a single LDP session between them, as described in
section 6.1, whether they are connected via a dual-stack LDP enabled
interface or via two single-stack LDP enabled interfaces. This is
also true when a single-stack interface is converted to a dual-stack
interface, or when another interface is added between two LSRs.
On the other hand, if a dual-stack interface is converted to a
single-stack interface (by disabling IPv4 or IPv6 routing), then the
LDP session should be torn down ONLY if the disabled IP version was
the same as that of the transport connection. Otherwise, the LDP
session should stay intact.
If the LDP session is torn down for whatever reason (LDP disabled
for the corresponding transport, hello adjacency expiry etc.), then
the LSRs should initiate establishing a new LDP session as per the
procedures described in section 6.1 of this document and RFC5036.
7. Label Distribution
This document specifies that an LSR should advertise and receive
both IPv4 and IPv6 label bindings from and to the peer, only if it
has valid IPv4 and IPv6 Hello Adjacencies for that peer, as
specified in section 6.2.
This means that the LSR must not advertise any IPv6 label bindings
to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency
existed for that peer (and vice versa).
8. IANA Considerations
None. None.
8. Security Considerations 9. 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. All the LDP, they do not define any new protocol procedures. All the
security issues relevant for the [RFC5036] are relevant for this security issues relevant for the [RFC5036] are relevant for this
document as well. document as well.
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]. specified in [RFC4835].
9. Acknowledgments 10. Acknowledgments
A lot of the text in this document is borrowed from [RFC5036]. The A lot of the text in this document is borrowed from [RFC5036]. The
authors of the document are acknowledged. The authors also authors of the document are acknowledged. The authors also
aknowledge the help of Manoj Dutta and Vividh Siddha. Thanks to Bob aknowledge the help of Manoj Dutta and Vividh Siddha. Thanks to Bob
Thomas for providing critical feedback to improve this document Thomas for providing critical feedback to improve this document
early on. early on. Thanks to Kamran Raza, Eric Rosen, Lizhong Jin, Bin Mo,
Mach Chen, Kishore Tiruveedhula for reviewing this document.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
10. References 11. References
10.1. Normative References 11.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.
[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.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
10.2. Informative References 11.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.
[RFC4853] Manral, V., "Cryptographic Algorithm Implementation [RFC4853] 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.
[RFC5918] Asati, R. Minei, I., and Thomas, B., "Label Distribution
Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
(FEC)", RFC 5918, April 2010.
[IANA-IPv6] http://www.iana.org/assignments/ipv6-address-space. [IANA-IPv6] http://www.iana.org/assignments/ipv6-address-space.
Author's Addresses Author's Addresses
Vishwas Manral Vishwas Manral
IP Infusion Inc., IP Infusion Inc.,
Bamankhola, Bansgali, Bamankhola, Bansgali,
Almora, Uttarakhand 263601 Almora, Uttarakhand 263601
Email: vishwas@ipinfusion.com Email: vishwas@ipinfusion.com
Rajiv Papneja Rajiv Papneja
ISOCORE ISOCORE
12359 Sunrise Valley Dr, STE 100 12359 Sunrise Valley Dr, STE 100
Reston, VA 20190 Reston, VA 20190
Email: rpapneja@isocore.com Email: rpapneja@isocore.com
Rajiv Asati Rajiv Asati
Cisco Systems, Cisco Systems,
7025-6 Kit Creek Rd, RTP, NC, 27709-4987 7025 Kit Creek Rd, RTP, NC, 27709-4987
Email: rajiva@cisco.com Email: rajiva@cisco.com
 End of changes. 29 change blocks. 
58 lines changed or deleted 168 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/