idnits 2.17.1 draft-ietf-mpls-ldp-ipv6-10.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 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 (December 8, 2013) is 3789 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: 'RFC6286' is mentioned on line 252, but not defined == Missing Reference: 'RFC6720' is mentioned on line 533, but not defined -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) Summary: 0 errors (**), 0 flaws (~~), 5 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 8, 2014 Hewlett-Packard, Inc. 7 Rajiv Papneja 8 Huawei 10 Carlos Pignataro 11 Cisco 13 December 8, 2013 15 Updates to LDP for IPv6 16 draft-ietf-mpls-ldp-ipv6-10 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 Abstract 52 The Label Distribution Protocol (LDP) specification defines 53 procedures to exchange label bindings over either IPv4, or IPv6 or 54 both networks. This document corrects and clarifies the LDP behavior 55 when IPv6 network is used (with or without IPv4). This document 56 updates RFC 5036. 58 Table of Contents 60 1. Introduction...................................................3 61 1.1. Scope.....................................................4 62 1.1.1. Topology Scenarios...................................4 63 1.1.2. LDP TTL Security.....................................5 64 2. Specification Language.........................................5 65 3. LSP Mapping....................................................6 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........................9 72 6.2. Maintaining Hello Adjacencies............................10 73 6.3. Maintaining LDP Sessions.................................11 74 7. Label Distribution............................................12 75 8. LDP Identifiers and Next Hop Addresses........................12 76 9. LDP TTL Security..............................................13 77 10. IANA Considerations..........................................13 78 11. Security Considerations......................................14 79 12. Acknowledgments..............................................14 80 13. Additional Contributors......................................14 81 14. References...................................................16 82 14.1. Normative References....................................16 83 14.2. Informative References..................................16 84 15. Appendix.....................................................17 85 15.1. A.1.....................................................17 86 Author's Addresses...............................................17 88 1. Introduction 90 The LDP [RFC5036] specification defines procedures and messages for 91 exchanging FEC-label bindings over either IPv4 or IPv6 or both (e.g. 92 dual-stack) networks. 94 However, RFC5036 specification has the following deficiencies in 95 regards to IPv6 usage: 97 1) LSP Mapping: No rule defined for mapping a particular packet to a 98 particular LSP that has an Address Prefix FEC element containing 99 IPv6 address of the egress router 101 2) LDP Identifier: No details specific to IPv6 usage 103 3) LDP Discovery: No details for using a particular IPv6 destination 104 (multicast) address or the source address (with or without IPv4 105 co-existence) 107 4) LDP Session establishment: No rule for handling both IPv4 and 108 IPv6 transport address optional objects in a Hello message, and 109 subsequently two IPv4 and IPv6 transport connections 111 5) LDP Label Distribution: No rule for advertising IPv4 or/and IPv6 112 FEC-label bindings over an LDP session, and denying the co- 113 existence of IPv4 and IPv6 FEC Elements in the same FEC TLV 115 6) Next Hop Address & LDP Identifier: No rule for accommodating the 116 usage of duplicate link-local IPv6 addresses 118 7) LDP TTL Security: No rule for built-in Generalized TTL Security 119 Mechanism (GTSM) in LDP 121 This document addresses the above deficiencies by specifying the 122 desired behavior/rules/details for using LDP in IPv6 enabled 123 networks (IPv6-only or Dual-stack networks). 125 Note that this document updates RFC5036. 127 1.1. Scope 129 1.1.1. Topology Scenarios 131 The following scenarios in which the LSRs may be inter-connected via 132 one or more dual-stack interfaces (figure 1), or one or more single- 133 stack interfaces (figure 2 and figure 3) are addressed by this 134 document: 136 R1------------------R2 137 IPv4+IPv6 139 Figure 1 LSRs connected via a Dual-stack Interface 141 IPv4 142 R1=================R2 143 IPv6 145 Figure 2 LSRs connected via two single-stack Interfaces 147 R1------------------R2---------------R3 148 IPv4 IPv6 150 Figure 3 LSRs connected via a single-stack Interface 152 Note that the topology scenario illustrated in figure 1 also covers 153 the case of a single-stack interface (IPv4, say) being converted to 154 a dual-stacked interface by enabling IPv6 routing as well as IPv6 155 LDP, even though the IPv4 LDP session may already be established 156 between the LSRs. 158 Note that the topology scenario illustrated in figure 2 also covers 159 the case of two routers getting connected via an additional single- 160 stack interface (IPv6 routing and IPv6 LDP), even though the IPv4 161 LDP session may already be established between the LSRs over the 162 existing interface(s). 164 1.1.2. LDP TTL Security 166 LDP TTL Security mechanism specified by this document applies only 167 to single-hop LDP peering sessions, but not to multi-hop LDP peering 168 sessions, in line with Section 5.5 of [RFC5082] that describes 169 Generalized TTL Security Mechanism (GTSM). 171 As a consequence, any LDP feature that relies on multi-hop LDP 172 peering session would not work with GTSM and will warrant 173 (statically or dynamically) disabling GTSM. Please see section 8. 175 2. Specification Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 Abbreviations: 183 LDP - Label Distribution Protocol 185 LDPv4 - LDP for enabling IPv4 MPLS forwarding 187 LDPv6 - LDP for enabling IPv6 MPLS forwarding 189 LDPoIPv4 - LDP over IPv4 transport session 191 LDPoIPv6 - LDP over IPv6 transport session 193 FEC - Forwarding Equivalence Class 195 TLV - Type Length Value 197 LSR - Label Switch Router 199 LSP - Label Switched Path 201 LSPv4 - IPv4-signaled Label Switched Path [RFC4798] 203 LSPv6 - IPv6-signaled Label Switched Path [RFC4798] 205 AFI - Address Family Identifier 207 3. LSP Mapping 209 Section 2.1 of [RFC5036] specifies the procedure for mapping a 210 particular packet to a particular LSP using three rules. Quoting the 211 3rd rule from RFC5036: 213 "If it is known that a packet must traverse a particular egress 214 router, and there is an LSP that has an Address Prefix FEC element 215 that is a /32 address of that router, then the packet is mapped to 216 that LSP." 218 Suffice to say, this rule is correct for IPv4, but not for IPv6, 219 since an IPv6 router may not have any /32 address. 221 This document proposes to modify this rule by also including a /128 222 address (for IPv6). In fact, it should be reasonable to just say 223 IPv4 or IPv6 address instead of /32 or /128 addresses as shown below 224 in the updated rule: 226 "If it is known that a packet must traverse a particular egress 227 router, and there is an LSP that has an Address Prefix FEC element 228 that is an IPv4 or IPv6 address of that router, then the packet is 229 mapped to that LSP." 231 4. LDP Identifiers 233 Section 2.2.2 of [RFC5036] specifies formulating at least one LDP 234 Identifier, however, it doesn't provide any consideration in case of 235 IPv6 (with or without dual-stacking). 237 The first four octets of the LDP identifier, the 32-bit LSR Id (e.g. 238 (i.e. LDP Router Id), identify the LSR and is a globally unique 239 value within the MPLS network. This is regardless of the address 240 family used for the LDP session. Hence, this document preserves the 241 usage of 32-bit (unsigned non-zero integer) LSR Id on an IPv6 only 242 LSR (note that BGP has also mandated using 32-bit BGP Router ID on 243 an IPv6 only Router [RFC6286]). 245 Please note that 32-bit LSR Id value would not map to any IPv4- 246 address in an IPv6 only LSR (i.e., single stack), nor would there 247 be an expectation of it being DNS-resolvable. In IPv4 deployments, 248 the LSR Id is typically derived from an IPv4 address, generally 249 assigned to a loopback interface. In IPv6 only deployments, this 250 32-bit LSR Id must be derived by some other means that guarantees 251 global uniqueness within the MPLS network, similar to that of BGP 252 Identifier [RFC6286]. 254 This document qualifies the first sentence of last paragraph of 255 Section 2.5.2 of [RFC5036] to be per address family and therefore 256 updates that sentence to the following: "For a given address family, 257 an LSR MUST advertise the same transport address in all Hellos that 258 advertise the same label space." This rightly enables the per- 259 platform label space to be shared between IPv4 and IPv6. 261 In summary, this document not only allows the usage of a common LDP 262 identifier i.e. same LSR-Id (aka LDP Router-Id), but also the common 263 Label space id for both IPv4 and IPv6 on a dual-stack LSR. 265 This document reserves 0.0.0.0 as the LSR-Id, and prohibits its 266 usage. 268 5. Peer Discovery 270 5.1. Basic Discovery Mechanism 272 Section 2.4.1 of [RFC5036] defines the Basic Discovery mechanism for 273 directly connected LSRs. Following this mechanism, LSRs periodically 274 sends LDP Link Hellos destined to "all routers on this subnet" group 275 multicast IP address. 277 Interesting enough, per the IPv6 addressing architecture [RFC4291], 278 IPv6 has three "all routers on this subnet" multicast addresses: 280 FF01:0:0:0:0:0:0:2 = Interface-local scope 282 FF02:0:0:0:0:0:0:2 = Link-local scope 284 FF05:0:0:0:0:0:0:2 = Site-local scope 286 [RFC5036] does not specify which particular IPv6 'all routers on 287 this subnet' group multicast IP address should be used by LDP Link 288 Hellos. 290 This document specifies the usage of link-local scope e.g. 291 FF02:0:0:0:0:0:0:2 as the destination multicast IP address in IPv6 292 LDP Link Hellos. An LDP Hello packet received on any of the other 293 destination addresses must be dropped. Additionally, the link-local 294 IPv6 address MUST be used as the source IP address in IPv6 LDP Link 295 Hellos. 297 Also, the LDP Link Hello packets must have their IPv6 Hop Limit set 298 to 255, and be checked for the same upon receipt before any further 299 processing, as specified in Generalized TTL Security Mechanism 300 (GTSM)[RFC5082]. The built-in inclusion of GTSM automatically 301 protects IPv6 LDP from off-link attacks. 303 More importantly, if an interface is a dual-stack LDP interface 304 (e.g. enabled with both IPv6 and IPv4 LDP), then the LSR must 305 periodically send both IPv6 and IPv4 LDP Link Hellos (using the same 306 LDP Identifier per section 4) on that interface and be able to 307 receive them. This facilitates discovery of IPv6-only, IPv4-only and 308 dual-stack peers on the interface's subnet. 310 An implementation should prefer sending IPv6 LDP link Hellos 311 before sending IPv4 LDP Link Hellos on a dual-stack interface, if 312 possible. 314 Lastly, the IPv6 and IPv4 LDP Link Hellos must carry the same LDP 315 identifier (assuming per-platform label space usage). 317 5.2. Extended Discovery Mechanism 319 Suffice to say, the extended discovery mechanism (defined in section 320 2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific 321 consideration, since the targeted LDP Hellos are sent to a pre- 322 configured (unicast) destination IPv6 address. 324 The link-local IP addresses MUST NOT be used as the source or 325 destination IPv6 addresses in extended discovery. 327 6. LDP Session Establishment and Maintenance 329 Section 2.5.1 of [RFC5036] defines a two-step process for LDP 330 session establishment, once the peer discovery has completed (LDP 331 Hellos have been exchanged): 333 1. Transport connection establishment 334 2. Session initialization 336 The forthcoming sub-sections discuss the LDP consideration for IPv6 337 and/or dual-stacking in the context of session establishment and 338 maintenance. 340 6.1. Transport connection establishment 342 Section 2.5.2 of [RFC5036] specifies the use of an optional 343 transport address object (TLV) in LDP Link Hello message to convey 344 the transport (IP) address, however, it does not specify the 345 behavior of LDP if both IPv4 and IPv6 transport address objects 346 (TLV) are sent in a Hello message or separate Hello messages. More 347 importantly, it does not specify whether both IPv4 and IPv6 348 transport connections should be allowed, if there were Hello 349 adjacencies for both IPv4 and IPv6 whether over a single interface 350 or multiple interfaces. 352 This document specifies that: 354 1. An LSR MUST NOT send a Hello containing both IPv4 and IPv6 355 transport address optional objects. In other words, there MUST 356 be at most one optional Transport Address object in a Hello 357 message. An LSR MUST include only the transport address whose 358 address family is the same as that of the IP packet carrying 359 Hello. 361 2. An LSR SHOULD accept the Hello message that contains both IPv4 362 and IPv6 transport address optional objects, but MUST use only 363 the transport address whose address family is the same as that 364 of the IP packet carrying Hello. An LSR SHOULD accept only the 365 first transport object for a given Address family in the 366 received Hello message, and ignore the rest, if the LSR 367 receives more than one transport object. 369 3. An LSR MUST send separate Hellos (each containing either IPv4 370 or IPv6 transport address optional object) for each IP address 371 family, if LDP was enabled for both IP address families. 373 4. An LSR MUST use a global unicast IPv6 address in IPv6 transport 374 address optional object of outgoing targeted hellos, and check 375 for the same in incoming targeted hellos (i.e. MUST discard the 376 hello, if it failed the check). 378 5. An LSR MUST prefer using global unicast IPv6 address for an LDP 379 session with a remote LSR, if it had to choose between global 380 unicast IPv6 address and unique-local or link-local IPv6 381 address (pertaining to the same LDP Identifier) for the 382 transport connection. 384 6. An LSR SHOULD NOT create (or honor the request for creating) a 385 TCP connection for a new LDP session with a remote LSR, if they 386 already have an LDP session (for the same LDP Identifier) 387 established over whatever IP version transport. 389 This means that only one transport connection is established, 390 regardless of one or two Hello adjacencies (one for IPv4 and 391 another for IPv6) are created & maintained over a single 392 interface (scenario 1 in section 1.1) or multiple interfaces 393 (scenario 2 in section 1.1) between two LSRs. 395 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new 396 LDP session with a remote LSR, if it has both IPv4 and IPv6 397 hello adjacencies for the same (peer) LDP Identifier (over a 398 dual-stack interface, or two or more single-stack IPv4 and IPv6 399 interfaces). This applies to the section 2.5.2 of RFC5036. 401 Each LSR, assuming an active role for whichever address 402 family(s), should enforce this LDP/TCP connection over IPv6 403 preference for a time-period (default value is 15 seconds), 404 after which LDP/TCP connection over IPv4 should be attempted. 405 This enforcement is independent of whether the LSR is assuming 406 the active role for IPv4. This timer is started upon receiving 407 the first hello from the neighbor. 409 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new 410 LDP session with a remote LSR, if they attempted two TCP 411 connections using different transport address families (IPv4 412 and IPv6) simultaneously. 414 An implementation may provide an option to favor one AFI (IPv4, say) 415 over another AFI (IPv6, say) for the TCP transport connection, so as 416 to use the favored IP version for the LDP session, and force 417 deterministic active/passive roles. 419 6.2. Maintaining Hello Adjacencies 421 In line with the section 2.5.5 of RFC5036, this draft describes that 422 if an LSR has a dual-stack interface, which is enabled with both 423 IPv6 and IPv4 LDP, then the LSR must periodically send and receive 424 both IPv6 and IPv4 LDP Link Hellos. 426 This ensures successful LDP discovery and subsequent peering using 427 the appropriate (address family) transport on a multi-access or 428 broadcast interface (even if there are IPv6-only, IPv4-only and 429 dual-stack LSRs connected to that interface). 431 This document allows an LSR to maintain Rx-side Link Hello adjacency 432 for only one address family that has been used for the establishment 433 of the LDP session. 435 6.3. Maintaining LDP Sessions 437 Two LSRs maintain a single LDP session between them (i.e. not tear 438 down an existing session), as described in section 6.1, whether 440 - they are connected via a dual-stack LDP enabled interface or via 441 two single-stack LDP enabled interfaces; 442 - a single-stack interface is converted to a dual-stack interface 443 (e.g. figure 1) on either LSR; 444 - an additional single-stack or dual-stack interface is added or 445 removed between two LSRs (e.g. figure 2). 447 Needless to say that the procedures defined in section 6.1 should 448 result in preferring LDPoIPv6 session only after the loss of an 449 existing LDP session (because of link failure, node failure, reboot 450 etc.). 452 If the last hello adjacency for a given address family goes down 453 (e.g. due to dual-stack interfaces being converted into a single- 454 stack interfaces on one LSR etc.), and that address family is the 455 same as the one used in the transport connection, then the transport 456 connection (LDP session) SHOULD be reset. Otherwise, the LDP session 457 should stay intact. 459 If the LDP session is torn down for whatever reason (LDP disabled 460 for the corresponding transport, hello adjacency expiry etc.), then 461 the LSRs should initiate establishing a new LDP session as per the 462 procedures described in section 6.1 of this document along with 463 RFC5036. 465 7. Label Distribution 467 An LSR MUST NOT allocate and advertise FEC-Label bindings for link- 468 local IPv6 address, and ignore such bindings, if ever received. An 469 LSR MUST treat the IPv4-mapped IPv6 address, defined in section 470 2.5.5.2 of [RFC4291], the same as that of a global IPv6 address and 471 not mix it with the 'corresponding' IPv4 address. 473 Additionally, to ensure backward compatibility (and interoperability 474 with IPv4-only LDP implementations) in light of section 3.4.1.1 of 475 RFC5036, as rationalized in the Appendix A.1, this document 476 specifies that - 478 1. An LSR MUST NOT send a label mapping message with a FEC TLV 479 containing FEC Elements of different address family. In other 480 words, a FEC TLV in the label mapping message MUST contain the 481 FEC Elements belonging to the same address family. 482 2. An LSR MUST NOT send an Address message (or Address Withdraw 483 message) with an Address List TLV containing IP addresses of 484 different address family. In other words, an Address List TLV 485 in the Address (or Address Withdraw) message MUST contain the 486 addresses belonging to the same address family. 488 An LSR MAY constrain the advertisement of FEC-label bindings for a 489 particular address family by negotiating the IP Capability for a 490 given AFI, as specified in [IPPWCap] document. 492 8. LDP Identifiers and Next Hop Addresses 494 RFC5036 section 2.7 specifies the logic for mapping the IP routing 495 next-hop (of a given FEC) to an LDP peer so as to find the correct 496 label entry for that FEC. The logic involves using the IP routing 497 next-hop address as an index into the (peer Address) database (which 498 is populated by the Address message containing mapping between each 499 peer's local addresses and its LDP Identifier) to determine the LDP 500 peer. 502 However, this logic is insufficient to deal with duplicate IPv6 503 (link-local) next-hop addresses used by two or more peers. The 504 reason is that all interior IPv6 routing protocols (can) use link- 505 local IPv6 addresses as the IP routing next-hops, and 'IPv6 506 Addressing Architecture [RFC4291]' allows a link-local IPv6 address 507 to be used on more than one links. 509 Hence, this logic is extended by this specification to involve not 510 only the IP routing next-hop address, but also the IP routing next- 511 hop interface to uniquely determine the LDP peer(s). The next-hop 512 address-based LDP peer mapping is to be done through LDP peer 513 address database (populated by Address messages received from the 514 LDP peers), whereas next-hop interface-based LDP peer mapping is to 515 be done through LDP hello adjacency/interface database (populated by 516 hello messages from the LDP peers). 518 This extension solves the problem of two or more peers using the 519 same link-local IPv6 address (in other words, duplicate addresses) 520 as the IP routing next-hops. 522 Lastly, for better scale and optimization, an LSR may advertise only 523 the link-local IPv6 addresses in the Address message, assuming that 524 the peer uses only the link-local IPv6 addresses as static and/or 525 dynamic IP routing next-hops. 527 9. LDP TTL Security 529 This document recommends enabling Generalized TTL Security Mechanism 530 (GTSM) for LDP, as specified in [RFC6720], for the LDP/TCP transport 531 connection over IPv6 (i.e. LDPoIPv6). 533 [RFC6720] allows for the implementation to statically 534 (configuration) and/or dynamically override the default behavior 535 (enable/disable GTSM) on a per-peer basis. Suffice to say that such 536 an option could be set on either LSR (since GTSM negotiation would 537 ultimately disable GTSM between LSR and its peer(s)). 539 The GTSM inclusion is intended to automatically protect IPv6 LDP 540 peering session from off-link attacks. 542 10. IANA Considerations 544 None. 546 11. Security Considerations 548 The extensions defined in this document only clarify the behavior of 549 LDP, they do not define any new protocol procedures. Hence, this 550 document does not add any new security issues to LDP. 552 While the security issues relevant for the [RFC5036] are relevant 553 for this document as well, this document reduces the chances of off- 554 link attacks when using IPv6 transport connection by including the 555 use of GTSM procedures [RFC5082]. 557 Moreover, this document allows the use of IPsec [RFC4301] for IPv6 558 protection, hence, LDP can benefit from the additional security as 559 specified in [RFC4835] as well as [RFC5920]. 561 12. Acknowledgments 563 We acknowledge the authors of [RFC5036], since the text in this 564 document is borrowed from [RFC5036]. 566 Thanks to Bob Thomas for providing critical feedback to improve this 567 document early on. Thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach 568 Chen, Shane Amante, Pranjal Dutta, Mustapha Aissaoui, Mark Tinka, 569 Tom Petch and Kishore Tiruveedhula for reviewing this document. The 570 authors also acknowledge the help of Manoj Dutta and Vividh Siddha. 572 Also, thanks to Andre Pelletier (who brought up the issue about 573 active/passive determination, and helped us craft the appropriate 574 solutions). 576 This document was prepared using 2-Word-v2.0.template.dot. 578 13. Additional Contributors 580 The following individuals contributed to this document: 582 Kamran Raza 583 Cisco Systems, Inc. 584 2000 Innovation Drive 585 Kanata, ON K2K-3E8, Canada 586 Email: skraza@cisco.com 587 Nagendra Kumar 588 Cisco Systems, Inc. 589 SEZ Unit, Cessna Business Park, 590 Bangalore, KT, India 591 Email: naikumar@cisco.com 593 Andre Pelletier 594 Email: apelleti@cisco.com 596 14. References 598 14.1. Normative References 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, March 1997. 603 [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 604 (IPv6) Addressing Architecture", RFC 4291, February 2006. 606 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 607 Specification", RFC 5036, October 2007. 609 [RFC5082] Pignataro, C., Gill, V., Heasley, J., Meyer, D., and 610 Savola, P., "The Generalized TTL Security Mechanism 611 (GTSM)", RFC 5082, October 2007. 613 14.2. Informative References 615 [RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet 616 Protocol", RFC 4301, December 2005. 618 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 619 Requirements for Encapsulating Security Payload (ESP) and 620 Authentication Header (AH)", RFC 4835, April 2007. 622 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 623 Networks", RFC 5920, July 2010. 625 [RFC4798] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS 626 Using IPv6 Provider Edge Routers (6PE)", RFC 4798, 627 February 2007. 629 [IPPWCap] Raza, K., "LDP IP and PW Capability", draft-ietf-mpls-ldp- 630 ip-pw-capability, June 2011. 632 15. Appendix 634 15.1. A.1 636 It is naive to assume that RFC5036 compliant implementations have 637 supported IPv6 address family (IPv6 FEC processing, in particular) 638 in label advertisement all along. And if that assumption turned out 639 to be not true, then section 3.4.1.1 of RFC5036 would cause LSRs to 640 abort processing the entire label mapping message and generate an 641 error. 643 This would result in LDPv6 to be somewhat undeployable in existing 644 production networks. 646 The change proposed in section 7 of this document provides a good 647 safety net and makes LDPv6 incrementally deployable without making 648 any such assumption on the routers' support for IPv6 FEC processing 649 in current production networks. 651 Author's Addresses 653 Vishwas Manral 654 Hewlet-Packard, Inc. 655 19111 Pruneridge Ave., Cupertino, CA, 95014 656 Phone: 408-447-1497 657 Email: vishwas.manral@hp.com 659 Rajiv Papneja 660 Huawei Technologies 661 2330 Central Expressway 662 Santa Clara, CA 95050 663 Phone: +1 571 926 8593 664 EMail: rajiv.papneja@huawei.com 666 Rajiv Asati 667 Cisco Systems, Inc. 668 7025 Kit Creek Road 669 Research Triangle Park, NC 27709-4987 670 Email: rajiva@cisco.com 671 Carlos Pignataro 672 Cisco Systems, Inc. 673 7200 Kit Creek Road 674 Research Triangle Park, NC 27709-4987 675 Email: cpignata@cisco.com