Internet Engineering Task Force Vishwas Manral
Internet-Draft IPInfusion Inc.
Intended status: Standards Track Rajiv Papneja
Expires: August 17, 2008 Isocore
February 17, 2008
Updates to LDP for IPv6
draft-manral-mpls-ldp-ipv6-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 17, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
LDP is defined in [RFC5036]. LDP (for Label Distribution Protocol)
defines procedures for LSRs to distribute labels to support MPLS
forwarding along normally routed paths.
Manral and Papneja Expires August 17, 2008 [Page 1]
Internet-Draft LDP for IPv6 February 2008
LDP is a protocol defined for distributing labels. It is the set of
procedures and messages by which Label Switched Routers (LSRs) establish
Label Switched Paths (LSPs) through a network by mapping network-layer
routing information directly to data-link layer switched paths. These LSPs
may have an endpoint at a directly attached neighbor (comparable to IP
hop-by-hop forwarding), or may have an endpoint at a network egress node,
enabling switching via all intermediary nodes.
The LDP procedures are defined for both IPv4 and IPv6 networks. This
document corrects and clarifies the LDP behavior for IPv6 networks as
defined in [RFC5036] for helping in better interoperability between
implementations.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LSP Mapping Procedures . . . . . . . . . . . . . . . . . . . . 3
3. LDP Identifiers . . . . . . . . . . . . . . . . . . . . . . . 4
4. LDP Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 Basic Discovery Mechanism . . . . . . . . . . . . . . . . . 4
4.2 Extended Discovery Mechanism . . . . . . . . . . . . . . . 4
5. Maintaining Hello Adjacencies . . . . . . . . . . . . . . . . 5
6. Hello Message Procedure . . . . . . . . . . . . . . . . . . . 5
7. LDP Session Establishment . . . . . . . . . . . . . . . . . . 6
7.1. Transport Connection Establishment . . . . . . . . . . . . 6
7.2. Session Initialization . . . . . . . . . . . . . . . . . . 6
8. Authenticity and Integrity of LDP Messages . . . . . . . . . . 6
8.1. LDP Hello Password . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Manral and Papneja Expires August 17, 2008 [Page 2]
Internet-Draft LDP for IPv6 February 2008
1. Introduction
The MPLS architecture [RFC3031] defines a label distribution protocol
as a set of procedures by which one Label Switched Router (LSR)
informs another of the meaning of labels used to forward traffic
between and through them.
A fundamental concept in MPLS is that two
Label Switching Routers (LSRs) must agree on the meaning of the
labels used to forward traffic between and through them. This common
understanding is achieved by using a set of procedures, called a
label distribution protocol, by which one LSR informs another of
label bindings it has made.
LDP defines four categories of messages to help convey such information:
1. Discovery messages, used to announce and maintain the presence
of an LSR in a network.
2. Session messages, used to establish, maintain, and terminate
sessions between LDP peers.
3. Advertisement messages, used to create, change, and delete
label mappings for FECs.
4. Notification messages, used to provide advisory information and
to signal error information.
All the messages are defined for both IPv4 and IPv6. However there are
some clarifications and corrections that need to be done.
2. LSP mapping procedures
[RFC5036] states that if Address Prefix FEC element that is a /32
address of that router which is the egress for an LSP, then the packet
is mapped to that LSP.
However the /32 address behavior is correct in the network is an IPv4
network . It is incorrect if the network is IPv6.
The point in the RFC should now read
- 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 that is a host address of that router (i.e. /32 address for
IPv4 or /128 for IPv6), then the packet is mapped to that LSP.
The procedure for obtaining this knowledge is beyond the scope of
this document.
Manral and Papneja Expires August 17, 2008 [Page 3]
Internet-Draft LDP for IPv6 February 2008
3. LDP Identifiers
An LDP Identifier is a six octet quantity used to identify an LSR label
space. This is true for IPv4 or IPv6 networks. Though the LSR-Id which
constitues the LDP Identifier is clealry defined as a Router-Id which is
always a 32 bit entity for both IPv4 and IPv6. We can use the same label
space for both IPv4 and IPv6.
4. LDP Discovery
LDP discovery is a mechanism that enables an LSR to discover potential
LDP peers. Discovery makes it unnecessary to explicitly configure an
LSR's label switching peers.[RFC5036] does not specify how LDP discovery
should work for a dual stack case when both IPv4 and IPv6 are enabled on
an interface.
4.1. Basic Discovery Mechanism
To engage in LDP Basic Discovery on an interface, an LSR periodically
sends LDP Link Hellos out the interface. LDP Link Hellos are sent as
UDP packets addressed to the well-known LDP discovery port for the
"all routers on this subnet" group multicast address.
For a dual stack case where the interface has both IPv4 as well as IPv6
configured we will have two sockets one for IPv4 and one for IPv6. We
will have hellos sent over both address family sockets for every label
space.
4.2. Extended Discovery Mechanism
LDP sessions between non-directly connected LSRs are supported by LDP
Extended Discovery. To engage in LDP Extended Discovery, an LSR
periodically sends LDP Targeted Hellos to a specific address.
Manral and Papneja Expires August 17, 2008 [Page 4]
Internet-Draft LDP for IPv6 February 2008
As Targeted Hellos will be sent to a particular preconfigured address,
we send the Hello only the socket of the same address family as the
configured address. If the address is configured for both IPv4 and IPv6
in that case we can send Hellos on the both IPv4 and IPv6 sockets.
5. Maintaining Hello Adjacencies
An LDP session with a peer has one or more Hello adjacencies.
An LDP session has multiple Hello adjacencies when a pair of LSRs is
connected by multiple links that share the same label space; for
example, multiple PPP links between a pair of routers. We can also have
multiple Hello adjacencies in the dual stack case where we have IPv4
and IPv6 Hellos exchanged for the same label space between a pair of
LSR's.
In this situation, the Hellos an LSR sends on each such link carry the same
LDP Identifier. The details of the behavior in case of the multiple Hello
adjacencies is defined in [RFC5036].
6. Hello Message Procedures
All LDP messages have a common structure that uses a Type-Length-
Value (TLV) encoding scheme. The Value part of a TLV-encoded object,
or TLV for short, may itself contain one or more TLVs.
However [RFC5036] states does not define the behavior of LDP in case
both IPv4 and IPv6 transport addresses are sent in the packet.
[RFC5036] seems to assume that only one such TLV is received
and specifies the behavior based on such a case.
Manral and Papneja Expires August 17, 2008 [Page 5]
Internet-Draft LDP for IPv6 February 2008
Going by the IETF philosophy of "being liberal in what you
accept and conservative in what you give out", a Hello
received with both the IPv4 and IPv6 transport address TLV's
is accepted. However only the Transport address corresponding
to the address family, of the socket over which the Hello is
received is used for the Hello Message Procedures.
Incase of sending out a Hello only the transport address corresponding
to the address family of the socket over which the Hello is sent out,
is used.
As [RFC5036] specifies the use of the tranport address itself is optional
7. LDP Session Establishment
The exchange of LDP Discovery Hellos between two LSRs triggers LDP session
establishment. Session establishment is a two step process:
- Transport connection establishment
- Session initialization
7.1. Transport Connection Establishment
The exchange of Hellos results in the creation of a Hello adjacency at LSR1
that serves to bind the link (L) and the label spaces LSR1:a and LSR2:b.
If LSR1 does not already have an LDP session for the exchange of label
spaces LSR1:a and LSR2:b, it attempts to open a TCP connection for a new LDP
session with LSR2. In this case we need to check the LDP session for any of
the address families either IPv4 or IPv6. this allows just one transport
connection to be used for both IPv4 and IPv6.
7.2. Session Initialization
In the case when LSR1 plays the passive role if LSR1 receives an
Initialization message, it attempts to match the LDP Identifier carried by
the message PDU with a Hello adjacency of the irrespective of the address
family of socket used for the adjacency.
8. Authenticity and Integrity of LDP Messages
[RFC5036] defines the use of TCP MD5 signature options. As IPsec is a
mandatory component of IPv6 specification, IPsec ESP in Tranport or Tunnel
mode can also be used to gain further security of LDP sessions.
Manral and Papneja Expires August 17, 2008 [Page 6]
Internet-Draft LDP for IPv6 February 2008
8.1. LDP Hello Password
The same Hello password should be used to verify receive as well as send Hellos
over both the IPv4 and IPv6 sockets.
9. Security Considerations
The extensions defined in this document only clarify the behavior of LDP,
they do not define any new protocol procedures. All the security issues
relevent for the [RFC5036] are relevent for this document too.
As this document allows the use of IPsec [RFC4301] for IPv6 protection we can
gain additional security as specified by [RFC4835].
10. IANA Considerations
This document has no actions for IANA.
11. Acknowledgements
A lot of the text in this document is borrowed from [RFC5036]. The
authors of the document are acknowledged. The authors also acknowledge
the help of Manoj Dutta and Vividh Siddha.
Manral and Papneja Expires August 17, 2008 [Page 7]
Internet-Draft LDP for IPv6 February 2008
8. References
8.1. Normative References
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[ASSIGNED_AF] http://www.iana.org/assignments/address-family-numbers
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet
Protocol", RFC 4301, December 2005.
[RFC4853] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007.
8.2. Informative References
[RFC2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
Savola, "Scenarios and Analysis for Introducing IPv6 into
ISP Networks", RFC 4029, March 2005.
[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS
Explicit NULL", RFC 4182, September 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006.
Manral and Papneja Expires August 17, 2008 [Page 8]
Internet-Draft LDP for IPv6 February 2008
Authors' Addresses
Vishwas Manral
IP Infusion Inc.,
Bamankhola,
Bansgali,
Almora,
Uttarakhand - 263601
India
Email: vishwas@ipinfusion.com
Rajiv Papneja
Isocore
12359 Sunrise Valley Drive, STE 100
Reston, VA 20190
USA
Phone: +1 703 860 9273
Email: rpapneja@isocore.com
Manral and Papneja Expires August 17, 2008 [Page 9]
Internet-Draft LDP for IPv6 February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Manral and Papneja Expires August 17, 2008 [Page 10]