idnits 2.17.1 draft-palet-v6ops-p2p-from-customer-prefix-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 195: '... As stated in [RFC3633], "the requesting router MUST NOT assign any...' RFC 2119 keyword, line 212: '... networks MUST support [RFC6603] if DHCPv6-PD is used....' RFC 2119 keyword, line 215: '... ([RFC7084]) WPD-8 (Prefix delegation Requirements), marked as SHOULD...' RFC 2119 keyword, line 218: '... MUST support [RFC6603]....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2017) is 2362 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3769 ** Downref: Normative reference to an Informational RFC: RFC 7084 ** Downref: Normative reference to an Informational RFC: RFC 7707 Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: Best Current Practice October 28, 2017 5 Expires: May 1, 2018 7 Using /64 from Customer Prefix for the Inter-Router Link 8 draft-palet-v6ops-p2p-from-customer-prefix-01 10 Abstract 12 This document describes the usage of a /64 from the customer prefix 13 for numbering IPv6 point-to-point links in non-broadcast layer 2 14 media. 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 May 1, 2018. 33 Copyright Notice 35 Copyright (c) 2017 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. Rational for using /64 . . . . . . . . . . . . . . . . . . . 3 52 3. Numbering Interfaces . . . . . . . . . . . . . . . . . . . . 3 53 4. Routing Aggregation of the Point-to-Point Links . . . . . . . 3 54 5. DHCPv6 Considerations . . . . . . . . . . . . . . . . . . . . 5 55 6. Router Considerations . . . . . . . . . . . . . . . . . . . . 5 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 There are different alternatives for numbering IPv6 point-to-point 65 links, and from an operational perspective, they may have different 66 advantages or disadvantages that need to be taken in consideration 67 under the scope of each specific network architecture design. 69 [RFC6164] describes using /127 prefixes for inter-router point-to- 70 point links, using two different address pools, one for numbering the 71 point-to-point links and another one for delegating the prefixes at 72 the end of the point-to-point link. However this doesn't exclude 73 other choices. 75 This document describes an alternative the approach, using a /64 from 76 the customer prefix, which ensure compliance with standards, and 77 consequently facilitate interoperability, avoids possible future 78 issues if more addresses are needed (e.g., managed bridges) and 79 simplifies the addressing plan. 81 The use of /64 also facilitates an easier way for routing the shorter 82 aggregated prefix into the point-to-point link. Consequently it 83 simplifies the "view" of a more unified addressing plan, providing an 84 easier path for following up any issue when operating IPv6 networks. 86 The proposed approach is suitable for those point-to-point links 87 connecting ISP to Customers and enterprise networks, but not limited 88 to those cases, and in fact, is being used by a relevant number of 89 networks worldwide, in several different scenarios. 91 This mechanism would not work in broadcast layer two media that rely 92 on ND (as it will try ND for all the addresses within the shorter 93 prefix being delegated thru the point-to-point link). 95 2. Rational for using /64 97 The IPv6 Addressing Architecture ([RFC4291]) specifies that all the 98 Interface Identifiers for all the unicast addresses (except for 99 000/3) are required to be 64 bits long and to be constructed in 100 Modified EUI-64 format. 102 The same document also mandates the usage of the predefined subnet- 103 router anycast address, which has cleared to zero all the bits that 104 do not form the subnet prefix. 106 [RFC6164] describes possible issues when using /64 for the point-to- 107 point linkes, however, it also states that they can be mitigated by 108 other means, and indeed, considering the publication date of that 109 document, those issues should not be any longer considered. The fact 110 is that many operators wordwide, today use /64 without any concerns, 111 as vendors have taken the necessary code updates. 113 Consequently, we shall conclude that /64 it is a valid approach to 114 use /64 prefixes for the point-to-point links. 116 3. Numbering Interfaces 118 Often, in point-to-point links, hardware tokens are not available, or 119 there is the need to keep certain bits (u, g) cleared, so the links 120 can be manually numbered sequentially with most of the bits cleared 121 to zero. This numbering makes as well easier to remember the 122 interfaces, which typically will become numbered as 1 (with 63 123 leading zero bits) for the provider side and 2 (with 63 leading zero 124 bits) for the customer side. 126 Using interface identifiers as 1 and 2 is not only a very simple 127 approach, but also a very common practice. Other different choices 128 can as well be used as required in each case. 130 On the other hand, using the EUI-64, makes it more difficult to 131 remember and handle the interfaces, but provides an additional degree 132 of protection against port (actually address) scanning as described 133 at [RFC7707]. 135 4. Routing Aggregation of the Point-to-Point Links 137 Following this approach and assuming that a shorter prefix is 138 typically delegated to a customer, for example a /48, it is possible 139 to simplify the routing aggregation of the point-to-point links. 140 Towards this, the point-to-point link may be numbered using the first 141 /64 of the /48 delegated to the customer. 143 Let's see a practical example: 145 o A service provider uses the prefix 2001:db8::/32 and is using 146 2001:db8:aaaa::/48 for a given customer. 148 o Instead of allocating the point-to-point link from a different 149 addressing pool, it may use 2001:db8:aaaa::/64 (which is the first 150 /64 subnet from the 2001:db8:aaaa::/48) to number the link. 152 o This means that, in the case the non-EUI-64 approach is used, the 153 point-to-point link may be numbered as 2001:db8:aaaa::1/64 for the 154 provider side and 2001:db8:aaaa::2/64 for the customer side. 156 o Note that using the first /64 and interface identifiers 1 and 2 is 157 a very common practice. However other values may be chosen 158 according to each case specific needs. 160 In this way, as the same address pool is being used for both, the 161 prefix and the point-to-point link, one of the advantages of this 162 approach is to make very easy the recognition of the point-to-point 163 link that belongs to a given customer prefix, or in the other way 164 around, the recognition of the prefix that is linked by a given 165 point-to-point link. 167 For example, making a trace-route to debug any issue to a given 168 address in the provider network, will show a straight view, and it 169 becomes unnecessary one extra step to check a database that correlate 170 an address pool for the point-to-point links and the customer 171 prefixes, as all they are the same. 173 Moreover, it is possible to use the shorter prefix as the provider 174 side numbering for the point-to-point link and keep the /64 for the 175 customer side. In our example, it will become: 177 o Point-to-point link at provider side: 2001:db8:aaaa::1/48 179 o Point-to-point link at customer side: 2001:db8:aaaa::2/64 181 This provides one additional advantage as in some platforms the 182 configuration may be easier saving one step for the route of the 183 delegated prefix (no need for two routes to be configured, one for 184 the delegated prefix, one for the point-to-point link). It is 185 possible because the longest-prefix-match rule. 187 The behavior of this type of configuration has been successfully 188 deployed in different operator and enterprise networks, using 189 commonly available implementations with different routing protocols, 190 including RIP, BGP, IS-IS, OSPF, along static routing, and no 191 failures or interoperability issues have been reported. 193 5. DHCPv6 Considerations 195 As stated in [RFC3633], "the requesting router MUST NOT assign any 196 delegated prefixes or subnets from the delegated prefix(es) to the 197 link through which is received the DHCP message from the delegating 198 router", however the approach described in this document is still 199 useful in other DHCPv6 scenarios or non-DHCPv6 scenarios. 201 Furthermore, [RFC3633] was updated by Prefix Exclude Option for 202 DHCPv6-based Prefix Delegation ([RFC6603]), precisely to define a new 203 DHCPv6 option, which covers the case described by this document. 205 Moreover, [RFC3769] has no explicit requirement that avoids the 206 approach described in this document. 208 6. Router Considerations 210 This approach is being used by operators in both, residential/SOHO 211 and enterprise networks, so the routers at the customer end for those 212 networks MUST support [RFC6603] if DHCPv6-PD is used. 214 In the case of Customer Edge Routers there is a specific requirement 215 ([RFC7084]) WPD-8 (Prefix delegation Requirements), marked as SHOULD 216 for [RFC6603]. However, in an scenario where the approach described 217 in this document is followed, together with DHCPv6-PD, the CE Router 218 MUST support [RFC6603]. 220 7. Security Considerations 222 This document does not have any new specific security considerations. 224 8. IANA Considerations 226 This document does not have any new specific IANA considerations. 228 9. Acknowledgements 230 The author would like to acknowledge the inputs of Mikael Abrahamsson 231 ... Acknowledgement to co-authors, Cesar Olvera and Miguel Angel 232 Diaz, of a previous related document (draft-palet-v6ops-point2point, 233 2006), as well as inputs for that version from Alain Durand, Chip 234 Popoviciu, Daniel Roesen, Fred Baker, Gert Doering, Olaf Bonness, Ole 235 Troan, Pekka Savola and Vincent Jardin, are also granted. 237 10. Normative References 239 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 240 Host Configuration Protocol (DHCP) version 6", RFC 3633, 241 DOI 10.17487/RFC3633, December 2003, 242 . 244 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 245 Delegation", RFC 3769, DOI 10.17487/RFC3769, June 2004, 246 . 248 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 249 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 250 2006, . 252 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 253 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 254 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 255 . 257 [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. 258 Troan, "Prefix Exclude Option for DHCPv6-based Prefix 259 Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, 260 . 262 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 263 Requirements for IPv6 Customer Edge Routers", RFC 7084, 264 DOI 10.17487/RFC7084, November 2013, 265 . 267 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 268 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 269 . 271 Author's Address 273 Jordi Palet Martinez 274 The IPv6 Company 275 Molino de la Navata, 75 276 La Navata - Galapagar, Madrid 28420 277 Spain 279 Email: jordi.palet@theipv6company.com 280 URI: http://www.theipv6company.com/