idnits 2.17.1 draft-ietf-mpls-ldp-ipv6-11.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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 (December 28, 2013) is 3772 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 (~~), 3 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: June 28, 2014 Hewlett-Packard, Inc. 7 Rajiv Papneja 8 Huawei 10 Carlos Pignataro 11 Cisco 13 December 28, 2013 15 Updates to LDP for IPv6 16 draft-ietf-mpls-ldp-ipv6-11 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 June 8, 2014. 35 Copyright Notice 37 Copyright (c) 2013 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 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Abstract 64 The Label Distribution Protocol (LDP) specification defines 65 procedures to exchange label bindings over either IPv4, or IPv6 or 66 both networks. This document corrects and clarifies the LDP behavior 67 when IPv6 network is used (with or without IPv4). This document 68 updates RFC 5036. 70 Table of Contents 72 1. Introduction...................................................3 73 1.1. Scope.....................................................4 74 1.1.1. Topology Scenarios...................................4 75 1.1.2. LDP TTL Security.....................................5 76 2. Specification Language.........................................5 77 3. LSP Mapping....................................................6 78 4. LDP Identifiers................................................6 79 5. Peer Discovery.................................................7 80 5.1. Basic Discovery Mechanism.................................7 81 5.2. Extended Discovery Mechanism..............................8 82 6. LDP Session Establishment and Maintenance......................8 83 6.1. Transport connection establishment........................9 84 6.2. Maintaining Hello Adjacencies............................10 85 6.3. Maintaining LDP Sessions.................................11 86 7. Label Distribution............................................12 87 8. LDP Identifiers and Next Hop Addresses........................12 88 9. LDP TTL Security..............................................13 89 10. IANA Considerations..........................................13 90 11. Security Considerations......................................14 91 12. Acknowledgments..............................................14 92 13. Additional Contributors......................................14 93 14. References...................................................16 94 14.1. Normative References....................................16 95 14.2. Informative References..................................16 96 Appendix.........................................................17 97 Author's Addresses...............................................17 99 1. Introduction 101 The LDP [RFC5036] specification defines procedures and messages for 102 exchanging FEC-label bindings over either IPv4 or IPv6 or both (e.g. 103 dual-stack) networks. 105 However, RFC5036 specification has the following deficiencies in 106 regards to IPv6 usage: 108 1) LSP Mapping: No rule defined for mapping a particular packet to a 109 particular LSP that has an Address Prefix FEC element containing 110 IPv6 address of the egress router 112 2) LDP Identifier: No details specific to IPv6 usage 114 3) LDP Discovery: No details for using a particular IPv6 destination 115 (multicast) address or the source address (with or without IPv4 116 co-existence) 118 4) LDP Session establishment: No rule for handling both IPv4 and 119 IPv6 transport address optional objects in a Hello message, and 120 subsequently two IPv4 and IPv6 transport connections 122 5) LDP Label Distribution: No rule for advertising IPv4 or/and IPv6 123 FEC-label bindings over an LDP session, and denying the co- 124 existence of IPv4 and IPv6 FEC Elements in the same FEC TLV 126 6) Next Hop Address & LDP Identifier: No rule for accommodating the 127 usage of duplicate link-local IPv6 addresses 129 7) LDP TTL Security: No rule for built-in Generalized TTL Security 130 Mechanism (GTSM) in LDP 132 This document addresses the above deficiencies by specifying the 133 desired behavior/rules/details for using LDP in IPv6 enabled 134 networks (IPv6-only or Dual-stack networks). 136 Note that this document updates RFC5036. 138 1.1. Scope 140 1.1.1. Topology Scenarios 142 The following scenarios in which the LSRs may be inter-connected via 143 one or more dual-stack interfaces (figure 1), or one or more single- 144 stack interfaces (figure 2 and figure 3) are addressed by this 145 document: 147 R1------------------R2 148 IPv4+IPv6 150 Figure 1 LSRs connected via a Dual-stack Interface 152 IPv4 153 R1=================R2 154 IPv6 156 Figure 2 LSRs connected via two single-stack Interfaces 158 R1------------------R2---------------R3 159 IPv4 IPv6 161 Figure 3 LSRs connected via a single-stack Interface 163 Note that the topology scenario illustrated in figure 1 also covers 164 the case of a single-stack interface (IPv4, say) being converted to 165 a dual-stacked interface by enabling IPv6 routing as well as IPv6 166 LDP, even though the IPv4 LDP session may already be established 167 between the LSRs. 169 Note that the topology scenario illustrated in figure 2 also covers 170 the case of two routers getting connected via an additional single- 171 stack interface (IPv6 routing and IPv6 LDP), even though the IPv4 172 LDP session may already be established between the LSRs over the 173 existing interface(s). 175 1.1.2. LDP TTL Security 177 LDP TTL Security mechanism specified by this document applies only 178 to single-hop LDP peering sessions, but not to multi-hop LDP peering 179 sessions, in line with Section 5.5 of [RFC5082] that describes 180 Generalized TTL Security Mechanism (GTSM). 182 As a consequence, any LDP feature that relies on multi-hop LDP 183 peering session would not work with GTSM and will warrant 184 (statically or dynamically) disabling GTSM. Please see section 8. 186 2. Specification Language 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 Abbreviations: 194 LDP - Label Distribution Protocol 196 LDPv4 - LDP for enabling IPv4 MPLS forwarding 198 LDPv6 - LDP for enabling IPv6 MPLS forwarding 200 LDPoIPv4 - LDP over IPv4 transport session 202 LDPoIPv6 - LDP over IPv6 transport session 204 FEC - Forwarding Equivalence Class 206 TLV - Type Length Value 208 LSR - Label Switch Router 210 LSP - Label Switched Path 212 LSPv4 - IPv4-signaled Label Switched Path [RFC4798] 214 LSPv6 - IPv6-signaled Label Switched Path [RFC4798] 216 AFI - Address Family Identifier 218 3. LSP Mapping 220 Section 2.1 of [RFC5036] specifies the procedure for mapping a 221 particular packet to a particular LSP using three rules. Quoting the 222 3rd rule from RFC5036: 224 "If it is known that a packet must traverse a particular egress 225 router, and there is an LSP that has an Address Prefix FEC element 226 that is a /32 address of that router, then the packet is mapped to 227 that LSP." 229 Suffice to say, this rule is correct for IPv4, but not for IPv6, 230 since an IPv6 router may not have any /32 address. 232 This document proposes to modify this rule by also including a /128 233 address (for IPv6). In fact, it should be reasonable to just say 234 IPv4 or IPv6 address instead of /32 or /128 addresses as shown below 235 in the updated rule: 237 "If it is known that a packet must traverse a particular egress 238 router, and there is an LSP that has an Address Prefix FEC element 239 that is an IPv4 or IPv6 address of that router, then the packet is 240 mapped to that LSP." 242 4. LDP Identifiers 244 Section 2.2.2 of [RFC5036] specifies formulating at least one LDP 245 Identifier, however, it doesn't provide any consideration in case of 246 IPv6 (with or without dual-stacking). 248 The first four octets of the LDP identifier, the 32-bit LSR Id (e.g. 249 (i.e. LDP Router Id), identify the LSR and is a globally unique 250 value within the MPLS network. This is regardless of the address 251 family used for the LDP session. Hence, this document preserves the 252 usage of 32-bit (unsigned non-zero integer) LSR Id on an IPv6 only 253 LSR (note that BGP has also mandated using 32-bit BGP Router ID on 254 an IPv6 only Router [RFC6286]). 256 Please note that 32-bit LSR Id value would not map to any IPv4- 257 address in an IPv6 only LSR (i.e., single stack), nor would there 258 be an expectation of it being DNS-resolvable. In IPv4 deployments, 259 the LSR Id is typically derived from an IPv4 address, generally 260 assigned to a loopback interface. In IPv6 only deployments, this 261 32-bit LSR Id must be derived by some other means that guarantees 262 global uniqueness within the MPLS network, similar to that of BGP 263 Identifier [RFC6286]. 265 This document qualifies the first sentence of last paragraph of 266 Section 2.5.2 of [RFC5036] to be per address family and therefore 267 updates that sentence to the following: "For a given address family, 268 an LSR MUST advertise the same transport address in all Hellos that 269 advertise the same label space." This rightly enables the per- 270 platform label space to be shared between IPv4 and IPv6. 272 In summary, this document not only allows the usage of a common LDP 273 identifier i.e. same LSR-Id (aka LDP Router-Id), but also the common 274 Label space id for both IPv4 and IPv6 on a dual-stack LSR. 276 This document reserves 0.0.0.0 as the LSR-Id, and prohibits its 277 usage. 279 5. Peer Discovery 281 5.1. Basic Discovery Mechanism 283 Section 2.4.1 of [RFC5036] defines the Basic Discovery mechanism for 284 directly connected LSRs. Following this mechanism, LSRs periodically 285 sends LDP Link Hellos destined to "all routers on this subnet" group 286 multicast IP address. 288 Interesting enough, per the IPv6 addressing architecture [RFC4291], 289 IPv6 has three "all routers on this subnet" multicast addresses: 291 FF01:0:0:0:0:0:0:2 = Interface-local scope 293 FF02:0:0:0:0:0:0:2 = Link-local scope 295 FF05:0:0:0:0:0:0:2 = Site-local scope 297 [RFC5036] does not specify which particular IPv6 'all routers on 298 this subnet' group multicast IP address should be used by LDP Link 299 Hellos. 301 This document specifies the usage of link-local scope e.g. 302 FF02:0:0:0:0:0:0:2 as the destination multicast IP address in IPv6 303 LDP Link Hellos. An LDP Hello packet received on any of the other 304 destination addresses must be dropped. Additionally, the link-local 305 IPv6 address MUST be used as the source IP address in IPv6 LDP Link 306 Hellos. 308 Also, the LDP Link Hello packets must have their IPv6 Hop Limit set 309 to 255, and be checked for the same upon receipt before any further 310 processing, as specified in Generalized TTL Security Mechanism 311 (GTSM)[RFC5082]. The built-in inclusion of GTSM automatically 312 protects IPv6 LDP from off-link attacks. 314 More importantly, if an interface is a dual-stack LDP interface 315 (e.g. enabled with both IPv6 and IPv4 LDP), then the LSR must 316 periodically send both IPv6 and IPv4 LDP Link Hellos (using the same 317 LDP Identifier per section 4) on that interface and be able to 318 receive them. This facilitates discovery of IPv6-only, IPv4-only and 319 dual-stack peers on the interface's subnet. 321 An implementation should prefer sending IPv6 LDP link Hellos 322 before sending IPv4 LDP Link Hellos on a dual-stack interface, if 323 possible. 325 Lastly, the IPv6 and IPv4 LDP Link Hellos MUST carry the same LDP 326 identifier (assuming per-platform label space usage). 328 5.2. Extended Discovery Mechanism 330 Suffice to say, the extended discovery mechanism (defined in section 331 2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific 332 consideration, since the targeted LDP Hellos are sent to a pre- 333 configured (unicast) destination IPv6 address. 335 The link-local IP addresses MUST NOT be used as the source or 336 destination IPv6 addresses in extended discovery. 338 6. LDP Session Establishment and Maintenance 340 Section 2.5.1 of [RFC5036] defines a two-step process for LDP 341 session establishment, once the peer discovery has completed (LDP 342 Hellos have been exchanged): 344 1. Transport connection establishment 345 2. Session initialization 347 The forthcoming sub-sections discuss the LDP consideration for IPv6 348 and/or dual-stacking in the context of session establishment and 349 maintenance. 351 6.1. Transport connection establishment 353 Section 2.5.2 of [RFC5036] specifies the use of an optional 354 transport address object (TLV) in LDP Link Hello message to convey 355 the transport (IP) address, however, it does not specify the 356 behavior of LDP if both IPv4 and IPv6 transport address objects 357 (TLV) are sent in a Hello message or separate Hello messages. More 358 importantly, it does not specify whether both IPv4 and IPv6 359 transport connections should be allowed, if there were Hello 360 adjacencies for both IPv4 and IPv6 whether over a single interface 361 or multiple interfaces. 363 This document specifies that: 365 1. An LSR MUST NOT send a Hello containing both IPv4 and IPv6 366 transport address optional objects. In other words, there MUST 367 be at most one optional Transport Address object in a Hello 368 message. An LSR MUST include only the transport address whose 369 address family is the same as that of the IP packet carrying 370 Hello. 372 2. An LSR SHOULD accept the Hello message that contains both IPv4 373 and IPv6 transport address optional objects, but MUST use only 374 the transport address whose address family is the same as that 375 of the IP packet carrying Hello. An LSR SHOULD accept only the 376 first transport object for a given Address family in the 377 received Hello message, and ignore the rest, if the LSR 378 receives more than one transport object. 380 3. An LSR MUST send separate Hellos (each containing either IPv4 381 or IPv6 transport address optional object) for each IP address 382 family, if LDP was enabled for both IP address families. 384 4. An LSR MUST use a global unicast IPv6 address in IPv6 transport 385 address optional object of outgoing targeted hellos, and check 386 for the same in incoming targeted hellos (i.e. MUST discard the 387 hello, if it failed the check). 389 5. An LSR MUST prefer using global unicast IPv6 address for an LDP 390 session with a remote LSR, if it had to choose between global 391 unicast IPv6 address and unique-local or link-local IPv6 392 address (pertaining to the same LDP Identifier) for the 393 transport connection. 395 6. An LSR SHOULD NOT create (or honor the request for creating) a 396 TCP connection for a new LDP session with a remote LSR, if they 397 already have an LDP session (for the same LDP Identifier) 398 established over whatever IP version transport. 400 This means that only one transport connection is established, 401 regardless of one or two Hello adjacencies (one for IPv4 and 402 another for IPv6) are created & maintained over a single 403 interface (scenario 1 in section 1.1) or multiple interfaces 404 (scenario 2 in section 1.1) between two LSRs. 406 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new 407 LDP session with a remote LSR, if it has both IPv4 and IPv6 408 hello adjacencies for the same (peer) LDP Identifier (over a 409 dual-stack interface, or two or more single-stack IPv4 and IPv6 410 interfaces). This applies to the section 2.5.2 of RFC5036. 412 Each LSR, assuming an active role for whichever address 413 family(s), should enforce this LDP/TCP connection over IPv6 414 preference for a time-period (default value is 15 seconds), 415 after which LDP/TCP connection over IPv4 should be attempted. 416 This enforcement is independent of whether the LSR is assuming 417 the active role for IPv4. This timer is started upon receiving 418 the first hello from the neighbor. 420 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new 421 LDP session with a remote LSR, if they attempted two TCP 422 connections using different transport address families (IPv4 423 and IPv6) simultaneously. 425 An implementation may provide an option to favor one AFI (IPv4, say) 426 over another AFI (IPv6, say) for the TCP transport connection, so as 427 to use the favored IP version for the LDP session, and force 428 deterministic active/passive roles. 430 6.2. Maintaining Hello Adjacencies 432 In line with the section 2.5.5 of RFC5036, this draft describes that 433 if an LSR has a dual-stack interface, which is enabled with both 434 IPv6 and IPv4 LDP, then the LSR must periodically send and receive 435 both IPv6 and IPv4 LDP Link Hellos. 437 This ensures successful LDP discovery and subsequent peering using 438 the appropriate (address family) transport on a multi-access or 439 broadcast interface (even if there are IPv6-only, IPv4-only and 440 dual-stack LSRs connected to that interface). 442 While the LSR receives both IPv4 and IPv6 LDP Link Hello messages on 443 the interface, this document however allows an LSR to maintain 444 Rx-side Link Hello adjacency for the address family that has been 445 used for the establishment of the LDP session (either IPv4 or IPv6), 446 or to maintain Rx-side Link Hellp adjacency for both IPv4 and IPv6 447 address families. 449 6.3. Maintaining LDP Sessions 451 Two LSRs maintain a single LDP session between them (i.e. not tear 452 down an existing session), as described in section 6.1, whether 454 - they are connected via a dual-stack LDP enabled interface or via 455 two single-stack LDP enabled interfaces; 456 - a single-stack interface is converted to a dual-stack interface 457 (e.g. figure 1) on either LSR; 458 - an additional single-stack or dual-stack interface is added or 459 removed between two LSRs (e.g. figure 2). 461 Needless to say that the procedures defined in section 6.1 should 462 result in preferring LDPoIPv6 session only after the loss of an 463 existing LDP session (because of link failure, node failure, reboot 464 etc.). 466 If the last hello adjacency for a given address family goes down 467 (e.g. due to dual-stack interfaces being converted into a single- 468 stack interfaces on one LSR etc.), and that address family is the 469 same as the one used in the transport connection, then the transport 470 connection (LDP session) SHOULD be reset. Otherwise, the LDP session 471 should stay intact. 473 If the LDP session is torn down for whatever reason (LDP disabled 474 for the corresponding transport, hello adjacency expiry etc.), then 475 the LSRs should initiate establishing a new LDP session as per the 476 procedures described in section 6.1 of this document along with 477 RFC5036. 479 7. Label Distribution 481 An LSR MUST NOT allocate and advertise FEC-Label bindings for link- 482 local IPv6 address, and ignore such bindings, if ever received. An 483 LSR MUST treat the IPv4-mapped IPv6 address, defined in section 484 2.5.5.2 of [RFC4291], the same as that of a global IPv6 address and 485 not mix it with the 'corresponding' IPv4 address. 487 Additionally, to ensure backward compatibility (and interoperability 488 with IPv4-only LDP implementations) in light of section 3.4.1.1 of 489 RFC5036, as rationalized in the Appendix A.1, this document 490 specifies that - 492 1. An LSR MUST NOT send a label mapping message with a FEC TLV 493 containing FEC Elements of different address family. In other 494 words, a FEC TLV in the label mapping message MUST contain the 495 FEC Elements belonging to the same address family. 496 2. An LSR MUST NOT send an Address message (or Address Withdraw 497 message) with an Address List TLV containing IP addresses of 498 different address family. In other words, an Address List TLV 499 in the Address (or Address Withdraw) message MUST contain the 500 addresses belonging to the same address family. 502 An LSR MAY constrain the advertisement of FEC-label bindings for a 503 particular address family by negotiating the IP Capability for a 504 given AFI, as specified in [IPPWCap] document. 506 8. LDP Identifiers and Next Hop Addresses 508 RFC5036 section 2.7 specifies the logic for mapping the IP routing 509 next-hop (of a given FEC) to an LDP peer so as to find the correct 510 label entry for that FEC. The logic involves using the IP routing 511 next-hop address as an index into the (peer Address) database (which 512 is populated by the Address message containing mapping between each 513 peer's local addresses and its LDP Identifier) to determine the LDP 514 peer. 516 However, this logic is insufficient to deal with duplicate IPv6 517 (link-local) next-hop addresses used by two or more peers. The 518 reason is that all interior IPv6 routing protocols (can) use link- 519 local IPv6 addresses as the IP routing next-hops, and 'IPv6 520 Addressing Architecture [RFC4291]' allows a link-local IPv6 address 521 to be used on more than one links. 523 Hence, this logic is extended by this specification to involve not 524 only the IP routing next-hop address, but also the IP routing next- 525 hop interface to uniquely determine the LDP peer(s). The next-hop 526 address-based LDP peer mapping is to be done through LDP peer 527 address database (populated by Address messages received from the 528 LDP peers), whereas next-hop interface-based LDP peer mapping is to 529 be done through LDP hello adjacency/interface database (populated by 530 hello messages from the LDP peers). 532 This extension solves the problem of two or more peers using the 533 same link-local IPv6 address (in other words, duplicate addresses) 534 as the IP routing next-hops. 536 Lastly, for better scale and optimization, an LSR may advertise only 537 the link-local IPv6 addresses in the Address message, assuming that 538 the peer uses only the link-local IPv6 addresses as static and/or 539 dynamic IP routing next-hops. 541 9. LDP TTL Security 543 This document recommends enabling Generalized TTL Security Mechanism 544 (GTSM) for LDP, as specified in [RFC6720], for the LDP/TCP transport 545 connection over IPv6 (i.e. LDPoIPv6). 547 [RFC6720] allows for the implementation to statically 548 (configuration) and/or dynamically override the default behavior 549 (enable/disable GTSM) on a per-peer basis. Suffice to say that such 550 an option could be set on either LSR (since GTSM negotiation would 551 ultimately disable GTSM between LSR and its peer(s)). 553 The GTSM inclusion is intended to automatically protect IPv6 LDP 554 peering session from off-link attacks. 556 10. IANA Considerations 558 None. 560 11. Security Considerations 562 The extensions defined in this document only clarify the behavior of 563 LDP, they do not define any new protocol procedures. Hence, this 564 document does not add any new security issues to LDP. 566 While the security issues relevant for the [RFC5036] are relevant 567 for this document as well, this document reduces the chances of off- 568 link attacks when using IPv6 transport connection by including the 569 use of GTSM procedures [RFC5082]. 571 Moreover, this document allows the use of IPsec [RFC4301] for IPv6 572 protection, hence, LDP can benefit from the additional security as 573 specified in [RFC4835] as well as [RFC5920]. 575 12. Acknowledgments 577 We acknowledge the authors of [RFC5036], since some text in this 578 document is borrowed from [RFC5036]. 580 Thanks to Bob Thomas for providing critical feedback to improve this 581 document early on. 583 Many thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach Chen, Shane 584 Amante, Pranjal Dutta, Mustapha Aissaoui, Matthew Bocci, Mark Tinka, 585 Tom Petch, Kishore Tiruveedhula, Manoj Dutta, Vividh Siddha, Qin Wu, 586 and Loa Andersson for thoroughly reviewing this document, and 587 providing insightful comments and multiple improvements. 589 Also, thanks to Andre Pelletier (who brought up the issue about 590 active/passive determination, and helped us craft the appropriate 591 solutions). 593 13. Additional Contributors 595 The following individuals contributed to this document: 597 Kamran Raza 598 Cisco Systems, Inc. 599 2000 Innovation Drive 600 Kanata, ON K2K-3E8, Canada 601 Email: skraza@cisco.com 602 Nagendra Kumar 603 Cisco Systems, Inc. 604 SEZ Unit, Cessna Business Park, 605 Bangalore, KT, India 606 Email: naikumar@cisco.com 608 Andre Pelletier 609 Email: apelleti@cisco.com 611 14. References 613 14.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, March 1997. 618 [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 619 (IPv6) Addressing Architecture", RFC 4291, February 2006. 621 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 622 Specification", RFC 5036, October 2007. 624 [RFC5082] Pignataro, C., Gill, V., Heasley, J., Meyer, D., and 625 Savola, P., "The Generalized TTL Security Mechanism 626 (GTSM)", RFC 5082, October 2007. 628 14.2. Informative References 630 [RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet 631 Protocol", RFC 4301, December 2005. 633 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 634 Requirements for Encapsulating Security Payload (ESP) and 635 Authentication Header (AH)", RFC 4835, April 2007. 637 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 638 Networks", RFC 5920, July 2010. 640 [RFC4798] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS 641 Using IPv6 Provider Edge Routers (6PE)", RFC 4798, 642 February 2007. 644 [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security 645 Mechanism (GTSM) for the Label Distribution Protocol 646 (LDP)", RFC 6720, August 2012 648 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 649 Identifier for BGP-4", RFC 6286, June 2011. 651 [IPPWCap] Raza, K., "LDP IP and PW Capability", draft-ietf-mpls-ldp- 652 ip-pw-capability, June 2011. 654 Appendix 656 It is naive to assume that RFC5036 compliant implementations have 657 supported IPv6 address family (IPv6 FEC processing, in particular) 658 in label advertisement all along. And if that assumption turned out 659 to be not true, then section 3.4.1.1 of RFC5036 would cause LSRs to 660 abort processing the entire label mapping message and generate an 661 error. 663 This would result in LDPv6 to be somewhat undeployable in existing 664 production networks. 666 The change proposed in section 7 of this document provides a good 667 safety net and makes LDPv6 incrementally deployable without making 668 any such assumption on the routers' support for IPv6 FEC processing 669 in current production networks. 671 Author's Addresses 673 Vishwas Manral 674 Hewlet-Packard, Inc. 675 19111 Pruneridge Ave., Cupertino, CA, 95014 676 Phone: 408-447-1497 677 Email: vishwas.manral@hp.com 679 Rajiv Papneja 680 Huawei Technologies 681 2330 Central Expressway 682 Santa Clara, CA 95050 683 Phone: +1 571 926 8593 684 EMail: rajiv.papneja@huawei.com 686 Rajiv Asati 687 Cisco Systems, Inc. 688 7025 Kit Creek Road 689 Research Triangle Park, NC 27709-4987 690 Email: rajiva@cisco.com 691 Carlos Pignataro 692 Cisco Systems, Inc. 693 7200 Kit Creek Road 694 Research Triangle Park, NC 27709-4987 695 Email: cpignata@cisco.com