idnits 2.17.1 draft-kohno-ipv6-prefixlen-p2p-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3627, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5375, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4291, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4291, updated by this document, for RFC5378 checks: 2003-10-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2010) is 5169 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3627 (Obsoleted by RFC 6547) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6man M. Kohno 3 Internet-Draft Juniper Networks, Keio University 4 Obsoletes: 3627 (if approved) B. Nitzan 5 Updates: 4291,5375 Juniper Networks 6 (if approved) R. Bush 7 Intended status: Standards Track Y. Matsuzaki 8 Expires: September 4, 2010 Internet Initiative Japan 9 L. Colitti 10 Google 11 March 3, 2010 13 Using 127-bit IPv6 Prefixes on Inter-Router Links 14 draft-kohno-ipv6-prefixlen-p2p-01.txt 16 Abstract 18 In many environments it is useful, for security and other reasons, to 19 use 127-bit IPv6 prefixes on inter-router links. This document 20 outlines some of these reasons and proposes that 127-bit IPv6 prefix 21 lengths be allowed on these links. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 4, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Conventions Used In This Document . . . . . . . . . . . . . . . 3 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Scope Of This Memo . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Problems identified with 127-bit prefix lengths in the past . . 3 67 5. Reasons for using longer prefixes . . . . . . . . . . . . . . . 4 68 5.1. Ping-pong issue . . . . . . . . . . . . . . . . . . . . . . 4 69 5.2. Neighbor Cache Exhaustion issue . . . . . . . . . . . . . . 4 70 5.3. Other reasons . . . . . . . . . . . . . . . . . . . . . . . 5 71 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 6 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 74 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 11.1. Normative References . . . . . . . . . . . . . . . . . . . 6 78 11.2. Informative References . . . . . . . . . . . . . . . . . . 7 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Conventions Used In This Document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 2. Introduction 89 RFC 4291 [RFC4291] specifies that interface IDs for all unicast 90 address, except those that start with the binary value 000, are 91 required to be 64 bits long and to be constructed in Modified EUI-64 92 format. In addition, it defines the Subnet-Router anycast address, 93 which is intended to be used for applications where a node needs to 94 communicate with any one of the set of routers on a link. 96 Some operators have been using 127-bit prefixes, but this has been 97 discouraged due to conflicts with Subnet-Router anycast [RFC3627]. 98 However, using 64-bit prefixes creates security issues which are 99 particularly problematic on inter-router links, and there are other 100 valid reasons to use prefixes longer than 64 bits, in particular /127 101 (see Section 5). 103 This document provides rationale for using 127-bit prefix lengths, 104 reevaluates the reasons why doing so was considered harmful, and 105 proposes that /127 prefixes may be used on inter-router links if 106 certain conditions are met. 108 3. Scope Of This Memo 110 This document is applicable to cases where operators assign specific 111 addresses on inter-router links and do not rely on link-local 112 addresses. Many operators assign specific addresses for purposes of 113 network monitoring, reverse DNS resolution for traceroute and other 114 management tools, EBGP peering sessions, and so on. 116 For the purposes of this document, an inter-router link is a link to 117 which only routers and no hosts are attached. Thus, links between a 118 router and a host, or links to which both routers and hosts are 119 attached, are out of scope of this document. 121 4. Problems identified with 127-bit prefix lengths in the past 123 [RFC3627] discourages the use of 127-bit prefix lengths due to 124 conflicts with the Subnet-Router anycast addresses. However, the RFC 125 also states that the utility of Subnet-Router Anycast for point-to- 126 point links is questionable. 128 [RFC5375] also says the usage of 127-bit prefix lengths is not valid 129 and should be strongly discouraged, but the stated reason for doing 130 this is to be in compliance with [RFC3627]. 132 Given that Subnet-Router Anycast is not currently widely implemented, 133 an alternative solution to this problem could have been to recommend 134 that Subnet-Router Anycast be disabled on prefixes that are 127 bits 135 long. 137 5. Reasons for using longer prefixes 139 There are various reasons for network operators to use IPv6 prefix 140 length greater than 64, particularly 127, for inter-router links. 142 5.1. Ping-pong issue 144 As described in [PINGPONG], a forwarding loop may occur on a point- 145 to-point link with a prefix length shorter than 127. This does not 146 affect interfaces that perform Neighbor Discovery, but some point-to- 147 point links, such as SONET, do not use Neighbor Discovery. As a 148 consequence, configuring any prefix length other than 127 bits on 149 these links creates an attack vector in the network. 151 The latest ICMPv6 specification [RFC4443] provides a solution to this 152 issue by specifying that a router receiving a packet on a point-to- 153 point link sent to an address on the link itself must not forward the 154 packet back onto the same link, instead generating an ICMPv6 155 Destination Unreachable (Code 3) message. However, checking all 156 traffic for this condition is likely to affect performance, as it 157 doubles the number of routing lookups required to forward every 158 packet. 160 5.2. Neighbor Cache Exhaustion issue 162 As described in Section 4.3.2 of [RFC3756], the use of a 64-bit 163 prefix length on an inter-router link that uses Neighbor Discovery 164 (e.g., Ethernet) potentially allows for denial-of-service attacks on 165 the routers on the link. 167 Consider an Ethernet link between two routers A and B to which a /64 168 subnet has been assigned. A packet sent to any address on the /64 169 (except the addresses of A and B) will cause the router attempting to 170 forward it to create an new cache entry in state INCOMPLETE, send a 171 Neighbor Solicitation message to be sent on the link, start a 172 retransmit timer, and so on [RFC4861]. 174 By sending a continuous stream of packets to a large number of the 175 2^64 - 3 addresses on the link that are not assigned to the routers 176 (one for each router and one for Subnet-Router Anycast), an attacker 177 can cause the routers to create a large number of neighbor cache 178 entries and send a large number of Neighbor Solicitation packets 179 which will never receive replies, possibly consuming a 180 disproportionate amount of memory and processing resources. Sending 181 the packets to one of the 2^24 addresses on the link that have the 182 same Solicited-Node multicast address as of one of the routers also 183 causes the other router to spend disproportionate amounts of 184 processing time discarding useless Neighbor Solicitation messages. 186 Careful implementation and rate-limiting can limit the impact of such 187 an attack, but are unlikely to neutralize it completely. Rate- 188 limiting neighbor solicitation messages will reduce CPU usage, and 189 following the garbage-collection recommendations in [RFC4861] will 190 maintain reachability, but if the link is down and neighbor cache 191 entries have expired while the attack is ongoing, legitimate traffic 192 (for example, BGP sessions) over the link might never be re- 193 established because the routers cannot resolve each others' IPv6 194 addresses to MAC addresses. 196 This attack is not specific to point-to-point links, but is 197 particularly harmful in the case of point-to-point backbone links, 198 which may carry large amounts of traffic to many destinations over 199 long distances. 201 5.3. Other reasons 203 1. With the use of 127-bit or other long prefix lengths, interface 204 IDs are simpler and easier to remember (e.g., the Interface ID is 205 0 or 1). 207 2. Using 64-bit prefixes for inter-router links leaves a large 208 number of unused addresses that an attacker with physical access 209 to a link could use to insert a node onto the link without having 210 to compromise the routing protocols used on the link. If 127-bit 211 prefix lengths are in use, this is not possible. 213 3. Though address space conservation considerations are less 214 important for IPv6 than they are in IPv4, it may still be 215 desirable to use the smallest possible prefix to number links 216 (and thus use, for example, /127 for point-to-point links). For 217 example, a large end-site that is assigned a /48 of IPv6 space 218 may not want to reserve a full /64 for every point-to-point link 219 to avoid renumbering in the future. 221 6. Recommendations 223 In light of the above reasons, this document proposes that inter- 224 router links MAY be assigned 127-bit prefix lengths. If such a 225 prefix is assigned to a link, Subnet-Router Anycast MUST be disabled 226 for the prefix. 228 7. Security Considerations 230 This draft addresses, among other things, various security issues. 232 8. IANA Considerations 234 None. 236 9. Contributors 238 Chris Morrow, morrowc@google.com 240 Pekka Savola, pekkas@netcore.fi 242 Remi Despres, remi.despres@free.fr 244 10. Acknowledgments 246 We'd like to thank Ron Bonica, Pramod Srinivasan, Olivier Vautrin, 247 Tomoya Yoshida and Warren Kumari for their helpful inputs. 249 11. References 251 11.1. Normative References 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 257 Architecture", RFC 4291, February 2006. 259 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 260 Message Protocol (ICMPv6) for the Internet Protocol 261 Version 6 (IPv6) Specification", RFC 4443, March 2006. 263 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 264 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 265 September 2007. 267 11.2. Informative References 269 [PINGPONG] 270 Hagino, H. and T. Jimmei, "Avoiding ping-pong packets on 271 point-to-point links", . 274 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 275 Considered Harmful", RFC 3627, September 2003. 277 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 278 Discovery (ND) Trust Models and Threats", RFC 3756, 279 May 2004. 281 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 282 and C. Hahn, "IPv6 Unicast Address Assignment 283 Considerations", RFC 5375, December 2008. 285 Authors' Addresses 287 Miya Kohno 288 Juniper Networks, Keio University 289 Shinjuku Park Tower, 3-7-1 Nishishinjuku 290 Shinjuku-ku, Tokyo 163-1035 291 Japan 293 Email: mkohno@juniper.net 295 Becca Nitzan 296 Juniper Networks 297 1194 North Marhilda Avenue 298 Sunnyvale, CA 94089 299 USA 301 Email: nitzan@juniper.net 302 Randy Bush 303 Internet Initiative Japan 304 5147 Crystal Springs 305 Bainbridge Island, WA 98110 306 USA 308 Email: randy@psg.com 310 Yoshinobu Matsuzaki 311 Internet Initiative Japan 312 Jinbocho Mitsui Building, 313 1-105 Kanda Jinbo-cho, Tokyo 101-0051 314 Japan 316 Email: maz@iij.ad.jp 318 Lorenzo Colitti 319 Google 320 1600 Amphitheatre Parkway, 321 Mountain View, CA 94043 322 USA 324 Email: lorenzo@google.com