draft-ietf-mpls-ldp-ipv6-10.txt   draft-ietf-mpls-ldp-ipv6-11.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: June 8, 2014 Hewlett-Packard, Inc. Expires: June 28, 2014 Hewlett-Packard, Inc.
Rajiv Papneja Rajiv Papneja
Huawei Huawei
Carlos Pignataro Carlos Pignataro
Cisco Cisco
December 8, 2013 December 28, 2013
Updates to LDP for IPv6 Updates to LDP for IPv6
draft-ietf-mpls-ldp-ipv6-10 draft-ietf-mpls-ldp-ipv6-11
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/.
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 (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
skipping to change at page 2, line 42 skipping to change at page 2, line 54
7. Label Distribution............................................12 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......................................14 11. Security Considerations......................................14
12. Acknowledgments..............................................14 12. Acknowledgments..............................................14
13. Additional Contributors......................................14 13. Additional Contributors......................................14
14. References...................................................16 14. References...................................................16
14.1. Normative References....................................16 14.1. Normative References....................................16
14.2. Informative References..................................16 14.2. Informative References..................................16
15. Appendix.....................................................17 Appendix.........................................................17
15.1. A.1.....................................................17
Author's Addresses...............................................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 8, line 25 skipping to change at page 8, line 25
(e.g. enabled with both IPv6 and IPv4 LDP), then the LSR must (e.g. enabled with both IPv6 and IPv4 LDP), then the LSR must
periodically send both IPv6 and IPv4 LDP Link Hellos (using the same periodically send both IPv6 and IPv4 LDP Link Hellos (using the same
LDP Identifier per section 4) on that interface and be able to LDP Identifier per section 4) on that interface and be able to
receive them. This facilitates discovery of IPv6-only, IPv4-only and receive them. This facilitates discovery of IPv6-only, IPv4-only and
dual-stack peers on the interface's subnet. dual-stack peers on the interface's subnet.
An implementation should prefer sending IPv6 LDP link Hellos An implementation should prefer sending IPv6 LDP link Hellos
before sending IPv4 LDP Link Hellos on a dual-stack interface, if before sending IPv4 LDP Link Hellos on a dual-stack interface, if
possible. possible.
Lastly, the IPv6 and IPv4 LDP Link Hellos must carry the same LDP Lastly, the IPv6 and IPv4 LDP Link Hellos MUST carry the same LDP
identifier (assuming per-platform label space usage). 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
skipping to change at page 11, line 12 skipping to change at page 11, line 12
In line with the 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
IPv6 and IPv4 LDP, then the LSR must periodically send and receive IPv6 and IPv4 LDP, then the LSR must periodically send and receive
both IPv6 and IPv4 LDP Link Hellos. both IPv6 and IPv4 LDP Link Hellos.
This ensures successful LDP discovery and subsequent peering using This ensures successful LDP discovery and subsequent peering using
the appropriate (address family) transport on a multi-access or the appropriate (address family) transport on a multi-access or
broadcast interface (even if there are IPv6-only, IPv4-only and broadcast interface (even if there are IPv6-only, IPv4-only and
dual-stack LSRs connected to that interface). dual-stack LSRs connected to that interface).
This document allows an LSR to maintain Rx-side Link Hello adjacency While the LSR receives both IPv4 and IPv6 LDP Link Hello messages on
for only one address family that has been used for the establishment the interface, this document however allows an LSR to maintain
of the LDP session. Rx-side Link Hello adjacency for the address family that has been
used for the establishment of the LDP session (either IPv4 or IPv6),
or to maintain Rx-side Link Hellp adjacency for both IPv4 and IPv6
address families.
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 22 skipping to change at page 14, line 22
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]. use of GTSM procedures [RFC5082].
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 12. Acknowledgments
We acknowledge the authors of [RFC5036], since the 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. Thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach document early on.
Chen, Shane Amante, Pranjal Dutta, Mustapha Aissaoui, Mark Tinka,
Tom Petch and Kishore Tiruveedhula for reviewing this document. The Many thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach Chen, Shane
authors also acknowledge the help of Manoj Dutta and Vividh Siddha. Amante, Pranjal Dutta, Mustapha Aissaoui, Matthew Bocci, Mark Tinka,
Tom Petch, Kishore Tiruveedhula, Manoj Dutta, Vividh Siddha, Qin Wu,
and Loa Andersson for thoroughly reviewing this document, and
providing insightful comments and multiple improvements.
Also, thanks to Andre Pelletier (who brought up the issue about Also, thanks to Andre Pelletier (who brought up the issue about
active/passive determination, and helped us craft the appropriate active/passive determination, and helped us craft the appropriate
solutions). solutions).
This document was prepared using 2-Word-v2.0.template.dot.
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
skipping to change at page 16, line 38 skipping to change at page 16, line 38
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.
[RFC4798] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS [RFC4798] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS
Using IPv6 Provider Edge Routers (6PE)", RFC 4798, Using IPv6 Provider Edge Routers (6PE)", RFC 4798,
February 2007. February 2007.
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol
(LDP)", RFC 6720, August 2012
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, June 2011.
[IPPWCap] Raza, K., "LDP IP and PW Capability", draft-ietf-mpls-ldp- [IPPWCap] Raza, K., "LDP IP and PW Capability", draft-ietf-mpls-ldp-
ip-pw-capability, June 2011. ip-pw-capability, June 2011.
15. Appendix Appendix
15.1. A.1
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.
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.
 End of changes. 12 change blocks. 
19 lines changed or deleted 39 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/