draft-ietf-6man-prefixlen-p2p-00.txt   draft-ietf-6man-prefixlen-p2p-01.txt 
6man M. Kohno 6man M. Kohno
Internet-Draft Juniper Networks, Keio University Internet-Draft Juniper Networks, Keio University
Intended status: Standards Track B. Nitzan Intended status: Standards Track B. Nitzan
Expires: April 19, 2011 Juniper Networks Expires: June 17, 2011 Juniper Networks
R. Bush R. Bush
Y. Matsuzaki Y. Matsuzaki
Internet Initiative Japan Internet Initiative Japan
L. Colitti L. Colitti
Google Google
T. Narten T. Narten
IBM Corporation IBM Corporation
October 16, 2010 December 14, 2010
Using 127-bit IPv6 Prefixes on Inter-Router Links Using 127-bit IPv6 Prefixes on Inter-Router Links
draft-ietf-6man-prefixlen-p2p-00.txt draft-ietf-6man-prefixlen-p2p-01.txt
Abstract Abstract
On inter-router point-to-point links, it is useful for security and On inter-router point-to-point links, it is useful for security and
other reasons, to use 127-bit IPv6 prefixes. Such a practice other reasons, to use 127-bit IPv6 prefixes. Such a practice
parallels the use of 31-bit prefixes in IPv4 [RFC3021]. This parallels the use of 31-bit prefixes in IPv4 [RFC3021]. This
document specifies motivation and usages of 127-bit IPv6 prefix document specifies motivation and usages of 127-bit IPv6 prefix
lengths on inter-router point-to-point links. lengths on inter-router point-to-point links.
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2011. This Internet-Draft will expire on June 17, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
3. Scope Of This Memo . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope Of This Memo . . . . . . . . . . . . . . . . . . . . . . 3
4. Problems identified with 127-bit prefix lengths in the past . . 4 4. Problems identified with 127-bit prefix lengths in the past . . 4
5. Reasons for using longer prefixes . . . . . . . . . . . . . . . 4 5. Reasons for using longer prefixes . . . . . . . . . . . . . . . 4
5.1. Ping-pong issue . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Ping-pong issue . . . . . . . . . . . . . . . . . . . . . . 4
5.2. Neighbor Cache Exhaustion issue . . . . . . . . . . . . . . 4 5.2. Neighbor Cache Exhaustion issue . . . . . . . . . . . . . . 4
5.3. Other reasons . . . . . . . . . . . . . . . . . . . . . . . 5 5.3. Other reasons . . . . . . . . . . . . . . . . . . . . . . . 5
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Conventions Used In This Document 1. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 3, line 43 skipping to change at page 3, line 43
This document is applicable to cases where operators assign specific This document is applicable to cases where operators assign specific
addresses on inter-router point-to-point links and do not rely on addresses on inter-router point-to-point links and do not rely on
link-local addresses. Many operators assign specific addresses for link-local addresses. Many operators assign specific addresses for
purposes of network monitoring, reverse DNS resolution for traceroute purposes of network monitoring, reverse DNS resolution for traceroute
and other management tools, EBGP peering sessions, and so on. and other management tools, EBGP peering sessions, and so on.
For the purposes of this document, an inter-router point-to-point For the purposes of this document, an inter-router point-to-point
link is a link to which only two routers and no hosts are attached. link is a link to which only two routers and no hosts are attached.
This may include Ethernet links which are configured to be point-to- This may include Ethernet links which are configured to be point-to-
point. In such cases, there is no need to support Neighbor Discovery point. Links between a router and a host, or links to which both
for address resolution, and other general scenarios like the use of routers and hosts are attached, are out of scope of this document.
stateless address autoconfiguration are not relevant.
Links between a router and a host, or links to which both routers and The recommendations in this document does not apply to link-local
hosts are attached, are out of scope of this document. address scope.
4. Problems identified with 127-bit prefix lengths in the past 4. Problems identified with 127-bit prefix lengths in the past
[RFC3627] discourages the use of 127-bit prefix lengths due to [RFC3627] discourages the use of 127-bit prefix lengths due to
conflicts with the Subnet-Router anycast addresses, while stating conflicts with the Subnet-Router anycast addresses, while stating
that the utility of Subnet-Router Anycast for point-to-point links is that the utility of Subnet-Router Anycast for point-to-point links is
questionable. questionable.
[RFC5375] also says the usage of 127-bit prefix lengths is not valid [RFC5375] also says the usage of 127-bit prefix lengths is not valid
and should be strongly discouraged, but the stated reason for doing and should be strongly discouraged, but the stated reason for doing
skipping to change at page 6, line 8 skipping to change at page 6, line 8
Though address space conservation considerations are less important Though address space conservation considerations are less important
for IPv6 than they are in IPv4, some operators prefer not to assign for IPv6 than they are in IPv4, some operators prefer not to assign
/64s to individual point-to-point links. Instead, they may be able /64s to individual point-to-point links. Instead, they may be able
to number all of their point-to-point links out of a single (or small to number all of their point-to-point links out of a single (or small
number of) /64s. number of) /64s.
6. Recommendations 6. Recommendations
Routers MUST support the assignment of /127 prefixes on point-to- Routers MUST support the assignment of /127 prefixes on point-to-
point inter-router links. point inter-router links. Routers MUST disable subnet-router anycast
for the prefix when /127 prefixes are used.
When assigning and using any /127 prefixes, the following When assigning and using any /127 prefixes, the following
considerations apply.Some addresses have special meanings, in considerations apply. Some addresses have special meanings, in
particular addresses corresponding to reserved anycast addresses. particular addresses corresponding to reserved anycast addresses.
When assigning prefixes (and addresses) to links, care should be When assigning prefixes (and addresses) to links, care should be
taken to ensure that addresses reserved for such purposes aren't taken to ensure that addresses reserved for such purposes aren't
inadvertently assigned and used as unicast addresses. Otherwise, inadvertently assigned and used as unicast addresses. Otherwise,
nodes may receive packets that they are not intended to receive. nodes may receive packets that they are not intended to receive.
Specifically, assuming that a number of point-to-point links will be Specifically, assuming that a number of point-to-point links will be
numbered out of a single /64 prefix: numbered out of a single /64 prefix:
a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be
assigned as unicast addresses, to avoid colliding with the Subnet- assigned as unicast addresses, to avoid colliding with the Subnet-
Router anycast address. [RFC4291] Router anycast address [RFC4291].
b) Addresses in which the rightmost 64 bits are assigned the b) Addresses in which the rightmost 64 bits are assigned the
highest 128 values SHOULD NOT be used as unicast addresses, to highest 128 values, (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff:
avoid colliding with Reserved Subnet Anycast Addresses. [RFC2526] ffff), SHOULD NOT be used as unicast addresses to avoid colliding
with Reserved Subnet Anycast Addresses [RFC2526].
7. Security Considerations 7. Security Considerations
Section 5.1 and 5.2 discuss about seurity related issues. This document does not have inherent security considerations. It
does discuss security related issues and proposes a solution to them.
8. IANA Considerations 8. IANA Considerations
None. None.
9. Contributors 9. Contributors
Chris Morrow, morrowc@google.com Chris Morrow, morrowc@google.com
Pekka Savola, pekkas@netcore.fi Pekka Savola, pekkas@netcore.fi
 End of changes. 12 change blocks. 
16 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/