idnits 2.17.1 draft-ietf-mpls-ldp-ipv6-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as well as interface addresses via ADDRESS message) from/to the peer over an LDP session (using whatever transport), unless it has valid IPv4 and IPv6 Hello Adjacencies for that peer, as specified in section 6.2. (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 (January 23, 2012) is 4471 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 (==), 4 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: July 23, 2012 Hewlett-Packard, Inc. 7 Rajiv Papneja 8 Huawei 10 Carlos Pignataro 11 Cisco 13 January 23, 2012 15 Updates to LDP for IPv6 16 draft-ietf-mpls-ldp-ipv6-06 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 July 23, 2012. 35 Copyright Notice 37 Copyright (c) 2012 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, IPv6 or both 54 networks. This document corrects and clarifies the LDP behavior when 55 IPv6 network is used (with or without IPv4). This document updates 56 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..........................................14 78 11. Security Considerations......................................14 79 12. Acknowledgments..............................................14 80 13. Additional Contributors......................................15 81 14. References...................................................16 82 14.1. Normative References....................................16 83 14.2. Informative References..................................16 84 Author's Addresses...............................................17 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. It also clarifies the scope (section 1.1). 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 two 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 as well as IPv6 LDP, even 153 though the IPv4 LDP session may already be established between the 154 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, say), even though the IPv4 LDP session may 159 already be established between the LSRs over the existing interface. 161 1.1.2. LDP TTL Security 163 LDP TTL Security mechanism specified by this document applies only 164 to single-hop LDP peering sessions, but not to multi-hop LDP peering 165 sessions, in line with Section 5.5 of [RFC5082] that describes 166 Generalized TTL Security Mechanism (GTSM). 168 As a consequence, any LDP feature that relies on multi-hop LDP 169 peering session would not work with GTSM and will warrant 170 (statically or dynamically) disabling GTSM. Please see section 8. 172 2. Specification Language 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119]. 178 Abbreviations: 180 LDP - Label Distribution Protocol 182 LDPv4 - LDP for enabling IPv4 MPLS forwarding 184 LDPv6 - LDP for enabling IPv6 MPLS forwarding 186 LDPoIPv4 - LDP over IPv4 transport session 188 LDPoIPv6 - LDP over IPv6 transport session 190 FEC - Forwarding Equivalence Class 192 TLV - Type Length Value 194 LSR - Label Switch Router 196 LSP - Label Switched Path 198 LSPv4 - IPv4-signaled Label Switched Path [RFC4798] 200 LSPv6 - IPv6-signaled Label Switched Path [RFC4798] 202 3. LSP Mapping 204 Section 2.1 of [RFC5036] specifies the procedure for mapping a 205 particular packet to a particular LSP using three rules. Quoting the 206 3rd rule from RFC5036: 208 "If it is known that a packet must traverse a particular egress 209 router, and there is an LSP that has an Address Prefix FEC element 210 that is a /32 address of that router, then the packet is mapped to 211 that LSP." 213 Suffice to say, this rule is correct for IPv4, but not for IPv6, 214 since an IPv6 router may not have any /32 address. 216 This document proposes to modify this rule by also including a /128 217 address (for IPv6). In fact, it should be reasonable to just say 218 IPv4 or IPv6 address instead of /32 or /128 addresses as shown below 219 in the updated rule: 221 "If it is known that a packet must traverse a particular egress 222 router, and there is an LSP that has an Address Prefix FEC element 223 that is an IPv4 or IPv6 address of that router, then the packet is 224 mapped to that LSP." 226 Additionally, it is desirable that a packet is forwarded to an LSP 227 of an egress router, only if LSP's address-family (e.g. LSPv4 or 228 LSPv6) matches with that of the LDP hello adjacency on the next-hop 229 interface. 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). Additionally, section 2.5.2 of 236 [RFC5036] implicitly prohibits using the same label space for both 237 IPv4 and IPv6 FEC-label bindings. 239 The first four octets of the LDP identifier, the 32-bit LSR Id, 240 identify the LSR and is a globally unique value. This is regardless 241 of the address family used for the LDP session. Hence, this document 242 preserves the usage of 32-bit LSR Id on an IPv6 only LSR. 244 Please note that 32-bit LSR Id value would not map to any IPv4- 245 address in an IPv6 only LSR (i.e., single stack), nor would there 246 be an expectation of it being DNS-resolvable. In IPv4 deployments, 247 the LSR Id is typically derived from an IPv4 address, generally 248 assigned to a loopback interface. In IPv6 only deployments, this 249 32-bit LSR Id must be derived by some other means that guarantees 250 global uniqueness. 252 This document qualifies the first sentence of last paragraph of 253 Section 2.5.2 of [RFC5036] to be per address family and therefore 254 updates that sentence to the following: "For a given address family 255 over which a Hello is sent, and a given label space, an LSR MUST 256 advertise the same transport address." This rightly enables the per- 257 platform label space to be shared between IPv4 and IPv6. 259 In summary, this document not only allows the usage of a common LDP 260 identifier i.e. same LSR-Id, but also the common Label space id for 261 both IPv4 and IPv6 on a dual-stack LSR. 263 This document reserves 0.0.0.0 as the LSR-Id, and prohibits its 264 usage. 266 5. Peer Discovery 268 5.1. Basic Discovery Mechanism 270 Section 2.4.1 of [RFC5036] defines the Basic Discovery mechanism for 271 directly connected LSRs. Following this mechanism, LSRs periodically 272 sends LDP Link Hellos destined to "all routers on this subnet" group 273 multicast IP address. 275 Interesting enough, per the IPv6 addressing architecture [RFC4291], 276 IPv6 has three "all routers on this subnet" multicast addresses: 278 FF01:0:0:0:0:0:0:2 = Interface-local scope 280 FF02:0:0:0:0:0:0:2 = Link-local scope 282 FF05:0:0:0:0:0:0:2 = Site-local scope 284 [RFC5036] does not specify which particular IPv6 'all routers on 285 this subnet' group multicast IP address should be used by LDP Link 286 Hellos. 288 This document specifies the usage of link-local scope e.g. 289 FF02:0:0:0:0:0:0:2 as the destination multicast IP address in IPv6 290 LDP Link Hellos. An LDP Hello packet received on any of the other 291 destination addresses must be dropped. Additionally, the link-local 292 IPv6 address MUST be used as the source IP address in IPv6 LDP Link 293 Hellos. 295 Also, the LDP Link Hello packets must have their IPv6 Hop Limit set 296 to 255, and be checked for the same upon receipt before any further 297 processing, as specified in Generalized TTL Security Mechanism 298 (GTSM)[RFC5082]. The built-in inclusion of GTSM automatically 299 protects IPv6 LDP from off-link attacks. 301 More importantly, if an interface is a dual-stack LDP interface 302 (e.g. enabled with both IPv4 and IPv6 LDP), then the LSR must 303 periodically send both IPv4 and IPv6 LDP Link Hellos (using the same 304 LDP Identifier per section 4) and must separately maintain the Hello 305 adjacency for IPv4 and IPv6 on that interface. 307 In summary, the IPv4 and IPv6 LDP Link Hellos must carry the same 308 LDP identifier (assuming per-platform label space usage). 310 5.2. Extended Discovery Mechanism 312 Suffice to say, the extended discovery mechanism (defined in section 313 2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific 314 consideration, since the targeted LDP Hellos are sent to a pre- 315 configured (unicast) destination IPv6 address. 317 The link-local IP addresses MUST NOT be used as the source or 318 destination IPv6 addresses in extended discovery. 320 6. LDP Session Establishment and Maintenance 322 Section 2.5.1 of [RFC5036] defines a two-step process for LDP 323 session establishment, once the peer discovery has completed (LDP 324 Hellos have been exchanged): 326 1. Transport connection establishment 327 2. Session initialization 329 The forthcoming sub-sections discuss the LDP consideration for IPv6 330 and/or dual-stacking in the context of session establishment and 331 maintenance. 333 6.1. Transport connection establishment 335 Section 2.5.2 of [RFC5036] specifies the use of an optional 336 transport address object (TLV) in LDP Link Hello message to convey 337 the transport (IP) address, however, it does not specify the 338 behavior of LDP if both IPv4 and IPv6 transport address objects 339 (TLV) are sent in a Hello message or separate Hello messages. More 340 importantly, it does not specify whether both IPv4 and IPv6 341 transport connections should be allowed, if there were Hello 342 adjacencies for both IPv4 and IPv6 whether over a single interface 343 or multiple interfaces. 345 This document specifies that: 347 1. An LSR MUST NOT send a Hello containing both IPv4 and IPv6 348 transport address optional objects. In other words, there MUST 349 be at most one optional Transport Address object in a Hello 350 message. An LSR MUST include only the transport address whose 351 address family is the same as that of the IP packet carrying 352 Hello. 354 2. An LSR SHOULD accept the Hello message that contains both IPv4 355 and IPv6 transport address optional objects, but MUST use only 356 the transport address whose address family is the same as that 357 of the IP packet carrying Hello. 359 3. An LSR MUST send separate Hellos (each containing either IPv4 360 or IPv6 transport address optional object) for each IP address- 361 family, if LDP was enabled for both IP address-families. 363 4. An LSR MUST use a global unicast IPv6 address in IPv6 transport 364 address optional object of outgoing targeted hellos, and check 365 for the same in incoming targeted hellos. 367 5. An LSR MUST prefer using global unicast IPv6 address for an LDP 368 session with a remote LSR, if it had to choose between global 369 unicast IPv6 address and link-local IPv6 address (pertaining to 370 the same LDP Identifier) for the transport connection. 372 6. An LSR SHOULD NOT create (or honor the request for creating) a 373 TCP connection for a new LDP session with a remote LSR, if they 374 already have an LDP session (for the same LDP Identifier) 375 established over whatever IP version transport. 377 This means that only one transport connection is established, 378 even if there are two Hello adjacencies (one for IPv4 and 379 another for IPv6). This is independent of whether the Hello 380 Adjacencies are created over a single interface (scenarios 1 in 381 section 1.1) or multiple interfaces (scenario 2 in section 1.1) 382 between two LSRs. 384 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new 385 LDP session with a remote LSR, if it has both IPv4 and IPv6 386 hello adjacencies for the same LDP Identifier (over a dual- 387 stack interface, or two or more single-stack IPv4 and IPv6 388 interfaces). This applies to the section 2.5.2 of RFC5036. 390 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new 391 LDP session with a remote LSR, if they attempted two TCP 392 connections using IPv4 and IPv6 transport addresses 393 simultaneously. 395 An implementation may provide an option to favor one AFI (IPv4, say) 396 over another AFI (IPv6, say) for the TCP transport connection, so as 397 to use the preferred IP version for the LDP session, and derive 398 deterministic active/passive roles. 400 6.2. Maintaining Hello Adjacencies 402 As outlined in section 2.5.5 of RFC5036, this draft describes that 403 if an LSR has a dual-stack interface, which is enabled with both 404 IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and 405 IPv6 LDP Link Hellos and must separately maintain the Hello 406 adjacency for IPv4 and IPv6 on that interface. 408 This ensures successful labeled IPv4 and labeled IPv6 traffic 409 forwarding on a dual-stacked interface, as well as successful LDP 410 peering using the appropriate transport on a multi-access 411 interface (even if there are IPv4-only, IPv6-only and dual-stack 412 LSRs connected to that multi-access interface). 414 6.3. Maintaining LDP Sessions 416 Two LSRs maintain a single LDP session between them, as described in 417 section 6.1, whether they are connected via a dual-stack LDP enabled 418 interface or via two single-stack LDP enabled interfaces. This is 419 also true when a single-stack interface is converted to a dual-stack 420 interface (e.g. figure 1), or when another interface is added 421 between two LSRs (e.g. figure 2). 423 Needless to say that the procedures defined in section 6.1 would 424 always result in preferring LDPoIPv6 session after the loss of an 425 existing LDP session (because of link failure, node failure, reboot 426 etc.). 428 On the other hand, if a dual-stack interface is converted to a 429 single-stack interface (by disabling IPv4 or IPv6 routing), then the 430 LDP session should be torn down ONLY if the disabled IP version was 431 the same as that of the transport connection. Otherwise, the LDP 432 session should stay intact. 434 If the LDP session is torn down for whatever reason (LDP disabled 435 for the corresponding transport, hello adjacency expiry etc.), then 436 the LSRs should initiate establishing a new LDP session as per the 437 procedures described in section 6.1 of this document along with 438 RFC5036. 440 7. Label Distribution 442 An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as 443 well as interface addresses via ADDRESS message) from/to the peer 444 over an LDP session (using whatever transport), unless it has valid 445 IPv4 and IPv6 Hello Adjacencies for that peer, as specified in 446 section 6.2. 448 Another solution for getting the same result as above is by 449 negotiating the IP Capability for a given AFI, as specified in 450 [IPPWCap]. 452 An LSR MUST NOT allocate and advertise FEC-Label bindings for link- 453 local IPv6 address, and ignore such bindings, if ever received. An 454 LSR MUST treat the IPv4-mapped IPv6 address, defined in section 455 2.5.1 of [RFC4291], the same as that of a global IPv6 address and 456 not mix it with the 'corresponding' IPv4 address. 458 Additionally, to ensure backward compatibility (and interoperability 459 with IPv4-only LDP implementations), this document specifies that - 461 1. An LSR MUST NOT send a label mapping message with a FEC TLV 462 containing FEC Elements of different address-family. In other 463 words, a FEC TLV in the label mapping message MUST contain the 464 FEC Elements belonging to the same address-family. 465 2. An LSR MUST NOT send an Address message (or Address Withdraw 466 message) with an Address List TLV containing IP addresses of 467 different address-family. In other words, an Address List TLV 468 in the Address (or Address Withdraw) message MUST contain the 469 addresses belonging to the same address-family. 471 8. LDP Identifiers and Next Hop Addresses 473 RFC5036 section 2.7 specifies logic for mapping between a peer LDP 474 Identifier and the peer's addresses to find the correct LIB entry 475 for any prefix by using a database populated by the Address message. 476 However, this logic is insufficient to deal with overlapping IPv6 477 (link-local) addresses used by two or more peers. One may note that 478 all interior IP routing protocols specify using link-local IPv6 479 addresses as the next-hops. 481 This document specifies that the logic is enhanced with the usage of 482 (Hello Adjacency) database populated by the Hello messages. This 483 additional database lookup is useful only if/when two or more peers 484 use the same link-local IPv6 address as the IP routing next-hops 485 (causing duplicate next-hop entries). 487 Specifically, this document specifies that an LSR should (continue 488 to) use the machinery described in RFC5036 section 2.7 to map 489 between a peer LDP Identifier and the peer's addresses (learned via 490 ADDRESS message) for any prefix. However, if this mapping fails (for 491 reasons such as the one described earlier), then an LSR can find the 492 peer LDP Identifier by checking for the particular link-local IPv6 493 address in the hello adjacency database. 495 If an LSR can't find such a mapping in either database, then LSR 496 should follow procedures specified in RFC5036 (e.g. not resolve the 497 label). 499 Lastly, for better scale and optimization, an LSR may advertise only 500 the link-local IPv6 addresses in the Address message, assuming that 501 the peer uses only the link-local IPv6 addresses as static and/or 502 dynamic IP routing next-hops. 504 9. LDP TTL Security 506 This document also specifies that the LDP/TCP transport connection 507 over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security 508 Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP 509 session peering established between the adjacent LSRs using Basic 510 Discovery, by default. 512 In other words, GTSM is enabled by default for an IPv6 LDP peering 513 session using Basic Discovery. This means that the 'IP Hop Limit' in 514 IPv6 packet is set to 255 upon sending, and checked to be 255 upon 515 receipt. The IPv6 packet must be dropped failing such a check upon 516 receipt. 518 The reason GTSM is enabled for Basic Discovery by default, but not 519 for Extended Discovery is that the usage of Basic Discovery 520 typically results in a single-hop LDP peering session, whereas the 521 usage of Extended Discovery typically results in a multi-hop LDP 522 peering session. While the latter is deemed out of scope (section 523 1.2), in line with GTSM [RFC5082], it is worth clarifying the 524 following exceptions that may occur with Basic or Extended Discovery 525 usage: 527 a) Two adjacent LSRs (i.e. back-to-back PE routers) forming a 528 single-hop LDP peering session after doing an Extended Discovery 529 (for Pseudowire, say) 530 b) Two adjacent LSRs forming a multi-hop LDP peering session after 531 doing a Basic Discovery, due to the way IP routing changes 532 between them (temporarily (e.g. session protection) or 533 permanently) 534 c) Two adjacent LSRs (i.e. back-to-back PE routers) forming a 535 single-hop LDP peering session after doing both Basic and 536 Extended Discovery 538 In (a), GTSM is not enabled for the LDP peering session by default, 539 hence, it would not do any harm or good. 541 In (b), GTSM is enabled by default for the LDP peering session by 542 default and enforced, hence, it would prohibit the LDP peering 543 session from getting established. 545 In (c), GTSM is enabled by default for Basic Discovery and enforced 546 on the subsequent LDP peering. However, if each LSR uses the same 547 IPv6 transport address object value in both Basic and Extended 548 discoveries, then it would result in a single LDP peering session 549 and that would be enabled with GTSM. Otherwise, GTSM would not be 550 enforced on the 2nd LDP peering session corresponding to the 551 Extended Discovery. 553 This document allows for the implementation to provide an option to 554 statically (configuration) and/or dynamically override the default 555 behavior (enable/disable GTSM) on a per-peer basis. This would also 556 address the exception (b) above. Suffice to say that such an option 557 could be set on either LSR (since GTSM negotiation would ultimately 558 disable GTSM between LSR and its peer(s)). 560 The built-in GTSM inclusion is intended to automatically protect 561 IPv6 LDP peering session from off-link attacks. 563 10. IANA Considerations 565 None. 567 11. Security Considerations 569 The extensions defined in this document only clarify the behavior of 570 LDP, they do not define any new protocol procedures. Hence, this 571 document does not add any new security issues to LDP. 573 While the security issues relevant for the [RFC5036] are relevant 574 for this document as well, this document reduces the chances of off- 575 link attacks when using IPv6 transport connection by including the 576 use of GTSM procedures [RFC5082]. 578 Moreover, this document allows the use of IPsec [RFC4301] for IPv6 579 protection, hence, LDP can benefit from the additional security as 580 specified in [RFC4835] as well as [RFC5920]. 582 12. Acknowledgments 584 We acknowledge the authors of [RFC5036], since the text in this 585 document is borrowed from [RFC5036]. 587 Thanks to Bob Thomas for providing critical feedback to improve this 588 document early on. Thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach 589 Chen, and Kishore Tiruveedhula for reviewing this document. The 590 authors also acknowledge the help of Manoj Dutta and Vividh Siddha. 592 Also, thanks to Andre Pelletier (who brought up the issue about 593 active/passive determination, and helped us craft the appropriate 594 solutions. 596 This document was prepared using 2-Word-v2.0.template.dot. 598 13. Additional Contributors 600 The following individuals contributed to this document: 602 Kamran Raza 603 Cisco Systems, Inc. 604 2000 Innovation Drive 605 Kanata, ON K2K-3E8, Canada 606 Email: skraza@cisco.com 608 Nagendra Kumar 609 Cisco Systems, Inc. 610 SEZ Unit, Cessna Business Park, 611 Bangalore, KT, India 612 Email: naikumar@cisco.com 614 14. References 616 14.1. Normative References 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, March 1997. 621 [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 622 (IPv6) Addressing Architecture", RFC 4291, February 2006. 624 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 625 Specification", RFC 5036, October 2007. 627 [RFC5082] Pignataro, C., Gill, V., Heasley, J., Meyer, D., and 628 Savola, P., "The Generalized TTL Security Mechanism 629 (GTSM)", RFC 5082, October 2007. 631 14.2. Informative References 633 [RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet 634 Protocol", RFC 4301, December 2005. 636 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 637 Requirements for Encapsulating Security Payload (ESP) and 638 Authentication Header (AH)", RFC 4835, April 2007. 640 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 641 Networks", RFC 5920, July 2010. 643 [RFC4798] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS 644 Using IPv6 Provider Edge Routers (6PE)", RFC 4798, 645 February 2007. 647 [IPPWCap] Raza, K., "LDP IP and PW Capability", draft-ietf-mpls-ldp- 648 ip-pw-capability, June 2011. 650 Author's Addresses 652 Vishwas Manral 653 Hewlet-Packard, Inc. 654 19111 Pruneridge Ave., Cupertino, CA, 95014 655 Phone: 408-447-1497 656 Email: vishwas.manral@hp.com 658 Rajiv Papneja 659 Huawei Technologies 660 2330 Central Expressway 661 Santa Clara, CA 95050 662 Phone: +1 571 926 8593 663 EMail: rajiv.papneja@huawei.com 665 Rajiv Asati 666 Cisco Systems, Inc. 667 7025 Kit Creek Road 668 Research Triangle Park, NC 27709-4987 669 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