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]