Internet Engineering Task Force J. Palet Internet-Draft C. Olvera Expires: August 31, 2006 M. Diaz Consulintel February 27, 2006 Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans draft-palet-v6ops-point2point-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document analyzes the rational for using /64 for numbering IPv6 point-to-point links and provides some guidelines to simplify the addressing plans. Palet, et al. Expires August 31, 2006 [Page 1] Internet-Draft IPv6 Point-to-Point Links February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rational for using /64 . . . . . . . . . . . . . . . . . . . . 3 3. Numbering Interfaces . . . . . . . . . . . . . . . . . . . . . 3 4. Routing Aggregation of the Point-to-Point Links . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Palet, et al. Expires August 31, 2006 [Page 2] Internet-Draft IPv6 Point-to-Point Links February 2006 1. Introduction There are different alternatives for numbering IPv6 point-to-point links, and from an operational perspective, they may have different advantages or disadvantages that need to be taken in consideration under the scope of each specific network architecture design. However, as a general rule, this document suggest the approach of using /64 in order to ensure not only compliance with standards, and consequently facilitate interoperability, but also in order to ensure avoiding possible future issues and simplifying the addressing plans. The use of /64 also facilitates an easier way for routing the shorter aggregated prefix into the point-to-point link. Consequently it simplifies the "view" of a more unified addressing plan, providing an easier path for following up any issue when operating IPv6 networks. 2. Rational for using /64 The IPv6 Addressing Architecture [1] specifies that all the Interface Identifiers for all the unicast addresses (except for 000/3) are required to be 64 bits long and to be constructed in Modified EUI-64 format. As a consequence it is forbidden to use prefixes longer than /64. The same document also mandates the usage of the predefined subnet- router anycast address, which has cleared to zero all the bits that do not form the subnet prefix. Moreover, [2] describes de problems of using /127 especially on point-to-point links between routers. This document also describes different choices for the point-to-point links and actually, without advocating for any specific prefix length, shows that /64 is the best solution from different perspectives, including operational practicality. Consequently, we shall conclude that /64 should be used for numbering point-to-point links. 3. Numbering Interfaces Often, in point-to-point links, hardware tokens are not available, so frequently they are manually numbered sequentially with most of the bits cleared to zero. This also match the need to keep certain bits (u, g) cleared. This numbering makes as well easier to remember the interfaces, which typically will become numbered as 1 (with 63 Palet, et al. Expires August 31, 2006 [Page 3] Internet-Draft IPv6 Point-to-Point Links February 2006 leading zero bits) for the provider side and 2 (with 63 leading zero bits) for the customer side. On the other hand, using the EUI-64, makes it more difficult to remember and handle the interfaces, but provides an additional degree of protection against port (actually address) scanning as described at [3]. 4. Routing Aggregation of the Point-to-Point Links Following this approach and assuming that a shorter prefix is typically delegated to a customer, in general a /48 [4], it is possible to simplify the routing aggregation of the point-to-point links. Towards this, the point-to-point link may be numbered using the first /64 of a given /48. Let's see a practical example: o A service provider uses the prefix 2001:db8::/32 and is using 2001:db8:aaaa::/48 for a given customer. o Instead of allocating the point-to-point link from a different addressing pool, it may use 2001:db8:aaaa::/64 (which is the first /64 subnet from the 2001:db8:aaaa::/48) to number the link. o This means that, in the case the non-EUI-64 approach is used, the point-to-point link will be numbered as 2001:db8:aaaa::1/64 for the provider side and 2001:db8:aaaa::2/64 for the customer side. In this way, as the same address pool is being used for both the prefix and the point-to-point link, one of the advantages of this approach is to make very easy remembering the point-to-point links that belong to a given customer prefix, or in the other way around, remember the prefix that is linked by a given point-to-point link. For example, making a trace-route to debug any issue to a given address in the provider network, will show a straight view, and there will not be need to check a database that related an address pool for the point-to-point links and the customer prefixes, as all they are the same. Moreover, it is possible to use the shorter prefix as the provider side numbering for the point-to-point link and keep the /64 for the customer side. In our example, it will become: o Point-to-point link at provider side: 2001:db8:aaaa::1/48 Palet, et al. Expires August 31, 2006 [Page 4] Internet-Draft IPv6 Point-to-Point Links February 2006 o Point-to-point link at customer side: 2001:db8:aaaa::2/64 This provides one additional advantage as in some platforms the configuration may be easier saving one step for the route of the delegated prefix (no need for two routes to be configured, one for the prefix, one for the point-to-point link). It is possible because the longest-prefix-match rule. The behavior of this type of configuration has been successfully tested in different commonly available implementations with different routing protocols, including RIP, BGP, IS-IS, OSPF, along static routing, and has been used in several scenarios for a few months without any failures having been reported. 5. Security Considerations No security concerns seem to be related to this proposal. 6. IANA Considerations This document does not have any specific IANA considerations. 7. Acknowledgements The authors would like to acknowledge the inputs of ... 8. References 8.1. Normative References [1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 8.2. Informative References [2] Savola, P., "Use of /127 Prefix Length Between Routers Considered Harmful", RFC 3627, September 2003. [3] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", draft-chown-v6ops-port-scanning-implications-02 (work in progress), October 2005. [4] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. Palet, et al. Expires August 31, 2006 [Page 5] Internet-Draft IPv6 Point-to-Point Links February 2006 Authors' Addresses Jordi Palet Martinez Consulintel Molino de la Navata, 75 La Navata - Galapagar - Madrid E-28420 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 Email: jordi.palet@consulintel.es Cesar Olvera Morales Consulintel Molino de la Navata, 75 La Navata - Galapagar - Madrid E-28420 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 Email: cesar.olvera@consulintel.es Miguel Angel Diaz Fernandez Consulintel Molino de la Navata, 75 La Navata - Galapagar - Madrid E-28420 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 Email: miguelangel.diaz@consulintel.es Palet, et al. Expires August 31, 2006 [Page 6] Internet-Draft IPv6 Point-to-Point Links February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Palet, et al. Expires August 31, 2006 [Page 7]