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