idnits 2.17.1 draft-ietf-mpls-ldp-ipv6-13.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 (July 3, 2014) is 3585 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: January 2015 Hewlett-Packard, Inc. 7 Rajiv Papneja 8 Huawei 10 Carlos Pignataro 11 Cisco 13 July 3, 2014 15 Updates to LDP for IPv6 16 draft-ietf-mpls-ldp-ipv6-13 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 3, 2015. 35 Copyright Notice 37 Copyright (c) 2014 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. Topology Scenarios for Dual-Stack Environment.............4 74 1.2. Single-hop vs. Multi-hop LDP Peering......................5 75 2. Specification Language.........................................6 76 3. LSP Mapping....................................................6 77 4. LDP Identifiers................................................7 78 5. Neighbor Discovery.............................................7 79 5.1. Basic Discovery Mechanism.................................8 80 5.1.1. Maintaining Hello Adjacencies........................9 81 5.2. Extended Discovery Mechanism..............................9 82 6. LDP Session Establishment and Maintenance......................9 83 6.1. Transport connection establishment........................9 84 6.1.1. Determining Transport connection Roles..............11 85 6.2. LDP Sessions Maintenance.................................13 86 7. Address Distribution..........................................14 87 8. Label Distribution............................................14 88 9. LDP Identifiers and Duplicate Next Hop Addresses..............15 89 10. LDP TTL Security.............................................16 90 11. IANA Considerations..........................................16 91 12. Security Considerations......................................16 92 13. Acknowledgments..............................................17 93 14. Additional Contributors......................................17 94 15. References...................................................18 95 15.1. Normative References....................................18 96 15.2. Informative References..................................18 97 Appendix A.......................................................20 98 A.1. LDPv6 and LDPv4 Interoperability Safety Net..............20 99 A.2. Why 32-bit value even for IPv6 LDP Router ID.............20 100 A.3. Why prohibit IPv4-mapped IPv6 addresses in LDP...........20 101 Author's Addresses...............................................22 103 1. Introduction 105 The LDP [RFC5036] specification defines procedures and messages for 106 exchanging FEC-label bindings over either IPv4 or IPv6 or both (e.g. 107 dual-stack) networks. 109 However, RFC5036 specification has the following deficiency (or 110 lacks details) in regards to IPv6 usage (with or without IPv4): 112 1) LSP Mapping: No rule for mapping a particular packet to a 113 particular LSP that has an Address Prefix FEC element containing 114 IPv6 address of the egress router 116 2) LDP Identifier: No details specific to IPv6 usage 118 3) LDP Discovery: No details for using a particular IPv6 destination 119 (multicast) address or the source address (with or without IPv4 120 co-existence) 122 4) LDP Session establishment: No rule for handling both IPv4 and 123 IPv6 transport address optional objects in a Hello message, and 124 subsequently two IPv4 and IPv6 transport connections 126 5) LDP Address Distribution: No rule for advertising IPv4 or/and 127 IPv6 FEC-Address bindings over an LDP session 129 6) LDP Label Distribution: No rule for advertising IPv4 or/and IPv6 130 FEC-label bindings over an LDP session, and for handling the co- 131 existence of IPv4 and IPv6 FEC Elements in the same FEC TLV 133 7) Next Hop Address Resolution: No rule for accommodating the usage 134 of duplicate link-local IPv6 addresses 136 8) LDP TTL Security: No rule for built-in Generalized TTL Security 137 Mechanism (GTSM) in LDP with IPv6 (this is a deficiency in 138 RFC6720) 140 This document addresses the above deficiencies by specifying the 141 desired behavior/rules/details for using LDP in IPv6 enabled 142 networks (IPv6-only or Dual-stack networks). 144 Note that this document updates RFC5036 and RFC6720. 146 1.1. Topology Scenarios for Dual-Stack Environment 148 Two LSRs may involve basic and/or extended LDP discovery in IPv6 149 and/or IPv4 address-families in various topology scenarios. 151 This document addresses the following 3 topology scenarios in which 152 the LSRs may be connected via one or more dual-stack interfaces 153 (figure 1), or one or more single-stack interfaces (figure 2 and 154 figure 3): 156 R1------------------R2 157 IPv4+IPv6 159 Figure 1 LSRs connected via a Dual-stack Interface 161 IPv4 162 R1=================R2 163 IPv6 165 Figure 2 LSRs connected via two single-stack Interfaces 166 R1------------------R2---------------R3 167 IPv4 IPv6 169 Figure 3 LSRs connected via a single-stack Interface 171 Note that the topology scenario illustrated in figure 1 also covers 172 the case of a single-stack interface (IPv4, say) being converted to 173 a dual-stacked interface by enabling IPv6 routing as well as IPv6 174 LDP, even though the IPv4 LDP session may already be established 175 between the LSRs. 177 Note that the topology scenario illustrated in figure 2 also covers 178 the case of two routers getting connected via an additional single- 179 stack interface (IPv6 routing and IPv6 LDP), even though the IPv4 180 LDP session may already be established between the LSRs over the 181 existing interface(s). 183 This document also addresses the scenario in which the LSRs do 184 extended discovery in IPv6 and/or IPv4 address-families: 186 IPv4 187 R1-------------------R2 188 IPv6 190 Figure 4 LSRs involving IPv4 and IPv6 address-families 192 1.2. Single-hop vs. Multi-hop LDP Peering 194 LDP TTL Security mechanism specified by this document applies only 195 to single-hop LDP peering sessions, but not to multi-hop LDP peering 196 sessions, in line with Section 5.5 of [RFC5082] that describes 197 Generalized TTL Security Mechanism (GTSM). 199 As a consequence, any LDP feature that relies on multi-hop LDP 200 peering session would not work with GTSM and will warrant 201 (statically or dynamically) disabling GTSM. Please see section 10. 203 2. Specification Language 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 Abbreviations: 211 LDP - Label Distribution Protocol 213 LDPoIPv4 - LDP over IPv4 transport session 215 LDPoIPv6 - LDP over IPv6 transport session 217 FEC - Forwarding Equivalence Class 219 TLV - Type Length Value 221 LSR - Label Switching Router 223 LSP - Label Switched Path 225 LSPv4 - IPv4-signaled Label Switched Path [RFC4798] 227 LSPv6 - IPv6-signaled Label Switched Path [RFC4798] 229 AFI - Address Family Identifier 231 LDP Id - LDP Identifier 233 3. LSP Mapping 235 Section 2.1 of [RFC5036] specifies the procedure for mapping a 236 particular packet to a particular LSP using three rules. Quoting the 237 3rd rule from RFC5036: 239 "If it is known that a packet must traverse a particular egress 240 router, and there is an LSP that has an Address Prefix FEC element 241 that is a /32 address of that router, then the packet is mapped to 242 that LSP." 244 This rule is correct for IPv4, but not for IPv6, since an IPv6 245 router may even have a /64 or /96 or /128 (or whatever prefix 246 length) address. Hence, it is reasonable to say IPv4 or IPv6 address 247 instead of /32 or /128 addresses as shown below in the updated rule: 249 "If it is known that a packet must traverse a particular egress 250 router, and there is an LSP that has an Address Prefix FEC element 251 that is an IPv4 or IPv6 address of that router, then the packet is 252 mapped to that LSP." 254 4. LDP Identifiers 256 In line with section 2.2.2 of [RFC5036], this document specifies the 257 usage of 32-bit (unsigned non-zero integer) LSR Id on an IPv6 258 enabled LSR (with or without dual-stacking). 260 This document also qualifies the first sentence of last paragraph of 261 Section 2.5.2 of [RFC5036] to be per address family and therefore 262 updates that sentence to the following: 264 "For a given address family, an LSR MUST advertise the same 265 transport address in all Hellos that advertise the same label 266 space." 268 This rightly enables the per-platform label space to be shared 269 between IPv4 and IPv6. 271 In summary, this document mandates the usage of a common LDP 272 identifier (same LSR Id aka LDP Router Id as well as a common Label 273 space id) for both IPv4 and IPv6 address families on a dual-stack 274 LSR. 276 5. Neighbor Discovery 278 If an LSR is enabled with dual-stack LDP (e.g. LDP enabled in both 279 IPv6 and IPv4 address families), then the LSR MUST advertise both 280 IPv6 and IPv4 LDP Link or targeted Hellos and include the same LDP 281 Identifier (assuming per-platform label space usage) in them. 283 If an LSR is enabled with single-stack LDP (e.g. LDP enabled in 284 either IPv6 or IPv4 address family), then the LSR MUST advertise 285 either IPv6 or IPv4 LDP Link or targeted Hellos respectively. 287 5.1. Basic Discovery Mechanism 289 Section 2.4.1 of [RFC5036] defines the Basic Discovery mechanism for 290 directly connected LSRs. Following this mechanism, LSRs periodically 291 send LDP Link Hellos destined to "all routers on this subnet" group 292 multicast IP address. 294 Interesting enough, per the IPv6 addressing architecture [RFC4291], 295 IPv6 has three "all routers on this subnet" multicast addresses: 297 FF01:0:0:0:0:0:0:2 = Interface-local scope 299 FF02:0:0:0:0:0:0:2 = Link-local scope 301 FF05:0:0:0:0:0:0:2 = Site-local scope 303 [RFC5036] does not specify which particular IPv6 'all routers on 304 this subnet' group multicast IP address should be used by LDP Link 305 Hellos. 307 This document specifies the usage of link-local scope e.g. 308 FF02:0:0:0:0:0:0:2 as the destination multicast IP address in IPv6 309 LDP Link Hellos. An LDP Hello packet received on any of the other 310 destination addresses MUST be dropped. Additionally, the link-local 311 IPv6 address MUST be used as the source IP address in IPv6 LDP Link 312 Hellos. 314 Also, the LDP Link Hello packets MUST have their IPv6 Hop Limit set 315 to 255, be checked for the same upon receipt (before any LDP 316 specific processing) and be handled as specified in Generalized TTL 317 Security Mechanism (GTSM) section 3 of [RFC5082]. The built-in 318 inclusion of GTSM automatically protects IPv6 LDP from off-link 319 attacks. 321 More importantly, if an interface is a dual-stack LDP interface 322 (e.g. LDP enabled in both IPv6 and IPv4 address families), then the 323 LSR MUST periodically send both IPv6 and IPv4 LDP Link Hellos (using 324 the same LDP Identifier per section 4) on that interface and be able 325 to receive them. This facilitates discovery of IPv6-only, IPv4-only 326 and dual-stack peers on the interface's subnet and ensures 327 successful subsequent peering using the appropriate (address family) 328 transport on a multi-access or broadcast interface. 330 An implementation MUST send IPv6 LDP link Hellos before sending IPv4 331 LDP Link Hellos on a dual-stack interface. 333 5.1.1. Maintaining Hello Adjacencies 335 In case of dual-stack LDP interface (e.g. LDP enabled in both IPv6 336 and IPv4 address families), the LSR SHOULD maintain link Hello 337 adjacencies for both IPv4 and IPv6 address families. This document, 338 however, allows an LSR to maintain Rx-side Link Hello adjacency for 339 the address family that has been used for the establishment of the 340 LDP session (either IPv4 or IPv6). 342 5.2. Extended Discovery Mechanism 344 The extended discovery mechanism (defined in section 2.4.2 of 345 [RFC5036]), in which the targeted LDP Hellos are sent to a pre- 346 configured (unicast) destination IPv6 address, requires only one 347 IPv6 specific consideration: the link-local IPv6 addresses MUST NOT 348 be used as the targeted LDP hello packet's source or destination 349 addresses. 351 6. LDP Session Establishment and Maintenance 353 Section 2.5.1 of [RFC5036] defines a two-step process for LDP 354 session establishment, once the peer discovery has completed (LDP 355 Hellos have been exchanged): 357 1. Transport connection establishment 358 2. Session initialization 360 The forthcoming sub-section 6.1 discusses the LDP consideration for 361 IPv6 and/or dual-stacking in the context of session establishment, 362 whereas sub-section 6.2 discusses the LDP consideration for IPv6 363 and/or dual-stacking in the context of session maintenance. 365 6.1. Transport connection establishment 367 Section 2.5.2 of [RFC5036] specifies the use of an optional 368 transport address object (TLV) in LDP Hello message to convey the 369 transport (IP) address, however, it does not specify the behavior of 370 LDP if both IPv4 and IPv6 transport address objects (TLV) are sent 371 in a Hello message or separate Hello messages. More importantly, it 372 does not specify whether both IPv4 and IPv6 transport connections 373 should be allowed, if there were both IPv4 and IPv6 Hello 374 adjacencies. 376 This document specifies that: 378 1. An LSR MUST NOT send a Hello message containing both IPv4 and 379 IPv6 transport address optional objects. In other words, there 380 MUST be at most one optional Transport Address object in a 381 Hello message. An LSR MUST include only the transport address 382 whose address family is the same as that of the IP packet 383 carrying Hello message. 385 2. An LSR SHOULD accept the Hello message that contains both IPv4 386 and IPv6 transport address optional objects, but MUST use only 387 the transport address whose address family is the same as that 388 of the IP packet carrying the Hello message. An LSR SHOULD 389 accept only the first transport object for a given Address 390 family in the received Hello message, and ignore the rest, if 391 the LSR receives more than one transport object. 393 3. An LSR MUST send separate Hello messages (each containing 394 either IPv4 or IPv6 transport address optional object) for each 395 IP address family, if LDP was enabled for both IP address 396 families. 398 4. An LSR MUST use a global unicast IPv6 address in IPv6 transport 399 address optional object of outgoing targeted Hellos, and check 400 for the same in incoming targeted hellos (i.e. MUST discard the 401 hello, if it failed the check). 403 5. An LSR MUST prefer using a global unicast IPv6 address in IPv6 404 transport address optional object of outgoing Link Hellos, if 405 it had to choose between global unicast IPv6 address and 406 unique-local or link-local IPv6 address. 408 6. An LSR SHOULD NOT create (or honor the request for creating) a 409 TCP connection for a new LDP session with a remote LSR, if they 410 already have an LDP session (for the same LDP Identifier) 411 established over whatever IP version transport. 413 This means that only one transport connection is established 414 regardless of IPv6 or/and IPv4 Hello adjacencies presence 415 between two LSRs. 417 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new 418 LDP session with a remote LSR, if it is able to determine the 419 IPv6 presence (e.g. IPv6 Hello adjacency), by following the 420 'transport connection role' determination logic in section 421 6.1.1. 423 6.1.1. Determining Transport connection Roles 425 Section 2.5.2 of [RFC5036] specifies the rules for determining 426 active/passive roles in setting up TCP connection. These rules are 427 clear for a single-stack (IPv4 or IPv6) LDP, but not for a dual- 428 stack (IPv4 and IPv6) LDP, in which an LSR may assume different 429 roles for different address families, causing LDP session to not get 430 established. 432 To ensure deterministic transport connection (active/passive) role 433 for dual-stack LDP peering, this document specifies that the LSR 434 convey its transport connection preference in every LDP Hello 435 message. A new optional parameter, encoded as a TLV, (section 3.5.2 436 of RFC5036) is defined as follows (for Hello Message): 438 0 1 2 3 439 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 9 0 1 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 |1|0| IPv4orIPv6 Preference | Length | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 |TR | Reserved | MBZ | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Figure 5 IPv4 or IPv6 Transport Preference TLV 448 Where: 450 U and F bits: 1 and 0 (as specified by RFC5036) 452 IPv4orIPv6 Preference: TLV code point for IPv4 or IPv6 Preference 453 (to be assigned by IANA). 455 TR, Transport Preference 457 00: IPv4 459 01: IPv6 (default value) 461 Reserved 463 This field is reserved. It MUST be set to zero on 464 transmission and ignored on receipt. 466 A dual-stack LDP enabled LSR (capable of supporting both IPv4 and 467 IPv6 transports for LDP) MUST include "IPv4orIPv6 Transport 468 Preference" optional parameter in all of its LDP Hellos, and MUST 469 set the "TR" field to announce its preference for either IPv4 or 470 IPv6 transport connection. The default preference is IPv6. 472 Upon receiving the hello message with this TLV, a dual-stack capable 473 receiving LSR MUST do the following: 475 1. If it understands the TLV, and if neighbor's preference does 476 not match with the local preference, then it discards the hello 477 (and no adjacency is formed) and logs an error. 479 2. If it understands the TLV, and if neighbor's preference matches 480 with the local preference, then: 482 a) If TR=0 (IPv4), then determine the active/passive roles 483 for TCP connection using IPv4 transport address as defined 484 in section 2.5.2 of RFC 5036. 486 b) If TR=1 (IPv6), then determine the active/passive roles 487 for TCP connection by comparing the LSR Id part of the LDP 488 Identifiers of LSRs. 490 The LSR with higher LSR Id MUST assume the active role and 491 other LSR MUST assume the passive role for the IPv6 TCP 492 connection. 494 3. If it does not understand the TLV, then it MUST silently 495 discard this TLV and process the rest of the Hello message. 497 If an LSR receives the hello message without the "IPv4orIPv6 498 Transport Preference" TLV, then it MUST proceed with session 499 establishment using single-stack rules, as per section 2.5.2 of RFC 500 5036. 502 An LSR MUST convey the same transport connection preference ("TR" 503 field) in all (link and targeted) Hellos that advertise the same 504 label space to the same peer and/or on same interface. This ensures 505 that two LSRs linked by multiple Hello adjacencies using the same 506 label spaces play the same connection establishment role for each 507 adjacency. 509 An implementation may provide an option to favor one AFI (IPv4, say) 510 over another AFI (IPv6, say) for the TCP transport connection, so as 511 to use the favored IP version for the LDP session, and force 512 deterministic active/passive roles. 514 Note - An alternative to Capability TLV could be a new Flag value in 515 LDP Hello message, however, it will get used even in a single-stack 516 IPv6 scenarios and linger on forever, even though dual-stack will 517 not. Hence, this alternative is discarded. 519 6.2. LDP Sessions Maintenance 521 This document specifies that two LSRs maintain a single LDP session 522 regardless of number of Link or Targeted Hello adjacencies between 523 them, as described in section 6.1. This is independent of whether: 525 - they are connected via a dual-stack LDP enabled interface(s) or 526 via two (or more) single-stack LDP enabled interfaces; 527 - a single-stack LDP enabled interface is converted to a dual-stack 528 LDP enabled interface (e.g. figure 1) on either LSR; 529 - an additional single-stack or dual-stack LDP enabled interface is 530 added or removed between two LSRs (e.g. figure 2). 532 The procedures defined in section 6.1 SHOULD result in preferring 533 LDPoIPv6 session only after the loss of an existing LDP session 534 (because of link failure, node failure, reboot etc.). 536 If the last hello adjacency for a given address family goes down 537 (e.g. due to dual-stack LDP enabled interfaces being converted into 538 a single-stack LDP enabled interfaces on one LSR etc.), and that 539 address family is the same as the one used in the transport 540 connection, then the transport connection (LDP session) SHOULD be 541 reset. Otherwise, the LDP session SHOULD stay intact. 543 If the LDP session is torn down for whatever reason (LDP disabled 544 for the corresponding transport, hello adjacency expiry etc.), then 545 the LSRs SHOULD initiate establishing a new LDP session as per the 546 procedures described in section 6.1 of this document. 548 7. Address Distribution 550 If an LSR is enabled with dual-stack LDP (i.e. LDP in both IPv4 and 551 IPv6 address families) for any (discovered or targeted) peer, then 552 it MUST advertise (via ADDRESS message) its local IPv4 and IPv6 553 addresses to that peer by default, independent of the transport 554 connection (address family) used for that peering. 556 If an LSR, compliant with this specification, is enabled with 557 single-stack LDP (i.e. LDP in either IPv6 or IPv4 address family) 558 for any (discovered or targeted) peer, then it MUST advertise (via 559 ADDRESS message) its local IP addresses as per the enabled address 560 family by default, and SHOULD accept a received Address message 561 containing both IPv4 and IPv6 addresses. 563 8. Label Distribution 565 An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings 566 for link-local or IPv4-mapped IPv6 addresses (defined in section 567 2.5.5.2 of [RFC4291]), and ignore such bindings, if ever received. 568 Please see Appendix A.3. 570 Additionally, to ensure backward compatibility (and interoperability 571 with IPv4-only LDP implementations) in light of section 3.4.1.1 of 572 RFC5036, as rationalized in the Appendix section A.1 later, this 573 document specifies that - 575 1. An LSR MUST NOT send a label mapping message with a FEC TLV 576 containing two or more Prefix FEC Elements of different address 577 families. This means that a FEC TLV in the label mapping 578 message must contain all the Prefix FEC Elements belonging to 579 IPv6 address family or IPv4 address family, but not both. 581 If an LSR is enabled with dual-stack LDP (i.e. LDP in both IPv4 and 582 IPv6 address families) for any peer, then it MUST advertise the FEC- 583 Label bindings for both IPv4 and IPv6 address families to that peer. 584 However, an LSR MAY constrain the advertisement of FEC-label 585 bindings for a particular address family by negotiating the IP 586 Capability for a given address family, as specified in [IPPWCap] 587 document. This allows an LSR pair to neither advertise nor receive 588 the undesired FEC-label bindings on a per address family basis. 590 If an LSR is configured to move an interface or peer from single- 591 stack (IPv6 or IPv4 address family) to dual-stack LDP (IPv6 and IPv4 592 address families), then an LSR SHOULD use Typed Wildcard FEC 593 procedures [RFC5918] to request the FEC-label bindings for the 594 enabled address family. This helps to relearn the FEC-label bindings 595 that may have been discarded before without resetting the peering. 597 9. LDP Identifiers and Duplicate Next Hop Addresses 599 RFC5036 section 2.7 specifies the logic for mapping the IP routing 600 next-hop (of a given FEC) to an LDP peer so as to find the correct 601 label entry for that FEC. The logic involves using the IP routing 602 next-hop address as an index into the (peer Address) database (which 603 is populated by the Address message containing mapping between each 604 peer's local addresses and its LDP Identifier) to determine the LDP 605 peer. 607 However, this logic is insufficient to deal with duplicate IPv6 608 (link-local) next-hop addresses used by two or more peers. The 609 reason is that all interior IPv6 routing protocols (can) use link- 610 local IPv6 addresses as the IP routing next-hops, and 'IPv6 611 Addressing Architecture [RFC4291]' allows a link-local IPv6 address 612 to be used on more than one links. 614 Hence, this logic is extended by this specification to use not only 615 the IP routing next-hop address, but also the IP routing next-hop 616 interface to uniquely determine the LDP peer(s). The next-hop 617 address-based LDP peer mapping is to be done through LDP peer 618 address database (populated by Address messages received from the 619 LDP peers), whereas next-hop interface-based LDP peer mapping is to 620 be done through LDP hello adjacency/interface database (populated by 621 hello messages from the LDP peers). 623 This extension solves the problem of two or more peers using the 624 same link-local IPv6 address (in other words, duplicate peer 625 addresses) as the IP routing next-hops. 627 Lastly, for better scale and optimization, an LSR may advertise only 628 the link-local IPv6 addresses in the Address message, assuming that 629 the peer uses only the link-local IPv6 addresses as static and/or 630 dynamic IP routing next-hops. 632 10. LDP TTL Security 634 This document recommends enabling Generalized TTL Security Mechanism 635 (GTSM) for LDP, as specified in [RFC6720], for the LDP/TCP transport 636 connection over IPv6 (i.e. LDPoIPv6). The GTSM inclusion is intended 637 to automatically protect IPv6 LDP peering session from off-link 638 attacks. 640 [RFC6720] allows for the implementation to statically 641 (configuration) and/or dynamically override the default behavior 642 (enable/disable GTSM) on a per-peer basis. Suffice to say that such 643 an option could be set on either LSR (since GTSM negotiation would 644 ultimately disable GTSM between LSR and its peer(s)). 646 LDP Link Hello packets MUST have their IPv6 Hop Limit set to 255, 647 and be checked for the same upon receipt before any further 648 processing, as per section 3 of [RFC5082]. 650 11. IANA Considerations 652 This document defines a new optional parameter for the LDP Hello 653 Message. The type code needs to be assigned by IANA. 655 12. Security Considerations 657 The extensions defined in this document only clarify the behavior of 658 LDP, they do not define any new protocol procedures. Hence, this 659 document does not add any new security issues to LDP. 661 While the security issues relevant for the [RFC5036] are relevant 662 for this document as well, this document reduces the chances of off- 663 link attacks when using IPv6 transport connection by including the 664 use of GTSM procedures [RFC5082]. Please see section 9 for LDP TTL 665 Security details. 667 Moreover, this document allows the use of IPsec [RFC4301] for IPv6 668 protection, hence, LDP can benefit from the additional security as 669 specified in [RFC4835] as well as [RFC5920]. 671 13. Acknowledgments 673 We acknowledge the authors of [RFC5036], since some text in this 674 document is borrowed from [RFC5036]. 676 Thanks to Bob Thomas for providing critical feedback to improve this 677 document early on. 679 Many thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach Chen, Shane 680 Amante, Pranjal Dutta, Mustapha Aissaoui, Matthew Bocci, Mark Tinka, 681 Tom Petch, Kishore Tiruveedhula, Manoj Dutta, Vividh Siddha, Qin Wu, 682 Simon Perreault, Brian E Carpenter, and Loa Andersson for thoroughly 683 reviewing this document, and providing insightful comments and 684 multiple improvements. 686 This document was prepared using 2-Word-v2.0.template.dot. 688 14. Additional Contributors 690 The following individuals contributed to this document: 692 Kamran Raza 693 Cisco Systems, Inc. 694 2000 Innovation Drive 695 Kanata, ON K2K-3E8, Canada 696 Email: skraza@cisco.com 698 Nagendra Kumar 699 Cisco Systems, Inc. 700 SEZ Unit, Cessna Business Park, 701 Bangalore, KT, India 702 Email: naikumar@cisco.com 704 Andre Pelletier 705 Cisco Systems, Inc. 706 2000 Innovation Drive 707 Kanata, ON K2K-3E8, Canada 708 Email: apelleti@cisco.com 710 15. References 712 15.1. Normative References 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, March 1997. 717 [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 718 (IPv6) Addressing Architecture", RFC 4291, February 2006. 720 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 721 Specification", RFC 5036, October 2007. 723 [RFC5082] Pignataro, C., Gill, V., Heasley, J., Meyer, D., and 724 Savola, P., "The Generalized TTL Security Mechanism 725 (GTSM)", RFC 5082, October 2007. 727 [RFC5918] Asati, R., Minei, I., and Thomas, B., "Label Distribution 728 Protocol (LDP) 'Typed Wildcard Forward Equivalence Class 729 (FEC)", RFC 5918, October 2010. 731 15.2. Informative References 733 [RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet 734 Protocol", RFC 4301, December 2005. 736 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 737 Requirements for Encapsulating Security Payload (ESP) and 738 Authentication Header (AH)", RFC 4835, April 2007. 740 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 741 Networks", RFC 5920, July 2010. 743 [RFC4798] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS 744 Using IPv6 Provider Edge Routers (6PE)", RFC 4798, 745 February 2007. 747 [IPPWCap] Raza, K., "LDP IP and PW Capability", draft-ietf-mpls-ldp- 748 ip-pw-capability, June 2011. 750 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 751 for IPv6", RFC 5340, July 2008. 753 [RFC6286] E. Chen, and J. Yuan, "Autonomous-System-Wide Unique BGP 754 Identifier for BGP-4", RFC 6286, June 2011. 756 [RFC6720] R. Asati, and C. Pignataro, "The Generalized TTL Security 757 Mechanism (GTSM) for the Label Distribution Protocol 758 (LDP)", RFC 6720, August 2012. 760 [RFC4038] M-K. Shin, Y-G. Hong, J. Hagino, P. Savola, and E. M. 761 Castro, "Application Aspects of IPv6 Transition", RFC 762 4038, March 2005. 764 Appendix A. 766 A.1. LDPv6 and LDPv4 Interoperability Safety Net 768 It is naive to assume that RFC5036 compliant implementations have 769 supported IPv6 address family (IPv6 FEC processing, in particular) 770 in label advertisement all along. And if that assumption turned out 771 to be not true, then section 3.4.1.1 of RFC5036 would cause LSRs to 772 abort processing the entire label mapping message and generate an 773 error. 775 This would result in LDPv6 to be somewhat undeployable in existing 776 production networks. 778 The change proposed in section 7 of this document provides a good 779 safety net and makes LDPv6 incrementally deployable without making 780 any such assumption on the routers' support for IPv6 FEC processing 781 in current production networks. 783 A.2. Why 32-bit value even for IPv6 LDP Router ID 785 The first four octets of the LDP identifier, the 32-bit LSR Id (e.g. 786 (i.e. LDP Router Id), identify the LSR and is a globally unique 787 value within the MPLS network. This is regardless of the address 788 family used for the LDP session. 790 Please note that 32-bit LSR Id value would not map to any IPv4- 791 address in an IPv6 only LSR (i.e., single stack), nor would there be 792 an expectation of it being IP routable, nor DNS-resolvable. In IPv4 793 deployments, the LSR Id is typically derived from an IPv4 address, 794 generally assigned to a loopback interface. In IPv6 only 795 deployments, this 32-bit LSR Id must be derived by some other means 796 that guarantees global uniqueness within the MPLS network, similar 797 to that of BGP Identifier [RFC6286] and OSPF router ID [RFC5340]. 799 This document reserves 0.0.0.0 as the LSR Id, and prohibits its 800 usage with IPv6, in line with OSPF router Id in OSPF version 3 801 [RFC5340]. 803 A.3. Why prohibit IPv4-mapped IPv6 addresses in LDP 804 Per discussion with 6MAN and V6OPS working groups, the overwhelming 805 consensus was to not promote IPv4-mapped IPv6 addresses appear in 806 the routing table, as well as in LDP (address and label) databases. 808 Also, [RFC4038] section 4.2 suggests that IPv4-mapped IPv6 addressed 809 packets should never appear on the wire. 811 Author's Addresses 813 Vishwas Manral 814 Hewlet-Packard, Inc. 815 19111 Pruneridge Ave., Cupertino, CA, 95014 816 Phone: 408-447-1497 817 Email: vishwas.manral@hp.com 819 Rajiv Papneja 820 Huawei Technologies 821 2330 Central Expressway 822 Santa Clara, CA 95050 823 Phone: +1 571 926 8593 824 EMail: rajiv.papneja@huawei.com 826 Rajiv Asati 827 Cisco Systems, Inc. 828 7025 Kit Creek Road 829 Research Triangle Park, NC 27709-4987 830 Email: rajiva@cisco.com 832 Carlos Pignataro 833 Cisco Systems, Inc. 834 7200 Kit Creek Road 835 Research Triangle Park, NC 27709-4987 836 Email: cpignata@cisco.com