idnits 2.17.1 draft-ietf-6man-why64-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2014) is 3475 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) -- No information found for draft-odell-8 - is the name correct? == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-02 == Outdated reference: A later version (-08) exists of draft-ietf-opsec-ipv6-host-scanning-04 == Outdated reference: A later version (-82) exists of draft-templin-aerolink-44 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN B. Carpenter, Ed. 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational T. Chown 5 Expires: April 23, 2015 Univ. of Southampton 6 F. Gont 7 SI6 Networks / UTN-FRH 8 S. Jiang 9 Huawei Technologies Co., Ltd 10 A. Petrescu 11 CEA, LIST 12 A. Yourtchenko 13 cisco 14 October 20, 2014 16 Analysis of the 64-bit Boundary in IPv6 Addressing 17 draft-ietf-6man-why64-07 19 Abstract 21 The IPv6 unicast addressing format includes a separation between the 22 prefix used to route packets to a subnet and the interface identifier 23 used to specify a given interface connected to that subnet. 24 Currently the interface identifier is defined as 64 bits long for 25 almost every case, leaving 64 bits for the subnet prefix. This 26 document describes the advantages of this fixed boundary and analyses 27 the issues that would be involved in treating it as a variable 28 boundary. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 23, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Advantages of a fixed identifier length . . . . . . . . . . . 4 66 3. Arguments for shorter identifier lengths . . . . . . . . . . 5 67 3.1. Insufficient address space delegated . . . . . . . . . . 5 68 3.2. Hierarchical addressing . . . . . . . . . . . . . . . . . 6 69 3.3. Audit requirement . . . . . . . . . . . . . . . . . . . . 6 70 3.4. Concerns over ND cache exhaustion . . . . . . . . . . . . 7 71 4. Effects of varying the interface identifier length . . . . . 7 72 4.1. Interaction with IPv6 specifications . . . . . . . . . . 7 73 4.2. Possible failure modes . . . . . . . . . . . . . . . . . 9 74 4.3. Experimental observations . . . . . . . . . . . . . . . . 11 75 4.3.1. Survey of the processing of Neighbor Discovery 76 options with prefixes other than /64 . . . . . . . . 11 77 4.3.2. Other Observations . . . . . . . . . . . . . . . . . 14 78 4.4. Implementation and deployment issues . . . . . . . . . . 14 79 4.5. Privacy issues . . . . . . . . . . . . . . . . . . . . . 16 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 83 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 17 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 86 9.2. Informative References . . . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 89 1. Introduction 91 Rather than simply overcoming the IPv4 address shortage by doubling 92 the address size to 64 bits, IPv6 addresses were originally chosen to 93 be 128 bits long to provide flexibility and new possibilities. In 94 particular, the notion of a well-defined interface identifier was 95 added to the IP addressing model. The IPv6 addressing architecture 96 [RFC4291] specifies that a unicast address is divided into n bits of 97 subnet prefix followed by (128-n) bits of interface identifier (IID). 98 The bits in the IID have no meaning and the entire identifier should 99 be treated as an opaque value [RFC7136]. Also, since IPv6 routing is 100 entirely based on variable length prefixes (also known as variable 101 length subnet masks), there is no basic architectural assumption that 102 n has any particular fixed value. All IPv6 routing protocols support 103 prefixes of any length up to /128. 105 The IID is of basic importance in the IPv6 stateless address 106 autoconfiguration (SLAAC) process [RFC4862]. However, it is 107 important to understand that its length is a parameter in the SLAAC 108 process, and it is determined in a separate link-type specific 109 document (see the definition of "interface identifier" in Section 2 110 of RFC 4862). The SLAAC protocol does not define its length or 111 assume any particular length. Similarly, DHCPv6 [RFC3315] does not 112 include a prefix length in its address assignment. 114 The notion of a /64 boundary in the address was introduced after the 115 initial design of IPv6, following a period when it was expected to be 116 at /80. There were two motivations for setting it at /64. One was 117 the original "8+8" proposal [DRAFT-odell] that eventually led to ILNP 118 [RFC6741], which required a fixed point for the split between local 119 and wide-area parts of the address. The other was the expectation 120 that EUI-64 MAC addresses would become widespread in place of 48-bit 121 addresses, coupled with the plan at that time that auto-configured 122 addresses would normally be based on interface identifiers derived 123 from MAC addresses. 125 As a result, RFC 4291 describes a method of forming interface 126 identifiers from IEEE EUI-64 hardware addresses [IEEE802] and this 127 specifies that such interface identifiers are 64 bits long. Various 128 other methods of forming interface identifiers also specify a length 129 of 64 bits. The addressing architecture, as modified by [RFC7136], 130 states that "For all unicast addresses, except those that start with 131 the binary value 000, Interface IDs are required to be 64 bits long. 132 If derived from an IEEE MAC-layer address, they must be constructed 133 in Modified EUI-64 format." The de facto length of almost all IPv6 134 interface identifiers is therefore 64 bits. The only documented 135 exception is in [RFC6164], which standardises 127-bit prefixes for 136 point-to-point links between routers, among other things to avoid a 137 loop condition known as the ping-pong problem. 139 With that exception, and despite the comments above about the routing 140 architecture and the design of SLAAC, using an IID shorter than 64 141 bits and a subnet prefix longer than 64 bits is outside the current 142 IPv6 specifications, so results may vary. 144 The question is often asked why the subnet prefix boundary is set 145 rigidly at /64. The first purpose of this document is to explain the 146 advantages of the fixed IID length. Its second purpose is to analyse 147 in some detail the effects of hypothetically varying the IID length. 148 The fixed length limits the practical length of a routing prefix to 149 64 bits, whereas architecturally, and from the point of view of 150 routing protocols, it could be any value up to /128, as for host 151 routes. Whatever the length of the IID, the longest match is done on 152 the concatenation of prefix and IID. Here, we mainly discuss the 153 question of a shorter IID, which would allow a longer subnet prefix. 154 The document makes no proposal for a change to the IID length. 156 The following three sections describe in turn the advantages of the 157 fixed length IID, some arguments for shorter lengths, and the 158 expected effects of varying the length. 160 2. Advantages of a fixed identifier length 162 As mentioned in Section 1, the existence of an IID of a given length 163 is a necessary part of IPv6 stateless address autoconfiguration 164 (SLAAC) [RFC4862]. This length is normally the same for all nodes on 165 a given link that is running SLAAC. Even though this length is a 166 parameter for SLAAC, determined separately for the link layer media 167 type of each interface, a globally fixed IID length for all link 168 layer media is the simplest solution, and is consistent with the 169 principles of Internet host configuration described in [RFC5505]. 171 An interface identifier of significant length, clearly separated from 172 the subnet prefix, makes it possible to limit the traceability of a 173 host computer by varying the identifier. This is discussed further 174 in Section 4.5. 176 An interface identifier of significant length guarantees that there 177 are always enough addresses in any subnet to add one or more real or 178 virtual interfaces. There might be other limits, but IP addressing 179 will never get in the way. 181 The addressing architecture [RFC4291] [RFC7136] sets the IID length 182 at 64 bits for all unicast addresses, and therefore for all media 183 supporting SLAAC. An immediate effect of fixing the IID length at 64 184 bits is, of course, that it fixes the subnet prefix length also at 64 185 bits, regardless of the aggregate prefix assigned to the site 186 concerned, which in accordance with [RFC6177] should be /56 or 187 shorter. This situation has various specific advantages: 189 o Everything is the same. Compared to IPv4, there is no more 190 calculating leaf subnet sizes, no more juggling between subnets, 191 and fewer consequent errors. Network design is therefore simpler 192 and much more straightforward. This is of importance for all 193 types of networks - enterprise, campus, small office, or home 194 networks - and for all types of operator, from professional to 195 consumer. 197 o Adding a subnet is easy - just take another /64 from the pool. No 198 estimates, calculations, consideration or judgement is needed. 200 o Router configurations are homogeneous and easier to understand. 202 o Documentation is easier to write and easier to read; training is 203 easier. 205 The remainder of this document describes arguments that have been 206 made against the current fixed IID length and analyses the effects of 207 a possible change. However, the consensus of the IETF is that the 208 benefits of keeping the length fixed at 64 bits, and the practical 209 difficulties of changing it, outweigh the arguments for change. 211 3. Arguments for shorter identifier lengths 213 In this section we describe arguments for scenarios where shorter 214 IIDs, implying prefixes longer than /64, have been used or proposed. 216 3.1. Insufficient address space delegated 218 A site may not be delegated a sufficiently generous prefix from which 219 to allocate a /64 prefix to all of its internal subnets. In this 220 case the site may either determine that it does not have enough 221 address space to number all its network elements and thus, at the 222 very best, be only partially operational, or it may choose to use 223 internal prefixes longer than /64 to allow multiple subnets and the 224 hosts within them to be configured with addresses. 226 In this case, the site might choose, for example, to use a /80 per 227 subnet, in combination with hosts using either manually configured 228 addressing or DHCPv6 [RFC3315]. 230 Scenarios that have been suggested where an insufficient prefix might 231 be delegated include home or small office networks, vehicles, 232 building services and transportation services (road signs, etc.). It 233 should be noted that the homenet architecture text 234 [I-D.ietf-homenet-arch] states that a CPE should consider the lack of 235 sufficient address space to be an error condition, rather than using 236 prefixes longer than /64 internally. 238 Another scenario occasionally suggested is one where the Internet 239 address registries actually begin to run out of IPv6 prefix space, 240 such that operators can no longer assign reasonable prefixes to users 241 in accordance with [RFC6177]. It is sometimes suggested that 242 assigning a prefix such as /48 or /56 to every user site (including 243 the smallest) as recommended by [RFC6177] is wasteful. In fact, the 244 currently released unicast address space, 2000::/3, contains 35 245 trillion /48 prefixes ((2**45 = 35,184,372,088,832), of which only a 246 small fraction have been allocated. Allowing for a conservative 247 estimate of allocation efficiency, i.e., an HD-ratio of 0.94 248 [RFC4692], approximately 5 trillion /48 prefixes can be allocated. 249 Even with a relaxed HD-ratio of 0.89, approximately one trillion /48 250 prefixes can be allocated. Furthermore, with only 2000::/3 currently 251 committed for unicast addressing, we still have approximately 85% of 252 the address space in reserve. Thus there is no objective risk of 253 prefix depletion by assigning /48 or /56 prefixes even to the 254 smallest sites. 256 3.2. Hierarchical addressing 258 Some operators have argued that more prefix bits are needed to allow 259 an aggregated hierarchical addressing scheme within a campus or 260 corporate network. However, if a campus or enterprise gets a /48 261 prefix (or shorter), then that already provides 16 bits for 262 hierarchical allocation. In any case, flat IGP routing is widely and 263 successfully used within rather large networks, with hundreds of 264 routers and thousands of end systems. Therefore there is no 265 objective need for additional prefix bits to support hierarchy and 266 aggregation within enterprises. 268 3.3. Audit requirement 270 Some network operators wish to know and audit which nodes are active 271 on a network, especially those that are allowed to communicate off 272 link or off site. They may also wish to limit the total number of 273 active addresses and sessions that can be sourced from a particular 274 host, LAN or site, in order to prevent potential resource depletion 275 attacks or other problems spreading beyond a certain scope of 276 control. It has been argued that this type of control would be 277 easier if only long network prefixes with relatively small numbers of 278 possible hosts per network were used, reducing the discovery problem. 279 However, such sites most typically operate using DHCPv6, which means 280 that all legitimate hosts are automatically known to the DHCPv6 281 servers, which is sufficient for audit purposes. Such hosts could, 282 if desired, be limited to a small range of IID values without 283 changing the /64 subnet length. Any hosts inadvertently obtaining 284 addresses via SLAAC can be audited through Neighbor Discovery logs. 286 3.4. Concerns over ND cache exhaustion 288 A site may be concerned that it is open to neighbour discovery (ND) 289 cache exhaustion attacks [RFC3756], whereby an attacker sends a large 290 number of messages in rapid succession to a series of (most likely 291 inactive) host addresses within a specific subnet. Such an attack 292 attempts to fill a router's ND cache with ND requests pending 293 completion, in so doing denying correct operation to active devices 294 on the network. 296 One potential way to mitigate this attack would be to consider using 297 a /120 prefix, thus limiting the number of addresses in the subnet to 298 be similar to an IPv4 /24 prefix, which should not cause any concerns 299 for ND cache exhaustion. Note that the prefix does need to be quite 300 long for this scenario to be valid. The number of theoretically 301 possible ND cache slots on the segment needs to be of the same order 302 of magnitude as the actual number of hosts. Thus small increases 303 from the /64 prefix length do not have a noticeable impact: even 2^32 304 potential entries, a factor of two billion decrease compared to 2^64, 305 is still more than enough to exhaust the memory on current routers. 306 Given that most link layer mappings cause SLAAC to assume a 64 bit 307 network boundary, in such an approach hosts would likely need to use 308 DHCPv6, or be manually configured with addresses. 310 It should be noted that several other mitigations of the ND cache 311 attack are described in [RFC6583], and that limiting the size of the 312 cache and the number of incomplete entries allowed would also defeat 313 the attack. For the specific case of a point-to-point link between 314 routers, this attack is indeed mitigated by a /127 prefix [RFC6164]. 316 4. Effects of varying the interface identifier length 318 This section of the document analyses the impact and effects of 319 varying the length of an IPv6 unicast IID by reducing it to less than 320 64 bits. 322 4.1. Interaction with IPv6 specifications 324 The precise 64-bit length of the Interface ID is widely mentioned in 325 numerous RFCs describing various aspects of IPv6. It is not 326 straightforward to distinguish cases where this has normative impact 327 or affects interoperability. This section aims to identify 328 specifications that contain an explicit reference to the 64-bit 329 length. Regardless of implementation issues, the RFCs themselves 330 would all need to be updated if the 64-bit rule was changed, even if 331 the updates were small, which would involve considerable time and 332 effort. 334 First and foremost, the RFCs describing the architectural aspects of 335 IPv6 addressing explicitly state, refer and repeat this apparently 336 immutable value: Addressing Architecture [RFC4291], IPv6 Address 337 Assignment to End Sites [RFC6177], Reserved Interface Identifiers 338 [RFC5453], ILNP Node Identifiers [RFC6741]. Customer Edge routers 339 impose /64 for their interfaces [RFC7084]. The IPv6 Subnet Model 340 [RFC5942] points out that the assumption of a /64 prefix length is a 341 potential implementation error. 343 Numerous IPv6-over-foo documents make mandatory statements with 344 respect to the 64-bit length of the Interface ID to be used during 345 the Stateless Autoconfiguration. These documents include [RFC2464] 346 (Ethernet), [RFC2467] (FDDI), [RFC2470] (Token Ring), [RFC2492] 347 (ATM), [RFC2497] (ARCnet), [RFC2590] (Frame Relay), [RFC3146] (IEEE 348 1394), [RFC4338] (Fibre Channel), [RFC4944] (IEEE 802.15.4), 349 [RFC5072] (PPP), [RFC5121] [RFC5692] (IEEE 802.16), [RFC2529] 350 (6over4), [RFC5214] (ISATAP), [I-D.templin-aerolink] (AERO), 351 [I-D.ietf-6lowpan-btle], [I-D.ietf-6man-6lobac], 352 [I-D.brandt-6man-lowpanz]. 354 To a lesser extent, the address configuration RFCs themselves may in 355 some ways assume the 64-bit length of an Interface ID (e.g, RFC 4862 356 for the link-local addresses, DHCPv6 for the potentially assigned 357 EUI-64-based IP addresses, Optimistic Duplicate Address Detection 358 [RFC4429] which computes 64-bit-based collision probabilities). 360 The MLDv1 [RFC2710] and MLDv2 [RFC3810] protocols mandate that all 361 queries be sent with a link-local source address, with the exception 362 of MLD messages sent using the unspecified address when the link- 363 local address is tentative [RFC3590]. At the time of publication of 364 RFC 2710, the IPv6 addressing architecture specified link-local 365 addresses with 64-bit interface identifiers. MLDv2 explicitly 366 specifies the use of the fe80::/64 link-local prefix, and bases the 367 querier election algorithm on the link-local subnet prefix of length 368 /64. 370 The IPv6 Flow Label Specification [RFC6437] gives an example of a 371 20-bit hash function generation which relies on splitting an IPv6 372 address in two equally-sized 64bit-length parts. 374 The basic transition mechanisms [RFC4213] refer to IIDs of length 64 375 for link-local addresses, and other transition mechanisms such as 376 Teredo [RFC4380] assume the use of IIDs of length 64. Similar 377 assumptions are found in 6to4 [RFC3056] and 6rd [RFC5969]. 378 Translation-based transition mechanisms such as NAT64 and NPTv6 have 379 some dependency on prefix length, discussed below. 381 The proposed method [RFC7278] of extending an assigned /64 prefix 382 from a smartphone's cellular interface to its WiFi link relies on 383 prefix length, and implicitly on the length of the Interface ID, to 384 be valued at 64. 386 The CGA and HBA specifications rely on the 64-bit identifier length 387 (see below), as do the Privacy extensions [RFC4941] and some examples 388 in IKEv2bis [RFC5996]. 390 464XLAT [RFC6877] explicitly mentions acquiring /64 prefixes. 391 However, it also discusses the possibility of using the interface 392 address on the device as the endpoint for the traffic, thus 393 potentially removing this dependency. 395 [RFC2526] reserves a number of subnet anycast addresses by reserving 396 some anycast IIDs. An anycast IID so reserved cannot be less than 7 397 bits long. This means that a subnet prefix length longer than /121 398 is not possible, and a subnet of exactly /121 would be useless since 399 all its identifiers are reserved. It also means that half of a /120 400 is reserved for anycast. This could of course be fixed in the way 401 described for /127 in [RFC6164], i.e., avoiding the use of anycast 402 within a /120 subnet. Note that support for "on-link anycast" is a 403 standard IPv6 neighbor discovery capability [RFC4861][RFC7094], and 404 therefore applications and their developers would expect it to be 405 available. 407 The Mobile IP home network models [RFC4887] rely heavily on the /64 408 subnet length and assume a 64-bit IID. 410 While preparing this document, it was noted that many other IPv6 411 specifications refer to mandatory alignment on 64-bit boundaries, 412 64-bit data structures, 64-bit counters in MIBs, 64-bit sequence 413 numbers and cookies in security, etc. Finally, the number "64" may 414 be considered "magic" in some RFCs, e.g., 64k limits in DNS and 415 Base64 encodings in MIME. None of this has any influence on the 416 length of the IID, but might confuse a careless reader. 418 4.2. Possible failure modes 420 This section discusses several specific aspects of IPv6 where we can 421 expect operational failures with subnet prefixes other than /64. 423 o Router implementations: Router implementors might interpret IETF 424 standards such as [RFC6164] and [RFC7136] to indicate that 425 prefixes between /65 and /126 inclusive for unicast packets on- 426 the-wire are invalid, and operational practices that utilize 427 prefix lengths in this range may fail on some devices, as 428 discussed in Section 4.3.2. 430 o Multicast: [RFC3306] defines a method for generating IPv6 431 multicast group addresses based on unicast prefixes. This method 432 assumes a longest prefix of 64 bits. If a longer prefix is used, 433 there is no way to generate a specific multicast group address 434 using this method. In such cases the administrator would need to 435 use an "artificial" prefix from within their allocation (a /64 or 436 shorter) from which to generate the group address. This prefix 437 would not correspond to a real subnet. 439 Similarly [RFC3956], which specifies Embedded-RP, allowing IPv6 440 multicast rendezvous point addresses to be embedded in the 441 multicast group address, would also fail, as the scheme assumes a 442 maximum prefix length of 64 bits. 444 o CGA: The Cryptographically Generated Address format (CGA, 445 [RFC3972]) is heavily based on a /64 interface identifier. 446 [RFC3972] has defined a detailed algorithm showing how to generate 447 a 64-bit interface identifier from a public key and a 64-bit 448 subnet prefix. Changing the /64 boundary would certainly 449 invalidate the current CGA definition. However, CGA might benefit 450 in a redefined version if more bits are used for interface 451 identifier (which means shorter prefix length). For now, 59 bits 452 are used for cryptographic purposes. The more bits are available, 453 the stronger CGA could be. Conversely, longer prefixes would 454 weaken CGA. 456 o NAT64: Both stateless [RFC6052] NAT64 and stateful NAT64 [RFC6146] 457 are flexible for the prefix length. [RFC6052] has defined 458 multiple address formats for NAT64. In Section 2 "IPv4-Embedded 459 IPv6 Prefix and Format" of [RFC6052], the network-specific prefix 460 could be one of /32, /40, /48, /56, /64 and /96. The remaining 461 part of the IPv6 address is constructed by a 32-bit IPv4 address, 462 a 8-bit u byte and a variable length suffix (there is no u byte 463 and suffix in the case of 96-bit Well-Known Prefix). NAT64 is 464 therefore OK with a subnet boundary out to /96, but not longer. 466 o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296] is also 467 bound to /64 boundary. NPTv6 maps a /64 prefix to another /64 468 prefix. When the NPTv6 Translator is configured with a /48 or 469 shorter prefix, the 64-bit interface identifier is kept unmodified 470 during translation. However, the /64 boundary might be changed as 471 long as the "inside" and "outside" prefixes have the same length. 473 o ILNP: Identifier-Locator Network Protocol (ILNP) [RFC6741] is 474 designed around the /64 boundary, since it relies on locally 475 unique 64-bit node identifiers (in the interface identifier 476 field). While a re-design to use longer prefixes is not 477 inconceivable, this would need major changes to the existing 478 specification for the IPv6 version of ILNP. 480 o shim6: The Multihoming Shim Protocol for IPv6 (shim6) [RFC5533] in 481 its insecure form treats IPv6 address as opaque 128-bit objects. 482 However, to secure the protocol against spoofing, it is essential 483 to either use CGAs (see above) or Hash-Based Addresses (HBA) 484 [RFC5535]. Like CGAs, HBAs are generated using a procedure that 485 assumes a 64-bit identifier. Therefore, in effect, secure shim6 486 is affected by the /64 boundary exactly like CGAs. 488 o Duplicate address risk: If SLAAC was modified to work with shorter 489 IIDs, the statistical risk of hosts choosing the same pseudo- 490 random identifier [RFC7217] would increase correspondingly. The 491 practical impact of this would range from slight to dramatic, 492 depending on how much the IID length was reduced. In particular, 493 a /120 prefix would imply an 8 bit IID and address collisions 494 would be highly probable. 496 o The link-local prefix: While RFC 4862 is careful not to define any 497 specific length of link-local prefix within fe80::/10, the 498 addressing architecture [RFC4291] does define the link-local IID 499 length to be 64 bits. If different hosts on a link used IIDs of 500 different lengths to form a link-local address, there is potential 501 for confusion and unpredictable results. Typically today the 502 choice of 64 bits for the link-local IID length is hard-coded per 503 interface, in accordance with the relevant IPv6-over-foo 504 specification, and systems behave as if the link local prefix was 505 actually fe80::/64. There might be no way to change this except 506 conceivably by manual configuration, which will be impossible if 507 the host concerned has no local user interface. 509 It goes without saying that if prefixes longer than /64 are to be 510 used, all hosts must be capable of generating IIDs shorter than 64 511 bits, in order to follow the auto-configuration procedure correctly 512 [RFC4862]. 514 4.3. Experimental observations 516 4.3.1. Survey of the processing of Neighbor Discovery options with 517 prefixes other than /64 519 This section provides a survey of the processing of Neighbor 520 Discovery options which include prefixes that are different than /64. 522 The behavior of nodes was assessed with respect to the following 523 options: 525 o PIO-A: Prefix Information Option (PIO) [RFC4861] with the A bit 526 set. 528 o PIO-L: Prefix Information Option (PIO) [RFC4861] with the L bit 529 set. 531 o PIO-AL: Prefix Information Option (PIO) [RFC4861] with both the A 532 and L bits set. 534 o RIO: Route Information Option (RIO) [RFC4191]. 536 In the tables below, the following notation is used: 538 NOT-SUP: 539 This option is not supported (i.e., it is ignored no matter the 540 prefix length used). 542 LOCAL: 543 The corresponding prefix is considered "on-link". 545 ROUTE: 546 The corresponding route is added to the IPv6 routing table. 548 NOT-DEF: 549 The default configuration is NOT-SUP, but there is an option to 550 enable ROUTE. 552 IGNORE: 553 The Option is ignored as an error. 555 +--------------------+--------+-------+--------+---------+ 556 | Operating System | PIO-A | PIO-L | PIO-AL | RIO | 557 +--------------------+--------+-------+--------+---------+ 558 | FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP | 559 +--------------------+--------+-------+--------+---------+ 560 | Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF | 561 +--------------------+--------+-------+--------+---------+ 562 | Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF | 563 +--------------------+--------+-------+--------+---------+ 564 | NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP | 565 +--------------------+--------+-------+--------+---------+ 566 | OpenBSD-current | IGNORE | LOCAL | LOCAL | NOT-SUP | 567 +--------------------+--------+-------+--------+---------+ 568 | Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE | 569 +--------------------+--------+-------+--------+---------+ 570 | Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE | 571 +--------------------+--------+-------+--------+---------+ 573 Table 1: Processing of ND options with prefixes longer than /64 575 +--------------------+--------+-------+--------+---------+ 576 | Operating System | PIO-A | PIO-L | PIO-AL | RIO | 577 +--------------------+--------+-------+--------+---------+ 578 | FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP | 579 +--------------------+--------+-------+--------+---------+ 580 | Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF | 581 +--------------------+--------+-------+--------+---------+ 582 | Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF | 583 +--------------------+--------+-------+--------+---------+ 584 | NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP | 585 +--------------------+--------+-------+--------+---------+ 586 | OpenBSD-current | IGNORE | LOCAL | LOCAL | NOT-SUP | 587 +--------------------+--------+-------+--------+---------+ 588 | Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE | 589 +--------------------+--------+-------+--------+---------+ 590 | Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE | 591 +--------------------+--------+-------+--------+---------+ 593 Table 2: Processing of ND options with prefixes shorter than /64 595 The results obtained can be summarized as follows: 597 o the "A" bit in the Prefix Information Options is honored only if 598 the prefix length is 64. At least for the case where the IID 599 length is defined to be 64 bits in the corresponding link-type- 600 specific document, which is the case for all currently published 601 such documents, this is consistent with [RFC4862], which defines 602 the case where the sum of the advertised prefix length and the IID 603 length does not equal 128 as an error condition. 605 o the "L" bit in the Prefix Information Options is honored for any 606 arbitrary prefix length (whether shorter or longer than /64). 608 o nodes that support the Route Information Option allow such routes 609 to be specified with prefixes of any arbitrary length (whether 610 shorter or longer than /64) 612 4.3.2. Other Observations 614 Participants in the V6OPS working group have indicated that some 615 forwarding devices have been shown to work correctly with long 616 prefixes such as /80 or /96. Indeed, it is to be expected that 617 longest prefix match based forwarding will work for any prefix 618 length, and no reports of this completely failing have been noted. 619 Also, DHCPv6 is in widespread use without any dependency on the /64 620 boundary. Reportedly, there are deployments of /120 subnets 621 configured using DHCPv6. 623 There have been definite reports that some routers have a performance 624 drop-off or even resource exhaustion for prefixes longer than /64, 625 due to design issues. In particular, some routing chip designs 626 allocate much less space for longer prefixes than for prefixes up to 627 /64, for the sake of savings in memory, power and lookup latency. 628 Some devices need special-case code to handle point-to-point links 629 according to [RFC6164]. 631 It has been reported that at least one type of switch has a content- 632 addressable memory limited to 144 bits, which is indeed a typical 633 value for commodity components [TCAM]. This means that packet 634 filters or access control lists cannot be defined based on 128-bit 635 addresses and two 16-bit port numbers; the longest prefix that could 636 be used in such a filter is a /112. 638 4.4. Implementation and deployment issues 640 From an early stage, implementations and deployments of IPv6 assumed 641 the /64 subnet length, even though routing was based on prefixes of 642 any length. As shown above, this became anchored in many 643 specifications (Section 4.1) and in important aspects of 644 implementations commonly used in local area networks (Section 4.3). 645 In fact, a programmer might be lulled into assuming a comfortable 646 rule of thumb that subnet prefixes are always /64 and an IID is 647 always of length 64. Apart from the limited evidence in 648 Section 4.3.1, we cannot tell without code inspections or tests 649 whether existing stacks are able to handle a flexible IID length, or 650 whether they would require modification to do so. A conforming 651 implementation of an IPv6-over-foo that specifies a 64 bit IID for 652 foo links will of course only support 64. But in a well designed 653 stack, the IP layer itself will treat that 64 as a parameter, so 654 changing the IID length in the IPv6-over-foo code should be all that 655 is necessary. 657 The main practical consequence of the existing specifications is that 658 deployments in which longer subnet prefixes are used cannot make use 659 of SLAAC-configured addresses, and require either manually configured 660 addresses or DHCPv6. To reverse this argument, if it was considered 661 desirable to allow auto-configured addresses with subnet prefixes 662 longer than /64, all of the specifications identified above as 663 depending on /64 would have to be modified, with due regard to 664 interoperability with unmodified stacks. In fact [RFC7217] allows 665 for this possibility. Then modified stacks would have to be 666 developed and deployed. It might be the case that some stacks 667 contain dependencies on the /64 boundary which are not directly 668 implied by the specifications, and any such hidden dependencies would 669 also need to be found and removed. 671 At least one DHCPv6 client unconditionally installs a /64 prefix as 672 on-link when it configures an interface with an address, although 673 some specific operating system vendors seem to change this default 674 behavior by tweaking a client-side script. This is in clear 675 violation of the IPv6 subnet model [RFC5942]. The motivation for 676 this choice is that if there is no router on the link, the hosts 677 would fail to communicate with each other using the configured 678 addresses because the "on-link assumption" was removed in [RFC4861]. 679 This is not really about the magic number of 64, but an 680 implementation may sometimes pick an arbitrary value of prefix length 681 due to the removal of the on-link assumption, and the value chosen 682 will most likely be 64. 684 Typical IP Address Management (IPAM) tools treat /64 as the default 685 subnet length, but allow users to specify longer subnet prefixes if 686 desired. Clearly, all IPAM tools and network management systems 687 would need to be checked in detail. 689 Finally, IPv6 is already deployed at many sites, with a large number 690 of staff trained on the basis of the existing standards, supported by 691 documentation and tools based on those standards. Numerous existing 692 middlebox devices are also based on those standards. These people, 693 documents, tools and devices represent a very large investment that 694 would be seriously impacted by a change in the /64 boundary. 696 4.5. Privacy issues 698 The length of the interface identifier has implications for privacy 699 [I-D.ietf-6man-ipv6-address-generation-privacy]. In any case in 700 which the value of the identifier is intended to be hard to guess, 701 whether or not it is cryptographically generated, it is apparent that 702 more bits are better. For example, if there are only 20 bits to be 703 guessed, at most just over a million guesses are needed, today well 704 within the capacity of a low cost attack mechanism. It is hard to 705 state in general how many bits are enough to protect privacy, since 706 this depends on the resources available to the attacker, but it seems 707 clear that a privacy solution needs to resist an attack requiring 708 billions rather than millions of guesses. Trillions would be better, 709 suggesting that at least 40 bits should be available. Thus we can 710 argue that subnet prefixes longer than say /80 might raise privacy 711 concerns by making the IID guessable. 713 A prefix long enough to limit the number of addresses comparably to 714 an IPv4 subnet, such as /120, would create exactly the same situation 715 for privacy as IPv4 except for the absence of NAT. In particular, a 716 host would be forced to pick a new IID when roaming to a new network, 717 to avoid collisions. As mentioned earlier, it is likely that SLAAC 718 will not be used on such a subnet. 720 5. Security Considerations 722 In addition to the privacy issues mentioned in Section 4.5, and the 723 issues mentioned with CGAs and HBAs in Section 4.2, the length of the 724 subnet prefix affects the matter of defence against scanning attacks 725 [I-D.ietf-opsec-ipv6-host-scanning]. Assuming the attacker has 726 discovered or guessed the prefix length, a longer prefix reduces the 727 space that the attacker needs to scan, e.g., to only 256 addresses if 728 the prefix is /120. On the other hand, if the attacker has not 729 discovered the prefix length and assumes it to be /64, routers can 730 trivially discard attack packets that do not fall within an actual 731 subnet. 733 However, assume that an attacker finds one valid address A and 734 assumes that it is within a long prefix such as a /120. The attacker 735 then starts a scanning attack by scanning "outwards" from A, by 736 trying A+1, A-1, A+2, A-2, etc. This attacker will easily find all 737 hosts in any subnet with a long prefix, because they will have 738 addresses close to A. We therefore conclude that any prefix 739 containing densely packed valid addresses is vulnerable to a scanning 740 attack, without the attacker needing to guess the prefix length. 741 Therefore, to preserve IPv6's advantage over IPv4 in resisting 742 scanning attacks, it is important that subnet prefixes are short 743 enough to allow sparse allocation of identifiers within each subnet. 745 The considerations are similar to those for privacy, and we can again 746 argue that prefixes longer than say /80 might significantly increase 747 vulnerability. Ironically, this argument is exactly converse to the 748 argument for longer prefixes to resist an ND cache attack, as 749 described in Section 3.4. 751 Denial of service attacks related to Neighbor Discovery are discussed 752 in Section 3.4 and in [RFC6583]. One of the mitigations suggested by 753 that document is "sizing subnets to reflect the number of addresses 754 actually in use", but the fact that this greatly simplifies scanning 755 attacks is not noted. For further discussion of scanning attacks, 756 see [I-D.ietf-opsec-ipv6-host-scanning]. 758 Note that, although not known at the time of writing, there might be 759 other resource exhaustion attacks available, similar in nature to the 760 ND cache attack. We cannot exclude that such attacks might be 761 exacerbated by sparsely populated subnets such as a /64. It should 762 also be noted that this analysis assumes a conventional deployment 763 model with a significant number of end-systems located in a single 764 LAN broadcast domain. Other deployment models might lead to 765 different conclusions. 767 6. IANA Considerations 769 This document requests no action by IANA. 771 7. Acknowledgements 773 This document was inspired by a vigorous discussion on the V6OPS 774 working group mailing list with at least 20 participants. Later, 775 valuable comments were received from Ran Atkinson, Fred Baker, Steven 776 Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter, 777 Paraskevi Iliadou, Jen Linkova, Philip Matthews, Matthew Petach, 778 Scott Schmit, Tatuya Jinmei, Fred Templin, Ole Troan, Stig Venaas, 779 and numerous other participants in the 6MAN working group. An 780 extremely detailed review by Mark Smith was especially helpful. 782 This document was produced using the xml2rfc tool [RFC2629]. 784 8. Change log [RFC Editor: Please remove] 786 draft-ietf-6man-why64-07: correction to Linux NOT-SUP status, 787 2014-10-20. 789 draft-ietf-6man-why64-06: minor IETF Last Call comments, 2014-10-02. 791 draft-ietf-6man-why64-05: Area Director review comments, 2014-09-16. 793 draft-ietf-6man-why64-04: fixed reference error, 2014-09-10. 795 draft-ietf-6man-why64-03: fixed nits, 2014-08-27. 797 draft-ietf-6man-why64-02: responded to WGLC reviews and comments, 798 2014-08-16. 800 draft-ietf-6man-why64-01: language improvements, added TCAM 801 reference, 2014-05-07. 803 draft-ietf-6man-why64-00: WG adoption, WG comments, including major 804 text reorganisation: 3 main sections describe advantages of fixed 805 length IID, arguments for shorter lengths, and expected effects of 806 varying the length, 2014-04-11. 808 draft-carpenter-6man-why64-01: WG comments, added experimental 809 results, implementation/deployment text, 2014-02-06. 811 draft-carpenter-6man-why64-00: original version, 2014-01-06. 813 9. References 815 9.1. Normative References 817 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 818 Networks", RFC 2464, December 1998. 820 [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI 821 Networks", RFC 2467, December 1998. 823 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of 824 IPv6 Packets over Token Ring Networks", RFC 2470, December 825 1998. 827 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 828 Networks", RFC 2492, January 1999. 830 [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet 831 Networks", RFC 2497, January 1999. 833 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 834 Addresses", RFC 2526, March 1999. 836 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 837 Domains without Explicit Tunnels", RFC 2529, March 1999. 839 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of 840 IPv6 Packets over Frame Relay Networks Specification", RFC 841 2590, May 1999. 843 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 844 Listener Discovery (MLD) for IPv6", RFC 2710, October 845 1999. 847 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 848 via IPv4 Clouds", RFC 3056, February 2001. 850 [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 851 over IEEE 1394 Networks", RFC 3146, October 2001. 853 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 854 Multicast Addresses", RFC 3306, August 2002. 856 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 857 and M. Carney, "Dynamic Host Configuration Protocol for 858 IPv6 (DHCPv6)", RFC 3315, July 2003. 860 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 861 Listener Discovery (MLD) Protocol", RFC 3590, September 862 2003. 864 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 865 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 867 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 868 Point (RP) Address in an IPv6 Multicast Address", RFC 869 3956, November 2004. 871 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 872 RFC 3972, March 2005. 874 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 875 More-Specific Routes", RFC 4191, November 2005. 877 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 878 for IPv6 Hosts and Routers", RFC 4213, October 2005. 880 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 881 Architecture", RFC 4291, February 2006. 883 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 884 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 885 over Fibre Channel", RFC 4338, January 2006. 887 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 888 Network Address Translations (NATs)", RFC 4380, February 889 2006. 891 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 892 for IPv6", RFC 4429, April 2006. 894 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 895 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 896 September 2007. 898 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 899 Address Autoconfiguration", RFC 4862, September 2007. 901 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 902 Extensions for Stateless Address Autoconfiguration in 903 IPv6", RFC 4941, September 2007. 905 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 906 "Transmission of IPv6 Packets over IEEE 802.15.4 907 Networks", RFC 4944, September 2007. 909 [RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over 910 PPP", RFC 5072, September 2007. 912 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 913 Madanapalli, "Transmission of IPv6 via the IPv6 914 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 915 February 2008. 917 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 918 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 919 March 2008. 921 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 922 5453, February 2009. 924 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 925 Shim Protocol for IPv6", RFC 5533, June 2009. 927 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 928 2009. 930 [RFC5692] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP 931 over Ethernet over IEEE 802.16 Networks", RFC 5692, 932 October 2009. 934 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 935 Model: The Relationship between Links and Subnet 936 Prefixes", RFC 5942, July 2010. 938 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 939 Infrastructures (6rd) -- Protocol Specification", RFC 940 5969, August 2010. 942 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 943 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 944 5996, September 2010. 946 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 947 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 948 October 2010. 950 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 951 NAT64: Network Address and Protocol Translation from IPv6 952 Clients to IPv4 Servers", RFC 6146, April 2011. 954 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 955 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 956 Router Links", RFC 6164, April 2011. 958 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 959 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 961 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 962 Translation", RFC 6296, June 2011. 964 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 965 "IPv6 Flow Label Specification", RFC 6437, November 2011. 967 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 968 Requirements for IPv6 Customer Edge Routers", RFC 7084, 969 November 2013. 971 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 972 Interface Identifiers", RFC 7136, February 2014. 974 9.2. Informative References 976 [DRAFT-odell] 977 O'Dell, M., "8+8 - An Alternate Addressing Architecture 978 for IPv6", draft-odell-8+8.00 (work in progress), October 979 1996. 981 [I-D.brandt-6man-lowpanz] 982 Brandt, A. and J. Buron, "Transmission of IPv6 packets 983 over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02 984 (work in progress), June 2013. 986 [I-D.ietf-6lowpan-btle] 987 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 988 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 989 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 990 (work in progress), February 2013. 992 [I-D.ietf-6man-6lobac] 993 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 994 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 995 6man-6lobac-01 (work in progress), March 2012. 997 [I-D.ietf-6man-ipv6-address-generation-privacy] 998 Cooper, A., Gont, F., and D. Thaler, "Privacy 999 Considerations for IPv6 Address Generation Mechanisms", 1000 draft-ietf-6man-ipv6-address-generation-privacy-02 (work 1001 in progress), October 2014. 1003 [I-D.ietf-homenet-arch] 1004 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1005 "IPv6 Home Networking Architecture Principles", draft- 1006 ietf-homenet-arch-17 (work in progress), July 2014. 1008 [I-D.ietf-opsec-ipv6-host-scanning] 1009 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1010 Networks", draft-ietf-opsec-ipv6-host-scanning-04 (work in 1011 progress), June 2014. 1013 [I-D.templin-aerolink] 1014 Templin, F., "Transmission of IP Packets over AERO Links", 1015 draft-templin-aerolink-44 (work in progress), October 1016 2014. 1018 [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area 1019 Networks: Overview and Architecture", IEEE Std 802-2001 1020 (R2007), 2007. 1022 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1023 June 1999. 1025 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1026 Discovery (ND) Trust Models and Threats", RFC 3756, May 1027 2004. 1029 [RFC4692] Huston, G., "Considerations on the IPv6 Host Density 1030 Metric", RFC 4692, October 2006. 1032 [RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network 1033 Mobility Home Network Models", RFC 4887, July 2007. 1035 [RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, 1036 "Principles of Internet Host Configuration", RFC 5505, May 1037 2009. 1039 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1040 Neighbor Discovery Problems", RFC 6583, March 2012. 1042 [RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol 1043 (ILNP) Engineering Considerations", RFC 6741, November 1044 2012. 1046 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1047 Combination of Stateful and Stateless Translation", RFC 1048 6877, April 2013. 1050 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1051 "Architectural Considerations of IP Anycast", RFC 7094, 1052 January 2014. 1054 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1055 Interface Identifiers with IPv6 Stateless Address 1056 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 1058 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 1059 /64 Prefix from a Third Generation Partnership Project 1060 (3GPP) Mobile Interface to a LAN Link", RFC 7278, June 1061 2014. 1063 [TCAM] Meiners, C., Liu, A., and E. Torng, "Algorithmic 1064 Approaches to Redesigning TCAM-Based Systems", ACM 1065 SIGMETRICS'08 467-468, 2008. 1067 Authors' Addresses 1069 Brian Carpenter (editor) 1070 Department of Computer Science 1071 University of Auckland 1072 PB 92019 1073 Auckland 1142 1074 New Zealand 1076 Email: brian.e.carpenter@gmail.com 1077 Tim Chown 1078 University of Southampton 1079 Southampton, Hampshire SO17 1BJ 1080 United Kingdom 1082 Email: tjc@ecs.soton.ac.uk 1084 Fernando Gont 1085 SI6 Networks / UTN-FRH 1086 Evaristo Carriego 2644 1087 Haedo, Provincia de Buenos Aires 1706 1088 Argentina 1090 Email: fgont@si6networks.com 1092 Sheng Jiang 1093 Huawei Technologies Co., Ltd 1094 Q14, Huawei Campus 1095 No.156 Beiqing Road 1096 Hai-Dian District, Beijing 100095 1097 P.R. China 1099 Email: jiangsheng@huawei.com 1101 Alexandru Petrescu 1102 CEA, LIST 1103 CEA Saclay 1104 Gif-sur-Yvette, Ile-de-France 91190 1105 France 1107 Email: Alexandru.Petrescu@cea.fr 1109 Andrew Yourtchenko 1110 cisco 1111 7a de Kleetlaan 1112 Diegem 1830 1113 Belgium 1115 Email: ayourtch@cisco.com