idnits 2.17.1 draft-manral-mpls-ldp-ipv6-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == 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 document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 13, 2010) is 4937 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) == Unused Reference: 'RFC2460' is defined on line 295, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3513 (ref. 'RFC4291') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) Summary: 4 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 Vishwas Manral 2 Internet Draft IPInfusion Inc. 3 Intended status: Standards Track 4 Expires: April 2011 Rajiv Papneja 5 Isocore 7 Rajiv Asati 8 Cisco Systems 10 October 13, 2010 12 Updates to LDP for IPv6 13 draft-manral-mpls-ldp-ipv6-04 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on April 15, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the BSD License. 53 Abstract 55 The Label Distribution Protocol (LDP) specification defines 56 procedures to exchange label bindings over either IPv4 or IPv6 or 57 both networks. This document corrects and clarifies the LDP behavior 58 when IPv6 network is used. 60 Table of Contents 62 1. Introduction...................................................3 63 2. Specification Language.........................................3 64 3. LSP Mapping....................................................4 65 4. LDP Identifiers................................................4 66 5. Peer Discovery.................................................5 67 5.1. Basic Discovery Mechanism.................................5 68 5.2. Extended Discovery Mechanism..............................5 69 6. LDP Session Establishment......................................6 70 6.1. Transport connection establishment........................6 71 6.2. Session initialization....................................7 72 7. IANA Considerations............................................7 73 8. Security Considerations........................................7 74 9. Acknowledgments................................................7 75 10. References....................................................8 76 10.1. Normative References.....................................8 77 10.2. Informative References...................................8 78 Author's Addresses................................................9 80 1. Introduction 82 The LDP [RFC5036] specification defines procedures and messages for 83 exchanging label bindings over either IPv4 or IPv6 or both (e.g. 84 dual-stack) networks. 86 However, RFC5036 specification has the following deficiencies in 87 regards to IPv6 usage: 89 1) LSP mapping: No rule defined for mapping a particular packet to a 90 particular LSP that has an Address Prefix FEC element containing 91 IPv6 address of the egress router 93 2) LDP identifier: No details specific to IPv6 usage 95 3) LDP discovery: No details for using a particular IPv6 multicast 96 address (with or without IPv4 co-existence) 98 4) LDP Session establishment: No prescription for handling both IPv4 99 and IPv6 transport address optional objects in a Hello message, 100 and subsequently two IPv4 and IPv6 transport connections. 102 This document addresses the above deficiencies by specifying the 103 desired behavior. 105 Note that this document updates RFC5036. 107 2. Specification Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 LDP - Label Distribution Protocol 115 FEC - Forwarding Equivalence Class 117 TLV - Type Length Value 119 LSR - Label Switch Router 121 LSP - Label Switched Path 123 3. LSP Mapping 125 Section 2.1 of [RFC5036] specifies the procedure for mapping a 126 particular packet to a particular LSP using three rules. Quoting the 127 3rd rule from RFC5036: 129 "If it is known that a packet must traverse a particular egress 130 router, and there is an LSP that has an Address Prefix FEC element 131 that is a /32 address of that router, then the packet is mapped to 132 that LSP." 134 Suffice to say, this rule is correct for IPv4, but not for IPv6, 135 since an IPv6 router may not have any /32 address. 137 This document proposes to modify this rule by also including a /128 138 address (for IPv6). In fact, it should be reasonable to just say 139 IPv4 or IPv6 address instead of /32 or /128 addresses as shown below 140 in the updated rule: 142 "If it is known that a packet must traverse a particular egress 143 router, and there is an LSP that has an Address Prefix FEC element 144 that is an IPv4 or IPv6 address of that router, then the packet is 145 mapped to that LSP." 147 4. LDP Identifiers 149 Section 2.2.2 of [RFC5036] specifies formulating at least one LDP 150 Identifier, however, it doesn't provide any consideration in case of 151 IPv6 (with or without dual-stacking). 153 This document preserves the usage of 32-bit LSR Id on an IPv6 only 154 LSR and allows the usage of a common LDP identifier i.e. same LSR-Id 155 and same Label space id for IPv4 and IPv6 on a dual-stack LSR. This 156 rightly enables the per-platform label space to be shared between 157 IPv4 and IPv6. 159 Editor's note: The possible conflict with last paragraph of 160 section 2.5.2 of RFC5036 needs to be addressed or clarified. 162 Additionally, this document reserves 0.0.0.0 as the LSR-Id, and 163 prohibits its usage. 165 5. Peer Discovery 167 5.1. Basic Discovery Mechanism 169 Section 2.4.1 of [RFC5036] defines the Basic Discovery mechanism for 170 directly connected LSRs. Following this mechanism, LSRs periodically 171 sends LDP Link Hellos destined to "all routers on this subnet" group 172 multicast IP address. 174 Interesting enough, per [IANA-IPv6] [RFC4291], IPv6 has three "all 175 routers on this subnet" multicast addresses: 177 FF01:0:0:0:0:0:0:2 = Interface-local scope 179 FF02:0:0:0:0:0:0:2 = Link-local scope 181 FF05:0:0:0:0:0:0:2 = Site-local scope 183 [RFC5036] does not specify which particular IPv6 'all routers on 184 this subnet' group multicast IP address should be used by LDP Link 185 Hellos. 187 This document specifies the usage of link-local scope e.g. 188 FF02:0:0:0:0:0:0:2 as the destination multicast IP address for IPv6 189 LDP Link Hellos. An LDP Hello packet received on any of the other 190 addresses should be dropped. Also, the LDP Link Hello packets must 191 have their IPv6 Hop Limit set to 1. 193 More importantly, if an interface is a dual-stack interface (e.g. 194 enabled with both IPv4 and IPv6 LDP), then the LSR must periodically 195 send both IPv4 and IPv6 LDP Link Hellos and must separately maintain 196 the Hello adjacency for IPv4 and IPv6. This ensures LDP peerings on 197 a multi-access interface (even if there are IPv4-only, IPv6-only and 198 dual-stack routers). Needless to say, the IPv4 and IPv6 LDP Link 199 Hellos must carry the same LDP identifier (assuming per-platform 200 label space usage). 202 5.2. Extended Discovery Mechanism 204 Suffice to say, the extended discovery mechanism (defined in section 205 2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific 206 consideration, since the targeted LDP Hellos are sent to a pre- 207 configured destination IP address. 209 6. LDP Session Establishment 211 Section 2.5.1 of [RFC5036] defines a two-step process for LDP 212 session establishment: 214 1. Transport connection establishment 215 2. Session initialization 217 Next two sections discuss the LDP consideration for IPv6 and/or 218 dual-stacking. 220 6.1. Transport connection establishment 222 Section 2.5.2 of [RFC5036] specifies the use of an optional 223 transport address object (TLV) in LDP Link Hello message, however, 224 it does not specify the behavior of LDP in case of both IPv4 and 225 IPv6 transport address objects (TLV) are sent in a Hello message. 226 Additionally, it does not specify whether both IPv4 and IPv6 227 transport connections should be allowed, if there were Hello 228 adjacencies for both IPv4 and IPv6. 230 This document specifies that: 232 - An LSR should not send the Hello containing both IPv4 and IPv6 233 transport address optional objects. In other words, there would 234 be at most one optional Transport Address object in a Hello 235 message. An LSR should include only the transport address whose 236 address family is the same as that of the IP packet carrying 237 Hello. 239 - An LSR should accept the Hello message that contains both IPv4 240 and IPv6 transport address optional objects, but use only the 241 transport address whose address family is the same as that of 242 the IP packet carrying Hello. 244 - An LSR should not create (or honor the request for creating) a 245 TCP connection for a new LDP session with a remote LSR, if they 246 already have an LDP session (for the same label spaces) 247 established using whatever IP version. This means that only one 248 transport connection is established, even if there are two 249 Hello adjacencies (one for IPv4 and another for IPv6), as 250 highlighted in the last paragraph of section 2.5.2. 252 - An LSR should close the lagging TCP connection for a new LDP 253 session with a remote LSR, if they attempted two TCP 254 connections using IPv4 and IPv6 transports simultaneously. 256 6.2. Session initialization 258 No additional consideration needed. 260 7. IANA Considerations 262 None. 264 8. Security Considerations 266 The extensions defined in this document only clarify the behavior of 267 LDP, they do not define any new protocol procedures. All the 268 security issues relevant for the [RFC5036] are relevant for this 269 document as well. 271 Moreover, this document allows the use of IPsec [RFC4301] for IPv6 272 protection, hence, LDP can benefit from the additional security as 273 specified in [RFC4835]. 275 9. Acknowledgments 277 A lot of the text in this document is borrowed from [RFC5036]. The 278 authors of the document are acknowledged. The authors also 279 aknowledge the help of Manoj Dutta and Vividh Siddha. Thanks to Bob 280 Thomas for providing critical feedback to improve this document 281 early on. 283 This document was prepared using 2-Word-v2.0.template.dot. 285 10. References 287 10.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 293 Specification", RFC 5036, October 2007. 295 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 296 (IPv6) Specification", RFC 2460, December 1998. 298 [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 299 (IPv6) Addressing Architecture", RFC 3513, April 2003. 301 10.2. Informative References 303 [RFC4301] Kent, S. and K. Seo, "Security Architecture and Internet 304 Protocol", RFC 4301, December 2005. 306 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 307 Requirements for Encapsulating Security Payload (ESP) and 308 Authentication Header (AH)", RFC 4835, April 2007. 310 [IANA-IPv6] http://www.iana.org/assignments/ipv6-address-space. 312 Author's Addresses 314 Vishwas Manral 315 IP Infusion Inc., 316 Bamankhola, Bansgali, 317 Almora, Uttarakhand 263601 318 Email: vishwas@ipinfusion.com 320 Rajiv Papneja 321 ISOCORE 322 12359 Sunrise Valley Dr, STE 100 323 Reston, VA 20190 324 Email: rpapneja@isocore.com 326 Rajiv Asati 327 Cisco Systems, 328 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 329 Email: rajiva@cisco.com