idnits 2.17.1 draft-palet-v6ops-point2point-00.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 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 240. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 247. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 253. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 27, 2006) is 6626 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) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 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: August 31, 2006 M. Diaz 5 Consulintel 6 February 27, 2006 8 Guidelines for Numbering IPv6 Point-to-Point Links and Easing the 9 Addressing Plans 10 draft-palet-v6ops-point2point-00.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 August 31, 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 . . . . . . . . . . . . . . . . . . . . . 3 52 4. Routing Aggregation of the Point-to-Point Links . . . . . . . . 4 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 55 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 58 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 60 Intellectual Property and Copyright Statements . . . . . . . . . . 7 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 2. Rational for using /64 81 The IPv6 Addressing Architecture [1] specifies that all the Interface 82 Identifiers for all the unicast addresses (except for 000/3) are 83 required to be 64 bits long and to be constructed in Modified EUI-64 84 format. As a consequence it is forbidden to use prefixes longer than 85 /64. 87 The same document also mandates the usage of the predefined subnet- 88 router anycast address, which has cleared to zero all the bits that 89 do not form the subnet prefix. 91 Moreover, [2] describes de problems of using /127 especially on 92 point-to-point links between routers. This document also describes 93 different choices for the point-to-point links and actually, without 94 advocating for any specific prefix length, shows that /64 is the best 95 solution from different perspectives, including operational 96 practicality. 98 Consequently, we shall conclude that /64 should be used for numbering 99 point-to-point links. 101 3. Numbering Interfaces 103 Often, in point-to-point links, hardware tokens are not available, so 104 frequently they are manually numbered sequentially with most of the 105 bits cleared to zero. This also match the need to keep certain bits 106 (u, g) cleared. This numbering makes as well easier to remember the 107 interfaces, which typically will become numbered as 1 (with 63 108 leading zero bits) for the provider side and 2 (with 63 leading zero 109 bits) for the customer side. 111 On the other hand, using the EUI-64, makes it more difficult to 112 remember and handle the interfaces, but provides an additional degree 113 of protection against port (actually address) scanning as described 114 at [3]. 116 4. Routing Aggregation of the Point-to-Point Links 118 Following this approach and assuming that a shorter prefix is 119 typically delegated to a customer, in general a /48 [4], it is 120 possible to simplify the routing aggregation of the point-to-point 121 links. Towards this, the point-to-point link may be numbered using 122 the first /64 of a given /48. 124 Let's see a practical example: 126 o A service provider uses the prefix 2001:db8::/32 and is using 127 2001:db8:aaaa::/48 for a given customer. 129 o Instead of allocating the point-to-point link from a different 130 addressing pool, it may use 2001:db8:aaaa::/64 (which is the first 131 /64 subnet from the 2001:db8:aaaa::/48) to number the link. 133 o This means that, in the case the non-EUI-64 approach is used, the 134 point-to-point link will be numbered as 2001:db8:aaaa::1/64 for 135 the provider side and 2001:db8:aaaa::2/64 for the customer side. 137 In this way, as the same address pool is being used for both the 138 prefix and the point-to-point link, one of the advantages of this 139 approach is to make very easy remembering the point-to-point links 140 that belong to a given customer prefix, or in the other way around, 141 remember the prefix that is linked by a given point-to-point link. 143 For example, making a trace-route to debug any issue to a given 144 address in the provider network, will show a straight view, and there 145 will not be need to check a database that related an address pool for 146 the point-to-point links and the customer prefixes, as all they are 147 the same. 149 Moreover, it is possible to use the shorter prefix as the provider 150 side numbering for the point-to-point link and keep the /64 for the 151 customer side. In our example, it will become: 153 o Point-to-point link at provider side: 2001:db8:aaaa::1/48 154 o Point-to-point link at customer side: 2001:db8:aaaa::2/64 156 This provides one additional advantage as in some platforms the 157 configuration may be easier saving one step for the route of the 158 delegated prefix (no need for two routes to be configured, one for 159 the prefix, one for the point-to-point link). It is possible because 160 the longest-prefix-match rule. 162 The behavior of this type of configuration has been successfully 163 tested in different commonly available implementations with different 164 routing protocols, including RIP, BGP, IS-IS, OSPF, along static 165 routing, and has been used in several scenarios for a few months 166 without any failures having been reported. 168 5. Security Considerations 170 No security concerns seem to be related to this proposal. 172 6. IANA Considerations 174 This document does not have any specific IANA considerations. 176 7. Acknowledgements 178 The authors would like to acknowledge the inputs of ... 180 8. References 182 8.1. Normative References 184 [1] Hinden, R. and S. Deering, "IP Version 6 Addressing 185 Architecture", RFC 4291, February 2006. 187 8.2. Informative References 189 [2] Savola, P., "Use of /127 Prefix Length Between Routers 190 Considered Harmful", RFC 3627, September 2003. 192 [3] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", 193 draft-chown-v6ops-port-scanning-implications-02 (work in 194 progress), October 2005. 196 [4] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 197 Allocations to Sites", RFC 3177, September 2001. 199 Authors' Addresses 201 Jordi Palet Martinez 202 Consulintel 203 Molino de la Navata, 75 204 La Navata - Galapagar - Madrid 205 E-28420 - Spain 207 Phone: +34 91 151 81 99 208 Fax: +34 91 151 81 98 209 Email: jordi.palet@consulintel.es 211 Cesar Olvera Morales 212 Consulintel 213 Molino de la Navata, 75 214 La Navata - Galapagar - Madrid 215 E-28420 - Spain 217 Phone: +34 91 151 81 99 218 Fax: +34 91 151 81 98 219 Email: cesar.olvera@consulintel.es 221 Miguel Angel Diaz Fernandez 222 Consulintel 223 Molino de la Navata, 75 224 La Navata - Galapagar - Madrid 225 E-28420 - Spain 227 Phone: +34 91 151 81 99 228 Fax: +34 91 151 81 98 229 Email: miguelangel.diaz@consulintel.es 231 Intellectual Property Statement 233 The IETF takes no position regarding the validity or scope of any 234 Intellectual Property Rights or other rights that might be claimed to 235 pertain to the implementation or use of the technology described in 236 this document or the extent to which any license under such rights 237 might or might not be available; nor does it represent that it has 238 made any independent effort to identify any such rights. Information 239 on the procedures with respect to rights in RFC documents can be 240 found in BCP 78 and BCP 79. 242 Copies of IPR disclosures made to the IETF Secretariat and any 243 assurances of licenses to be made available, or the result of an 244 attempt made to obtain a general license or permission for the use of 245 such proprietary rights by implementers or users of this 246 specification can be obtained from the IETF on-line IPR repository at 247 http://www.ietf.org/ipr. 249 The IETF invites any interested party to bring to its attention any 250 copyrights, patents or patent applications, or other proprietary 251 rights that may cover technology that may be required to implement 252 this standard. Please address the information to the IETF at 253 ietf-ipr@ietf.org. 255 Disclaimer of Validity 257 This document and the information contained herein are provided on an 258 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 259 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 260 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 261 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 262 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 263 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 265 Copyright Statement 267 Copyright (C) The Internet Society (2006). This document is subject 268 to the rights, licenses and restrictions contained in BCP 78, and 269 except as set forth therein, the authors retain all their rights. 271 Acknowledgment 273 Funding for the RFC Editor function is currently provided by the 274 Internet Society.