diff options
Diffstat (limited to 'doc/rfc/rfc7421.txt')
| -rw-r--r-- | doc/rfc/rfc7421.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc7421.txt b/doc/rfc/rfc7421.txt new file mode 100644 index 0000000..dfcf4cd --- /dev/null +++ b/doc/rfc/rfc7421.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Carpenter, Ed. +Request for Comments: 7421 Univ. of Auckland +Category: Informational T. Chown +ISSN: 2070-1721 Univ. of Southampton + F. Gont + SI6 Networks / UTN-FRH + S. Jiang + Huawei Technologies Co., Ltd + A. Petrescu + CEA, LIST + A. Yourtchenko + Cisco + January 2015 + + + Analysis of the 64-bit Boundary in IPv6 Addressing + +Abstract + + The IPv6 unicast addressing format includes a separation between the + prefix used to route packets to a subnet and the interface identifier + used to specify a given interface connected to that subnet. + Currently, the interface identifier is defined as 64 bits long for + almost every case, leaving 64 bits for the subnet prefix. This + document describes the advantages of this fixed boundary and analyzes + the issues that would be involved in treating it as a variable + boundary. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7421. + + + + + + + + +Carpenter, et al. Informational [Page 1] + +RFC 7421 Why 64 January 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Advantages of a Fixed Identifier Length . . . . . . . . . . . 4 + 3. Arguments for Shorter Identifier Lengths . . . . . . . . . . 5 + 3.1. Insufficient Address Space Delegated . . . . . . . . . . 5 + 3.2. Hierarchical Addressing . . . . . . . . . . . . . . . . . 6 + 3.3. Audit Requirement . . . . . . . . . . . . . . . . . . . . 7 + 3.4. Concerns over ND Cache Exhaustion . . . . . . . . . . . . 7 + 4. Effects of Varying the Interface Identifier Length . . . . . 8 + 4.1. Interaction with IPv6 Specifications . . . . . . . . . . 8 + 4.2. Possible Failure Modes . . . . . . . . . . . . . . . . . 10 + 4.3. Experimental Observations . . . . . . . . . . . . . . . . 12 + 4.3.1. Survey of the processing of Neighbor Discovery + Options with Prefixes Other than /64 . . . . . . . . 12 + 4.3.2. Other Observations . . . . . . . . . . . . . . . . . 14 + 4.4. Implementation and Deployment Issues . . . . . . . . . . 14 + 4.5. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 16 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 6.2. Informative References . . . . . . . . . . . . . . . . . 21 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + + + + + + + + + + + + +Carpenter, et al. Informational [Page 2] + +RFC 7421 Why 64 January 2015 + + +1. Introduction + + Rather than simply overcoming the IPv4 address shortage by doubling + the address size to 64 bits, IPv6 addresses were originally chosen to + be 128 bits long to provide flexibility and new possibilities. In + particular, the notion of a well-defined interface identifier was + added to the IP addressing model. The IPv6 addressing architecture + [RFC4291] specifies that a unicast address is divided into n bits of + subnet prefix followed by (128-n) bits of interface identifier (IID). + The bits in the IID may have significance only in the process of + deriving the IID; once it is derived, the entire identifier should be + treated as an opaque value [RFC7136]. Also, since IPv6 routing is + entirely based on variable length prefixes (also known as variable + length subnet masks), there is no basic architectural assumption that + n has any particular fixed value. All IPv6 routing protocols support + prefixes of any length up to /128. + + The IID is of basic importance in the IPv6 stateless address + autoconfiguration (SLAAC) process [RFC4862]. However, it is + important to understand that its length is a parameter in the SLAAC + process, and it is determined in a separate link-type specific + document (see the definition of "interface identifier" in Section 2 + of RFC 4862). The SLAAC protocol does not define its length or + assume any particular length. Similarly, DHCPv6 [RFC3315] does not + include a prefix length in its address assignment. + + The notion of a /64 boundary in the address was introduced after the + initial design of IPv6, following a period when it was expected to be + at /80. There were two motivations for setting it at /64. One was + the original "8+8" proposal [ODELL] that eventually led to the + Identifier-Locator Network Protocol (ILNP) [RFC6741], which required + a fixed point for the split between local and wide-area parts of the + address. The other was the expectation that 64-bit Extended Unique + Identifier (EUI-64) Media Access Control (MAC) addresses would become + widespread in place of 48-bit addresses, coupled with the plan at + that time that auto-configured addresses would normally be based on + interface identifiers derived from MAC addresses. + + As a result, RFC 4291 describes a method of forming interface + identifiers from IEEE EUI-64 hardware addresses [IEEE802], and this + specifies that such interface identifiers are 64 bits long. Various + other methods of forming interface identifiers also specify a length + of 64 bits. The addressing architecture, as modified by [RFC7136], + states that: + + + + + + + +Carpenter, et al. Informational [Page 3] + +RFC 7421 Why 64 January 2015 + + + For all unicast addresses, except those that start with the binary + value 000, Interface IDs are required to be 64 bits long. If + derived from an IEEE MAC-layer address, they must be constructed + in Modified EUI-64 format. + + The de facto length of almost all IPv6 interface identifiers is + therefore 64 bits. The only documented exception is in [RFC6164], + which standardizes 127-bit prefixes for point-to-point links between + routers, among other things, to avoid a loop condition known as the + ping-pong problem. + + With that exception, and despite the comments above about the routing + architecture and the design of SLAAC, using an IID shorter than 64 + bits and a subnet prefix longer than 64 bits is outside the current + IPv6 specifications, so results may vary. + + The question is often asked why the subnet prefix boundary is set + rigidly at /64. The first purpose of this document is to explain the + advantages of the fixed IID length. Its second purpose is to + analyze, in some detail, the effects of hypothetically varying the + IID length. The fixed-length limits the practical length of a + routing prefix to 64 bits, whereas architecturally, and from the + point of view of routing protocols, it could be any value up to /128, + as in the case of host routes. Whatever the length of the IID, the + longest match is done on the concatenation of prefix and IID. Here, + we mainly discuss the question of a shorter IID, which would allow a + longer subnet prefix. The document makes no proposal for a change to + the IID length. + + The following three sections describe, in turn, the advantages of the + fixed-length IID, some arguments for shorter lengths, and the + expected effects of varying the length. + +2. Advantages of a Fixed Identifier Length + + As mentioned in Section 1, the existence of an IID of a given length + is a necessary part of IPv6 stateless address autoconfiguration + (SLAAC) [RFC4862]. This length is normally the same for all nodes on + a given link that is running SLAAC. Even though this length is a + parameter for SLAAC, determined separately for the link-layer media + type of each interface, a globally fixed IID length for all link- + layer media is the simplest solution and is consistent with the + principles of Internet host configuration described in [RFC5505]. + + An interface identifier of significant length, clearly separated from + the subnet prefix, makes it possible to limit the traceability of a + host computer by varying the identifier. This is discussed further + in Section 4.5. + + + +Carpenter, et al. Informational [Page 4] + +RFC 7421 Why 64 January 2015 + + + An interface identifier of significant length guarantees that there + are always enough addresses in any subnet to add one or more real or + virtual interfaces. There might be other limits, but IP addressing + will never get in the way. + + The addressing architecture [RFC4291] [RFC7136] sets the IID length + at 64 bits for all unicast addresses and therefore for all media + supporting SLAAC. An immediate effect of fixing the IID length at 64 + bits is, of course, that it fixes the subnet prefix length also at 64 + bits, regardless of the aggregate prefix assigned to the site + concerned, which in accordance with [RFC6177] should be /56 or + shorter. This situation has various specific advantages: + + o Everything is the same. Compared to IPv4, there is no more + calculating leaf subnet sizes, no more juggling between subnets, + and fewer consequent errors. Network design is therefore simpler + and much more straightforward. This is of importance for all + types of networks -- enterprise, campus, small office, or home + networks -- and for all types of operator, from professional to + consumer. + + o Adding a subnet is easy -- just take another /64 from the pool. + No estimates, calculations, consideration, or judgement is needed. + + o Router configurations are homogeneous and easier to understand. + + o Documentation is easier to write and easier to read; training is + easier. + + The remainder of this document describes arguments that have been + made against the current fixed IID length and analyzes the effects of + a possible change. However, the consensus of the IETF is that the + benefits of keeping the length fixed at 64 bits and the practical + difficulties of changing it outweigh the arguments for change. + +3. Arguments for Shorter Identifier Lengths + + In this section, we describe arguments for scenarios where shorter + IIDs, implying prefixes longer than /64, have been used or proposed. + +3.1. Insufficient Address Space Delegated + + A site may not be delegated a sufficiently generous prefix from which + to allocate a /64 prefix to all of its internal subnets. In this + case, the site may either determine that it does not have enough + address space to number all its network elements and thus, at the + very best, be only partially operational, or it may choose to use + + + + +Carpenter, et al. Informational [Page 5] + +RFC 7421 Why 64 January 2015 + + + internal prefixes longer than /64 to allow multiple subnets and the + hosts within them to be configured with addresses. + + In this case, the site might choose, for example, to use a /80 per + subnet in combination with hosts using either manually configured + addressing or DHCPv6 [RFC3315]. + + Scenarios that have been suggested where an insufficient prefix might + be delegated include home or small office networks, vehicles, + building services, and transportation services (e.g., road signs). + It should be noted that the homenet architecture text [RFC7368] + states that Customer Premises Equipment (CPE) should consider the + lack of sufficient address space to be an error condition, rather + than using prefixes longer than /64 internally. + + Another scenario occasionally suggested is one where the Internet + address registries actually begin to run out of IPv6 prefix space, + such that operators can no longer assign reasonable prefixes to users + in accordance with [RFC6177]. It is sometimes suggested that + assigning a prefix such as /48 or /56 to every user site (including + the smallest) as recommended by [RFC6177] is wasteful. In fact, the + currently released unicast address space, 2000::/3, contains 35 + trillion /48 prefixes ((2**45 = 35,184,372,088,832), of which only a + small fraction have been allocated. Allowing for a conservative + estimate of allocation efficiency, i.e., an HD-ratio of 0.94 + [RFC4692], approximately 5 trillion /48 prefixes can be allocated. + Even with a relaxed HD-ratio of 0.89, approximately one trillion /48 + prefixes can be allocated. Furthermore, with only 2000::/3 currently + committed for unicast addressing, we still have approximately 85% of + the address space in reserve. Thus, there is no objective risk of + prefix depletion by assigning /48 or /56 prefixes even to the + smallest sites. + +3.2. Hierarchical Addressing + + Some operators have argued that more prefix bits are needed to allow + an aggregated hierarchical addressing scheme within a campus or + corporate network. However, if a campus or enterprise gets a /48 + prefix (or shorter), then that already provides 16 bits for + hierarchical allocation. In any case, flat IGP routing is widely and + successfully used within rather large networks, with hundreds of + routers and thousands of end systems. Therefore, there is no + objective need for additional prefix bits to support hierarchy and + aggregation within enterprises. + + + + + + + +Carpenter, et al. Informational [Page 6] + +RFC 7421 Why 64 January 2015 + + +3.3. Audit Requirement + + Some network operators wish to know and audit nodes that are active + on a network, especially those that are allowed to communicate off- + link or off-site. They may also wish to limit the total number of + active addresses and sessions that can be sourced from a particular + host, LAN, or site, in order to prevent potential resource-depletion + attacks or other problems spreading beyond a certain scope of + control. It has been argued that this type of control would be + easier if only long network prefixes with relatively small numbers of + possible hosts per network were used, reducing the discovery problem. + However, such sites most typically operate using DHCPv6, which means + that all legitimate hosts are automatically known to the DHCPv6 + servers, which is sufficient for audit purposes. Such hosts could, + if desired, be limited to a small range of IID values without + changing the /64 subnet length. Any hosts inadvertently obtaining + addresses via SLAAC can be audited through Neighbor Discovery (ND) + logs. + +3.4. Concerns over ND Cache Exhaustion + + A site may be concerned that it is open to ND cache exhaustion + attacks [RFC3756], whereby an attacker sends a large number of + messages in rapid succession to a series of (most likely inactive) + host addresses within a specific subnet. Such an attack attempts to + fill a router's ND cache with ND requests pending completion, which + results in denying correct operation to active devices on the + network. + + One potential way to mitigate this attack would be to consider using + a /120 prefix, thus limiting the number of addresses in the subnet to + be similar to an IPv4 /24 prefix, which should not cause any concerns + for ND cache exhaustion. Note that the prefix does need to be quite + long for this scenario to be valid. The number of theoretically + possible ND cache slots on the segment needs to be of the same order + of magnitude as the actual number of hosts. Thus, small increases + from the /64 prefix length do not have a noticeable impact; even 2^32 + potential entries, a factor of two billion decrease compared to 2^64, + is still more than enough to exhaust the memory on current routers. + Given that most link-layer mappings cause SLAAC to assume a 64-bit + network boundary, in such an approach hosts would likely need to use + DHCPv6 or be manually configured with addresses. + + It should be noted that several other mitigations of the ND cache + attack are described in [RFC6583], and that limiting the size of the + cache and the number of incomplete entries allowed would also defeat + the attack. For the specific case of a point-to-point link between + routers, this attack is indeed mitigated by a /127 prefix [RFC6164]. + + + +Carpenter, et al. Informational [Page 7] + +RFC 7421 Why 64 January 2015 + + +4. Effects of Varying the Interface Identifier Length + + This section of the document analyzes the impact and effects of + varying the length of an IPv6 unicast IID by reducing it to less than + 64 bits. + +4.1. Interaction with IPv6 Specifications + + The precise 64-bit length of the IID is widely mentioned in numerous + RFCs describing various aspects of IPv6. It is not straightforward + to distinguish cases where this has normative impact or affects + interoperability. This section aims to identify specifications that + contain an explicit reference to the 64-bit length. Regardless of + implementation issues, the RFCs themselves would all need to be + updated if the 64-bit rule was changed, even if the updates were + small, which would involve considerable time and effort. + + First and foremost, the RFCs describing the architectural aspects of + IPv6 addressing explicitly state, refer, and repeat this apparently + immutable value: Addressing Architecture [RFC4291], IPv6 Address + Assignment to End Sites [RFC6177], Reserved IIDs [RFC5453], and ILNP + Node Identifiers [RFC6741]. Customer edge routers impose /64 for + their interfaces [RFC7084]. The IPv6 Subnet Model [RFC5942] points + out that the assumption of a /64 prefix length is a potential + implementation error. + + Numerous IPv6-over-foo documents make mandatory statements with + respect to the 64-bit length of the IID to be used during the + Stateless Autoconfiguration. These documents include [RFC2464] + (Ethernet), [RFC2467] (Fiber Distributed Data Interface (FDDI)), + [RFC2470] (Token Ring), [RFC2492] (ATM), [RFC2497] (ARCnet), + [RFC2590] (Frame Relay), [RFC3146] (IEEE 1394), [RFC4338] (Fibre + Channel), [RFC4944] (IEEE 802.15.4), [RFC5072] (PPP), [RFC5121] + [RFC5692] (IEEE 802.16), [RFC2529] (6over4), [RFC5214] (Intra-Site + Automatic Tunnel Addressing Protocol (ISATAP)), [AERO-TRANS] + (Asymmetric Extended Route Optimization (AERO)), [BLUETOOTH-LE] + (BLUETOOTH Low Energy), [IPv6-TRANS] (IPv6 over MS/TP), and + [IPv6-G9959] (IPv6 packets over ITU-T G.9959). + + To a lesser extent, the address configuration RFCs themselves may in + some ways assume the 64-bit length of an IID (e.g, RFC 4862 for the + link-local addresses, DHCPv6 for the potentially assigned EUI- + 64-based IP addresses, and Optimistic Duplicate Address Detection + [RFC4429] that computes 64-bit-based collision probabilities). + + The Multicast Listener Discovery Version 1 (MLDv1) [RFC2710] and + MLDv2 [RFC3810] protocols mandate that all queries be sent with a + link-local source address, with the exception of MLD messages sent + + + +Carpenter, et al. Informational [Page 8] + +RFC 7421 Why 64 January 2015 + + + using the unspecified address when the link-local address is + tentative [RFC3590]. At the time of publication of RFC 2710, the + IPv6 addressing architecture specified link-local addresses with + 64-bit interface identifiers. MLDv2 explicitly specifies the use of + the fe80::/64 link-local prefix and bases the querier election + algorithm on the link-local subnet prefix of length /64. + + The "IPv6 Flow Label Specification" [RFC6437] gives an example of a + 20-bit hash function generation, which relies on splitting an IPv6 + address in two equally sized, 64-bit-length parts. + + The basic transition mechanisms [RFC4213] refer to IIDs of length 64 + for link-local addresses; other transition mechanisms such as Teredo + [RFC4380] assume the use of IIDs of length 64. Similar assumptions + are found in 6to4 [RFC3056] and 6rd [RFC5969]. Translation-based + transition mechanisms such as NAT64 and NPTv6 have some dependency on + prefix length, discussed below. + + The proposed method [RFC7278] of extending an assigned /64 prefix + from a smartphone's cellular interface to its WiFi link relies on + prefix length, and implicitly on the length of the IID, to be valued + at 64. + + The Cryptographically Generated Addresses (CGA) and Hash-Based + Addresses (HBA) specifications rely on the 64-bit identifier length + (see below), as do the Privacy extensions [RFC4941] and some examples + in "Internet Key Exchange Version 2 (IKEv2)" [RFC7296]. + + 464XLAT [RFC6877] explicitly mentions acquiring /64 prefixes. + However, it also discusses the possibility of using the interface + address on the device as the end point for the traffic, thus + potentially removing this dependency. + + [RFC2526] reserves a number of subnet anycast addresses by reserving + some anycast IIDs. An anycast IID so reserved cannot be less than 7 + bits long. This means that a subnet prefix length longer than /121 + is not possible, and a subnet of exactly /121 would be useless since + all its identifiers are reserved. It also means that half of a /120 + is reserved for anycast. This could of course be fixed in the way + described for /127 in [RFC6164], i.e., avoiding the use of anycast + within a /120 subnet. Note that support for "on-link anycast" is a + standard IPv6 neighbor discovery capability [RFC4861] [RFC7094]; + therefore, applications and their developers would expect it to be + available. + + The Mobile IP home network models [RFC4887] rely heavily on the /64 + subnet length and assume a 64-bit IID. + + + + +Carpenter, et al. Informational [Page 9] + +RFC 7421 Why 64 January 2015 + + + While preparing this document, it was noted that many other IPv6 + specifications refer to mandatory alignment on 64-bit boundaries, + 64-bit data structures, 64-bit counters in MIBs, 64-bit sequence + numbers and cookies in security, etc. Finally, the number "64" may + be considered "magic" in some RFCs, e.g., 64k limits in DNS and + Base64 encodings in MIME. None of this has any influence on the + length of the IID but might confuse a careless reader. + +4.2. Possible Failure Modes + + This section discusses several specific aspects of IPv6 where we can + expect operational failures with subnet prefixes other than /64. + + o Router implementations: Router implementors might interpret IETF + specifications such as [RFC6164] and [RFC7136] as indicating that + prefixes between /65 and /126 (inclusive) for unicast packets on- + the-wire are invalid and that operational practices that utilize + prefix lengths in this range may fail on some devices, as + discussed in Section 4.3.2. + + o Multicast: [RFC3306] defines a method for generating IPv6 + multicast group addresses based on unicast prefixes. This method + assumes a longest prefix of 64 bits. If a longer prefix is used, + there is no way to generate a specific multicast group address + using this method. In such cases, the administrator would need to + use an "artificial" prefix from within their allocation (a /64 or + shorter) from which to generate the group address. This prefix + would not correspond to a real subnet. + + Similarly, [RFC3956], which specifies the Embedded Rendezvous + Point (RP)) allowing IPv6 multicast rendezvous point addresses to + be embedded in the multicast group address, would also fail, as + the scheme assumes a maximum prefix length of 64 bits. + + o CGA: The Cryptographically Generated Address format [RFC3972] is + heavily based on a /64 interface identifier. [RFC3972] has + defined a detailed algorithm showing how to generate a 64-bit + interface identifier from a public key and a 64-bit subnet prefix. + Changing the /64 boundary would certainly invalidate the current + CGA definition. However, the CGA might benefit in a redefined + version if more bits are used for interface identifiers (which + means shorter prefix length). For now, 59 bits are used for + cryptographic purposes. The more bits are available, the stronger + CGA could be. Conversely, longer prefixes would weaken CGA. + + o NAT64: Both stateless NAT64 [RFC6052] and stateful NAT64 [RFC6146] + are flexible for the prefix length. [RFC6052] has defined + multiple address formats for NAT64. In Section 2 of + + + +Carpenter, et al. Informational [Page 10] + +RFC 7421 Why 64 January 2015 + + + "IPv4-Embedded IPv6 Address Prefix and Format" [RFC6052], the + network-specific prefix could be one of /32, /40, /48, /56, /64, + and /96. The remaining part of the IPv6 address is constructed by + a 32-bit IPv4 address, an 8-bit u byte and a variable length + suffix (there is no u byte and suffix in the case of the 96-bit + Well-Known Prefix). NAT64 is therefore OK with a subnet boundary + out to /96 but not longer. + + o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296] is also + bound to /64 boundary. NPTv6 maps a /64 prefix to another /64 + prefix. When the NPTv6 Translator is configured with a /48 or + shorter prefix, the 64-bit interface identifier is kept unmodified + during translation. However, the /64 boundary might be changed as + long as the "inside" and "outside" prefixes have the same length. + + o ILNP: Identifier-Locator Network Protocol (ILNP) [RFC6741] is + designed around the /64 boundary, since it relies on locally + unique 64-bit node identifiers (in the interface identifier + field). While a redesign to use longer prefixes is not + inconceivable, this would need major changes to the existing + specification for the IPv6 version of ILNP. + + o Shim6: The Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] in + its insecure form treats IPv6 addresses as opaque 128-bit objects. + However, to secure the protocol against spoofing, it is essential + to either use CGAs (see above) or HBAs [RFC5535]. Like CGAs, HBAs + are generated using a procedure that assumes a 64-bit identifier. + Therefore, in effect, secure shim6 is affected by the /64 boundary + exactly like CGAs. + + o Duplicate address risk: If SLAAC was modified to work with shorter + IIDs, the statistical risk of hosts choosing the same pseudo- + random identifier [RFC7217] would increase correspondingly. The + practical impact of this would range from slight to dramatic, + depending on how much the IID length was reduced. In particular, + a /120 prefix would imply an 8-bit IID and address collisions + would be highly probable. + + o The link-local prefix: While RFC 4862 is careful not to define any + specific length of link-local prefix within fe80::/10, the + addressing architecture [RFC4291] does define the link-local IID + length to be 64 bits. If different hosts on a link used IIDs of + different lengths to form a link-local address, there is potential + for confusion and unpredictable results. Typically today the + choice of 64 bits for the link-local IID length is hard-coded per + interface, in accordance with the relevant IPv6-over-foo + specification, and systems behave as if the link-local prefix was + actually fe80::/64. There might be no way to change this except + + + +Carpenter, et al. Informational [Page 11] + +RFC 7421 Why 64 January 2015 + + + conceivably by manual configuration, which will be impossible if + the host concerned has no local user interface. + + It goes without saying that if prefixes longer than /64 are to be + used, all hosts must be capable of generating IIDs shorter than 64 + bits, in order to follow the auto-configuration procedure correctly + [RFC4862]. + +4.3. Experimental Observations + +4.3.1. Survey of the processing of Neighbor Discovery Options with + Prefixes Other than /64 + + This section provides a survey of the processing of Neighbor + Discovery options that include prefixes that are different than /64. + + The behavior of nodes was assessed with respect to the following + options: + + o PIO-A: Prefix Information Option (PIO) [RFC4861] with the A bit + set. + + o PIO-L: Prefix Information Option (PIO) [RFC4861] with the L bit + set. + + o PIO-AL: Prefix Information Option (PIO) [RFC4861] with both the A + and L bits set. + + o RIO: Route Information Option (RIO) [RFC4191]. + + In the tables below, the following notation is used: + + NOT-SUP: + This option is not supported (i.e., it is ignored no matter the + prefix length used). + + LOCAL: + The corresponding prefix is considered "on-link". + + ROUTE: + The corresponding route is added to the IPv6 routing table. + + NOT-DEF: + The default configuration is NOT-SUP, but there is an option to + enable ROUTE. + + IGNORE: + The option is ignored as an error. + + + +Carpenter, et al. Informational [Page 12] + +RFC 7421 Why 64 January 2015 + + + +--------------------+--------+-------+--------+---------+ + | Operating System | PIO-A | PIO-L | PIO-AL | RIO | + +--------------------+--------+-------+--------+---------+ + | FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP | + +--------------------+--------+-------+--------+---------+ + | Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF | + +--------------------+--------+-------+--------+---------+ + | Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF | + +--------------------+--------+-------+--------+---------+ + | NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP | + +--------------------+--------+-------+--------+---------+ + | OpenBSD-current | IGNORE | LOCAL | LOCAL | NOT-SUP | + +--------------------+--------+-------+--------+---------+ + | Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE | + +--------------------+--------+-------+--------+---------+ + | Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE | + +--------------------+--------+-------+--------+---------+ + + Table 1: Processing of ND options with prefixes longer than /64 + + +--------------------+--------+-------+--------+---------+ + | Operating System | PIO-A | PIO-L | PIO-AL | RIO | + +--------------------+--------+-------+--------+---------+ + | FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP | + +--------------------+--------+-------+--------+---------+ + | Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF | + +--------------------+--------+-------+--------+---------+ + | Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF | + +--------------------+--------+-------+--------+---------+ + | NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP | + +--------------------+--------+-------+--------+---------+ + | OpenBSD-current | IGNORE | LOCAL | LOCAL | NOT-SUP | + +--------------------+--------+-------+--------+---------+ + | Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE | + +--------------------+--------+-------+--------+---------+ + | Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE | + +--------------------+--------+-------+--------+---------+ + + Table 2: Processing of ND options with prefixes shorter than /64 + + The results obtained can be summarized as follows: + + o The "A" bit in the Prefix Information Options is honored only if + the prefix length is 64. This is consistent with [RFC4862], at + least for the case where the IID length is defined to be 64 bits + in the corresponding link-type-specific document, which is the + + + + + +Carpenter, et al. Informational [Page 13] + +RFC 7421 Why 64 January 2015 + + + case for all currently published such documents. [RFC4862] + defines the case where the sum of the advertised prefix length and + the IID length does not equal 128 as an error condition. + + o The "L" bit in the Prefix Information Options is honored for any + arbitrary prefix length (whether shorter or longer than /64). + + o Nodes that support the Route Information Option allow such routes + to be specified with prefixes of any arbitrary length (whether + shorter or longer than /64) + +4.3.2. Other Observations + + Participants in the V6OPS working group have indicated that some + forwarding devices have been shown to work correctly with long + prefixes such as /80 or /96. Indeed, it is to be expected that + forwarding based on the longest prefix match will work for any prefix + length, and no reports of this completely failing have been noted. + Also, DHCPv6 is in widespread use without any dependency on the /64 + boundary. Reportedly, there are deployments of /120 subnets + configured using DHCPv6. + + There have been definite reports that some routers have a performance + drop-off or even resource exhaustion for prefixes longer than /64 due + to design issues. In particular, some routing chip designs allocate + much less space for longer prefixes than for prefixes up to /64 for + the sake of savings in memory, power, and lookup latency. Some + devices need special-case code to handle point-to-point links + according to [RFC6164]. + + It has been reported that at least one type of switch has a content- + addressable memory limited to 144 bits, which is indeed a typical + value for commodity components [TCAM]. This means that packet + filters or access control lists cannot be defined based on 128-bit + addresses and two 16-bit port numbers; the longest prefix that could + be used in such a filter is a /112. + +4.4. Implementation and Deployment Issues + + From an early stage, implementations and deployments of IPv6 assumed + the /64 subnet length, even though routing was based on prefixes of + any length. As shown above, this became anchored in many + specifications (Section 4.1) and in important aspects of + implementations commonly used in local area networks (Section 4.3). + In fact, a programmer might be lulled into assuming a comfortable + rule of thumb that subnet prefixes are always /64 and an IID is + always of length 64. Apart from the limited evidence in + Section 4.3.1, we cannot tell without code inspections or tests + + + +Carpenter, et al. Informational [Page 14] + +RFC 7421 Why 64 January 2015 + + + whether existing stacks are able to handle a flexible IID length or + whether they would require modification to do so. A conforming + implementation of an IPv6-over-foo that specifies a 64 bit IID for + foo links will of course only support 64. But in a well designed + stack, the IP layer itself will treat that 64 as a parameter, so + changing the IID length in the IPv6-over-foo code should be all that + is necessary. + + The main practical consequence of the existing specifications is that + deployments in which longer subnet prefixes are used cannot make use + of SLAAC-configured addresses and require either manually configured + addresses or DHCPv6. To reverse this argument, if it was considered + desirable to allow auto-configured addresses with subnet prefixes + longer than /64, all of the specifications identified above as + depending on /64 would have to be modified with due regard to + interoperability with unmodified stacks. In fact, [RFC7217] allows + for this possibility. Then, modified stacks would have to be + developed and deployed. It might be the case that some stacks + contain dependencies on the /64 boundary that are not directly + implied by the specifications, and any such hidden dependencies would + also need to be found and removed. + + At least one DHCPv6 client unconditionally installs a /64 prefix as + on-link when it configures an interface with an address, although + some specific operating system vendors seem to change this default + behavior by tweaking a client-side script. This is in clear + violation of the IPv6 subnet model [RFC5942]. The motivation for + this choice is that if there is no router on the link, the hosts + would fail to communicate with each other using the configured + addresses because the "on-link assumption" was removed in [RFC4861]. + This is not really about the magic number of 64, but an + implementation may sometimes pick an arbitrary value of prefix length + due to the removal of the on-link assumption, and the value chosen + will most likely be 64. + + Typical IP Address Management (IPAM) tools treat /64 as the default + subnet length but allow users to specify longer subnet prefixes if + desired. Clearly, all IPAM tools and network management systems + would need to be checked in detail. + + Finally, IPv6 is already deployed at many sites, with a large number + of staff trained on the basis of the existing standards, supported by + documentation and tools based on those standards. Numerous existing + middlebox devices are also based on those standards. These people, + documents, tools, and devices represent a very large investment that + would be seriously impacted by a change in the /64 boundary. + + + + + +Carpenter, et al. Informational [Page 15] + +RFC 7421 Why 64 January 2015 + + +4.5. Privacy Issues + + The length of the interface identifier has implications for privacy + [ADDRESS-PRIVACY]. In any case in which the value of the identifier + is intended to be hard to guess, whether or not it is + cryptographically generated, it is apparent that more bits are + better. For example, if there are only 20 bits to be guessed, then + at most just over a million guesses are needed, which is well within + the capacity of a low-cost attack mechanism. It is hard to state in + general how many bits are enough to protect privacy, since this + depends on the resources available to the attacker, but it seems + clear that a privacy solution needs to resist an attack requiring + billions rather than millions of guesses. Trillions would be better, + suggesting that at least 40 bits should be available. Thus, we can + argue that subnet prefixes longer than say /80 might raise privacy + concerns by making the IID guessable. + + A prefix long enough to limit the number of addresses comparably to + an IPv4 subnet, such as /120, would create exactly the same situation + for privacy as IPv4 except for the absence of NAT. In particular, a + host would be forced to pick a new IID when roaming to a new network + to avoid collisions. As mentioned earlier, it is likely that SLAAC + will not be used on such a subnet. + +5. Security Considerations + + In addition to the privacy issues mentioned in Section 4.5 and the + issues mentioned with CGAs and HBAs in Section 4.2, the length of the + subnet prefix affects the matter of defense against scanning attacks + [HOST-SCANNING]. Assuming the attacker has discovered or guessed the + prefix length, a longer prefix reduces the space that the attacker + needs to scan, e.g., to only 256 addresses if the prefix is /120. On + the other hand, if the attacker has not discovered the prefix length + and assumes it to be /64, routers can trivially discard attack + packets that do not fall within an actual subnet. + + However, assume that an attacker finds one valid address "A" and + assumes that it is within a long prefix such as a /120. The attacker + then starts a scanning attack by scanning "outwards" from A, by + trying A+1, A-1, A+2, A-2, etc. This attacker will easily find all + hosts in any subnet with a long prefix, because they will have + addresses close to A. We therefore conclude that any prefix + containing densely packed valid addresses is vulnerable to a scanning + attack, without the attacker needing to guess the prefix length. + Therefore, to preserve IPv6's advantage over IPv4 in resisting + scanning attacks, it is important that subnet prefixes are short + enough to allow sparse allocation of identifiers within each subnet. + The considerations are similar to those for privacy, and we can again + + + +Carpenter, et al. Informational [Page 16] + +RFC 7421 Why 64 January 2015 + + + argue that prefixes longer than say /80 might significantly increase + vulnerability. Ironically, this argument is exactly converse to the + argument for longer prefixes to resist an ND cache attack, as + described in Section 3.4. + + Denial-of-service attacks related to Neighbor Discovery are discussed + in Section 3.4 and in [RFC6583]. One of the mitigations suggested by + that document is "sizing subnets to reflect the number of addresses + actually in use", but the fact that this greatly simplifies scanning + attacks is not noted. For further discussion of scanning attacks, + see [HOST-SCANNING]. + + Note that, although not known at the time of writing, there might be + other resource exhaustion attacks available, similar in nature to the + ND cache attack. We cannot exclude that such attacks might be + exacerbated by sparsely populated subnets such as a /64. It should + also be noted that this analysis assumes a conventional deployment + model with a significant number of end-systems located in a single + LAN broadcast domain. Other deployment models might lead to + different conclusions. + +6. References + +6.1. Normative References + + [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet + Networks", RFC 2464, December 1998, + <http://www.rfc-editor.org/info/rfc2464>. + + [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI + Networks", RFC 2467, December 1998, + <http://www.rfc-editor.org/info/rfc2467>. + + [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of + IPv6 Packets over Token Ring Networks", RFC 2470, December + 1998, <http://www.rfc-editor.org/info/rfc2470>. + + [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM + Networks", RFC 2492, January 1999, + <http://www.rfc-editor.org/info/rfc2492>. + + [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet + Networks", RFC 2497, January 1999, + <http://www.rfc-editor.org/info/rfc2497>. + + [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast + Addresses", RFC 2526, March 1999, + <http://www.rfc-editor.org/info/rfc2526>. + + + +Carpenter, et al. Informational [Page 17] + +RFC 7421 Why 64 January 2015 + + + [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 + Domains without Explicit Tunnels", RFC 2529, March 1999, + <http://www.rfc-editor.org/info/rfc2529>. + + [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of + IPv6 Packets over Frame Relay Networks Specification", RFC + 2590, May 1999, <http://www.rfc-editor.org/info/rfc2590>. + + [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999, <http://www.rfc-editor.org/info/rfc2710>. + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001, + <http://www.rfc-editor.org/info/rfc3056>. + + [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets + over IEEE 1394 Networks", RFC 3146, October 2001, + <http://www.rfc-editor.org/info/rfc3146>. + + [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 + Multicast Addresses", RFC 3306, August 2002, + <http://www.rfc-editor.org/info/rfc3306>. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003, + <http://www.rfc-editor.org/info/rfc3315>. + + [RFC3590] Haberman, B., "Source Address Selection for the Multicast + Listener Discovery (MLD) Protocol", RFC 3590, September + 2003, <http://www.rfc-editor.org/info/rfc3590>. + + [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004, + <http://www.rfc-editor.org/info/rfc3810>. + + [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous + Point (RP) Address in an IPv6 Multicast Address", RFC + 3956, November 2004, + <http://www.rfc-editor.org/info/rfc3956>. + + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, March 2005, + <http://www.rfc-editor.org/info/rfc3972>. + + + + + + +Carpenter, et al. Informational [Page 18] + +RFC 7421 Why 64 January 2015 + + + [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and + More-Specific Routes", RFC 4191, November 2005, + <http://www.rfc-editor.org/info/rfc4191>. + + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms + for IPv6 Hosts and Routers", RFC 4213, October 2005, + <http://www.rfc-editor.org/info/rfc4213>. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006, + <http://www.rfc-editor.org/info/rfc4291>. + + [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of + IPv6, IPv4, and Address Resolution Protocol (ARP) Packets + over Fibre Channel", RFC 4338, January 2006, + <http://www.rfc-editor.org/info/rfc4338>. + + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, February + 2006, <http://www.rfc-editor.org/info/rfc4380>. + + [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) + for IPv6", RFC 4429, April 2006, + <http://www.rfc-editor.org/info/rfc4429>. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + September 2007, <http://www.rfc-editor.org/info/rfc4861>. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, September 2007, + <http://www.rfc-editor.org/info/rfc4862>. + + [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy + Extensions for Stateless Address Autoconfiguration in + IPv6", RFC 4941, September 2007, + <http://www.rfc-editor.org/info/rfc4941>. + + [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, + "Transmission of IPv6 Packets over IEEE 802.15.4 + Networks", RFC 4944, September 2007, + <http://www.rfc-editor.org/info/rfc4944>. + + [RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over + PPP", RFC 5072, September 2007, + <http://www.rfc-editor.org/info/rfc5072>. + + + + + +Carpenter, et al. Informational [Page 19] + +RFC 7421 Why 64 January 2015 + + + [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. + Madanapalli, "Transmission of IPv6 via the IPv6 + Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, + February 2008, <http://www.rfc-editor.org/info/rfc5121>. + + [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site + Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, + March 2008, <http://www.rfc-editor.org/info/rfc5214>. + + [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC + 5453, February 2009, + <http://www.rfc-editor.org/info/rfc5453>. + + [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming + Shim Protocol for IPv6", RFC 5533, June 2009, + <http://www.rfc-editor.org/info/rfc5533>. + + [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June + 2009, <http://www.rfc-editor.org/info/rfc5535>. + + [RFC5692] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP + over Ethernet over IEEE 802.16 Networks", RFC 5692, + October 2009, <http://www.rfc-editor.org/info/rfc5692>. + + [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet + Model: The Relationship between Links and Subnet + Prefixes", RFC 5942, July 2010, + <http://www.rfc-editor.org/info/rfc5942>. + + [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 + Infrastructures (6rd) -- Protocol Specification", RFC + 5969, August 2010, + <http://www.rfc-editor.org/info/rfc5969>. + + [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. + Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, + October 2010, <http://www.rfc-editor.org/info/rfc6052>. + + [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from IPv6 + Clients to IPv4 Servers", RFC 6146, April 2011, + <http://rfc-editor.org/info/rfc6146>. + + [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, + L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- + Router Links", RFC 6164, April 2011, + <http://www.rfc-editor.org/info/rfc6164>. + + + + +Carpenter, et al. Informational [Page 20] + +RFC 7421 Why 64 January 2015 + + + [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address + Assignment to End Sites", BCP 157, RFC 6177, March 2011, + <http://www.rfc-editor.org/info/rfc6177>. + + [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix + Translation", RFC 6296, June 2011, + <http://www.rfc-editor.org/info/rfc6296>. + + [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, + "IPv6 Flow Label Specification", RFC 6437, November 2011, + <http://www.rfc-editor.org/info/rfc6437>. + + [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic + Requirements for IPv6 Customer Edge Routers", RFC 7084, + November 2013, <http://www.rfc-editor.org/info/rfc7084>. + + [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 + Interface Identifiers", RFC 7136, February 2014, + <http://www.rfc-editor.org/info/rfc7136>. + + [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. + Kivinen, "Internet Key Exchange Protocol Version 2 + (IKEv2)", STD 79, RFC 7296, October 2014, + <http://www.rfc-editor.org/info/rfc7296>. + +6.2. Informative References + + [ADDRESS-PRIVACY] + Cooper, A., Gont, F., and D. Thaler, "Privacy + Considerations for IPv6 Address Generation Mechanisms", + Work in Progress, draft-ietf-6man-ipv6-address-generation- + privacy-02, October 2014. + + [AERO-TRANS] + Templin, F., "Transmission of IP Packets over AERO Links", + Work in Progress, draft-templin-aerolink-46, October 2014. + + [BLUETOOTH-LE] + Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., + Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets + over BLUETOOTH Low Energy", Work in Progress, draft-ietf- + 6lowpan-btle-12, February 2013. + + [HOST-SCANNING] + Gont, F. and T. Chown, "Network Reconnaissance in IPv6 + Networks", Work in Progress, draft-ietf-opsec-ipv6-host- + scanning-04, June 2014. + + + + +Carpenter, et al. Informational [Page 21] + +RFC 7421 Why 64 January 2015 + + + [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area + Networks: Overview and Architecture", IEEE Std 802-2001 + (R2007), 2007. + + [IPv6-G9959] + Brandt, A. and J. Buron, "Transmission of IPv6 packets + over ITU-T G.9959 Networks", Work in Progress, draft-ietf- + 6lo-lowpanz-08, October 2014. + + [IPv6-TRANS] + Lynn, K., Ed., Martocci, J., Neilson, C., and S. + Donaldson, "Transmission of IPv6 over MS/TP Networks", + Work in Progress, draft-ietf-6lo-6lobac-00, July 2014. + + [ODELL] O'Dell, M., "8+8 - An Alternate Addressing Architecture + for IPv6", Work in Progress, draft-odell-8+8-00, October + 1996. + + [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, + June 1999, <http://www.rfc-editor.org/info/rfc2629>. + + [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor + Discovery (ND) Trust Models and Threats", RFC 3756, May + 2004, <http://www.rfc-editor.org/info/rfc3756>. + + [RFC4692] Huston, G., "Considerations on the IPv6 Host Density + Metric", RFC 4692, October 2006, + <http://www.rfc-editor.org/info/rfc4692>. + + [RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network + Mobility Home Network Models", RFC 4887, July 2007, + <http://www.rfc-editor.org/info/rfc4887>. + + [RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, + "Principles of Internet Host Configuration", RFC 5505, May + 2009, <http://www.rfc-editor.org/info/rfc5505>. + + [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational + Neighbor Discovery Problems", RFC 6583, March 2012, + <http://rfc-editor.org/info/rfc6583>. + + [RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol + (ILNP) Engineering Considerations", RFC 6741, November + 2012, <http://www.rfc-editor.org/info/rfc6741>. + + + + + + + +Carpenter, et al. Informational [Page 22] + +RFC 7421 Why 64 January 2015 + + + [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: + Combination of Stateful and Stateless Translation", RFC + 6877, April 2013, + <http://www.rfc-editor.org/info/rfc6877>. + + [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, + "Architectural Considerations of IP Anycast", RFC 7094, + January 2014, <http://www.rfc-editor.org/info/rfc7094>. + + [RFC7217] Gont, F., "A Method for Generating Semantically Opaque + Interface Identifiers with IPv6 Stateless Address + Autoconfiguration (SLAAC)", RFC 7217, April 2014, + <http://www.rfc-editor.org/info/rfc7217>. + + [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 + /64 Prefix from a Third Generation Partnership Project + (3GPP) Mobile Interface to a LAN Link", RFC 7278, June + 2014, <http://www.rfc-editor.org/info/rfc7278>. + + [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. + Weil, "IPv6 Home Networking Architecture Principles", RFC, + 7368, October 2014. + + [TCAM] Meiners, C., Liu, A., and E. Torng, "Algorithmic + Approaches to Redesigning TCAM-Based Systems", ACM + SIGMETRICS'08 467-468, 2008. + +Acknowledgements + + This document was inspired by a vigorous discussion on the V6OPS + working group mailing list with at least 20 participants. Later, + valuable comments were received from Ran Atkinson, Fred Baker, Steven + Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter, + Paraskevi Iliadou, Jen Linkova, Philip Matthews, Matthew Petach, + Scott Schmit, Tatuya Jinmei, Fred Templin, Ole Troan, Stig Venaas, + and numerous other participants in the 6MAN working group. An + extremely detailed review by Mark Smith was especially helpful. + + This document was originally produced using the xml2rfc tool + [RFC2629]. + + + + + + + + + + + +Carpenter, et al. Informational [Page 23] + +RFC 7421 Why 64 January 2015 + + +Authors' Addresses + + Brian Carpenter (editor) + Department of Computer Science + University of Auckland + PB 92019 + Auckland 1142 + New Zealand + EMail: brian.e.carpenter@gmail.com + + Tim Chown + University of Southampton + Southampton, Hampshire SO17 1BJ + United Kingdom + EMail: tjc@ecs.soton.ac.uk + + Fernando Gont + SI6 Networks / UTN-FRH + Evaristo Carriego 2644 + Haedo, Provincia de Buenos Aires 1706 + Argentina + EMail: fgont@si6networks.com + + Sheng Jiang + Huawei Technologies Co., Ltd + Q14, Huawei Campus + No.156 Beiqing Road + Hai-Dian District, Beijing 100095 + P.R. China + EMail: jiangsheng@huawei.com + + Alexandru Petrescu + CEA, LIST + CEA Saclay + Gif-sur-Yvette, Ile-de-France 91190 + France + EMail: Alexandru.Petrescu@cea.fr + + Andrew Yourtchenko + Cisco + 7a de Kleetlaan + Diegem 1830 + Belgium + EMail: ayourtch@cisco.com + + + + + + + +Carpenter, et al. Informational [Page 24] + |