idnits 2.17.1 draft-ietf-mpls-ldp-ipv6-12.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 5, 2014) is 3732 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: August 2014 6 Hewlett-Packard, Inc. 8 Rajiv Papneja 9 Huawei 11 Carlos Pignataro 12 Cisco 14 February 5, 2014 16 Updates to LDP for IPv6 17 draft-ietf-mpls-ldp-ipv6-12 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 5, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Abstract 65 The Label Distribution Protocol (LDP) specification defines 66 procedures to exchange label bindings over either IPv4, or IPv6 or 67 both networks. This document corrects and clarifies the LDP behavior 68 when IPv6 network is used (with or without IPv4). This document 69 updates RFC 5036. 71 Table of Contents 73 1. Introduction...................................................3 74 1.1. Scope.....................................................4 75 1.1.1. Topology Scenarios...................................4 76 1.1.2. LDP TTL Security.....................................5 77 2. Specification Language.........................................6 78 3. LSP Mapping....................................................6 79 4. LDP Identifiers................................................7 80 5. Peer Discovery.................................................7 81 5.1. Basic Discovery Mechanism.................................8 82 5.1.1. Maintaining Hello Adjacencies........................9 83 5.2. Extended Discovery Mechanism..............................9 84 6. LDP Session Establishment and Maintenance......................9 85 6.1. Transport connection establishment........................9 86 6.2. LDP Sessions Maintenance.................................11 87 7. Label Distribution............................................12 88 8. LDP Identifiers and Next Hop Addresses........................12 89 9. LDP TTL Security..............................................13 90 10. IANA Considerations..........................................14 91 11. Security Considerations......................................14 92 12. Acknowledgments..............................................14 93 13. Additional Contributors......................................14 94 14. References...................................................16 95 14.1. Normative References....................................16 96 14.2. Informative References..................................16 97 Appendix A.......................................................18 98 A.1. LDPv6 and LDPv4 Interoperability Safety Net..............18 99 A.2. Why 32-bit value even for IPv6 LDP Router ID.............18 100 Author's Addresses...............................................19 102 1. Introduction 104 The LDP [RFC5036] specification defines procedures and messages for 105 exchanging FEC-label bindings over either IPv4 or IPv6 or both (e.g. 106 dual-stack) networks. 108 However, RFC5036 specification has the following deficiencies in 109 regards to IPv6 usage: 111 1) LSP Mapping: No rule defined for mapping a particular packet to a 112 particular LSP that has an Address Prefix FEC element containing 113 IPv6 address of the egress router 115 2) LDP Identifier: No details specific to IPv6 usage 117 3) LDP Discovery: No details for using a particular IPv6 destination 118 (multicast) address or the source address (with or without IPv4 119 co-existence) 121 4) LDP Session establishment: No rule for handling both IPv4 and 122 IPv6 transport address optional objects in a Hello message, and 123 subsequently two IPv4 and IPv6 transport connections 125 5) LDP Label Distribution: No rule for advertising IPv4 or/and IPv6 126 FEC-label bindings over an LDP session, and denying the co- 127 existence of IPv4 and IPv6 FEC Elements in the same FEC TLV 129 6) Next Hop Address & LDP Identifier: No rule for accommodating the 130 usage of duplicate link-local IPv6 addresses 132 7) LDP TTL Security: No rule for built-in Generalized TTL Security 133 Mechanism (GTSM) in LDP 135 This document addresses the above deficiencies by specifying the 136 desired behavior/rules/details for using LDP in IPv6 enabled 137 networks (IPv6-only or Dual-stack networks). 139 Note that this document updates RFC5036. 141 1.1. Scope 143 1.1.1. Topology Scenarios 145 Two LSRs may involve basic and/or extended LDP discovery in IPv6 146 and/or IPv4 address-families in various topology scenarios. 148 This document addresses the following 3 topology scenarios in which 149 the LSRs may be connected via one or more dual-stack interfaces 150 (figure 1), or one or more single-stack interfaces (figure 2 and 151 figure 3): 153 R1------------------R2 154 IPv4+IPv6 156 Figure 1 LSRs connected via a Dual-stack Interface 158 IPv4 159 R1=================R2 160 IPv6 162 Figure 2 LSRs connected via two single-stack Interfaces 163 R1------------------R2---------------R3 164 IPv4 IPv6 166 Figure 3 LSRs connected via a single-stack Interface 168 Note that the topology scenario illustrated in figure 1 also covers 169 the case of a single-stack interface (IPv4, say) being converted to 170 a dual-stacked interface by enabling IPv6 routing as well as IPv6 171 LDP, even though the IPv4 LDP session may already be established 172 between the LSRs. 174 Note that the topology scenario illustrated in figure 2 also covers 175 the case of two routers getting connected via an additional single- 176 stack interface (IPv6 routing and IPv6 LDP), even though the IPv4 177 LDP session may already be established between the LSRs over the 178 existing interface(s). 180 This document also addresses the scenario in which the LSRs do 181 extended discovery in IPv6 and/or IPv4 address-families: 183 IPv4 184 R1-------------------R2 185 IPv6 187 Figure 4 LSRs involving IPv4 and IPv6 address-families 189 1.1.2. LDP TTL Security 191 LDP TTL Security mechanism specified by this document applies only 192 to single-hop LDP peering sessions, but not to multi-hop LDP peering 193 sessions, in line with Section 5.5 of [RFC5082] that describes 194 Generalized TTL Security Mechanism (GTSM). 196 As a consequence, any LDP feature that relies on multi-hop LDP 197 peering session would not work with GTSM and will warrant 198 (statically or dynamically) disabling GTSM. Please see section 8. 200 2. Specification Language 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 Abbreviations: 208 LDP - Label Distribution Protocol 210 LDPoIPv4 - LDP over IPv4 transport session 212 LDPoIPv6 - LDP over IPv6 transport session 214 FEC - Forwarding Equivalence Class 216 TLV - Type Length Value 218 LSR - Label Switching Router 220 LSP - Label Switched Path 222 LSPv4 - IPv4-signaled Label Switched Path [RFC4798] 224 LSPv6 - IPv6-signaled Label Switched Path [RFC4798] 226 AFI - Address Family Identifier 228 LDP Id - LDP Identifier 230 3. LSP Mapping 232 Section 2.1 of [RFC5036] specifies the procedure for mapping a 233 particular packet to a particular LSP using three rules. Quoting the 234 3rd rule from RFC5036: 236 "If it is known that a packet must traverse a particular egress 237 router, and there is an LSP that has an Address Prefix FEC element 238 that is a /32 address of that router, then the packet is mapped to 239 that LSP." 241 This rule is correct for IPv4, but not for IPv6, since an IPv6 242 router may even have a /64 or /96 or /128 (or whatever prefix 243 length) address. Hence, it is reasonable to say IPv4 or IPv6 address 244 instead of /32 or /128 addresses as shown below in the updated rule: 246 "If it is known that a packet must traverse a particular egress 247 router, and there is an LSP that has an Address Prefix FEC element 248 that is an IPv4 or IPv6 address of that router, then the packet is 249 mapped to that LSP." 251 4. LDP Identifiers 253 Section 2.2.2 of [RFC5036] specifies formulating at least one LDP 254 Identifier, however, it doesn't provide any consideration in case of 255 IPv6 (with or without dual-stacking). 257 The first four octets of the LDP identifier, the 32-bit LSR Id (e.g. 258 (i.e. LDP Router Id), identify the LSR and is a globally unique 259 value within the MPLS network. This is regardless of the address 260 family used for the LDP session. Hence, this document preserves the 261 usage of 32-bit (unsigned non-zero integer) LSR Id on an IPv6 only 262 LSR. 264 This document also qualifies the first sentence of last paragraph of 265 Section 2.5.2 of [RFC5036] to be per address family and therefore 266 updates that sentence to the following: 268 "For a given address family, an LSR MUST advertise the same 269 transport address in all Hellos that advertise the same label 270 space." 272 This rightly enables the per-platform label space to be shared 273 between IPv4 and IPv6. 275 In summary, this document allows the usage of a common LDP 276 identifier (same LSR Id aka LDP Router Id as well as a common Label 277 space id) for both IPv4 and IPv6 on a dual-stack LSR. 279 5. Peer Discovery 281 If an LSR is enabled with both IPv4 and IPv6 LDP, then the LSR MUST 282 include the same LDP Identifier (assuming per-platform label space 283 usage) in both IPv6 and IPv4 LDP Link or targeted Hellos. 285 5.1. Basic Discovery Mechanism 287 Section 2.4.1 of [RFC5036] defines the Basic Discovery mechanism for 288 directly connected LSRs. Following this mechanism, LSRs periodically 289 send LDP Link Hellos destined to "all routers on this subnet" group 290 multicast IP address. 292 Interesting enough, per the IPv6 addressing architecture [RFC4291], 293 IPv6 has three "all routers on this subnet" multicast addresses: 295 FF01:0:0:0:0:0:0:2 = Interface-local scope 297 FF02:0:0:0:0:0:0:2 = Link-local scope 299 FF05:0:0:0:0:0:0:2 = Site-local scope 301 [RFC5036] does not specify which particular IPv6 'all routers on 302 this subnet' group multicast IP address should be used by LDP Link 303 Hellos. 305 This document specifies the usage of link-local scope e.g. 306 FF02:0:0:0:0:0:0:2 as the destination multicast IP address in IPv6 307 LDP Link Hellos. An LDP Hello packet received on any of the other 308 destination addresses MUST be dropped. Additionally, the link-local 309 IPv6 address MUST be used as the source IP address in IPv6 LDP Link 310 Hellos. 312 Also, the LDP Link Hello packets MUST have their IPv6 Hop Limit set 313 to 255, be checked for the same upon receipt (before any LDP 314 specific processing) and be handled as specified in Generalized TTL 315 Security Mechanism (GTSM) section 3 of [RFC5082]. The built-in 316 inclusion of GTSM automatically protects IPv6 LDP from off-link 317 attacks. 319 More importantly, if an interface is a dual-stack LDP interface 320 (e.g. enabled with both IPv6 and IPv4 LDP), then the LSR MUST 321 periodically send both IPv6 and IPv4 LDP Link Hellos (using the same 322 LDP Identifier per section 4) on that interface and be able to 323 receive them. This facilitates discovery of IPv6-only, IPv4-only and 324 dual-stack peers on the interface's subnet and ensures successful 325 subsequent peering using the appropriate (address family) transport 326 on a multi-access or broadcast interface. 328 An implementation MUST send IPv6 LDP link Hellos before sending IPv4 329 LDP Link Hellos on a dual-stack interface. 331 5.1.1. Maintaining Hello Adjacencies 333 In case of dual-stack LDP interface, the LSR SHOULD maintain link 334 Hello adjacencies for both IPv4 and IPv6 address families. This 335 document, however, allows an LSR to maintain Rx-side Link Hello 336 adjacency for the address family that has been used for the 337 establishment of the LDP session (either IPv4 or IPv6). 339 5.2. Extended Discovery Mechanism 341 The extended discovery mechanism (defined in section 2.4.2 of 342 [RFC5036]), in which the targeted LDP Hellos are sent to a pre- 343 configured (unicast) destination IPv6 address, requires only one 344 IPv6 specific consideration: the link-local IPv6 addresses MUST NOT 345 be used as the targeted LDP hello packet's source or destination 346 addresses. 348 6. LDP Session Establishment and Maintenance 350 Section 2.5.1 of [RFC5036] defines a two-step process for LDP 351 session establishment, once the peer discovery has completed (LDP 352 Hellos have been exchanged): 354 1. Transport connection establishment 355 2. Session initialization 357 The forthcoming sub-section 6.1 discusses the LDP consideration for 358 IPv6 and/or dual-stacking in the context of session establishment, 359 whereas sub-section 6.2 discusses the LDP consideration for IPv6 360 and/or dual-stacking in the context of session maintenance. 362 6.1. Transport connection establishment 364 Section 2.5.2 of [RFC5036] specifies the use of an optional 365 transport address object (TLV) in LDP Hello message to convey the 366 transport (IP) address, however, it does not specify the behavior of 367 LDP if both IPv4 and IPv6 transport address objects (TLV) are sent 368 in a Hello message or separate Hello messages. More importantly, it 369 does not specify whether both IPv4 and IPv6 transport connections 370 should be allowed, if there were both IPv4 and IPv6 Hello 371 adjacencies. 373 This document specifies that: 375 1. An LSR MUST NOT send a Hello message containing both IPv4 and 376 IPv6 transport address optional objects. In other words, there 377 MUST be at most one optional Transport Address object in a 378 Hello message. An LSR MUST include only the transport address 379 whose address family is the same as that of the IP packet 380 carrying Hello message. 382 2. An LSR SHOULD accept the Hello message that contains both IPv4 383 and IPv6 transport address optional objects, but MUST use only 384 the transport address whose address family is the same as that 385 of the IP packet carrying the Hello message. An LSR SHOULD 386 accept only the first transport object for a given Address 387 family in the received Hello message, and ignore the rest, if 388 the LSR receives more than one transport object. 390 3. An LSR MUST send separate Hello messages (each containing 391 either IPv4 or IPv6 transport address optional object) for each 392 IP address family, if LDP was enabled for both IP address 393 families. 395 4. An LSR MUST use a global unicast IPv6 address in IPv6 transport 396 address optional object of outgoing targeted Hellos, and check 397 for the same in incoming targeted hellos (i.e. MUST discard the 398 hello, if it failed the check). 400 5. An LSR MUST prefer using a global unicast IPv6 address in IPv6 401 transport address optional object of outgoing Link Hellos, if 402 it had to choose between global unicast IPv6 address and 403 unique-local or link-local IPv6 address. 405 6. An LSR SHOULD NOT create (or honor the request for creating) a 406 TCP connection for a new LDP session with a remote LSR, if they 407 already have an LDP session (for the same LDP Identifier) 408 established over whatever IP version transport. 410 This means that only one transport connection is established 411 regardless of IPv6 or/and IPv4 Hello adjacencies presence 412 between two LSRs. 414 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new 415 LDP session with a remote LSR, if it is able to determine the 416 dual-stack presence (e.g. they have both IPv4 and IPv6 Hello 417 adjacencies). This applies to the section 2.5.2 of RFC5036. 419 Each LSR, assuming an active role for whichever address 420 family(s), SHOULD enforce the LDP/TCP connection over IPv6 421 preference for a time-period (default value is 5 seconds), 422 after which LDP/TCP connection over IPv4 SHOULD be attempted. 423 This enforcement is independent of whether the LSR is assuming 424 the active role for IPv4. This timer is started upon receiving 425 the first (IPv4 or IPv6) Hello from the neighbor. 427 An implementation may provide an option to favor one AFI (IPv4, say) 428 over another AFI (IPv6, say) for the TCP transport connection, so as 429 to use the favored IP version for the LDP session, and force 430 deterministic active/passive roles. 432 6.2. LDP Sessions Maintenance 434 This document specifies that two LSRs maintain a single LDP session 435 regardless of number of Link or Targeted Hello adjacencies between 436 them, as described in section 6.1. This is independent of whether: 438 - they are connected via a dual-stack LDP enabled interface or via 439 two single-stack LDP enabled interfaces; 440 - a single-stack interface is converted to a dual-stack interface 441 (e.g. figure 1) on either LSR; 442 - an additional single-stack or dual-stack interface is added or 443 removed between two LSRs (e.g. figure 2). 445 The procedures defined in section 6.1 SHOULD result in preferring 446 LDPoIPv6 session only after the loss of an existing LDP session 447 (because of link failure, node failure, reboot etc.). 449 If the last hello adjacency for a given address family goes down 450 (e.g. due to dual-stack interfaces being converted into a single- 451 stack interfaces on one LSR etc.), and that address family is the 452 same as the one used in the transport connection, then the transport 453 connection (LDP session) SHOULD be reset. Otherwise, the LDP session 454 SHOULD stay intact. 456 If the LDP session is torn down for whatever reason (LDP disabled 457 for the corresponding transport, hello adjacency expiry etc.), then 458 the LSRs SHOULD initiate establishing a new LDP session as per the 459 procedures described in section 6.1 of this document along with 460 RFC5036. 462 7. Label Distribution 464 An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings 465 for link-local IPv6 address, and ignore such bindings, if ever 466 received. An LSR MUST treat the IPv4-mapped IPv6 address, defined in 467 section 2.5.5.2 of [RFC4291], the same as that of a global IPv6 468 address and not mix it with the 'corresponding' IPv4 address. 470 Additionally, to ensure backward compatibility (and interoperability 471 with IPv4-only LDP implementations) in light of section 3.4.1.1 of 472 RFC5036, as rationalized in the Appendix section A.1 later, this 473 document specifies that - 475 1. An LSR MUST NOT send a label mapping message with a FEC TLV 476 containing two or more Prefix FEC Elements of different address 477 families. This means that a FEC TLV in the label mapping 478 message must contain all the Prefix FEC Elements belonging to 479 IPv6 address family or IPv4 address family, but not both. 481 An LSR may constrain the advertisement of FEC-label bindings for a 482 particular address family by negotiating the IP Capability for a 483 given AFI, as specified in [IPPWCap] document. This allows an LSR 484 pair to neither advertise nor receive the undesired FEC-label 485 bindings on a per AFI basis. 487 8. LDP Identifiers and Next Hop Addresses 489 RFC5036 section 2.7 specifies the logic for mapping the IP routing 490 next-hop (of a given FEC) to an LDP peer so as to find the correct 491 label entry for that FEC. The logic involves using the IP routing 492 next-hop address as an index into the (peer Address) database (which 493 is populated by the Address message containing mapping between each 494 peer's local addresses and its LDP Identifier) to determine the LDP 495 peer. 497 However, this logic is insufficient to deal with duplicate IPv6 498 (link-local) next-hop addresses used by two or more peers. The 499 reason is that all interior IPv6 routing protocols (can) use link- 500 local IPv6 addresses as the IP routing next-hops, and 'IPv6 501 Addressing Architecture [RFC4291]' allows a link-local IPv6 address 502 to be used on more than one links. 504 Hence, this logic is extended by this specification to use not only 505 the IP routing next-hop address, but also the IP routing next-hop 506 interface to uniquely determine the LDP peer(s). The next-hop 507 address-based LDP peer mapping is to be done through LDP peer 508 address database (populated by Address messages received from the 509 LDP peers), whereas next-hop interface-based LDP peer mapping is to 510 be done through LDP hello adjacency/interface database (populated by 511 hello messages from the LDP peers). 513 This extension solves the problem of two or more peers using the 514 same link-local IPv6 address (in other words, duplicate peer 515 addresses) as the IP routing next-hops. 517 Lastly, for better scale and optimization, an LSR may advertise only 518 the link-local IPv6 addresses in the Address message, assuming that 519 the peer uses only the link-local IPv6 addresses as static and/or 520 dynamic IP routing next-hops. 522 9. LDP TTL Security 524 This document recommends enabling Generalized TTL Security Mechanism 525 (GTSM) for LDP, as specified in [RFC6720], for the LDP/TCP transport 526 connection over IPv6 (i.e. LDPoIPv6). The GTSM inclusion is intended 527 to automatically protect IPv6 LDP peering session from off-link 528 attacks. 530 [RFC6720] allows for the implementation to statically 531 (configuration) and/or dynamically override the default behavior 532 (enable/disable GTSM) on a per-peer basis. Suffice to say that such 533 an option could be set on either LSR (since GTSM negotiation would 534 ultimately disable GTSM between LSR and its peer(s)). 536 LDP Link Hello packets MUST have their IPv6 Hop Limit set to 255, 537 and be checked for the same upon receipt before any further 538 processing, as per section 3 of [RFC5082]. 540 10. IANA Considerations 542 None. 544 11. Security Considerations 546 The extensions defined in this document only clarify the behavior of 547 LDP, they do not define any new protocol procedures. Hence, this 548 document does not add any new security issues to LDP. 550 While the security issues relevant for the [RFC5036] are relevant 551 for this document as well, this document reduces the chances of off- 552 link attacks when using IPv6 transport connection by including the 553 use of GTSM procedures [RFC5082]. Please see section 9 for LDP TTL 554 Security details. 556 Moreover, this document allows the use of IPsec [RFC4301] for IPv6 557 protection, hence, LDP can benefit from the additional security as 558 specified in [RFC4835] as well as [RFC5920]. 560 12. Acknowledgments 562 We acknowledge the authors of [RFC5036], since some text in this 563 document is borrowed from [RFC5036]. 565 Thanks to Bob Thomas for providing critical feedback to improve this 566 document early on. 568 Many thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach Chen, Shane 569 Amante, Pranjal Dutta, Mustapha Aissaoui, Matthew Bocci, Mark Tinka, 570 Tom Petch, Kishore Tiruveedhula, Manoj Dutta, Vividh Siddha, Qin Wu, 571 and Loa Andersson for thoroughly reviewing this document, and 572 providing insightful comments and multiple improvements. 574 This document was prepared using 2-Word-v2.0.template.dot. 576 13. Additional Contributors 578 The following individuals contributed to this document: 580 Kamran Raza 581 Cisco Systems, Inc. 582 2000 Innovation Drive 583 Kanata, ON K2K-3E8, Canada 584 Email: skraza@cisco.com 586 Nagendra Kumar 587 Cisco Systems, Inc. 588 SEZ Unit, Cessna Business Park, 589 Bangalore, KT, India 590 Email: naikumar@cisco.com 592 Andre Pelletier 593 Cisco Systems, Inc. 594 2000 Innovation Drive 595 Kanata, ON K2K-3E8, Canada 596 Email: apelleti@cisco.com 598 14. References 600 14.1. Normative References 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, March 1997. 605 [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 606 (IPv6) Addressing Architecture", RFC 4291, February 2006. 608 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 609 Specification", RFC 5036, October 2007. 611 [RFC5082] Pignataro, C., Gill, V., Heasley, J., Meyer, D., and 612 Savola, P., "The Generalized TTL Security Mechanism 613 (GTSM)", RFC 5082, October 2007. 615 14.2. Informative References 617 [RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet 618 Protocol", RFC 4301, December 2005. 620 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 621 Requirements for Encapsulating Security Payload (ESP) and 622 Authentication Header (AH)", RFC 4835, April 2007. 624 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 625 Networks", RFC 5920, July 2010. 627 [RFC4798] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS 628 Using IPv6 Provider Edge Routers (6PE)", RFC 4798, 629 February 2007. 631 [IPPWCap] Raza, K., "LDP IP and PW Capability", draft-ietf-mpls-ldp- 632 ip-pw-capability, June 2011. 634 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 635 for IPv6", RFC 5340, July 2008. 637 [RFC6286] E. Chen, and J. Yuan, "Autonomous-System-Wide Unique BGP 638 Identifier for BGP-4", RFC 6286, June 2011. 640 [RFC6720] R. Asati, and C. Pignataro, "The Generalized TTL Security 641 Mechanism (GTSM) for the Label Distribution Protocol 642 (LDP)", RFC 6720, August 2012. 644 Appendix A. 646 A.1. LDPv6 and LDPv4 Interoperability Safety Net 648 It is naive to assume that RFC5036 compliant implementations have 649 supported IPv6 address family (IPv6 FEC processing, in particular) 650 in label advertisement all along. And if that assumption turned out 651 to be not true, then section 3.4.1.1 of RFC5036 would cause LSRs to 652 abort processing the entire label mapping message and generate an 653 error. 655 This would result in LDPv6 to be somewhat undeployable in existing 656 production networks. 658 The change proposed in section 7 of this document provides a good 659 safety net and makes LDPv6 incrementally deployable without making 660 any such assumption on the routers' support for IPv6 FEC processing 661 in current production networks. 663 A.2. Why 32-bit value even for IPv6 LDP Router ID 665 Please note that 32-bit LSR Id value would not map to any IPv4- 666 address in an IPv6 only LSR (i.e., single stack), nor would there be 667 an expectation of it being IP routable, nor DNS-resolvable. In IPv4 668 deployments, the LSR Id is typically derived from an IPv4 address, 669 generally assigned to a loopback interface. In IPv6 only 670 deployments, this 32-bit LSR Id must be derived by some other means 671 that guarantees global uniqueness within the MPLS network, similar 672 to that of BGP Identifier [RFC6286] and OSPF router ID [RFC5340]. 674 This document reserves 0.0.0.0 as the LSR Id, and prohibits its 675 usage with IPv6, in line with OSPF router Id in OSPF version 3 676 [RFC5340]. 678 Author's Addresses 680 Vishwas Manral 681 Hewlet-Packard, Inc. 682 19111 Pruneridge Ave., Cupertino, CA, 95014 683 Phone: 408-447-1497 684 Email: vishwas.manral@hp.com 686 Rajiv Papneja 687 Huawei Technologies 688 2330 Central Expressway 689 Santa Clara, CA 95050 690 Phone: +1 571 926 8593 691 EMail: rajiv.papneja@huawei.com 693 Rajiv Asati 694 Cisco Systems, Inc. 695 7025 Kit Creek Road 696 Research Triangle Park, NC 27709-4987 697 Email: rajiva@cisco.com 699 Carlos Pignataro 700 Cisco Systems, Inc. 701 7200 Kit Creek Road 702 Research Triangle Park, NC 27709-4987 703 Email: cpignata@cisco.com