idnits 2.17.1 draft-ietf-6man-prefixlen-p2p-01.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 (December 14, 2010) is 4872 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: June 17, 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 December 14, 2010 15 Using 127-bit IPv6 Prefixes on Inter-Router Links 16 draft-ietf-6man-prefixlen-p2p-01.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 June 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 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. Links between a router and a host, or links to which both 117 routers and hosts are attached, are out of scope of this document. 119 The recommendations in this document does not apply to link-local 120 address scope. 122 4. Problems identified with 127-bit prefix lengths in the past 124 [RFC3627] discourages the use of 127-bit prefix lengths due to 125 conflicts with the Subnet-Router anycast addresses, while stating 126 that the utility of Subnet-Router Anycast for point-to-point links is 127 questionable. 129 [RFC5375] also says the usage of 127-bit prefix lengths is not valid 130 and should be strongly discouraged, but the stated reason for doing 131 this is to be in compliance with [RFC3627]. 133 Though the analyses in the RFCs are correct, operational experience 134 with IPv6 has shown that /127 prefixes can be used successfully. 136 5. Reasons for using longer prefixes 138 There are reasons network operators use IPv6 prefix lengths greater 139 than 64, particularly 127, for inter-router point-to-point links. 141 5.1. Ping-pong issue 143 A forwarding loop may occur on a point-to-point link with a prefix 144 length shorter than 127. This does not affect interfaces that 145 perform Neighbor Discovery, but some point-to-point links, which uses 146 medium such as SONET, do not use Neighbor Discovery. As a 147 consequence, configuring any prefix length shorter than 127 bits on 148 these links can create an attack vector in the network. 150 The pingpong issue happens in case of IPv4 as well. But due to the 151 scarcity of IPv4 address space, the current practice is to assign 152 long prefix lengths such as /30 or /31 [RFC3021] on point-to-point 153 links, thus the problem did not come to the fore. 155 The latest ICMPv6 specification [RFC4443] mitigates this problem by 156 specifying that a router receiving a packet on a point-to-point link, 157 which is destined to an address within a subnet assigned to that same 158 link (other than one of the receiving router's own addresses), MUST 159 NOT forward the packet back on that link. Instead, it SHOULD 160 generate an ICMPv6 Destination Unreachable message code 3 in 161 response. This check is on the forwarding processing path, so it may 162 have performance impact. 164 5.2. Neighbor Cache Exhaustion issue 166 As described in Section 4.3.2 of [RFC3756], the use of a 64-bit 167 prefix length on an inter-router link that uses Neighbor Discovery 168 (e.g., Ethernet) potentially allows for denial-of-service attacks on 169 the routers on the link. 171 Consider an Ethernet link between two routers A and B to which a /64 172 subnet has been assigned. A packet sent to any address on the /64 173 (except the addresses of A and B) will cause the router attempting to 174 forward it to create an new cache entry in state INCOMPLETE, send a 175 Neighbor Solicitation message to be sent on the link, start a 176 retransmit timer, and so on [RFC4861]. 178 By sending a continuous stream of packets to a large number of the 179 2^64 - 3 unassigned addresses on the link (one for each router and 180 one for Subnet-Router Anycast), an attacker can create a large number 181 of neighbor cache entries and send a large number of Neighbor 182 Solicitation packets which will never receive replies, thereby 183 consuming large amounts of memory and processing resources. Sending 184 the packets to one of the 2^24 addresses on the link which has the 185 same Solicited-Node multicast address as one of the routers also 186 causes the victim to spend large amounts of processing time 187 discarding useless Neighbor Solicitation messages. 189 Careful implementation and rate-limiting can limit the impact of such 190 an attack, but are unlikely to neutralize it completely. Rate- 191 limiting neighbor solicitation messages will reduce CPU usage, and 192 following the garbage-collection recommendations in [RFC4861] will 193 maintain reachability, but if the link is down and neighbor cache 194 entries have expired while the attack is ongoing, legitimate traffic 195 (for example, BGP sessions) over the link might never be re- 196 established because the routers cannot resolve each others' IPv6 197 addresses to MAC addresses. 199 This attack is not specific to point-to-point links, but is 200 particularly harmful in the case of point-to-point backbone links, 201 which may carry large amounts of traffic to many destinations over 202 long distances. 204 While there are a number of ways to mitigate this kind of issue, 205 assigning /127 subnets eliminates it completely. 207 5.3. Other reasons 209 Though address space conservation considerations are less important 210 for IPv6 than they are in IPv4, some operators prefer not to assign 211 /64s to individual point-to-point links. Instead, they may be able 212 to number all of their point-to-point links out of a single (or small 213 number of) /64s. 215 6. Recommendations 217 Routers MUST support the assignment of /127 prefixes on point-to- 218 point inter-router links. Routers MUST disable subnet-router anycast 219 for the prefix when /127 prefixes are used. 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, (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: 237 ffff), SHOULD NOT be used as unicast addresses to avoid colliding 238 with Reserved Subnet Anycast Addresses [RFC2526]. 240 7. Security Considerations 242 This document does not have inherent security considerations. It 243 does discuss security related issues and proposes a solution to them. 245 8. IANA Considerations 247 None. 249 9. Contributors 251 Chris Morrow, morrowc@google.com 253 Pekka Savola, pekkas@netcore.fi 255 Remi Despres, remi.despres@free.fr 257 Seiichi Kawamura, kawamucho@mesh.ad.jp 259 10. Acknowledgments 261 We'd like to thank Ron Bonica, Pramod Srinivasan, Olivier Vautrin, 262 Tomoya Yoshida, Warren Kumari and Tatsuya Jinmei for their helpful 263 inputs. 265 11. References 267 11.1. Normative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, March 1997. 272 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 273 Architecture", RFC 4291, February 2006. 275 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 276 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 277 September 2007. 279 11.2. Informative References 281 [RFC2526] Johnson, J. and S. Deering, "Reserved IPv6 Subnet Anycast 282 Addresses", RFC 2526, March 1999. 284 [RFC3021] Retana, A., White, R., and V. Fuller, "Using 31-Bit 285 Prefixes on IPv4 Point-to-Point Links", December 2000. 287 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 288 Considered Harmful", RFC 3627, September 2003. 290 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 291 Discovery (ND) Trust Models and Threats", RFC 3756, 292 May 2004. 294 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 295 Message Protocol (ICMPv6) for the Internet Protocol 296 Version 6 (IPv6) Specification", RFC 4443, March 2006. 298 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 299 and C. Hahn, "IPv6 Unicast Address Assignment 300 Considerations", RFC 5375, December 2008. 302 Authors' Addresses 304 Miya Kohno 305 Juniper Networks, Keio University 306 Shinjuku Park Tower, 3-7-1 Nishishinjuku 307 Shinjuku-ku, Tokyo 163-1035 308 Japan 310 Email: mkohno@juniper.net 312 Becca Nitzan 313 Juniper Networks 314 1194 North Marhilda Avenue 315 Sunnyvale, CA 94089 316 USA 318 Email: nitzan@juniper.net 320 Randy Bush 321 Internet Initiative Japan 322 5147 Crystal Springs 323 Bainbridge Island, WA 98110 324 USA 326 Email: randy@psg.com 328 Yoshinobu Matsuzaki 329 Internet Initiative Japan 330 Jinbocho Mitsui Building, 331 1-105 Kanda Jinbo-cho, Tokyo 101-0051 332 Japan 334 Email: maz@iij.ad.jp 336 Lorenzo Colitti 337 Google 338 1600 Amphitheatre Parkway, 339 Mountain View, CA 94043 340 USA 342 Email: lorenzo@google.com 343 Thomas Narten 344 IBM Corporation 345 3039 Cornwallis Ave. 346 PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 347 USA 349 Email: narten@us.ibm.com