idnits 2.17.1 draft-palet-v6ops-point2point-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 296. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 190: '... As stated in [5], "the requesting router MUST NOT assign any...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 26, 2006) is 6507 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 3627 (ref. '2') (Obsoleted by RFC 6547) -- Obsolete informational reference (is this intentional?): RFC 3177 (ref. '4') (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '5') (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Palet 3 Internet-Draft C. Olvera 4 Expires: December 28, 2006 M. Diaz 5 Consulintel 6 June 26, 2006 8 Guidelines for Numbering IPv6 Point-to-Point Links and Easing the 9 Addressing Plans 10 draft-palet-v6ops-point2point-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 28, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document analyzes the rational for using /64 for numbering IPv6 44 point-to-point links and provides some guidelines to simplify the 45 addressing plans. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Rational for using /64 . . . . . . . . . . . . . . . . . . . . 3 51 3. Numbering Interfaces . . . . . . . . . . . . . . . . . . . . . 4 52 4. Routing Aggregation of the Point-to-Point Links . . . . . . . . 4 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 55 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 58 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 60 Intellectual Property and Copyright Statements . . . . . . . . . . 8 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 However, as a general rule, this document suggest the approach of 70 using /64 in order to ensure not only compliance with standards, and 71 consequently facilitate interoperability, but also in order to ensure 72 avoiding possible future issues and simplifying the addressing plans. 74 The use of /64 also facilitates an easier way for routing the shorter 75 aggregated prefix into the point-to-point link. Consequently it 76 simplifies the "view" of a more unified addressing plan, providing an 77 easier path for following up any issue when operating IPv6 networks. 79 The proposed approach is suitable for those point-to-point links 80 connecting ISP to Customers, but not limited to this case, and in 81 fact, has been tried in real scenarios for different cases. In that 82 sense, this document can be read as guidelines for one of the 83 possible choices available, not as a generic guideline for all the 84 possible ways to address this. 86 There is another well known approach, which use two different address 87 pools, one for the numbering the point-to-point links and another one 88 for delegating the prefixes at the end of the point-to-point link. 89 This document approaches for a more unified and aggregated addressing 90 plan. 92 2. Rational for using /64 94 The IPv6 Addressing Architecture [1] specifies that all the Interface 95 Identifiers for all the unicast addresses (except for 000/3) are 96 required to be 64 bits long and to be constructed in Modified EUI-64 97 format. As a consequence it is forbidden to use prefixes longer than 98 /64. 100 The same document also mandates the usage of the predefined subnet- 101 router anycast address, which has cleared to zero all the bits that 102 do not form the subnet prefix. 104 Moreover, [2] describes de problems of using /127 especially on 105 point-to-point links between routers. This document also describes 106 different choices for the point-to-point links and actually, without 107 advocating for any specific prefix length, shows that /64 is the best 108 solution from different perspectives, including operational 109 practicality. 111 Consequently, we shall conclude that /64 should be used for numbering 112 point-to-point links. 114 3. Numbering Interfaces 116 Often, in point-to-point links, hardware tokens are not available, or 117 there is the need to keep certain bits (u, g) cleared, so the links 118 can be manually numbered sequentially with most of the bits cleared 119 to zero. This numbering makes as well easier to remember the 120 interfaces, which typically will become numbered as 1 (with 63 121 leading zero bits) for the provider side and 2 (with 63 leading zero 122 bits) for the customer side. 124 Using interface identifies as 1 and 2 is only a very simple suggested 125 example, and other different choices can as well be used as required 126 in each case. 128 On the other hand, using the EUI-64, makes it more difficult to 129 remember and handle the interfaces, but provides an additional degree 130 of protection against port (actually address) scanning as described 131 at [3]. 133 4. Routing Aggregation of the Point-to-Point Links 135 Following this approach and assuming that a shorter prefix is 136 typically delegated to a customer, in general a /48 [4], it is 137 possible to simplify the routing aggregation of the point-to-point 138 links. Towards this, the point-to-point link may be numbered using 139 the first /64 of a given /48. 141 Let's see a practical example: 143 o A service provider uses the prefix 2001:db8::/32 and is using 144 2001:db8:aaaa::/48 for a given customer. 146 o Instead of allocating the point-to-point link from a different 147 addressing pool, it may use 2001:db8:aaaa::/64 (which is the first 148 /64 subnet from the 2001:db8:aaaa::/48) to number the link. 150 o This means that, in the case the non-EUI-64 approach is used, the 151 point-to-point link may be numbered as 2001:db8:aaaa::1/64 for the 152 provider side and 2001:db8:aaaa::2/64 for the customer side. 154 o Note that using the first /64 and interface identifiers 1 and 2 is 155 only a very simple example, and other values may be chosen 156 according to each case specific needs. 158 In this way, as the same address pool is being used for both the 159 prefix and the point-to-point link, one of the advantages of this 160 approach is to make very easy remembering the point-to-point links 161 that belong to a given customer prefix, or in the other way around, 162 remember the prefix that is linked by a given point-to-point link. 164 For example, making a trace-route to debug any issue to a given 165 address in the provider network, will show a straight view, and there 166 will not be need to check a database that related an address pool for 167 the point-to-point links and the customer prefixes, as all they are 168 the same. 170 Moreover, it is possible to use the shorter prefix as the provider 171 side numbering for the point-to-point link and keep the /64 for the 172 customer side. In our example, it will become: 174 o Point-to-point link at provider side: 2001:db8:aaaa::1/48 176 o Point-to-point link at customer side: 2001:db8:aaaa::2/64 178 This provides one additional advantage as in some platforms the 179 configuration may be easier saving one step for the route of the 180 delegated prefix (no need for two routes to be configured, one for 181 the prefix, one for the point-to-point link). It is possible because 182 the longest-prefix-match rule. 184 The behavior of this type of configuration has been successfully 185 tested in different commonly available implementations with different 186 routing protocols, including RIP, BGP, IS-IS, OSPF, along static 187 routing, and has been used in several scenarios for a few months 188 without any failures having been reported. 190 As stated in [5], "the requesting router MUST NOT assign any 191 delegated prefixes or subnets from the delegated prefix(es) to the 192 link through which is received the DHCP message from the delegating 193 router", however the approach described in this document may still be 194 useful in other DHCPv6 scenarios or non-DHCPv6 scenarios. Moreover, 195 [6] has no explicit requirement that avoids the approach described in 196 this document. Furthermore, this has been tested in DHCPv6-PD 197 implementations and worked well, so we must say that it may be 198 implementation-dependent. 200 5. Security Considerations 202 No security concerns seem to be related to this proposal. 204 6. IANA Considerations 206 This document does not have any specific IANA considerations. 208 7. Acknowledgements 210 The authors would like to acknowledge the inputs/comments from Alain 211 Durand, Chip Popoviciu, Daniel Roesen, Fred Baker, Gert Doering, Olaf 212 Bonness, Ole Troan, Pekka Savola, Vincent Jardin and the Spanish 213 Ministry of Industry support in the co-funding of the Eureka PlaNetS 214 project, where this work is being developed. 216 8. References 218 8.1. Normative References 220 [1] Hinden, R. and S. Deering, "IP Version 6 Addressing 221 Architecture", RFC 4291, February 2006. 223 8.2. Informative References 225 [2] Savola, P., "Use of /127 Prefix Length Between Routers 226 Considered Harmful", RFC 3627, September 2003. 228 [3] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", 229 draft-chown-v6ops-port-scanning-implications-02 (work in 230 progress), October 2005. 232 [4] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 233 Allocations to Sites", RFC 3177, September 2001. 235 [5] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 236 Configuration Protocol (DHCP) version 6", RFC 3633, 237 December 2003. 239 [6] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 240 Delegation", RFC 3769, June 2004. 242 Authors' Addresses 244 Jordi Palet Martinez 245 Consulintel 246 Molino de la Navata, 75 247 La Navata - Galapagar - Madrid 248 E-28420 - Spain 250 Phone: +34 91 151 81 99 251 Fax: +34 91 151 81 98 252 Email: jordi.palet@consulintel.es 254 Cesar Olvera Morales 255 Consulintel 256 Molino de la Navata, 75 257 La Navata - Galapagar - Madrid 258 E-28420 - Spain 260 Phone: +34 91 151 81 99 261 Fax: +34 91 151 81 98 262 Email: cesar.olvera@consulintel.es 264 Miguel Angel Diaz Fernandez 265 Consulintel 266 Molino de la Navata, 75 267 La Navata - Galapagar - Madrid 268 E-28420 - Spain 270 Phone: +34 91 151 81 99 271 Fax: +34 91 151 81 98 272 Email: miguelangel.diaz@consulintel.es 274 Intellectual Property Statement 276 The IETF takes no position regarding the validity or scope of any 277 Intellectual Property Rights or other rights that might be claimed to 278 pertain to the implementation or use of the technology described in 279 this document or the extent to which any license under such rights 280 might or might not be available; nor does it represent that it has 281 made any independent effort to identify any such rights. Information 282 on the procedures with respect to rights in RFC documents can be 283 found in BCP 78 and BCP 79. 285 Copies of IPR disclosures made to the IETF Secretariat and any 286 assurances of licenses to be made available, or the result of an 287 attempt made to obtain a general license or permission for the use of 288 such proprietary rights by implementers or users of this 289 specification can be obtained from the IETF on-line IPR repository at 290 http://www.ietf.org/ipr. 292 The IETF invites any interested party to bring to its attention any 293 copyrights, patents or patent applications, or other proprietary 294 rights that may cover technology that may be required to implement 295 this standard. Please address the information to the IETF at 296 ietf-ipr@ietf.org. 298 Disclaimer of Validity 300 This document and the information contained herein are provided on an 301 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 302 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 303 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 304 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 305 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 306 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 308 Copyright Statement 310 Copyright (C) The Internet Society (2006). This document is subject 311 to the rights, licenses and restrictions contained in BCP 78, and 312 except as set forth therein, the authors retain all their rights. 314 Acknowledgment 316 Funding for the RFC Editor function is currently provided by the 317 Internet Society.