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