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