Internet Engineering Task Force Vishwas Manral Internet-Draft IPInfusion Inc. Intended status: Standards Track Rajiv Papneja Expires: March 4, 2009 Isocore September 4, 2008 Updates to LDP for IPv6 draft-manral-mpls-ldp-ipv6-02 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 March 4, 2009. 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 March 4, 2009 [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 March 4, 2009 [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 March 4, 2009 [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. IPv6 defines the 3 well known Multicast addresses [IANA-IPV6][RFC4291]: All Routers Addresses: FF01:0:0:0:0:0:0:2 FF02:0:0:0:0:0:0:2 FF05:0:0:0:0:0:0:2 Each of the addresses define a scope 1 (interface-local), 2 (link-local), or 5 (site-local). LDP will use the link-local scope address. An LDP Hello packet received on any of the other addresses will be dropped. 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 March 4, 2009 [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 March 4, 2009 [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 March 4, 2009 [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 [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 March 4, 2009 [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 [IANA-IPV6] http://www.iana.org/assignments/ipv6-address-space [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. [RFC4291] 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 March 4, 2009 [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 March 4, 2009 [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 March 4, 2009 [Page 10]