doc: Add RFC documents

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]
+