6man M. Kohno
Internet-Draft Juniper Networks, Keio University
Updates: 3627,4291,5375 B. Nitzan
(if approved) Juniper Networks
Intended status: Standards Track R. Bush
Expires: January 30, 2011 Y. Matsuzaki
Internet Initiative Japan
L. Colitti
Google
July 29, 2010
Using 127-bit IPv6 Prefixes on Inter-Router Links
draft-kohno-ipv6-prefixlen-p2p-02.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 outlines some of these reasons and specifies that 127-bit
IPv6 prefix lengths must be supported on such links.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 January 30, 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
Kohno, et al. Expires January 30, 2011 [Page 1]
Internet-Draft IPv6 prefixlen p2p July 2010
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Conventions Used In This Document . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Kohno, et al. Expires January 30, 2011 [Page 2]
Internet-Draft IPv6 prefixlen p2p July 2010
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].
2. Introduction
RFC 4291 [RFC4291] specifies that interface IDs for all unicast
address, except those that start with the binary value 000, are
required to be 64 bits long and to be constructed in Modified EUI-64
format. In addition, it defines the Subnet-Router anycast address,
which is intended to be used for applications where a node needs to
communicate with any one of the set of routers on a link.
Some operators have been using 127-bit prefixes, but this has been
discouraged due to conflicts with Subnet-Router anycast [RFC3627].
However, using 64-bit prefixes creates security issues which are
particularly problematic on inter-router links, and there are other
valid reasons to use prefixes longer than 64 bits, in particular /127
(see Section 5).
This document provides rationale for using 127-bit prefix lengths,
reevaluates the reasons why doing so was considered harmful, and
specifies that /127 prefixes MUST be supported on inter-router links
configured for use as point-to-point links.
3. Scope Of This Memo
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 addresss autoconfiguration are not relevant.
Links between a router and a host, or links to which both routers and
hosts are attached, are out of scope of this document.
Kohno, et al. Expires January 30, 2011 [Page 3]
Internet-Draft IPv6 prefixlen p2p July 2010
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
this is to be in compliance with [RFC3627].
Though the analysis in the RFCs are correct, it contradicts the
reality as to the /127 discussion. Given that Subnet-Router Anycast
is not currently used, the RFCs could have been to recommend that
Subnet-Router Anycast be disabled on prefixes that are 127 bits long.
5. Reasons for using longer prefixes
There are various reasons for network operators to use IPv6 prefix
length greater than 64, particularly 127, for inter-router links.
5.1. Ping-pong issue
As described in [PINGPONG], a forwarding loop may occur on a point-
to-point link with a prefix length shorter than 127. This does not
affect interfaces that perform Neighbor Discovery, but some point-to-
point links, which uses medium such as SONET, do not use Neighbor
Discovery. As a consequence, configuring any prefix length shorter
than 127 bits on these links can create an attack vector in the
network.
The pingpong issue happens in case of IPv4 as well. But due to the
scarcity of IPv4 address space, the current practice is to assgin
long prefix lengths such as /30 or /31 [RFC3021] on point-to-point
links, thus the problem did not come to the fore.
The latest ICMPv6 specification [RFC4443] provides a solution to this
issue by specifying that a router receiving a packet on a point-to-
point link sent to an address on the link itself must not forward the
packet back onto the same link, instead generating an ICMPv6
Destination Unreachable (Code 3) message. However, checking every
packets for this condition could have some drawbacks.
5.2. Neighbor Cache Exhaustion issue
As described in Section 4.3.2 of [RFC3756], the use of a 64-bit
prefix length on an inter-router link that uses Neighbor Discovery
Kohno, et al. Expires January 30, 2011 [Page 4]
Internet-Draft IPv6 prefixlen p2p July 2010
(e.g., Ethernet) potentially allows for denial-of-service attacks on
the routers on the link.
Consider an Ethernet link between two routers A and B to which a /64
subnet has been assigned. A packet sent to any address on the /64
(except the addresses of A and B) will cause the router attempting to
forward it to create an new cache entry in state INCOMPLETE, send a
Neighbor Solicitation message to be sent on the link, start a
retransmit timer, and so on [RFC4861].
By sending a continuous stream of packets to a large number of the
2^64 - 3 addresses on the link that are not assigned to the routers
(one for each router and one for Subnet-Router Anycast), an attacker
can cause the routers to create a large number of neighbor cache
entries and send a large number of Neighbor Solicitation packets
which will never receive replies, possibly consuming a
disproportionate amount of memory and processing resources. Sending
the packets to one of the 2^24 addresses on the link that have the
same Solicited-Node multicast address as of one of the routers also
causes the other router to spend disproportionate amounts of
processing time discarding useless Neighbor Solicitation messages.
Careful implementation and rate-limiting can limit the impact of such
an attack, but are unlikely to neutralize it completely. Rate-
limiting neighbor solicitation messages will reduce CPU usage, and
following the garbage-collection recommendations in [RFC4861] will
maintain reachability, but if the link is down and neighbor cache
entries have expired while the attack is ongoing, legitimate traffic
(for example, BGP sessions) over the link might never be re-
established because the routers cannot resolve each others' IPv6
addresses to MAC addresses.
This attack is not specific to point-to-point links, but is
particularly harmful in the case of point-to-point backbone links,
which may carry large amounts of traffic to many destinations over
long distances.
5.3. Other reasons
Though address space conservation considerations are less important
for IPv6 than they are in IPv4, it may still be desirable to use the
smallest possible prefix to number links (and thus use, for example,
/127 for point-to-point links). For example, a large end-site that
is assigned a /48 of IPv6 space may not want to reserve a full /64
for every point-to-point link to avoid renumbering in the future.
Kohno, et al. Expires January 30, 2011 [Page 5]
Internet-Draft IPv6 prefixlen p2p July 2010
6. Recommendations
In light of the above reasons, this document specifies that 127-
bit prefix lengths MUST be supported on inter-router point-to-
point links, and proposes that such links MAY be assigned 127-bit
prefix lengths. If such a prefix is assigned to a link, Subnet-
Router Anycast MUST be disabled for the prefix.
The [RFC4291]is to be revised to allow longer prefix than /64, and
state that Subnet-router anycast address MUST be disabled if the
prefix length of the link is /127.
7. Security Considerations
This draft addresses, among other things, various security issues.
8. IANA Considerations
None.
9. Contributors
Chris Morrow, morrowc@google.com
Pekka Savola, pekkas@netcore.fi
Remi Despres, remi.despres@free.fr
Thomas Narten, narten@us.ibm.com
10. Acknowledgments
We'd like to thank Ron Bonica, Pramod Srinivasan, Olivier Vautrin,
Tomoya Yoshida, Warren Kumari and Tatsuya Jinmei for their helpful
inputs.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Kohno, et al. Expires January 30, 2011 [Page 6]
Internet-Draft IPv6 prefixlen p2p July 2010
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
11.2. Informative References
[PINGPONG]
Hagino, H. and T. Jimmei, "Avoiding ping-pong packets on
point-to-point links", <http://tools.ietf.org/html/
draft-ietf-ipngwg-p2p-pingpong-00>.
[RFC3021] Retana, A., "Using 31-Bit Prefixes on IPv4 Point-to-Point
Links", RFC 3021, December 2000.
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers
Considered Harmful", RFC 3627, September 2003.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
and C. Hahn, "IPv6 Unicast Address Assignment
Considerations", RFC 5375, December 2008.
Authors' Addresses
Miya Kohno
Juniper Networks, Keio University
Shinjuku Park Tower, 3-7-1 Nishishinjuku
Shinjuku-ku, Tokyo 163-1035
Japan
Email: mkohno@juniper.net
Kohno, et al. Expires January 30, 2011 [Page 7]
Internet-Draft IPv6 prefixlen p2p July 2010
Becca Nitzan
Juniper Networks
1194 North Marhilda Avenue
Sunnyvale, CA 94089
USA
Email: nitzan@juniper.net
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, WA 98110
USA
Email: randy@psg.com
Yoshinobu Matsuzaki
Internet Initiative Japan
Jinbocho Mitsui Building,
1-105 Kanda Jinbo-cho, Tokyo 101-0051
Japan
Email: maz@iij.ad.jp
Lorenzo Colitti
Google
1600 Amphitheatre Parkway,
Mountain View, CA 94043
USA
Email: lorenzo@google.com
Kohno, et al. Expires January 30, 2011 [Page 8]