idnits 2.17.1 draft-ietf-mpls-ldp-ipv6-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (Using the creation date from RFC5036, updated by this document, for RFC5378 checks: 2004-10-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 23, 2011) is 4623 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) -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Rajiv Asati 2 Internet Draft Cisco 3 Updates: 5036 (if approved) 4 Intended status: Standards Track Vishwas Manral 5 Expires: February 23, 2012 Hewlett-Packard, Inc. 7 Rajiv Papneja 8 Isocore 10 Carlos Pignataro 11 Cisco 13 August 23, 2011 15 Updates to LDP for IPv6 16 draft-ietf-mpls-ldp-ipv6-05 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 23, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 The Label Distribution Protocol (LDP) specification defines 53 procedures to exchange label bindings over either IPv4, IPv6 or both 54 networks. This document corrects and clarifies the LDP behavior when 55 IPv6 network is used (with or without IPv4). This document updates 56 RFC 5036. 58 Table of Contents 60 1. Introduction...................................................3 61 1.1. Scope.....................................................3 62 1.1.1. Topology Scenarios...................................3 63 1.1.2. LDP TTL Security.....................................4 64 2. Specification Language.........................................5 65 3. LSP Mapping....................................................5 66 4. LDP Identifiers................................................6 67 5. Peer Discovery.................................................7 68 5.1. Basic Discovery Mechanism.................................7 69 5.2. Extended Discovery Mechanism..............................8 70 6. LDP Session Establishment and Maintenance......................8 71 6.1. Transport connection establishment........................8 72 6.2. Maintaining Hello Adjacencies............................10 73 6.3. Maintaining LDP Sessions.................................10 74 7. Label Distribution............................................10 75 8. LDP TTL Security..............................................11 76 9. IANA Considerations...........................................12 77 10. Security Considerations......................................12 78 11. Acknowledgments..............................................12 79 12. References...................................................14 80 12.1. Normative References....................................14 81 12.2. Informative References..................................14 82 Author's Addresses...............................................15 84 1. Introduction 86 The LDP [RFC5036] specification defines procedures and messages for 87 exchanging FEC-label bindings over either IPv4 or IPv6 or both (e.g. 88 dual-stack) networks. 90 However, RFC5036 specification has the following deficiencies in 91 regards to IPv6 usage: 93 1) LSP Mapping: No rule defined for mapping a particular packet to a 94 particular LSP that has an Address Prefix FEC element containing 95 IPv6 address of the egress router 97 2) LDP Identifier: No details specific to IPv6 usage 99 3) LDP Discovery: No details for using a particular IPv6 multicast 100 address (with or without IPv4 co-existence) 102 4) LDP Session establishment: No rule for handling both IPv4 and 103 IPv6 transport address optional objects in a Hello message, and 104 subsequently two IPv4 and IPv6 transport connections 106 5) LDP TTL Security: No rule for built-in Generalized TTL Security 107 Mechanism (GTSM) in LDP 109 6) LDP Label Distribution: No rule for advertising IPv4 or/and IPv6 110 FEC-label bindings over an LDP session 112 This document addresses the above deficiencies by specifying the 113 desired behavior/rules/details for using LDP in IPv6 enabled 114 networks. It also clarifies the scope (section 1.1). 116 Note that this document updates RFC5036. 118 1.1. Scope 120 1.1.1. Topology Scenarios 122 The following scenarios in which the LSRs may be inter-connected via 123 one or more dual-stack interfaces (figure 1), or two or more single- 124 stack interfaces (figure 2 and figure 3) are addressed by this 125 document: 127 R1------------------R2 128 IPv4+IPv6 130 Figure 1 LSRs connected via a Dual-stack Interface 132 IPv4 133 R1=================R2 134 IPv6 136 Figure 2 LSRs connected via two single-stack Interfaces 138 R1------------------R2---------------R3 139 IPv4 IPv6 141 Figure 3 LSRs connected via a single-stack Interface 143 Note that the topology scenario illustrated in figure 1 also covers 144 the case of a single-stack interface (IPv4, say) being converted to 145 a dual-stacked interface by enabling IPv6 as well as IPv6 LDP, even 146 though the IPv4 LDP session may already be established between the 147 LSRs. 149 Note that the topology scenario illustrated in figure 2 also covers 150 the case of two routers getting connected via an additional single- 151 stack interface (IPv6, say), even though the IPv4 LDP session may 152 already be established between the LSRs over the existing interface. 154 1.1.2. LDP TTL Security 156 LDP TTL Security mechanism specified by this document applies only 157 to single-hop LDP peering sessions, but not to multi-hop LDP peering 158 sessions, in line with Section 5.5 of [RFC5082] that describes 159 Generalized TTL Security Mechanism (GTSM). 161 As a consequence, any LDP feature that relies on multi-hop LDP 162 peering session would not work with GTSM and will warrant 163 (statically or dynamically) disabling GTSM. Please see section 8. 165 2. Specification Language 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 Abbreviations: 173 LDP - Label Distribution Protocol 175 LDPv4 - LDP for enabling IPv4 MPLS forwarding 177 LDPv6 - LDP for enabling IPv6 MPLS forwarding 179 LDPoIPv4 - LDP over IPv4 transport session 181 LDPoIPv6 - LDP over IPv6 transport session 183 FEC - Forwarding Equivalence Class 185 TLV - Type Length Value 187 LSR - Label Switch Router 189 LSP - Label Switched Path 191 3. LSP Mapping 193 Section 2.1 of [RFC5036] specifies the procedure for mapping a 194 particular packet to a particular LSP using three rules. Quoting the 195 3rd rule from RFC5036: 197 "If it is known that a packet must traverse a particular egress 198 router, and there is an LSP that has an Address Prefix FEC element 199 that is a /32 address of that router, then the packet is mapped to 200 that LSP." 202 Suffice to say, this rule is correct for IPv4, but not for IPv6, 203 since an IPv6 router may not have any /32 address. 205 This document proposes to modify this rule by also including a /128 206 address (for IPv6). In fact, it should be reasonable to just say 207 IPv4 or IPv6 address instead of /32 or /128 addresses as shown below 208 in the updated rule: 210 "If it is known that a packet must traverse a particular egress 211 router, and there is an LSP that has an Address Prefix FEC element 212 that is an IPv4 or IPv6 address of that router, then the packet is 213 mapped to that LSP." 215 While the above rule mentions 'Address Prefix FEC', it is also 216 applicable to 'Typed WildCard prefix FEC' [RFC5918]. 218 Additionally, it is desirable that a packet is forwarded to an LSP 219 of an egress router, only if LSP's address-family matches with that 220 of the LDP hello adjacency on the next-hop interface. 222 4. LDP Identifiers 224 Section 2.2.2 of [RFC5036] specifies formulating at least one LDP 225 Identifier, however, it doesn't provide any consideration in case of 226 IPv6 (with or without dual-stacking). Additionally, section 2.5.2 of 227 [RFC5036] implicitly prohibits using the same label space for both 228 IPv4 and IPv6 FEC-label bindings. 230 The first four octets of the LDP identifier, the 32-bit LSR Id, 231 identify the LSR and is a globally unique value. This is regardless 232 of the address family used for the LDP session. In other words, this 233 document preserves the usage of 32-bit LSR Id on an IPv6 only LSR. 235 Please note that 32-bit LSR Id value would not map to any IPv4- 236 address in an IPv6 only LSR (i.e., single stack), nor would there 237 be an expectation of it being DNS-resolvable. In IPv4 deployments, 238 the LSR Id is typically derived from an IPv4 address, generally 239 assigned to a loopback interface. In IPv6 only deployments, this 240 32-bit LSR Id must be derived by some other means that guarantees 241 global uniqueness. 243 The first sentence of last paragraph of Section 2.5.2 of [RFC5036] 244 is qualified per address family and therefore updated to the 245 following: "For a given address family over which a Hello is sent, 246 and a given label space, an LSR MUST advertise the same transport 247 address." This rightly enables the per-platform label space to be 248 shared between IPv4 and IPv6. 250 In summary, this document not only allows the usage of a common LDP 251 identifier i.e. same LSR-Id, but also the common Label space id for 252 both IPv4 and IPv6 on a dual-stack LSR. 254 This document reserves 0.0.0.0 as the LSR-Id, and prohibits its 255 usage. 257 5. Peer Discovery 259 5.1. Basic Discovery Mechanism 261 Section 2.4.1 of [RFC5036] defines the Basic Discovery mechanism for 262 directly connected LSRs. Following this mechanism, LSRs periodically 263 sends LDP Link Hellos destined to "all routers on this subnet" group 264 multicast IP address. 266 Interesting enough, per the IPv6 addressing architecture [RFC4291], 267 IPv6 has three "all routers on this subnet" multicast addresses: 269 FF01:0:0:0:0:0:0:2 = Interface-local scope 271 FF02:0:0:0:0:0:0:2 = Link-local scope 273 FF05:0:0:0:0:0:0:2 = Site-local scope 275 [RFC5036] does not specify which particular IPv6 'all routers on 276 this subnet' group multicast IP address should be used by LDP Link 277 Hellos. 279 This document specifies the usage of link-local scope e.g. 280 FF02:0:0:0:0:0:0:2 as the destination multicast IP address for IPv6 281 LDP Link Hellos. An LDP Hello packet received on any of the other 282 addresses must be dropped. 284 Also, the LDP Link Hello packets must have their IPv6 Hop Limit set 285 to 255, and be checked for the same upon receipt before any further 286 processing, as specified in Generalized TTL Security Mechanism 287 (GTSM)[RFC5082]. The built-in inclusion of GTSM automatically 288 protects IPv6 LDP from off-link attacks. 290 More importantly, if an interface is a dual-stack LDP interface 291 (e.g. enabled with both IPv4 and IPv6 LDP), then the LSR must 292 periodically send both IPv4 and IPv6 LDP Link Hellos (using the same 293 LDP Identifier per section 4) and must separately maintain the Hello 294 adjacency for IPv4 and IPv6 on that interface. 296 Needless to say, the IPv4 and IPv6 LDP Link Hellos must carry the 297 same LDP identifier (assuming per-platform label space usage). 299 5.2. Extended Discovery Mechanism 301 Suffice to say, the extended discovery mechanism (defined in section 302 2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific 303 consideration, since the targeted LDP Hellos are sent to a pre- 304 configured destination IPv6 address. 306 6. LDP Session Establishment and Maintenance 308 Section 2.5.1 of [RFC5036] defines a two-step process for LDP 309 session establishment, once the peer discovery has completed (LDP 310 Hellos have been exchanged): 312 1. Transport connection establishment 313 2. Session initialization 315 The forthcoming sub-sections discuss the LDP consideration for IPv6 316 and/or dual-stacking in the context of session establishment and 317 maintenance. 319 6.1. Transport connection establishment 321 Section 2.5.2 of [RFC5036] specifies the use of an optional 322 transport address object (TLV) in LDP Link Hello message to convey 323 the transport (IP) address, however, it does not specify the 324 behavior of LDP if both IPv4 and IPv6 transport address objects 325 (TLV) are sent in a Hello message or separate Hello messages. More 326 importantly, it does not specify whether both IPv4 and IPv6 327 transport connections should be allowed, if there were Hello 328 adjacencies for both IPv4 and IPv6 whether over a single interface 329 or multiple interfaces. 331 This document specifies that: 333 - An LSR should not send a Hello containing both IPv4 and IPv6 334 transport address optional objects. In other words, there 335 should be at most one optional Transport Address object in a 336 Hello message. An LSR should include only the transport address 337 whose address family is the same as that of the IP packet 338 carrying Hello. 340 - An LSR should accept the Hello message that contains both IPv4 341 and IPv6 transport address optional objects, but use only the 342 transport address whose address family is the same as that of 343 the IP packet carrying Hello. 345 - An LSR must send separate Hellos (each containing either IPv4 346 or IPv6 transport address optional object) for each IP address- 347 family, if LDP was enabled for both IP address-families. 349 - An LSR should not create (or honor the request for creating) a 350 TCP connection for a new LDP session with a remote LSR, if they 351 already have an LDP session (for the same LDP Identifier) 352 established over whatever IP version transport. This means that 353 only one transport connection should be established, even if 354 there are two Hello adjacencies (one for IPv4 and another for 355 IPv6). This is independent of whether the Hello Adjacencies are 356 created over a single interface (scenarios 1 in section 1.1) or 357 multiple interfaces (scenario 2 in section 1.1) between two 358 LSRs. 360 - An LSR should prefer the LDP/TCP connection over IPv6 for a new 361 LDP session with a remote LSR, if it has both IPv4 and IPv6 362 hello adjacencies for the same LDP Identifier (over a dual- 363 stack interface, or two or more single-stack IPv4 and IPv6 364 interfaces). This applies to the section 2.5.2 of RFC5036. 366 - An LSR should prefer the LDP/TCP connection over IPv6 for a new 367 LDP session with a remote LSR, if they attempted two TCP 368 connections using IPv4 and IPv6 transport addresses 369 simultaneously. 371 This document allows for the implementation to provide a 372 configuration option to override the above stated preference from 373 IPv6 to IPv4 on a per-peer basis. Suffice to say that such option 374 must be set on both LSRs. 376 6.2. Maintaining Hello Adjacencies 378 As outlined in section 2.5.5 of RFC5036, this draft suggests that if 379 an LSR has a dual-stack interface, which is enabled with both IPv4 380 and IPv6 LDP, then the LSR must periodically send both IPv4 and IPv6 381 LDP Link Hellos and must separately maintain the Hello adjacency for 382 IPv4 and IPv6 on that interface. 384 This ensures successful labeled IPv4 and labeled IPv6 traffic 385 forwarding on a dual-stacked interface, as well as successful LDP 386 peering using the appropriate transport on a multi-access 387 interface (even if there are IPv4-only, IPv6-only and dual-stack 388 LSRs connected to that multi-access interface). 390 6.3. Maintaining LDP Sessions 392 Two LSRs maintain a single LDP session between them, as described in 393 section 6.1, whether they are connected via a dual-stack LDP enabled 394 interface or via two single-stack LDP enabled interfaces. This is 395 also true when a single-stack interface is converted to a dual-stack 396 interface, or when another interface is added between two LSRs. 398 On the other hand, if a dual-stack interface is converted to a 399 single-stack interface (by disabling IPv4 or IPv6 routing), then the 400 LDP session should be torn down ONLY if the disabled IP version was 401 the same as that of the transport connection. Otherwise, the LDP 402 session should stay intact. 404 If the LDP session is torn down for whatever reason (LDP disabled 405 for the corresponding transport, hello adjacency expiry etc.), then 406 the LSRs should initiate establishing a new LDP session as per the 407 procedures described in section 6.1 of this document and RFC5036. 409 7. Label Distribution 411 This document specifies that an LSR should advertise and receive 412 both IPv4 and IPv6 label bindings from and to the peer, only if it 413 has valid IPv4 and IPv6 Hello Adjacencies for that peer, as 414 specified in section 6.2. 416 This means that the LSR must not advertise any IPv6 label bindings 417 to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency 418 existed for that peer (and vice versa). 420 8. LDP TTL Security 422 This document also specifies that the LDP/TCP transport connection 423 over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security 424 Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP 425 session peering established between the adjacent LSRs using Basic 426 Discovery, by default. 428 In other words, GTSM is enabled by default for an IPv6 LDP peering 429 session using Basic Discovery. This means that the 'IP Hop Limit' in 430 IPv6 packet is set to 255 upon sending, and checked to be 255 upon 431 receipt. The IPv6 packet must be dropped failing such a check upon 432 receipt. 434 The reason GTSM is enabled for Basic Discovery by default, but not 435 for Extended Discovery is that the usage of Basic Discovery 436 typically results in a single-hop LDP peering session, whereas the 437 usage of Extended Discovery typically results in a multi-hop LDP 438 peering session. While the latter is deemed out of scope (section 439 1.2), in line with GTSM [RFC5082], it is worth clarifying the 440 following exceptions that may occur with Basic or Extended Discovery 441 usage: 443 a) Two adjacent LSRs (i.e. back-to-back PE routers) forming a 444 single-hop LDP peering session after doing an Extended Discovery 445 (for Pseudowire, say) 446 b) Two adjacent LSRs forming a multi-hop LDP peering session after 447 doing a Basic Discovery, due to the way IP routing is setup 448 between them (temporarily or permanently) 449 c) Two adjacent LSRs (i.e. back-to-back PE routers) forming a 450 single-hop LDP peering session after doing both Basic and 451 Extended Discovery 453 In (a), GTSM is not enabled for the LDP peering session by default, 454 hence, it would not do any harm or good. 456 In (b), GTSM is enabled by default for the LDP peering session by 457 default and enforced, hence, it would prohibit the LDP peering 458 session from getting established. 460 In (c), GTSM is enabled by default for Basic Discovery and enforced 461 on the subsequent LDP peering. However, if each LSR uses the same 462 IPv6 transport address object value in both Basic and Extended 463 discoveries, then it would result in a single LDP peering session 464 and that would be enabled with GTSM. Otherwise, GTSM would not be 465 enforced on the 2nd LDP peering session corresponding to the 466 Extended Discovery. 468 This document allows for the implementation to provide an option to 469 statically (configuration) and/or dynamically override the default 470 behavior (i.e. disable GTSM) on a per-peer basis. This would also 471 address the exception (b) above. Suffice to say that such an option 472 could be set on either LSR (since GTSM negotiation would ultimately 473 disable GTSM between an LSR and its peer(s)). 475 The built-in GTSM inclusion is intended to automatically protect 476 IPv6 LDP peering session from off-link attacks. 478 9. IANA Considerations 480 None. 482 10. Security Considerations 484 The extensions defined in this document only clarify the behavior of 485 LDP, they do not define any new protocol procedures. Hence, this 486 document does not add any new security issues to LDP. 488 While the security issues relevant for the [RFC5036] are relevant 489 for this document as well, this document reduces the chances of off- 490 link attacks when using IPv6 transport connection by including the 491 use of GTSM procedures [RFC5082]. 493 Moreover, this document allows the use of IPsec [RFC4301] for IPv6 494 protection, hence, LDP can benefit from the additional security as 495 specified in [RFC4835] as well as [RFC5920]. 497 11. Acknowledgments 499 We acknowledge the authors of [RFC5036], since the text in this 500 document is borrowed from [RFC5036]. 502 Thanks to Bob Thomas for providing critical feedback to improve this 503 document early on. Thanks to Kamran Raza, Eric Rosen, Lizhong Jin, 504 Bin Mo, Mach Chen, and Kishore Tiruveedhula for reviewing this 505 document. The authors also acknowledge the help of Manoj Dutta and 506 Vividh Siddha. 508 This document was prepared using 2-Word-v2.0.template.dot. 510 12. References 512 12.1. Normative References 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 518 (IPv6) Addressing Architecture", RFC 4291, February 2006. 520 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 521 Specification", RFC 5036, October 2007. 523 [RFC5082] Pignataro, C., Gill, V., Heasley, J., Meyer, D., and 524 Savola, P., "The Generalized TTL Security Mechanism 525 (GTSM)", RFC 5082, October 2007. 527 12.2. Informative References 529 [RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet 530 Protocol", RFC 4301, December 2005. 532 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 533 Requirements for Encapsulating Security Payload (ESP) and 534 Authentication Header (AH)", RFC 4835, April 2007. 536 [RFC5918] Asati, R. Minei, I., and Thomas, B., "Label Distribution 537 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 538 (FEC)", RFC 5918, April 2010. 540 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 541 Networks", RFC 5920, July 2010. 543 Author's Addresses 545 Vishwas Manral 546 Hewlet-Packard, Inc. 547 19111 Pruneridge Ave., Cupertino, CA, 95014 548 Phone: 408-447-1497 549 Email: vishwas.manral@hp.com 551 Rajiv Papneja 552 ISOCORE 553 12359 Sunrise Valley Dr, STE 100 554 Reston, VA 20190 555 Email: rpapneja@isocore.com 557 Rajiv Asati 558 Cisco Systems, Inc. 559 7025 Kit Creek Road 560 Research Triangle Park, NC 27709-4987 561 Email: rajiva@cisco.com 563 Carlos Pignataro 564 Cisco Systems, Inc. 565 7200 Kit Creek Road 566 Research Triangle Park, NC 27709-4987 567 Email: cpignata@cisco.com