idnits 2.17.1 draft-palet-v6ops-p2p-links-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 29, 2018) is 2153 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3627 (Obsoleted by RFC 6547) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops J. Palet Martinez 3 Internet-Draft The IPv6 Company 4 Intended status: Informational May 29, 2018 5 Expires: November 30, 2018 7 IPv6 Point-to-Point Links 8 draft-palet-v6ops-p2p-links-02 10 Abstract 12 This document describes different alternatives for configuring IPv6 13 point-to-point links, considering the prefix size, numbering choices 14 and prefix pool to be used. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on November 30, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 52 3. Prefix Size Choices . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Rationale for using /64 . . . . . . . . . . . . . . . . . 3 54 3.2. Rationale for using /127 . . . . . . . . . . . . . . . . 4 55 3.3. Rationale for using /126 and Other Options . . . . . . . 4 56 3.4. A Possible Middle-Term Choice . . . . . . . . . . . . . . 4 57 4. Numbering Choices . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. GUA (Global Unicast Addresses) . . . . . . . . . . . . . 4 59 4.2. ULA (Unique Local Addresses) . . . . . . . . . . . . . . 5 60 4.3. Unnumbered . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Prefix Pool Choices . . . . . . . . . . . . . . . . . . . . . 6 62 6. /64 from Customer Prefix for point-to-point links . . . . . . 6 63 6.1. Numbering Interfaces . . . . . . . . . . . . . . . . . . 6 64 6.2. Routing Aggregation of the Point-to-Point Links . . . . . 7 65 6.3. DHCPv6 Considerations . . . . . . . . . . . . . . . . . . 8 66 6.4. Router Considerations . . . . . . . . . . . . . . . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 10.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 There are different alternatives for numbering IPv6 point-to-point 78 links, and from an operational perspective, there may have different 79 advantages or disadvantages that need to be taken in consideration 80 under the scope of each specific network architecture design. 82 [RFC6164] describes using /127 prefixes for inter-router point-to- 83 point links, using two different address pools, one for numbering the 84 point-to-point links and another one for delegating the prefixes at 85 the end of the point-to-point link. However this doesn't exclude 86 other choices. 88 This document describes alternative approaches, for the prefix size, 89 the numbering of the link and the prefix pool. 91 The proposed approaches are suitable for those point-to-point links 92 connecting ISP to customers, but not limited to those cases, and in 93 fact, all them are being used by a relevant number of networks 94 worldwide, in several different scenarios (service providers, 95 enterprise networks, etc.). 97 2. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 3. Prefix Size Choices 107 [RFC7608] already discusses about the IPv6 prefix length 108 recommendations for forwarding, and the need for routing and 109 forwarding implementations to ensure that longest-prefix-match works 110 on any prefix length. So, in this document, we concentrate in the 111 most commonly used choices, not excluding other options. 113 3.1. Rationale for using /64 115 The IPv6 Addressing Architecture ([RFC4291]) specifies that all the 116 Interface Identifiers for all the unicast addresses (except for 117 000/3) are required to be 64 bits long and to be constructed in 118 Modified EUI-64 format. 120 The same document also mandates the usage of the predefined subnet- 121 router anycast address, which has cleared to zero all the bits that 122 do not form the subnet prefix. 124 Using /64 is the most common scenario and currently the best practice 125 by the number of service providers using this approach compared to 126 others. 128 Using a /64 has the advantage of being future proof and avoids 129 renumbering, in the event that new standards take advantage of the 64 130 bits for other purposes, or the link becomes a point-to-multipoint, 131 or there is a need to use more addresses in the link (e.g., 132 monitoring equipment, managed bridges). 134 It has been raised also the issue of some hardware having limitations 135 in using prefixes longer then /64, for example using extra hardware 136 resources. 138 [RFC6164] describes possible issues when using /64 for the point-to- 139 point links, however, it also states that they can be mitigated by 140 other means, and indeed, considering the publication date of that 141 document, those issues should not be any longer a concern. The fact 142 is that many operators wordwide, today use /64 without any concerns, 143 as vendors have taken the necessary code updates. 145 Consequently, we shall conclude that it is a valid approach to use 146 /64 prefixes for the point-to-point links. 148 3.2. Rationale for using /127 150 [RFC6164] already do a complete review of reasons why /127 is a good 151 approach vs other options. However, it needs to be considered that 152 it was published a number of years ago, and most of the hardware 153 today already incorporate mitigations. 155 It is a valid approach to use /127 for the point-to-point links, 156 however is not future proof considering the comments from the 157 previous section, and older equipment may not support it. 159 3.3. Rationale for using /126 and Other Options 161 /126 was considered by [RFC3627], and despite this document has been 162 obsoleted, because was considering /127 as harmful, the 163 considerations in Section 4.3 are still valid. 165 The same document describes options such as /112 and /120, and all 166 those are commonly used in worldwide IPv6 deployments, though in a 167 lesser degree than /64 or /127. 169 Consequently, we shall conclude that /126, /120 and /112 are valid 170 approaches for the point-to-point links. 172 3.4. A Possible Middle-Term Choice 174 A possible "middle-term" approach, will be to allocate a /64 for each 175 point-to-point link, but use just one /127 out of it, making it 176 future proof and at the same time avoiding possible issues indicated 177 in the previous sections. 179 4. Numbering Choices 181 IPv6 provides different unicast addressing types which can be 182 considered when numbering a point-to-point link. 184 It has been reported that certain hardware may consume resources when 185 using numbered links. This is a very specific situation that may 186 need to be consider on a case by case basis. 188 4.1. GUA (Global Unicast Addresses) 190 Using GUA is the most common approach. It provides full 191 functionality for both and end-points of the point-to-point links and 192 consequently, facilitates troubleshooting . 194 4.2. ULA (Unique Local Addresses) 196 Some networks use ULAs for numbering the point-to-point links. This 197 approach may cause numerous problems and therefore is strongly 198 discouraged. For example, if the CE needs to send an ICMPv6 message 199 to a host outside that network (to the Internet), the packet with ULA 200 source address will not get thru and PMTUD will break, which in turn 201 will completely break that IPv6 connection when the MTU is not the 202 same for all the path. 204 However, this approach is valid if, following Section 2.2 of 205 [RFC4443], and despite using ULA for the point-to-point link, the 206 router is configured with at least one GUA and the source of the 207 ICMPv6 messages are always a GUA. 209 4.3. Unnumbered 211 Some networks leave the point-to-point links unnumbered, so only 212 link-local addresses are used at both ends of the link. 214 Considerations of [RFC7404] (Using Only Link-Local Addressing inside 215 an IPv6 Network) fully apply to this case. 217 While this might work for routers, it does not work for devices that 218 can't request a prefix delegation over DHCPv6 and are therefore left 219 without any usable GUA to allow traffic forwarding. 221 In the case of a router, the route for the assigned prefix is pointed 222 towards the link-local address on the router WAN port and the default 223 route on the router is pointed towards the link-local address on the 224 upstream network equipment port. 226 This choice seems easier to implement, compared the previous ones, 227 but it also brings some drawbacks, such as difficulties with 228 troubleshooting and monitoring. For example, link local addresses do 229 not appear in traceroute, so it makes more difficult to locate the 230 exact point of failure. 232 It is more useful in scenarios where it is known that only a router 233 will be attached to the point-to-point link, and where the configured 234 address of the router is known. Non-routers connecting to a network, 235 which can't initiate DHCPv6-PD might experience problems and will 236 stay unnumbered upon connection, if a /64 prefix is not used to 237 number the link. This may be also the case for routers, which will 238 not be able to complete the DHCPv6-PD in unnumbered links. 240 The considerations indicated in the previous section, regarding not 241 using ULA as source address of ICMPv6 messages, and instead ensuring 242 there is at least one GUA configured for that, also apply if link- 243 locals are used for the point-to-point link. 245 5. Prefix Pool Choices 247 The logic choice seems to use a dedicated pool of IPv6 addresses, as 248 this is the way we are "used to" with IPv4. Actually this is done 249 often by means of different IPv6 pools at every PoP in a service 250 provider network. 252 A possible benefit of using a dedicated IPv6 pool, is that allows 253 applying security policies without harming the customers. This is 254 only true if customers always have a CE at their end of the WAN link. 256 However, the fact that the default IPv6 link size is /64 and commonly 257 multiple /64's are assigned to a single customer, provides an 258 interesting alternative approach for combining "best practices" 259 described in the precedent sections. 261 The following section depicts this alternative. 263 6. /64 from Customer Prefix for point-to-point links 265 Using a /64 from the customer prefix, in addition to the advantages 266 already indicated when using /64, simplifies the addressing plan. 268 The use of /64 also facilitates an easier way for routing the shorter 269 aggregated prefix into the point-to-point link. Consequently it 270 simplifies the "view" of a more unified addressing plan, providing an 271 easier path for following up any issue when operating IPv6 networks, 272 and typically will have a great impact in saving expensive hardware 273 resources (lower usage of TCAM, typically by half). 275 This mechanism would not work in broadcast layer two media that rely 276 on ND (as it will try ND for all the addresses within the shorter 277 prefix being delegated thru the point-to-point link). 279 6.1. Numbering Interfaces 281 Often, in point-to-point links, hardware tokens are not available, or 282 there is the need to keep certain bits (u, g) cleared, so the links 283 can be manually numbered sequentially with most of the bits cleared 284 to zero. This numbering makes as well easier to remember the 285 interfaces, which typically will become numbered as 1 (with 63 286 leading zero bits) for the provider side and 2 (with 63 leading zero 287 bits) for the customer side. 289 Using interface identifiers as 1 and 2 is not only a very simple 290 approach, but also a very common practice. Other different choices 291 can as well be used as required in each case. 293 On the other hand, using the EUI-64, makes it more difficult to 294 remember and handle the interfaces, but provides an additional degree 295 of protection against port (actually address) scanning as described 296 at [RFC7707]. 298 6.2. Routing Aggregation of the Point-to-Point Links 300 Following this approach and assuming that a shorter prefix is 301 typically delegated to a customer, for example a /48, it is possible 302 to simplify the routing aggregation of the point-to-point links. 303 Towards this, the point-to-point link may be numbered using the first 304 /64 of the /48 delegated to the customer. 306 Let's see a practical example: 308 o A service provider uses the prefix 2001:db8::/32 and is using 309 2001:db8:aaaa::/48 for a given customer. 311 o Instead of allocating the point-to-point link from a different 312 addressing pool, it may use 2001:db8:aaaa::/64 (which is the first 313 /64 subnet from the 2001:db8:aaaa::/48) to number the link. 315 o This means that, in the case the non-EUI-64 approach is used, the 316 point-to-point link may be numbered as 2001:db8:aaaa::1/64 for the 317 provider side and 2001:db8:aaaa::2/64 for the customer side. 319 o Note that using the first /64 and interface identifiers 1 and 2 is 320 a very common practice. However other values may be chosen 321 according to each case specific needs. 323 In this way, as the same address pool is being used for both, the 324 prefix and the point-to-point link, one of the advantages of this 325 approach is to make very easy the recognition of the point-to-point 326 link that belongs to a given customer prefix, or in the other way 327 around, the recognition of the prefix that is linked by a given 328 point-to-point link. 330 For example, making a trace-route to debug any issue to a given 331 address in the provider network, will show a straight view, and it 332 becomes unnecessary one extra step to check a database that correlate 333 an address pool for the point-to-point links and the customer 334 prefixes, as all they are the same. 336 Moreover, it is possible to use the shorter prefix as the provider 337 side numbering for the point-to-point link and keep the /64 for the 338 customer side. In our example, it will become: 340 o Point-to-point link at provider side: 2001:db8:aaaa::1/48 342 o Point-to-point link at customer side: 2001:db8:aaaa::2/64 344 This provides one additional advantage as in some platforms the 345 configuration may be easier saving one step for the route of the 346 delegated prefix (no need for two routes to be configured, one for 347 the delegated prefix, one for the point-to-point link). It is 348 possible because the longest-prefix-match rule. 350 The behavior of this type of configuration has been successfully 351 deployed in different operator and enterprise networks, using 352 commonly available implementations with different routing protocols, 353 including RIP, BGP, IS-IS, OSPF, along static routing, and no 354 failures or interoperability issues have been reported. 356 6.3. DHCPv6 Considerations 358 As stated in [RFC3633], "the requesting router MUST NOT assign any 359 delegated prefixes or subnets from the delegated prefix(es) to the 360 link through which is received the DHCP message from the delegating 361 router", however the approach described in this document is still 362 useful in other DHCPv6 scenarios or non-DHCPv6 scenarios. 364 Furthermore, [RFC3633] was updated by Prefix Exclude Option for 365 DHCPv6-based Prefix Delegation ([RFC6603]), precisely to define a new 366 DHCPv6 option, which covers the case described by this document. 368 Moreover, [RFC3769] has no explicit requirement that avoids the 369 approach described in this document. 371 6.4. Router Considerations 373 This approach is being used by operators in both, residential/SOHO 374 and enterprise networks, so the routers at the customer end for those 375 networks MUST support [RFC6603] if DHCPv6-PD is used. 377 In the case of Customer Edge Routers there is a specific requirement 378 ([RFC7084]) WPD-8 (Prefix delegation Requirements), marked as SHOULD 379 for [RFC6603]. However, in an scenario where the approach described 380 in this document is followed, together with DHCPv6-PD, the CE Router 381 MUST support [RFC6603]. 383 7. Security Considerations 385 This document does not have any new specific security considerations. 387 8. IANA Considerations 389 This document does not have any new specific IANA considerations. 391 9. Acknowledgements 393 The author would like to acknowledge the inputs of Mikael 394 Abrahamsson, Brian Carpenter and ... 396 Acknowledge is also due to my co-authors of RIPE-690 (Best Current 397 Operational Practice for Operators: IPv6 prefix assignment for end- 398 users - persistent vs non-persistent, and what size to choose, 399 https://www.ripe.net/publications/docs/ripe-690) and global 400 community, which provided valuable inputs which have been key for 401 this document. 403 Acknowledgement to co-authors, Cesar Olvera and Miguel Angel Diaz, of 404 a previous related document (draft-palet-v6ops-point2point, 2006), as 405 well as inputs for that version from Alain Durand, Chip Popoviciu, 406 Daniel Roesen, Fred Baker, Gert Doering, Olaf Bonness, Ole Troan, 407 Pekka Savola and Vincent Jardin, are also granted. 409 10. References 411 10.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 419 Host Configuration Protocol (DHCP) version 6", RFC 3633, 420 DOI 10.17487/RFC3633, December 2003, 421 . 423 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 424 Delegation", RFC 3769, DOI 10.17487/RFC3769, June 2004, 425 . 427 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 428 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 429 2006, . 431 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 432 Control Message Protocol (ICMPv6) for the Internet 433 Protocol Version 6 (IPv6) Specification", STD 89, 434 RFC 4443, DOI 10.17487/RFC4443, March 2006, 435 . 437 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 438 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 439 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 440 . 442 [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. 443 Troan, "Prefix Exclude Option for DHCPv6-based Prefix 444 Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, 445 . 447 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 448 Requirements for IPv6 Customer Edge Routers", RFC 7084, 449 DOI 10.17487/RFC7084, November 2013, 450 . 452 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 453 Length Recommendation for Forwarding", BCP 198, RFC 7608, 454 DOI 10.17487/RFC7608, July 2015, 455 . 457 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 458 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 459 . 461 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 462 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 463 May 2017, . 465 10.2. Informative References 467 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 468 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 469 September 2003, . 471 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 472 Addressing inside an IPv6 Network", RFC 7404, 473 DOI 10.17487/RFC7404, November 2014, 474 . 476 Author's Address 478 Jordi Palet Martinez 479 The IPv6 Company 480 Molino de la Navata, 75 481 La Navata - Galapagar, Madrid 28420 482 Spain 484 Email: jordi.palet@theipv6company.com 485 URI: http://www.theipv6company.com/