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", . [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]