idnits 2.17.1 draft-ietf-mpls-ldp-ipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 8, 2010) is 4890 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4835' is mentioned on line 275, but not defined ** Obsolete undefined reference: RFC 4835 (Obsoleted by RFC 7321) == Unused Reference: 'RFC2460' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'RFC4853' is defined on line 308, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3513 (ref. 'RFC4291') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 4835 (ref. 'RFC4853') (Obsoleted by RFC 7321) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Vishwas Manral 2 Internet Draft IPInfusion Inc. 3 Intended status: Standards Track 4 Expires: May 2011 Rajiv Papneja 5 Isocore 7 Rajiv Asati 8 Cisco Systems 10 November 8, 2010 12 Updates to LDP for IPv6 13 draft-ietf-mpls-ldp-ipv6-00 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on May 8, 2010. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the BSD License. 53 Abstract 55 The Label Distribution Protocol (LDP) specification defines 56 procedures to exchange label bindings over either IPv4 or IPv6 or 57 both networks. This document corrects and clarifies the LDP behavior 58 when IPv6 network is used. 60 Table of Contents 62 1. Introduction...................................................3 63 2. Specification Language.........................................3 64 3. LSP Mapping....................................................4 65 4. LDP Identifiers................................................4 66 5. Peer Discovery.................................................5 67 5.1. Basic Discovery Mechanism.................................5 68 5.2. Extended Discovery Mechanism..............................5 69 6. LDP Session Establishment......................................6 70 6.1. Transport connection establishment........................6 71 6.2. Session initialization....................................7 72 7. IANA Considerations............................................7 73 8. Security Considerations........................................7 74 9. Acknowledgments................................................7 75 10. References....................................................8 76 10.1. Normative References.....................................8 77 10.2. Informative References...................................8 78 Author's Addresses................................................9 80 1. Introduction 82 The LDP [RFC5036] specification defines procedures and messages for 83 exchanging label bindings over either IPv4 or IPv6 or both (e.g. 84 dual-stack) networks. 86 However, RFC5036 specification has the following deficiencies in 87 regards to IPv6 usage: 89 1) LSP mapping: No rule defined for mapping a particular packet to a 90 particular LSP that has an Address Prefix FEC element containing 91 IPv6 address of the egress router 93 2) LDP identifier: No details specific to IPv6 usage 95 3) LDP discovery: No details for using a particular IPv6 multicast 96 address (with or without IPv4 co-existence) 98 4) LDP Session establishment: No prescription for handling both IPv4 99 and IPv6 transport address optional objects in a Hello message, 100 and subsequently two IPv4 and IPv6 transport connections. 102 This document addresses the above deficiencies by specifying the 103 desired behavior. 105 Note that this document updates RFC5036. 107 2. Specification Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 LDP - Label Distribution Protocol 115 FEC - Forwarding Equivalence Class 117 TLV - Type Length Value 119 LSR - Label Switch Router 121 LSP - Label Switched Path 123 3. LSP Mapping 125 Section 2.1 of [RFC5036] specifies the procedure for mapping a 126 particular packet to a particular LSP using three rules. Quoting the 127 3rd rule from RFC5036: 129 "If it is known that a packet must traverse a particular egress 130 router, and there is an LSP that has an Address Prefix FEC element 131 that is a /32 address of that router, then the packet is mapped to 132 that LSP." 134 Suffice to say, this rule is correct for IPv4, but not for IPv6, 135 since an IPv6 router may not have any /32 address. 137 This document proposes to modify this rule by also including a /128 138 address (for IPv6). In fact, it should be reasonable to just say 139 IPv4 or IPv6 address instead of /32 or /128 addresses as shown below 140 in the updated rule: 142 "If it is known that a packet must traverse a particular egress 143 router, and there is an LSP that has an Address Prefix FEC element 144 that is an IPv4 or IPv6 address of that router, then the packet is 145 mapped to that LSP." 147 4. LDP Identifiers 149 Section 2.2.2 of [RFC5036] specifies formulating at least one LDP 150 Identifier, however, it doesn't provide any consideration in case of 151 IPv6 (with or without dual-stacking). 153 This document preserves the usage of 32-bit LSR Id on an IPv6 only 154 LSR and allows the usage of a common LDP identifier i.e. same LSR-Id 155 and same Label space id for IPv4 and IPv6 on a dual-stack LSR. This 156 rightly enables the per-platform label space to be shared between 157 IPv4 and IPv6. 159 Editor's note: The possible conflict with last paragraph of 160 section 2.5.2 of RFC5036 needs to be addressed or clarified. 162 Additionally, this document reserves 0.0.0.0 as the LSR-Id, and 163 prohibits its usage. 165 5. Peer Discovery 167 5.1. Basic Discovery Mechanism 169 Section 2.4.1 of [RFC5036] defines the Basic Discovery mechanism for 170 directly connected LSRs. Following this mechanism, LSRs periodically 171 sends LDP Link Hellos destined to "all routers on this subnet" group 172 multicast IP address. 174 Interesting enough, per [IANA-IPv6] [RFC4291], IPv6 has three "all 175 routers on this subnet" multicast addresses: 177 FF01:0:0:0:0:0:0:2 = Interface-local scope 179 FF02:0:0:0:0:0:0:2 = Link-local scope 181 FF05:0:0:0:0:0:0:2 = Site-local scope 183 [RFC5036] does not specify which particular IPv6 'all routers on 184 this subnet' group multicast IP address should be used by LDP Link 185 Hellos. 187 This document specifies the usage of link-local scope e.g. 188 FF02:0:0:0:0:0:0:2 as the destination multicast IP address for IPv6 189 LDP Link Hellos. An LDP Hello packet received on any of the other 190 addresses should be dropped. Also, the LDP Link Hello packets must 191 have their IPv6 Hop Limit set to 1. 193 More importantly, if an interface is a dual-stack LDP interface 194 (e.g. enabled with both IPv4 and IPv6 LDP), then the LSR must 195 periodically send both IPv4 and IPv6 LDP Link Hellos and must 196 separately maintain the Hello adjacency for IPv4 and IPv6. This 197 ensures labeled IPv4 and labeled IPv6 traffic forwarding on a dual- 198 stacked interface, as well as the LDP peerings using the appropriate 199 transport can be established on a multi-access interface (even if 200 there are IPv4-only, IPv6-only and dual-stack routers on that multi- 201 access segment). Needless to say, the IPv4 and IPv6 LDP Link Hellos 202 must carry the same LDP identifier (assuming per-platform label 203 space usage). 205 5.2. Extended Discovery Mechanism 207 Suffice to say, the extended discovery mechanism (defined in section 208 2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific 209 consideration, since the targeted LDP Hellos are sent to a pre- 210 configured destination IP address. 212 6. LDP Session Establishment 214 Section 2.5.1 of [RFC5036] defines a two-step process for LDP 215 session establishment: 217 1. Transport connection establishment 218 2. Session initialization 220 Next two sections discuss the LDP consideration for IPv6 and/or 221 dual-stacking. 223 6.1. Transport connection establishment 225 Section 2.5.2 of [RFC5036] specifies the use of an optional 226 transport address object (TLV) in LDP Link Hello message to convey 227 the transport (IP) address, however, it does not specify the 228 behavior of LDP if both IPv4 and IPv6 transport address objects 229 (TLV) are sent in a Hello message. Moreover, it does not specify 230 whether both IPv4 and IPv6 transport connections should be allowed, 231 if there were Hello adjacencies for both IPv4 and IPv6. 233 This document specifies that: 235 - An LSR should not send a Hello containing both IPv4 and IPv6 236 transport address optional objects. In other words, there 237 should be at most one optional Transport Address object in a 238 Hello message. An LSR should include only the transport address 239 whose address family is the same as that of the IP packet 240 carrying Hello. 242 - An LSR should accept the Hello message that contains both IPv4 243 and IPv6 transport address optional objects, but use only the 244 transport address whose address family is the same as that of 245 the IP packet carrying Hello. 247 - An LSR should not create (or honor the request for creating) a 248 TCP connection for a new LDP session with a remote LSR, if they 249 already have an LDP session (for the same label spaces) 250 established using whatever IP version. This means that only one 251 transport connection should be established, even if there are 252 two Hello adjacencies (one for IPv4 and another for IPv6). 254 - An LSR should prefer the TCP connection over IPv6 for a new LDP 255 session with a remote LSR, if they attempted two TCP 256 connections using IPv4 and IPv6 transports simultaneously. 258 6.2. Session initialization 260 No additional consideration needed. 262 7. IANA Considerations 264 None. 266 8. Security Considerations 268 The extensions defined in this document only clarify the behavior of 269 LDP, they do not define any new protocol procedures. All the 270 security issues relevant for the [RFC5036] are relevant for this 271 document as well. 273 Moreover, this document allows the use of IPsec [RFC4301] for IPv6 274 protection, hence, LDP can benefit from the additional security as 275 specified in [RFC4835]. 277 9. Acknowledgments 279 A lot of the text in this document is borrowed from [RFC5036]. The 280 authors of the document are acknowledged. The authors also 281 aknowledge the help of Manoj Dutta and Vividh Siddha. Thanks to Bob 282 Thomas for providing critical feedback to improve this document 283 early on. 285 This document was prepared using 2-Word-v2.0.template.dot. 287 10. References 289 10.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, March 1997. 294 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 295 Specification", RFC 5036, October 2007. 297 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 298 (IPv6) Specification", RFC 2460, December 1998. 300 [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 301 (IPv6) Addressing Architecture", RFC 3513, April 2003. 303 10.2. Informative References 305 [RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet 306 Protocol", RFC 4301, December 2005. 308 [RFC4853] Manral, V., "Cryptographic Algorithm Implementation 309 Requirements for Encapsulating Security Payload (ESP) and 310 Authentication Header (AH)", RFC 4835, April 2007. 312 [IANA-IPv6] http://www.iana.org/assignments/ipv6-address-space. 314 Author's Addresses 316 Vishwas Manral 317 IP Infusion Inc., 318 Bamankhola, Bansgali, 319 Almora, Uttarakhand 263601 320 Email: vishwas@ipinfusion.com 322 Rajiv Papneja 323 ISOCORE 324 12359 Sunrise Valley Dr, STE 100 325 Reston, VA 20190 326 Email: rpapneja@isocore.com 328 Rajiv Asati 329 Cisco Systems, 330 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 331 Email: rajiva@cisco.com