idnits 2.17.1 draft-kohno-ipv6-prefixlen-p2p-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 abstract seems to contain references ([RFC3021]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 8, 2010) is 4948 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man M. Kohno 3 Internet-Draft Juniper Networks, Keio University 4 Intended status: Standards Track B. Nitzan 5 Expires: April 11, 2011 Juniper Networks 6 R. Bush 7 Y. Matsuzaki 8 Internet Initiative Japan 9 L. Colitti 10 Google 11 T. Narten 12 IBM Corporation 13 October 8, 2010 15 Using 127-bit IPv6 Prefixes on Inter-Router Links 16 draft-kohno-ipv6-prefixlen-p2p-03.txt 18 Abstract 20 On inter-router point-to-point links, it is useful for security and 21 other reasons, to use 127-bit IPv6 prefixes. Such a practice 22 parallels the use of 31-bit prefixes in IPv4 [RFC3021]. This 23 document specifies motivation and usages of 127-bit IPv6 prefix 24 lengths on inter-router point-to-point links. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 11, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Conventions Used In This Document . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Scope Of This Memo . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Problems identified with 127-bit prefix lengths in the past . . 4 64 5. Reasons for using longer prefixes . . . . . . . . . . . . . . . 4 65 5.1. Ping-pong issue . . . . . . . . . . . . . . . . . . . . . . 4 66 5.2. Neighbor Cache Exhaustion issue . . . . . . . . . . . . . . 4 67 5.3. Other reasons . . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 71 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Conventions Used In This Document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 2. Introduction 86 [RFC4291] specifies that interface IDs for all unicast address, 87 except those that start with the binary value 000, are required to be 88 64 bits long and to be constructed in Modified EUI-64 format. In 89 addition, it defines the Subnet-Router anycast address, which is 90 intended to be used for applications where a node needs to 91 communicate with any one of the set of routers on a link. 93 Some operators have been using 127-bit prefixes, but this has been 94 discouraged due to conflicts with Subnet-Router anycast [RFC3627]. 95 However, using 64-bit prefixes creates security issues which are 96 particularly problematic on inter-router links, and there are other 97 valid reasons to use prefixes longer than 64 bits, in particular /127 98 (see Section 5). 100 This document provides rationale for using 127-bit prefix lengths, 101 reevaluates the reasons why doing so was considered harmful, and 102 specifies how /127 prefixes can be used on inter-router links 103 configured for use as point-to-point links. 105 3. Scope Of This Memo 107 This document is applicable to cases where operators assign specific 108 addresses on inter-router point-to-point links and do not rely on 109 link-local addresses. Many operators assign specific addresses for 110 purposes of network monitoring, reverse DNS resolution for traceroute 111 and other management tools, EBGP peering sessions, and so on. 113 For the purposes of this document, an inter-router point-to-point 114 link is a link to which only two routers and no hosts are attached. 115 This may include Ethernet links which are configured to be point-to- 116 point. In such cases, there is no need to support Neighbor Discovery 117 for address resolution, and other general scenarios like the use of 118 stateless address autoconfiguration are not relevant. 120 Links between a router and a host, or links to which both routers and 121 hosts are attached, are out of scope of this document. 123 4. Problems identified with 127-bit prefix lengths in the past 125 [RFC3627] discourages the use of 127-bit prefix lengths due to 126 conflicts with the Subnet-Router anycast addresses, while stating 127 that the utility of Subnet-Router Anycast for point-to-point links is 128 questionable. 130 [RFC5375] also says the usage of 127-bit prefix lengths is not valid 131 and should be strongly discouraged, but the stated reason for doing 132 this is to be in compliance with [RFC3627]. 134 Though the analyses in the RFCs are correct, operational experience 135 with IPv6 has shown that /127 prefixes can be used successfully. 137 5. Reasons for using longer prefixes 139 There are reasons network operators use IPv6 prefix lengths greater 140 than 64, particularly 127, for inter-router point-to-point links. 142 5.1. Ping-pong issue 144 A forwarding loop may occur on a point-to-point link with a prefix 145 length shorter than 127. This does not affect interfaces that 146 perform Neighbor Discovery, but some point-to-point links, which uses 147 medium such as SONET, do not use Neighbor Discovery. As a 148 consequence, configuring any prefix length shorter than 127 bits on 149 these links can create an attack vector in the network. 151 The pingpong issue happens in case of IPv4 as well. But due to the 152 scarcity of IPv4 address space, the current practice is to assign 153 long prefix lengths such as /30 or /31 [RFC3021] on point-to-point 154 links, thus the problem did not come to the fore. 156 The latest ICMPv6 specification [RFC4443] mitigates this problem by 157 specifying that a router receiving a packet on a point-to-point link, 158 which is destined to an address within a subnet assigned to that same 159 link (other than one of the receiving router's own addresses), MUST 160 NOT forward the packet back on that link. Instead, it SHOULD 161 generate an ICMPv6 Destination Unreachable message code 3 in 162 response. This check is on the forwarding processing path, so it may 163 have performance impact. 165 5.2. Neighbor Cache Exhaustion issue 167 As described in Section 4.3.2 of [RFC3756], the use of a 64-bit 168 prefix length on an inter-router link that uses Neighbor Discovery 169 (e.g., Ethernet) potentially allows for denial-of-service attacks on 170 the routers on the link. 172 Consider an Ethernet link between two routers A and B to which a /64 173 subnet has been assigned. A packet sent to any address on the /64 174 (except the addresses of A and B) will cause the router attempting to 175 forward it to create an new cache entry in state INCOMPLETE, send a 176 Neighbor Solicitation message to be sent on the link, start a 177 retransmit timer, and so on [RFC4861]. 179 By sending a continuous stream of packets to a large number of the 180 2^64 - 3 unassigned addresses on the link (one for each router and 181 one for Subnet-Router Anycast), an attacker can create a large number 182 of neighbor cache entries and send a large number of Neighbor 183 Solicitation packets which will never receive replies, thereby 184 consuming large amounts of memory and processing resources. Sending 185 the packets to one of the 2^24 addresses on the link which has the 186 same Solicited-Node multicast address as one of the routers also 187 causes the victim to spend large amounts of processing time 188 discarding useless Neighbor Solicitation messages. 190 Careful implementation and rate-limiting can limit the impact of such 191 an attack, but are unlikely to neutralize it completely. Rate- 192 limiting neighbor solicitation messages will reduce CPU usage, and 193 following the garbage-collection recommendations in [RFC4861] will 194 maintain reachability, but if the link is down and neighbor cache 195 entries have expired while the attack is ongoing, legitimate traffic 196 (for example, BGP sessions) over the link might never be re- 197 established because the routers cannot resolve each others' IPv6 198 addresses to MAC addresses. 200 This attack is not specific to point-to-point links, but is 201 particularly harmful in the case of point-to-point backbone links, 202 which may carry large amounts of traffic to many destinations over 203 long distances. 205 While there are a number of ways to mitigate this kind of issue, 206 assigning /127 subnets eliminates it completely. 208 5.3. Other reasons 210 Though address space conservation considerations are less important 211 for IPv6 than they are in IPv4, some operators prefer not to assign 212 /64s to individual point-to-point links. Instead, they may be able 213 to number all of their point-to-point links out of a single (or small 214 number of) /64s. 216 6. Recommendations 218 Routers MUST support the assignment of /127 prefixes on point-to- 219 point inter-router links. 221 When assigning and using any /127 prefixes, the following 222 considerations apply.Some addresses have special meanings, in 223 particular addresses corresponding to reserved anycast addresses. 224 When assigning prefixes (and addresses) to links, care should be 225 taken to ensure that addresses reserved for such purposes aren't 226 inadvertently assigned and used as unicast addresses. Otherwise, 227 nodes may receive packets that they are not intended to receive. 228 Specifically, assuming that a number of point-to-point links will be 229 numbered out of a single /64 prefix: 231 a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be 232 assigned as unicast addresses, to avoid colliding with the Subnet- 233 Router anycast address. [RFC4291] 235 b) Addresses in which the rightmost 64 bits are assigned the 236 highest 128 values SHOULD NOT be used as unicast addresses, to 237 avoid colliding with Reserved Subnet Anycast Addresses. [RFC2526] 239 7. Security Considerations 241 Section 5.1 and 5.2 discuss about seurity related issues. 243 8. IANA Considerations 245 None. 247 9. Contributors 249 Chris Morrow, morrowc@google.com 251 Pekka Savola, pekkas@netcore.fi 253 Remi Despres, remi.despres@free.fr 255 Seiichi Kawamura, karamucho@mesh.ad.jp 257 10. Acknowledgments 259 We'd like to thank Ron Bonica, Pramod Srinivasan, Olivier Vautrin, 260 Tomoya Yoshida, Warren Kumari and Tatsuya Jinmei for their helpful 261 inputs. 263 11. References 265 11.1. Normative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 271 Architecture", RFC 4291, February 2006. 273 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 274 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 275 September 2007. 277 11.2. Informative References 279 [RFC2526] Johnson, J. and S. Deering, "Reserved IPv6 Subnet Anycast 280 Addresses", RFC 2526, March 1999. 282 [RFC3021] Retana, A., White, R., and V. Fuller, "Using 31-Bit 283 Prefixes on IPv4 Point-to-Point Links", December 2000. 285 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 286 Considered Harmful", RFC 3627, September 2003. 288 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 289 Discovery (ND) Trust Models and Threats", RFC 3756, 290 May 2004. 292 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 293 Message Protocol (ICMPv6) for the Internet Protocol 294 Version 6 (IPv6) Specification", RFC 4443, March 2006. 296 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 297 and C. Hahn, "IPv6 Unicast Address Assignment 298 Considerations", RFC 5375, December 2008. 300 Authors' Addresses 302 Miya Kohno 303 Juniper Networks, Keio University 304 Shinjuku Park Tower, 3-7-1 Nishishinjuku 305 Shinjuku-ku, Tokyo 163-1035 306 Japan 308 Email: mkohno@juniper.net 310 Becca Nitzan 311 Juniper Networks 312 1194 North Marhilda Avenue 313 Sunnyvale, CA 94089 314 USA 316 Email: nitzan@juniper.net 318 Randy Bush 319 Internet Initiative Japan 320 5147 Crystal Springs 321 Bainbridge Island, WA 98110 322 USA 324 Email: randy@psg.com 326 Yoshinobu Matsuzaki 327 Internet Initiative Japan 328 Jinbocho Mitsui Building, 329 1-105 Kanda Jinbo-cho, Tokyo 101-0051 330 Japan 332 Email: maz@iij.ad.jp 334 Lorenzo Colitti 335 Google 336 1600 Amphitheatre Parkway, 337 Mountain View, CA 94043 338 USA 340 Email: lorenzo@google.com 341 Thomas Narten 342 IBM Corporation 343 3039 Cornwallis Ave. 344 PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 345 USA 347 Email: narten@us.ibm.com