One document matched: draft-ietf-6man-why64-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->
<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
(which supports the latest, sometimes undocumented and under-tested, features.) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- You need one entry like the following for each RFC referenced -->
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC2460 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC4291 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC5453 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5453.xml">
<!ENTITY RFC4941 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml">
<!ENTITY RFC7042 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7042.xml">
<!ENTITY RFC6741 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6741.xml">
<!ENTITY RFC5157 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5157.xml">
<!ENTITY RFC5533 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5533.xml">
<!ENTITY RFC5535 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5535.xml">
<!ENTITY RFC6296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6296.xml">
<!ENTITY RFC6164 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6164.xml">
<!ENTITY RFC6146 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6146.xml">
<!ENTITY RFC6052 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml">
<!ENTITY RFC3972 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY RFC4291 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC6741 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6741.xml">
<!ENTITY RFC7084 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7084.xml">
<!ENTITY RFC5942 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5942.xml">
<!ENTITY RFC2464 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2464.xml">
<!ENTITY RFC2467 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2467.xml">
<!ENTITY RFC2470 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2470.xml">
<!ENTITY RFC2492 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2492.xml">
<!ENTITY RFC2497 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2497.xml">
<!ENTITY RFC2590 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2590.xml">
<!ENTITY RFC3146 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3146.xml">
<!ENTITY RFC4338 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4338.xml">
<!ENTITY RFC4944 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC5072 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5072.xml">
<!ENTITY RFC5121 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5121.xml">
<!ENTITY RFC5692 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5692.xml">
<!ENTITY RFC4191 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml">
<!ENTITY RFC4429 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4429.xml">
<!ENTITY RFC3810 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3810.xml">
<!ENTITY RFC6437 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6437.xml">
<!ENTITY RFC6877 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6877.xml">
<!ENTITY RFC3306 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3306.xml">
<!ENTITY RFC3956 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3956.xml">
<!ENTITY RFC4861 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC2526 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2526.xml">
<!ENTITY RFC6583 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6583.xml">
<!ENTITY RFC5214 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5214.xml">
<!ENTITY RFC4213 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4213.xml">
<!ENTITY RFC4380 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml">
<!ENTITY RFC2529 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2529.xml">
<!ENTITY RFC3056 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!ENTITY RFC5969 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969.xml">
<!ENTITY RFC5996 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY RFC4941 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml">
<!ENTITY RFC6177 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6177.xml">
<!ENTITY RFC7136 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7136.xml">
<!ENTITY RFC4887 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4887.xml">
<!ENTITY RFC5505 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5505.xml">
<!-- You need one entry like the following for each I-D referenced -->
<!ENTITY DRAFT-privacy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-ipv6-address-generation-privacy.xml">
<!ENTITY DRAFT-homenet SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-homenet-arch.xml">
<!ENTITY DRAFT-btle SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6lowpan-btle.xml">
<!ENTITY DRAFT-6lobac SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-6lobac.xml">
<!ENTITY DRAFT-lowpanz SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.brandt-6man-lowpanz.xml">
<!ENTITY DRAFT-64share SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-64share.xml">
<!ENTITY DRAFT-scan SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-opsec-ipv6-host-scanning.xml">
<!ENTITY DRAFT-aero SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.templin-aerolink.xml">
<!ENTITY DRAFT-stable SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-stable-privacy-addresses.xml">
]>
<?rfc toc="yes"?>
<!-- You want a table of contents -->
<?rfc symrefs="yes"?>
<!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>
<!-- This sorts the references -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc category="info" docName="draft-ietf-6man-why64-00" ipr="trust200902">
<front>
<title abbrev="Why 64">Analysis of the 64-bit Boundary in IPv6
Addressing</title>
<author fullname="Brian Carpenter" initials="B. E." role="editor"
surname="Carpenter">
<organization abbrev="Univ. of Auckland"></organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>University of Auckland</street>
<street>PB 92019</street>
<city>Auckland</city>
<region></region>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>brian.e.carpenter@gmail.com</email>
</address>
</author>
<author fullname="Tim Chown" initials="T. J." surname="Chown">
<organization abbrev="Univ. of Southampton"></organization>
<address>
<postal>
<street>University of Southampton</street>
<city>Southampton</city>
<region>Hampshire</region>
<code>SO17 1BJ</code>
<country>United Kingdom</country>
</postal>
<email>tjc@ecs.soton.ac.uk</email>
</address>
</author>
<author fullname="Fernando Gont" initials="F." surname="Gont">
<organization>SI6 Networks / UTN-FRH</organization>
<address>
<postal>
<street>Evaristo Carriego 2644</street>
<city>Haedo</city>
<region>Provincia de Buenos Aires</region>
<code>1706</code>
<country>Argentina</country>
</postal>
<email>fgont@si6networks.com</email>
</address>
</author>
<author fullname="Sheng Jiang" initials="S." surname="Jiang">
<organization>Huawei Technologies Co., Ltd</organization>
<address>
<postal>
<street>Q14, Huawei Campus</street>
<street>No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing</city>
<code>100095</code>
<country>P.R. China</country>
</postal>
<email>jiangsheng@huawei.com</email>
</address>
</author>
<author fullname="Alexandru Petrescu" initials="A." surname="Petrescu">
<organization abbrev="CEA, LIST">CEA, LIST</organization>
<address>
<postal>
<street>CEA Saclay</street>
<city>Gif-sur-Yvette</city>
<region>Ile-de-France</region>
<code>91190</code>
<country>France</country>
</postal>
<email>Alexandru.Petrescu@cea.fr</email>
</address>
</author>
<author fullname="Andrew Yourtchenko" initials="A" surname="Yourtchenko">
<organization>cisco</organization>
<address>
<postal>
<street>7a de Kleetlaan</street>
<city>Diegem</city>
<code>1830</code>
<country>Belgium</country>
</postal>
<email>ayourtch@cisco.com</email>
</address>
</author>
<date day="11" month="April" year="2014" />
<area>Internet</area>
<workgroup>6MAN</workgroup>
<abstract>
<t>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 routing prefix. This document describes the advantages
of this fixed boundary and analyses the issues that would be involved in
treating it as a variable boundary.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>IPv6 addresses were originally chosen to be 128 bits long
to provide flexibility and new possibilities,
rather than simply relieving the IPv4 address shortage
by doubling the address size to 64 bits. In particular, the notion
of a well-defined interface identifier was added to the IP addressing model.
The IPv6 addressing architecture <xref target="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 have no meaning and the entire identifier should be treated as
an opaque value <xref target="RFC7136"/>. Also, since IPv6 routing is
entirely based on variable length subnet masks, there is no basic
architectural assumption that n has any particular fixed value. All IPv6
routing protocols support subnet masks of any length up to /128. </t>
<t>The IID is of basic importance in the IPv6 stateless address autoconfiguration (SLAAC)
process <xref target="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 Section 2 of RFC 4862). The SLAAC
protocol does not define its length or assume any particular length. </t>
<t>The notion of a /64 boundary in the address was introduced after the
initial design of IPv6 was done, 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 <xref target="DRAFT-odell"/> that eventually led to ILNP
<xref target="RFC6741"/>, which required a fixed point for the split between
local and wide-area parts of the address. The other was the expectation that EUI-64
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. </t>
<t> As a result, RFC 4291 describes a method of forming interface identifiers from
IEEE EUI-64 hardware addresses <xref target="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 <xref target="RFC7136"/>
states that "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 <xref target="RFC6164"/>,
which standardises 127-bit prefixes for point-to-point links between routers,
among other things to avoid a loop condition known as the ping-pong problem. </t>
<t>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. </t>
<!-- Recently it has been clarified that the bits in an IPv6 interface
identifier have no particular meaning and should be treated as
opaque values <xref target="RFC7136"/>. Therefore, there are
no bit positions in the currently used 64 bits that need to be
preserved. -->
<t>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 analyse 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 anything (in theory) between /1 and /128 inclusive. Here, we mainly discuss the
question of a shorter IID, which would allow a longer routing prefix. The document makes
no proposal for a change to the IID length. </t>
<t>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. </t>
</section> <!-- intro -->
<section anchor="adv" title="Advantages of a fixed identifier length">
<t>As mentioned in <xref target="intro"/>, the existence of an IID of a given length is
a necessary part of IPv6 stateless address autoconfiguration (SLAAC) <xref target="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 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 <xref target="RFC5505"/>.
</t>
<t>An interface identifier of significant length, clearly separated from the routing prefix,
makes it possible to limit the traceability of a host computer by varying the identifier.
This is discussed further in <xref target="privacy"/>. </t>
<t>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.</t>
<t>The addressing architecture <xref target="RFC4291"/> <xref target="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 wide-area prefix
assigned to the site concerned, which in accordance with <xref target="RFC6177"/>
should be /56 or shorter. This situation has various specific advantages:</t>
<t><list style="symbols">
<t>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 much more
straightforward. </t>
<t>Adding a subnet is easy - just take the next /64. No estimates,
calculations, consideration or judgment is needed. </t>
<t>Router configurations are homogeneous and easier to understand. </t>
<t>Documentation is easier to write and easier to read; training is easier. </t>
</list></t>
<t>The remainder of this document describes arguments that have been made against the current
fixed IID length and analyses 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. </t>
</section> <!-- adv -->
<section anchor="scenarios" title="Arguments for shorter identifier lengths">
<t>In this section we describe arguments for scenarios where shorter IIDs, implying prefixes
longer than /64, have been used or proposed. </t>
<section anchor="insuff" title="Insufficient address space delegated">
<t>A site may not be delegated a sufficiently large 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 internal prefixes longer than /64 to allow
multiple subnets and the hosts within them to be configured with addresses. </t>
<t>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. </t>
<t>Scenarios that have been suggested where an insufficient prefix might be delegated
include home or small office networks, vehicles, building services and transportation
services (road signs, etc.). It should be noted that the homenet architecture text
<xref target="I-D.ietf-homenet-arch"/>
states that a CPE should consider the lack of sufficient address space to be an error
condition, rather than using prefixes longer than /64 internally. </t>
<t>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 <xref target="RFC6177"/>.
It is sometimes suggested that assigning a prefix such as /48 or /56 to every
user site (including the smallest) as recommended by <xref target="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). With only 2000::/3 currently
committed for unicast addressing, we still have most 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.
</t>
</section>
<section anchor="hier" title="Hierarchical addressing">
<t>Some operators have argued that more prefix bits are needed to allow an
aggregated hierarchical addressing scheme within a campus or corporate network.
However, 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.
</t>
</section>
<section anchor="audit" title="Audit requirement">
<t>Some network operators wish to know and audit which nodes 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 logs. </t>
</section>
<section anchor="cacheattack" title="Concerns over ND cache exhaustion">
<t>A site may be concerned that it is open to neighbour discovery (ND) cache exhaustion
attacks, 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, in an attempt
to fill a router's ND cache with ND requests pending completion, in so doing denying
correct operation to active devices on the network. </t>
<t>An example would be to use a /120 prefix, 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. </t>
<t>Hosts would likely use DHCPv6, or be manually configured with addresses. </t>
<t>It should be noted that several other mitigations of the ND cache attack
are described in <xref target="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 <xref target="RFC6164"/>. </t>
</section>
</section> <!-- scenarios -->
<section anchor="effects" title="Effects of varying the interface identifier length">
<t>This section of the document analyses the impact and effects of varying the length
of an IPv6 unicast IID by reducing it to less than 64 bits. </t>
<section anchor="standards" title="Interaction with IPv6 specifications">
<t>
The precise 64-bit length of the Interface ID 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.
</t>
<t>
First and foremost, the RFCs describing the architectural
aspects of IPv6 addressing explicitly state, refer and repeat
this apparently immutable value: Addressing Architecture <xref target="RFC4291"/>, Reserved Interface
Identifiers <xref target="RFC5453"/>, ILNP <xref target="RFC6741"/>. Customer Edge routers impose /64 for
their interfaces <xref target="RFC7084"/>. Only the IPv6 Subnet Model <xref target="RFC5942"/>
refers to the assumption of /64 prefix length as a potential implementation error.
</t>
<t>
Numerous IPv6-over-foo documents make mandatory statements with
respect to the 64-bit length of the Interface ID to be used
during the Stateless Autoconfiguration. These
documents include <xref target="RFC2464"/> (Ethernet), <xref target="RFC2467"/> (FDDI),
<xref target="RFC2470"/> (Token Ring), <xref target="RFC2492"/> (ATM), <xref target="RFC2497"/> (ARCnet),
<xref target="RFC2590"/> (Frame Relay),
<xref target="RFC3146"/> (IEEE 1394), <xref target="RFC4338"/> (Fibre Channel),
<xref target="RFC4944"/> (IEEE 802.15.4), <xref target="RFC5072"/> (PPP), <xref target="RFC5121"/>
<xref target="RFC5692"/> (IEEE 802.16),
<xref target="RFC2529"/> (6over4),
<xref target="RFC5214"/> (ISATAP), <xref target="I-D.templin-aerolink"/> (AERO),
<xref target="I-D.ietf-6lowpan-btle"/>, <xref target="I-D.ietf-6man-6lobac"/>,
<xref target="I-D.brandt-6man-lowpanz"/>.
</t>
<t>
To a lesser extent, the address configuration RFCs
themselves may in some way assume the 64-bit length of an
Interface ID (SLAAC for the link-local addresses, DHCPv6 for
the potentially assigned EUI-64-based IP addresses, Default Router Preferences
<xref target="RFC4191"/>
for its impossibility of Prefix Length 4, Optimistic Duplicate Address Detection <xref target="RFC4429"/>
which computes 64-bit-based collision probabilities).
</t>
<t>
The MLDv2 protocol <xref target="RFC3810"/> mandates all queries be sent with
the fe80::/64 link-local source address prefix and
subsequently bases the querier election algorithm on the
link-local subnet prefix length of length /64.
</t>
<t>
The IPv6 Flow Label Specification <xref target="RFC6437"/> gives an example of
a 20-bit hash function generation which relies on splitting an
IPv6 address in two equally-sized 64bit-length parts.
</t>
<t>
The basic transition mechanisms <xref target="RFC4213"/> refer to IIDs of length
64 for link-local addresses, and other transition mechanisms such as
Teredo <xref target="RFC4380"/> assume the use of IIDs of length 64.
Similar assumptions are found in 6to4 <xref target="RFC3056"/> and 6rd <xref target="RFC5969"/>.
Translation-based transition mechanisms such as NAT64 and NPTv6 have some dependency
on prefix length, discussed below.
</t>
<t>
The proposed method <xref target="I-D.ietf-v6ops-64share"/> of extending an assigned /64 prefix from a
smartphone's cellular interface to its WiFi link relies on
prefix length, and implicitely on the length of the Interface
ID, to be valued at 64.
</t>
<t>
The CGA and HBA specifications rely on the 64-bit identifier
length (see below), as do the Privacy extensions <xref target="RFC4941"/> and some examples in
IKEv2bis <xref target="RFC5996"/>. </t>
<t>
464XLAT <xref target="RFC6877"/> explicitly mentions acquiring /64 prefixes. However, it also discusses
the possibility of using the interface address on the device as the endpoint for the
traffic, thus potentially removing this dependency. </t>
<t><xref target="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 <xref target="RFC6164"/>, i.e.,
avoiding the use of anycast within a /120 subnet. </t>
<t>The Mobile IP home network models <xref target="RFC4887"/> rely heavily
on the /64 subnet length and assume a 64-bit IID. </t>
<t>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. </t>
</section> <!-- standards -->
<section anchor="breakage" title="Possible areas of breakage">
<t>This section discusses several specific aspects of IPv6 where we
can expect operational breakage with subnet prefixes other than /64. </t>
<t><list style="symbols">
<t>Router implementations: Router implementors might interpret IETF standards such as
<xref target="RFC6164"/> and <xref target="RFC7136"/> to indicate that routing prefixes
between /65 and /126 inclusive for unicast packets on-the-wire are
invalid, and operational practices that utilize prefix lengths in this
range may break on some devices, as discussed in <xref target="other"/>. </t>
<t>Multicast: <xref target="RFC3306"/> defines a method for generating
IPv6 multicast group addresses based on unicast prefixes.
This method assumes a longest network 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.
<vspace blankLines="1"/>
Similarly <xref target="RFC3956"/>, which specifies Embedded-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.</t>
<t>CGA: The Cryptographically Generated Address format (CGA, <xref
target="RFC3972"/>) is heavily based on a /64 interface
identifier. <xref target="RFC3972"/> has defined a detailed
algorithm how to generate 64-bit interface identifier from a public
key and a 64-bit subnet prefix. Breaking the /64 boundary would
certainly break the current CGA definition. However, CGA might
benefit in a redefined version if more bits are used for interface
identifier (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. </t>
<t>NAT64: Both stateless <xref target="RFC6052"/> NAT64 and
stateful NAT64 <xref target="RFC6146"/> are flexible for the
prefix length. <xref target="RFC6052"> </xref> has defined multiple
address formats for NAT64. In Section 2 "IPv4-Embedded IPv6 Prefix
and Format" of <xref target="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, a
8-bit u byte and a variable length suffix (there is no u byte and
suffix in the case of 96-bit Well-Known Prefix). NAT64 is therefore
OK with a boundary out to /96, but not longer.</t>
<t>NPTv6: IPv6-to-IPv6 Network Prefix Translation <xref
target="RFC6296"/> is also bound to /64 boundary. NPTv6 maps a
/64 prefix with other /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 broken as long as the "inside" and "outside"
prefix has the same length.</t>
<t>ILNP: Identifier-Locator Network Protocol (ILNP) <xref target="RFC6741"/> is designed
around the /64 boundary, since it relies on locally unique 64-bit interface identifiers.
While a re-design to use longer prefixes is not inconceivable, this would need
major changes to the existing specification for the IPv6 version of ILNP. </t>
<t>shim6: The Multihoming Shim Protocol for IPv6 (shim6) <xref target="RFC5533"/>
in its insecure form treats IPv6 address as opaque 128-bit objects. However, to secure
the protocol against spoofing, it is essential to either use CGAs (see above) or Hash-Based
Addresses (HBA) <xref target="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.
</t>
</list></t>
<t>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 <xref target="RFC4862"/>. There is however the rather special case of
the link-local prefix. While RFC 4862 is careful not to define any specific length
of link-local prefix within fe80::/10, <xref target="RFC4291"/> does define the link-local
IID length to be 64 bits. Operationally there could be a problem unless all
hosts on a link use IIDs of the same length to configure a link-local address during reboot.
Typically today the choice of 64 bits for the link-local IID length is hard-coded per interface,
and systems behave as if the link local prefix was actually fe80::/64.
There might be no way to change this except conceivably by manual configuration, which will be
impossible if the host concerned has no local user interface. </t>
</section> <!-- breakage -->
<section anchor="expt" title="Experimental observations">
<section title="Survey of the processing of Neighbor Discovery options with prefixes other than /64" anchor="survey">
<t>This section provides a survey of the processing of Neighbor Discovery options which include prefixes that are different than /64.</t>
<t>The behavior of nodes was assessed with respect to the following options:</t>
<t> <list style="symbols">
<t>PIO-A: Prefix Information Option (PIO) <xref target="RFC4861"/> with the A bit set.</t>
<t>PIO-L: Prefix Information Option (PIO) <xref target="RFC4861"/> with the L bit set.</t>
<t>PIO-AL: Prefix Information Option (PIO) <xref target="RFC4861"/> with both the A and L bits set.</t>
<t>RIO: Route Information Option (RIO) <xref target="RFC4191"/>.</t>
</list> </t>
<t>In the tables below, the following notation is used:</t>
<t> <list style="hanging">
<t hangText="NOT-SUP:">
<vspace blankLines="0" />This option is not supported (i.e., it is ignored no matter the prefix length used).</t>
<t hangText="LOCAL:">
<vspace blankLines="0" />The corresponding prefix is considered "on-link".</t>
<t hangText="ROUTE">
<vspace blankLines="0" />The corresponding route is added to the IPv6 routing table.</t>
<t hangText="IGNORE:">
<vspace blankLines="0" />The Option is ignored as an error.</t>
<!--
<t hangText="DROP:">
<vspace blankLines="0" />The whole packet is treated as bogus, and thus dropped/ignored</t>
<t hangText="FAIL:">
<vspace blankLines="0" />The receiving node crashes or exhibits some other misbehavior</t>
-->
</list> </t>
<texttable title="Processing of ND options with prefixes longer than /64" style="all" anchor="survey-long-prefix">
<ttcol align="center">Operating System</ttcol>
<ttcol align="center">PIO-A</ttcol><ttcol align="center">PIO-L</ttcol><ttcol align="center">PIO-AL</ttcol><ttcol align="center">RIO</ttcol>
<c>FreeBSD 9.0</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>NOT-SUP</c>
<c>Linux 3.0.0-15</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>NOT-SUP</c>
<c>Linux-current</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>NOT-SUP</c>
<c>NetBSD 5.1</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>NOT-SUP</c>
<c>OpenBSD-current</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>NOT-SUP</c>
<!--
<c>Solaris 10</c> <c>PIO-A</c><c>PIO-L</c><c>PIO-AL</c><c>RIO</c>
-->
<c>Win XP SP2</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>ROUTE</c>
<!--
<c>Win Vista (Build 6000)</c> <c>PIO-A</c><c>PIO-L</c><c>PIO-AL</c><c>RIO</c>
-->
<c>Win 7 Home Premium</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>ROUTE</c>
<!--
<c>Win 8 Home Premium</c> <c>PIO-A</c><c>PIO-L</c><c>PIO-AL</c><c>RIO</c>
-->
</texttable>
<t></t>
<texttable title="Processing of ND options with prefixes shorter than /64" style="all" anchor="survey-short-prefix">
<ttcol align="center">Operating System</ttcol>
<ttcol align="center">PIO-A</ttcol><ttcol align="center">PIO-L</ttcol><ttcol align="center">PIO-AL</ttcol><ttcol align="center">RIO</ttcol>
<c>FreeBSD 9.0</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>NOT-SUP</c>
<c>Linux 3.0.0-15</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>NOT-SUP</c>
<c>Linux-current</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>NOT-SUP</c>
<c>NetBSD 5.1</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>NOT-SUP</c>
<c>OpenBSD-current</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>NOT-SUP</c>
<!--
<c>Solaris 10</c> <c></c><c>PIO-L</c><c>PIO-AL</c><c>RIO</c>
-->
<c>Win XP SP2</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>ROUTE</c>
<!--
<c>Win Vista (Build 6000)</c> <ttcol align="center">PIO-A</c><ttcol align="center">PIO-L</c><ttcol align="center">PIO-AL</c><ttcol align="center">RIO</c>
-->
<c>Win 7 Home Premium</c> <c>IGNORE</c><c>LOCAL</c><c>LOCAL</c><c>ROUTE</c>
<!--
<c>Win 8 Home Premium</c> <c>PIO-A</c><c>PIO-L</c><c>PIO-AL</c><c>RIO</c>
-->
</texttable>
<t>The results obtained can be summarized as follows:</t>
<t><list style="symbols">
<t>the "A" bit in the Prefix Information Options is honored only if the prefix length is 64.
At least for the case of a prefix longer than /64, this is consistent with <xref target="RFC4862"/>, which defines
the case where the sum of the link-local prefix length and the IID length is larger than 128 as an error consition.</t>
<t>the "L bit in the Prefix Information Options is honored for any arbitrary prefix length (whether shorter or longer than /64).</t>
<t>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)</t>
</list></t>
</section> <!-- survey -->
<section anchor="other" title="Other Observations">
<t>Participants in the V6OPS working group have indicated that some forwarding devices have been
shown to work correctly with long prefix masks such as /80 or /96. Indeed, it is to be expected
that longest prefix match based forwarding 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. </t>
<t>It has been reported that at least one type of switch has a content-addressable memory limited
to 144 bits. This means that filters 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 /112. </t>
<t>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 <xref target="RFC6164"/>. </t>
</section>
</section> <!-- expt -->
<section anchor="impl" title="Implementation and deployment issues">
<t>From an early stage, implementations and deployments of IPv6 assumed the /64
subnet length, even though routing was based on variable-length subnet masks of any length.
As shown above, this became anchored in many specifications (<xref target="standards"/>)
and in important aspects of implementations commonly used in local area networks
(<xref target="expt"/>). 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 <xref target="survey"/>, we cannot tell without code
inspections or tests 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. </t>
<t>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 statically 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 <xref target="I-D.ietf-6man-stable-privacy-addresses"/>
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 which are not directly implied by the specifications,
and any such hidden dependencies would also need to be found and removed. </t>
<t>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. It
does this (even if technically it violates the protocol) because if
there is no router on the link, the hosts effectively would fail to
communicate each other with the configured addresses because the
"on-link assumption" was removed in <xref target="RFC4861"/>. This is not really about
the magic number of 64, but an implementation may sometimes pick a
specific value of prefix length due to the removal of the on-link
assumption, and the value chosen will most likely be 64. </t>
<t>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. </t>
<t>Finally, IPv6 is already installed on 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. </t>
</section> <!-- impl -->
<section anchor="privacy" title="Privacy issues">
<t>The length of the interface identifier has implications for privacy
<xref target="I-D.ietf-6man-ipv6-address-generation-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, at most just over
a million guesses are needed, today 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. </t>
<t>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. An argument could be made that since this reduces
traceability, it is a good thing from a privacy point of view. </t>
</section> <!-- privacy -->
</section> <!-- effects -->
<section anchor="security" title="Security Considerations">
<t>In addition to the privacy issues mentioned in <xref target="privacy"/>, and the issues mentioned
with CGAs and HBAs in <xref target="breakage"/>, the length of the subnet prefix affects the
matter of defence against scanning attacks <xref target="I-D.ietf-opsec-ipv6-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. </t>
<t>However, assume that an attacker finds one valid address A and 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
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 <xref target="cacheattack"/>. </t>
<t>Denial of service attacks related to Neighbor Discovery are discussed in <xref target="cacheattack"/>
and in <xref target="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 <xref target="I-D.ietf-opsec-ipv6-host-scanning"/>.</t>
<t>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. </t>
</section> <!-- security -->
<section anchor="iana" title="IANA Considerations">
<t>This document requests no action by IANA.</t>
</section> <!-- iana -->
<section anchor="ack" title="Acknowledgements">
<t>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,
Jen Linkova,
Philip Matthews,
Mark Smith,
Tatuya Jinmei,
Fred Templin,
Stig Venaas,
and numerous other participants in the 6MAN working group.</t>
<t>This document was produced using the xml2rfc tool <xref
target="RFC2629"/>.</t>
</section> <!-- ack -->
<section anchor="changes" title="Change log [RFC Editor: Please remove]">
<t>draft-ietf-6man-why64-00: WG adoption, WG comments, including major text reorganisation: 3 main
sections describe advantages of fixed length IID, arguments for shorter lengths, and expected
effects of varying the length, 2014-04-11. </t>
<t>draft-carpenter-6man-why64-01: WG comments, added experimental results, implementation/deployment text,
2014-02-06.</t>
<t>draft-carpenter-6man-why64-00: original version, 2014-01-06.</t>
</section> <!-- changes -->
</middle>
<back>
<references title="Normative References">
&RFC3972;
&RFC4291;
&RFC4861;
&RFC5533;
&RFC5535;
&RFC6052;
<!-- &RFC5157; -->
&RFC6146;
&RFC6164;
&RFC6296;
&RFC6741;
&RFC5453;
&RFC7084;
&RFC5942;
&RFC2464;
&RFC2467;
&RFC2470;
&RFC2492;
&RFC2497;
&RFC2590;
&RFC3146;
&RFC4338;
&RFC4944;
&RFC5072;
&RFC5121;
&RFC5692;
&RFC4191;
&RFC4429;
&RFC3810;
&RFC6437;
&RFC3306;
&RFC3956;
&RFC4862;
&RFC2526;
&RFC5214;
&RFC4213;
&RFC4380;
&RFC2529;
&RFC3056;
&RFC5969;
&RFC4941;
&RFC5996;
&RFC6177;
&RFC7136;
&DRAFT-scan;
</references>
<references title="Informative References">
&RFC2629;
&RFC6741;
&RFC6877;
&RFC6583;
&RFC4887;
&RFC5505;
&DRAFT-privacy;
&DRAFT-homenet;
&DRAFT-btle;
&DRAFT-6lobac;
&DRAFT-lowpanz;
&DRAFT-64share;
&DRAFT-aero;
&DRAFT-stable;
<reference anchor='DRAFT-odell'>
<!-- Draft not in public bibliography -->
<front>
<title>8+8 - An Alternate Addressing Architecture for IPv6</title>
<author initials="M. " surname="O'Dell" fullname="Mike O'Dell"/>
<date month='October' year='1996'/>
</front>
<seriesInfo name="draft-odell-8+8.00" value='(work in progress)' />
</reference>
<reference anchor="IEEE802">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks:
Overview and Architecture</title>
<author><organization>IEEE</organization></author>
<date year="2007" />
</front>
<seriesInfo name="IEEE Std 802-2001" value="(R2007)" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:47:34 |