idnits 2.17.1 draft-ietf-mpls-ldp-ipv6-01.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. == Unrecognized Status in 'Intended status: Standards Track (updates RFC5036)', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (March 13, 2011) is 4791 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 380, but not defined ** Obsolete undefined reference: RFC 4835 (Obsoleted by RFC 7321) == Unused Reference: 'RFC2460' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC4853' is defined on line 414, 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 (~~), 7 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 (updates RFC5036) 4 Expires: April 2011 Rajiv Papneja 5 Isocore 7 Rajiv Asati 8 Cisco Systems 10 March 13, 2011 12 Updates to LDP for IPv6 13 draft-ietf-mpls-ldp-ipv6-01 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 April 13, 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 1.1. Topology Scenarios........................................3 64 2. Specification Language.........................................4 65 3. LSP Mapping....................................................5 66 4. LDP Identifiers................................................6 67 5. Peer Discovery.................................................6 68 5.1. Basic Discovery Mechanism.................................6 69 5.2. Extended Discovery Mechanism..............................7 70 6. LDP Session Establishment and Maintenance......................7 71 6.1. Transport connection establishment........................7 72 6.2. Maintaining Hello Adjacencies.............................9 73 6.3. Maintaining LDP Sessions..................................9 74 7. Label Distribution.............................................9 75 8. IANA Considerations...........................................10 76 9. Security Considerations.......................................10 77 10. Acknowledgments..............................................10 78 11. References...................................................11 79 11.1. Normative References....................................11 80 11.2. Informative References..................................11 81 Author's Addresses...............................................12 83 1. Introduction 85 The LDP [RFC5036] specification defines procedures and messages for 86 exchanging label bindings over either IPv4 or IPv6 or both (e.g. 87 dual-stack) networks. 89 However, RFC5036 specification has the following deficiencies in 90 regards to IPv6 usage: 92 1) LSP mapping: No rule defined for mapping a particular packet to a 93 particular LSP that has an Address Prefix FEC element containing 94 IPv6 address of the egress router 96 2) LDP identifier: No details specific to IPv6 usage 98 3) LDP discovery: No details for using a particular IPv6 multicast 99 address (with or without IPv4 co-existence) 101 4) LDP Session establishment: No rule for handling both IPv4 and 102 IPv6 transport address optional objects in a Hello message, and 103 subsequently two IPv4 and IPv6 transport connections. 105 5) LDP Label exchange: No rule for advertising IPv4 or/and IPv6 106 label bindings over an LDP session 108 This document addresses the above deficiencies by specifying the 109 desired behavior/rules/details. It also clarifies the topology 110 scenarios in section 1.1. 112 Note that this document updates RFC5036. 114 1.1. Topology Scenarios 116 The following scenarios in which the LSRs may be inter-connected via 117 one or more dual-stack interfaces (figure 1), or two or more single- 118 stack interfaces (figure 2 and figure 3) become quite relevant to 119 consider while addressing the deficiencies highlighted in section 1. 121 R1------------------R2 122 IPv4+IPv6 124 Figure 1 LSRs connected via a Dual-stack Interface 126 IPv4 127 R1=================R2 128 IPv6 130 Figure 2 LSRs connected via two single-stack Interfaces 132 R1------------------R2---------------R3 133 IPv4 IPv6 135 Figure 3 LSRs connected via a single-stack Interface 137 The topology scenario illustrated in figure 1 also covers the case 138 of a single-stack interface (IPv4, say) being converted to a dual- 139 stacked interface by enabling IPv6 as well as IPv6 LDP, even though 140 the IPv4 LDP session may already be established between the LSRs. 142 The topology scenario illustrated in figure 2 also covers the case 143 of two routers getting connected via an additional single-stack 144 interface (IPv6, say), even though the IPv4 LDP session may already 145 be established between the LSRs over the existing interface. 147 2. Specification Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 LDP - Label Distribution Protocol 154 FEC - Forwarding Equivalence Class 156 TLV - Type Length Value 158 LSR - Label Switch Router 160 LSP - Label Switched Path 162 3. LSP Mapping 164 Section 2.1 of [RFC5036] specifies the procedure for mapping a 165 particular packet to a particular LSP using three rules. Quoting the 166 3rd rule from RFC5036: 168 "If it is known that a packet must traverse a particular egress 169 router, and there is an LSP that has an Address Prefix FEC element 170 that is a /32 address of that router, then the packet is mapped to 171 that LSP." 173 Suffice to say, this rule is correct for IPv4, but not for IPv6, 174 since an IPv6 router may not have any /32 address. 176 This document proposes to modify this rule by also including a /128 177 address (for IPv6). In fact, it should be reasonable to just say 178 IPv4 or IPv6 address instead of /32 or /128 addresses as shown below 179 in the updated rule: 181 "If it is known that a packet must traverse a particular egress 182 router, and there is an LSP that has an Address Prefix FEC element 183 that is an IPv4 or IPv6 address of that router, then the packet is 184 mapped to that LSP." 186 While the above rule mentions 'Address Prefix FEC', it is also 187 applicable to 'Typed WildCard prefix FEC' [RFC5918]. 189 Additionally, it is desirable that a packet is forwarded to an LSP 190 of an egress router, only if LSP's address-family matches with that 191 of the LDP hello adjacency on the next-hop interface. 193 4. LDP Identifiers 195 Section 2.2.2 of [RFC5036] specifies formulating at least one LDP 196 Identifier, however, it doesn't provide any consideration in case of 197 IPv6 (with or without dual-stacking). 199 This document preserves the usage of 32-bit LSR Id on an IPv6 only 200 LSR and allows the usage of a common LDP identifier i.e. same LSR-Id 201 and same Label space id for IPv4 and IPv6 on a dual-stack LSR. This 202 rightly enables the per-platform label space to be shared between 203 IPv4 and IPv6. 205 Editor's note: The possible conflict with last paragraph of 206 section 2.5.2 of RFC5036 needs to be addressed or clarified. 208 Additionally, this document reserves 0.0.0.0 as the LSR-Id, and 209 prohibits its usage. 211 5. Peer Discovery 213 5.1. Basic Discovery Mechanism 215 Section 2.4.1 of [RFC5036] defines the Basic Discovery mechanism for 216 directly connected LSRs. Following this mechanism, LSRs periodically 217 sends LDP Link Hellos destined to "all routers on this subnet" group 218 multicast IP address. 220 Interesting enough, per [IANA-IPv6] [RFC4291], IPv6 has three "all 221 routers on this subnet" multicast addresses: 223 FF01:0:0:0:0:0:0:2 = Interface-local scope 225 FF02:0:0:0:0:0:0:2 = Link-local scope 227 FF05:0:0:0:0:0:0:2 = Site-local scope 229 [RFC5036] does not specify which particular IPv6 'all routers on 230 this subnet' group multicast IP address should be used by LDP Link 231 Hellos. 233 This document specifies the usage of link-local scope e.g. 234 FF02:0:0:0:0:0:0:2 as the destination multicast IP address for IPv6 235 LDP Link Hellos. An LDP Hello packet received on any of the other 236 addresses should be dropped. Also, the LDP Link Hello packets must 237 have their IPv6 Hop Limit set to 1. 239 More importantly, if an interface is a dual-stack LDP interface 240 (e.g. enabled with both IPv4 and IPv6 LDP), then the LSR must 241 periodically send both IPv4 and IPv6 LDP Link Hellos (using the same 242 LDP Identifier per section 4) and must separately maintain the Hello 243 adjacency for IPv4 and IPv6 on that interface. 245 Needless to say, the IPv4 and IPv6 LDP Link Hellos must carry the 246 same LDP identifier (assuming per-platform label space usage). 248 5.2. Extended Discovery Mechanism 250 Suffice to say, the extended discovery mechanism (defined in section 251 2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific 252 consideration, since the targeted LDP Hellos are sent to a pre- 253 configured destination IP address. 255 6. LDP Session Establishment and Maintenance 257 Section 2.5.1 of [RFC5036] defines a two-step process for LDP 258 session establishment, once the peer discovery has completed (LDP 259 Hellos have been exchanged): 261 1. Transport connection establishment 262 2. Session initialization 264 The forthcoming sub-sections discuss the LDP consideration for IPv6 265 and/or dual-stacking in the context of session establishment and 266 maintenance. 268 6.1. Transport connection establishment 270 Section 2.5.2 of [RFC5036] specifies the use of an optional 271 transport address object (TLV) in LDP Link Hello message to convey 272 the transport (IP) address, however, it does not specify the 273 behavior of LDP if both IPv4 and IPv6 transport address objects 274 (TLV) are sent in a Hello message or separate Hello messages. More 275 importantly, it does not specify whether both IPv4 and IPv6 276 transport connections should be allowed, if there were Hello 277 adjacencies for both IPv4 and IPv6 whether over a single interface 278 or multiple interfaces. 280 This document specifies that: 282 - An LSR should not send a Hello containing both IPv4 and IPv6 283 transport address optional objects. In other words, there 284 should be at most one optional Transport Address object in a 285 Hello message. An LSR should include only the transport address 286 whose address family is the same as that of the IP packet 287 carrying Hello. 289 - An LSR should accept the Hello message that contains both IPv4 290 and IPv6 transport address optional objects, but use only the 291 transport address whose address family is the same as that of 292 the IP packet carrying Hello. 294 - An LSR must send separate Hellos (each containing either IPv4 295 or IPv6 transport address optional object) for each IP 296 transport, if LDP was enabled for both IP transports. 298 - An LSR should not create (or honor the request for creating) a 299 TCP connection for a new LDP session with a remote LSR, if they 300 already have an LDP session (for the same LDP Identifier) 301 established using whatever IP version transport. This means 302 that only one transport connection should be established, even 303 if there are two Hello adjacencies (one for IPv4 and another 304 for IPv6). This is independent of whether the Hello Adjacencies 305 are created over a single interface (scenarios 1 in section 306 1.1) or multiple interfaces (scenario 2 in section 1.1). 308 - An LSR should prefer the LDP/TCP connection over IPv6 for a new 309 LDP session with a remote LSR, if it has both IPv4 and IPv6 310 hello adjacencies for the same LDP Identifier (over a dual- 311 stack interface, or two or more single-stack IPv4 and IPv6 312 interfaces). 314 - An LSR should prefer the LDP/TCP connection over IPv6 for a new 315 LDP session with a remote LSR, if they attempted two TCP 316 connections using IPv4 and IPv6 transports simultaneously. 318 This document allows an implementation to provide a configuration to 319 override the above stated preference from IPv6 to IPv4. Suffice to 320 say that, such preference must be set on both LSRs, whether on a 321 per-peer granularity or not. 323 6.2. Maintaining Hello Adjacencies 325 As outlined in section 2.5.5 of RFC5036, this draft suggests that if 326 an LSR has a dual-stack interface, which is enabled with both IPv4 327 and IPv6 LDP, then the LSR must periodically send both IPv4 and IPv6 328 LDP Link Hellos and must separately maintain the Hello adjacency for 329 IPv4 and IPv6 on that interface. 331 This ensures successful labeled IPv4 and labeled IPv6 traffic 332 forwarding on a dual-stacked interface, as well as successful LDP 333 peerings using the appropriate transport on a multi-access 334 interface (even if there are IPv4-only, IPv6-only and dual-stack 335 LSRs connected to that multi-access interface). 337 6.3. Maintaining LDP Sessions 339 Two LSRs maintain a single LDP session between them, as described in 340 section 6.1, whether they are connected via a dual-stack LDP enabled 341 interface or via two single-stack LDP enabled interfaces. This is 342 also true when a single-stack interface is converted to a dual-stack 343 interface, or when another interface is added between two LSRs. 345 On the other hand, if a dual-stack interface is converted to a 346 single-stack interface (by disabling IPv4 or IPv6 routing), then the 347 LDP session should be torn down ONLY if the disabled IP version was 348 the same as that of the transport connection. Otherwise, the LDP 349 session should stay intact. 351 If the LDP session is torn down for whatever reason (LDP disabled 352 for the corresponding transport, hello adjacency expiry etc.), then 353 the LSRs should initiate establishing a new LDP session as per the 354 procedures described in section 6.1 of this document and RFC5036. 356 7. Label Distribution 358 This document specifies that an LSR should advertise and receive 359 both IPv4 and IPv6 label bindings from and to the peer, only if it 360 has valid IPv4 and IPv6 Hello Adjacencies for that peer, as 361 specified in section 6.2. 363 This means that the LSR must not advertise any IPv6 label bindings 364 to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency 365 existed for that peer (and vice versa). 367 8. IANA Considerations 369 None. 371 9. Security Considerations 373 The extensions defined in this document only clarify the behavior of 374 LDP, they do not define any new protocol procedures. All the 375 security issues relevant for the [RFC5036] are relevant for this 376 document as well. 378 Moreover, this document allows the use of IPsec [RFC4301] for IPv6 379 protection, hence, LDP can benefit from the additional security as 380 specified in [RFC4835]. 382 10. Acknowledgments 384 A lot of the text in this document is borrowed from [RFC5036]. The 385 authors of the document are acknowledged. The authors also 386 aknowledge the help of Manoj Dutta and Vividh Siddha. Thanks to Bob 387 Thomas for providing critical feedback to improve this document 388 early on. Thanks to Kamran Raza, Eric Rosen, Lizhong Jin, Bin Mo, 389 Mach Chen, Kishore Tiruveedhula for reviewing this document. 391 This document was prepared using 2-Word-v2.0.template.dot. 393 11. References 395 11.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 401 Specification", RFC 5036, October 2007. 403 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 404 (IPv6) Specification", RFC 2460, December 1998. 406 [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 407 (IPv6) Addressing Architecture", RFC 3513, April 2003. 409 11.2. Informative References 411 [RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet 412 Protocol", RFC 4301, December 2005. 414 [RFC4853] Manral, V., "Cryptographic Algorithm Implementation 415 Requirements for Encapsulating Security Payload (ESP) and 416 Authentication Header (AH)", RFC 4835, April 2007. 418 [RFC5918] Asati, R. Minei, I., and Thomas, B., "Label Distribution 419 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 420 (FEC)", RFC 5918, April 2010. 422 [IANA-IPv6] http://www.iana.org/assignments/ipv6-address-space. 424 Author's Addresses 426 Vishwas Manral 427 IP Infusion Inc., 428 Bamankhola, Bansgali, 429 Almora, Uttarakhand 263601 430 Email: vishwas@ipinfusion.com 432 Rajiv Papneja 433 ISOCORE 434 12359 Sunrise Valley Dr, STE 100 435 Reston, VA 20190 436 Email: rpapneja@isocore.com 438 Rajiv Asati 439 Cisco Systems, 440 7025 Kit Creek Rd, RTP, NC, 27709-4987 441 Email: rajiva@cisco.com