v6ops M. Kohno
Internet-Draft Juniper Networks, Keio University
Intended status: Informational B. Nitzan
Expires: April 22, 2010 Juniper Networks
R. Bush
Y. Matsuzaki
Internet Initiative Japan
October 19, 2009
Use of /127 IPv6 Prefix Length on P2P Links Not Considered Harmful
draft-kohno-ipv6-prefixlen-p2p-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 April 22, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Kohno, et al. Expires April 22, 2010 [Page 1]
Internet-Draft IPv6 prefixlen p2p October 2009
Abstract
This document reconsiders the reasons why the use of /127 was
regarded as harmful and reevaluates some rationales for using it for
IPv6 point-to-point links.
This document adheres fundamentally to RFC 3627 [RFC3627]. The main
difference is that the use of /127 IPv6 prefix length is no longer
considered as harmful.
Table of Contents
1. Conventions Used In This Document . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope Of This Memo . . . . . . . . . . . . . . . . . . . . . . 3
4. Reconsidering the problems with /127 . . . . . . . . . . . . . 3
5. Rationale for using /127 . . . . . . . . . . . . . . . . . . . 4
6. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Kohno, et al. Expires April 22, 2010 [Page 2]
Internet-Draft IPv6 prefixlen p2p October 2009
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
Although the use of /127 prefix length on IPv6 point-to-point links
has been viewed as harmful [RFC3627], experience has shown this to
not be the case, because Subnet-Router anycast address has not been
used in practice. This document reevaluates the reasons why this was
considered harmful and provides some rationales for using /127 (and
other long prefixes e.g. /112-/126).
3. Scope Of This Memo
This document is applicable to cases where operators assign specific
addresses on point-to-point links and do not rely on link-local
addresses. Most operators assign specific addresses for purposes of
management, reverse DNS resolution of traceroutes, network monitoring
infrastructure, and so on.
4. Reconsidering the problems with /127
RFC 4291 [RFC4291] says all unicast address Interface IDs, (except
those that start with the binary value 000), are required to be 64
bits long and to be constructed with a Modified EUI-64 format. In
addition, it defines 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.
As RFC3627 [RFC3627] has already pointed out, the usability of a
Subnet-Router anycast address between two routers on a point-to-point
link is questionable. Moreover, there are security concerns in
mandating their use. RFC 2526 [RFC2526] contains the following:
"The use of any type of reserved anycast addresses poses a security
concern only in allowing potential attackers a well-known address to
attack. By designating certain services to be located at specific
reserved anycast addresses, an attacker may more profitably focus an
attack against such a specific service."
RFC3627 [RFC3627] indicated that the use of /127 was harmful based on
the condition that Subnet-Router anycast address was a mandatory
Kohno, et al. Expires April 22, 2010 [Page 3]
Internet-Draft IPv6 prefixlen p2p October 2009
requirement. It brought up a conflict between the /127 masks and the
existence of Subnet-Router anycast addresses. However, Subnet-router
anycast address has not been implemented and in practice, this has
not been a problem.
Therefore, while there could be merit in the uniform treatment for
any link type (whether the link is point-to-point or broadcast/
multicast media), if it is important to treat particular link types
differently, operators should be free to make this determination as
assign suitable prefix length including /127.
5. Rationale for using /127
There are some benefits for network operators to use /127 prefix
length for IPv6 point-to-point links.
Points which are specific to /127.
As described in [PINGPONG], a forwarding loop may occur when the
link-type is point-to-point and the prefix length is shorter than
/127, while this does not affect interfaces that perform Neighbor
Discovery. In consequence, configuring a shorter than /127 prefix
would create an attack vector in the network unless otherwise
mitigated.
The latest ICMPv6 specification [RFC4443] included a solution to
this matter, but a few issues still remain :
1) A rule described in ICMPv6 [RFC4443] indicates that a
Destination Unreachable (Code 3) message should be sent by a
router rather than forwarding packets back onto point-to-point
links from which they were received if their destination
address belongs to the link itself. Checking all traffic for
this condition is likely to affect performance.
2) There could be a case that a packet needs to be sent back
onto point-to-point links from which they were received. For
example, LER (Label Edge Router) could just forward the packet
solely based on its label without IP resolution. In this case,
if the destination was the LER's egress interface, then the
downstream router would do an IP lookup and sent back to the
interface.
Kohno, et al. Expires April 22, 2010 [Page 4]
Internet-Draft IPv6 prefixlen p2p October 2009
So the use of /127 prefix length on point-to-point links (along
with disabled Subnet-Router anycast) is a simpler and more
practical option to avoid this matter.
Points which are not necessarily specific to /127.
- With the use of /127 or even other long prefix, the interface
IDs are simpler and easier to remember (e.g., the Interface ID is
1 or 0).
- Though address space conservation doesn't carry much weight
today in the case of IPv6, it may be desirable to use the minimum
amount needed.
- The current recommendation of /64 leaves a broad unused address
space. Considering that the IPv4 "Darknet" is drawing
considerable malware traffic [RFC4948], it is safer to narrow down
the unused space.
6. Appendix
Neighbor Discovery [RFC4861] and SLAAC [RFC4862] can be a point of
vulnerability as mentioned in [RFC3756]. So it MAY be safer to
disable them as well, when they are not required. But this is beyond
the scope of this document.
7. Security Considerations
This draft addresses, among other things, a security issue.
8. IANA Considerations
None.
9. Contributors
Chris Morrow, morrowc@google.com
Pekka Savola, pekkas@netcore.fi
10. Acknowledgments
We'd like to thank Ron Bonica, Pramod Srinivasan, Olivier Vautrin,
Kohno, et al. Expires April 22, 2010 [Page 5]
Internet-Draft IPv6 prefixlen p2p October 2009
Tomoya Yoshida and Warren Kumari 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.
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999.
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers
Considered Harmful", RFC 3627, September 2003.
[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.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, 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>.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the
IAB workshop on Unwanted Traffic March 9-10, 2006",
RFC 4948, August 2007.
Kohno, et al. Expires April 22, 2010 [Page 6]
Internet-Draft IPv6 prefixlen p2p October 2009
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
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
Kohno, et al. Expires April 22, 2010 [Page 7]