SLAAC Prefixes with Variable Interface ID (IID) Problem Statement
Verizon Inc.gyan.s.mishra@verizon.com6WINDParisFrancedmytro@shytyi.netCEA, LISTCEA SaclayGif-sur-YvetteIle-de-France91190France+33169089223Alexandre.Petrescu@cea.frCiena 300 Concord RoadBillericaMA 01821United States of America+1 978 223 4700nkottapalli@benu.netCienaCanada+1-613-670-2425dmudric@ciena.com
Internet
6MAN Working Group
keywords
In the past, various IPv6 addressing models have been proposed
based on a subnet hierarchy embedding a 64-bit prefix. The
last remnant of IPv6 classful addressing is a inflexible interface
identifier boundary at /64. This document details the 64-bit boundary
problem statement.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14
when, and
only when, they appear in all capitals, as shown here.
From the beginning, the IPv6 addressing plan was based on a
128 bit address format made up of 8 hextets which were broken
down into a 64 bit four hextet prefix and 64 bit four hextet
interface identifier. For example, the address
2001:db8:3:4::1 has the first 4 hextets forming the /64 prefix
2001:db8:3:4::/64, whereas the last four hextets form an
interface identifier abbreviated as ::1 (a 'hextet' is a group
of max 4 hex digits between two columns, e.g. "2001" and "db8"
are each a hextet). A comprehensive analysis of the 64-bit
boundary is provided in . The history
of IPv6 Classful models proposed, and the last remnant of IPv6
Classful addressing rigid network interface identifier
boundary at /64 is discussed in detail as well as the removal
of the fixed position of the boundary for interface addressing
in draft .
This document discusses the reasons why the interface
identifier has been fixed at 64 bits, and the problems that
can be addressed by changing the GUA interface identifier from
fixed 64 bit size to a variable interface identifier. This
change would be consistent with static and DHCPv6 stateful
IPv6 address assignment. This document tries to achieve
clearing the confusion related to prefix length, and provide
consistency of variable length prefix across the three IPv6
addressing strategies deployed, static, DHCPv6 and Stateless
Address Autoconfiguration(SLAAC), and finally update all RFCs
with the new variable IID standard.
Over the years one of the merits of increasing the prefix length,
and reducing the size of the interface identifier has been
incorrectly stated as the possibility of IPv6 address space
exhaustion could be circumvented, or that a 64 bit interface
identifier is an efficient use of address space.
The fixed length of an Interface Identifier has roots in other
early non-IP networks such as IPX of Novell and another from
Apple.
Over the course of the history of the IPv6 protocol, several
addressing models have been proposed to break up the prefix
into a hierarchical format. One of the first attempts was
which was based on a 13 bit Level
Aggregation (TLA), 24 bit Next-Level Aggregation (NLA), 16 bit
Site Level aggregator Identifiers. The current IPv6
addressing architecture for global unicast addressing uses
for global unicast address currently
being delegated by IANA 2000::/3 prefix. With the
recommendation in which called for a
default end site assignment of a /48 which was adopted by the
Regional Internet Registry was revised with to a smaller block size of /56 prefix to
end sites to avoid risk of premature address depletion. The
current IPv6 addressing architecture
for global unicast addressing was now based on an IPv6
hierarchical format which now consists of a 45 bit global
routing prefix, 16 bit subnet ID followed by 64 bit interface
identifier. In the earlier deployments of IPv6 due to the
stringent guidelines of which stated
that for all unicast addresses, except those that start with
the binary value 000, Interface IDs are required to be 64 bits
long and to be constructed in Modified EUI-64 format.
Referencing IPv6 Addressing architecture section 2.5.5 depicts examples of global
unicast addresses that start with binary 000 are IPv6
addresses with embedded IPv4 addresses and IPv6 address
containing encoded NSAP addresses
described in . An example use case
would be for NAT64 as well as many
other use cases that exist with transition technology
tunneling using IPv4 IPv6 translators.
The general format for IPv6 global unicast addresses is as follows:
Even though states that all global
unicast addresses except those that start with binary value
000, which use ipv4 ipv6 translators , that static and DHCPv6 violates as variable length masking to 128 is
supported, where SLAAC variable length masking remains
forbidden. IPv6 packets over LAN based technologies such as
ethernet must use 64 bit interface identifier per . Nothing is mentioned regarding wireless
based technologies such as MIP6, V2V or 6loWPAN, with regards
to interface identifier length stringent requirement for 64
bit prefix length. Stateful Address Autoconfiguration states that the sum total of the prefix
length and interface identifier should equal 128 bits, but
does not state that the interface identifier should be 64
bits. Note that states that the PIO
(Prefix information Options), that the A-bit Autonomous
address-configuration flag when set indicates that the prefix
can be used for (SLAAC) stateless address
autoconfiguration, and states to
silently ignore the PIO options if the A flag is not set in
the Router Advertisement. If the A flag is not set then /64 is
only a recommendation which applies to DHCPv6 and static.
During the early deployments of IPv6, /64 was a 'de facto'
standard prefix length for deployment to all router interfaces
including point-to-point and loopbacks. In early deployments
of IPv6, due to the complexity and overall learning curve, and
change going from IPv4 to IPv6, the keep it simple approach of
/64 everywhere was the general rule of thumb for deployment.
After decades of deployment, operators started to dig
further into how IPv4 started out as classful with classful
routing protocols such as RIP or IGRP. Later as Classless
inter-domain routing with BGP became mainstream with larger
enterprises and service providers, operators started looking
at IPv6 and variable length masking. Operators now started
experimenting trying to subnet at nibble boundaries to start
and became brave enough to tackle subnetting on a bit
boundary. As variable length subnet masking became more
mainstream with IPv6, operators started to use /126 mask on
point-to-point links. Around that time came out which talked about the harmful
effects of /127 and that it was forbidden due to operational
impacts. Harmful impacts of /127 were due to subnet-router
anycast being in conflict with
/121. Later was found the benefits of /127 avoided the
ping-pong effect and the subnet-router anycast conflict could
be avoided by disabling Duplicate address detection thus the
status of use of /127 on point-to-point links was updated by
. As the evolution of IPv6 continued,
questions would come as to why the interface identifier is so
large at 64 bits, as 64 bits equates to
18,446,744,073,709,551,616 IPv6 addresses, which is more than
anyone could ever imagine on a single flat subnet far into the
distant future. The main reason for the larger 64 bit
interface identifier is for privacy when connected directly to
the internet, or on an unsecure public hotspot or location so
your device is not traceable.
From the beginning of IPv6 deployments most enterprises went with SLAAC, but as DHCPv6
matured, enterprises migrated to DHCPv6, and network
infrastructure remained configured manually using static
configurations. Since so many RFC’s mention the SLAAC 64 bit
boundary requirement and confusion related to this topic, in
fact prevented operators proliferation of even attempting to
use longer prefixes on host subnets with static or DHCPv6
stateful. Most IPv6 implementations even to this day do not
use longer than 64 bit prefixes, and still maintain the 64 bit
boundary for host subnet, for both DHCPv6 and static, even
though technically feasible, due to fear of interoperability issues
that may arise. With this new evolution of IPv6 addressing
architecture with variable SLAAC, we can bring back SLAAC to
the mainstream for all IPv6 deployments. This will also allow
operators to now comfortably deploy both DHCPv6 and static
with greater than 64 bit prefix length to host subnets, without
fear of interoperability problems.
Today we have three methods of IPv6 address deployment, SLAAC, DHCPv6 and static.
DHCPv6 does not provide an adequate IPv6 addressing solution as described in
detail in the DHCPv6, Static, and SLAAC comparison section. As user subnets flatten out further,
as the IPv4 under pinning is eliminated, removing the shackles on IPv6, the subnets will get much flatter.
As the subnets flatten out in large Enterprise networks where you have 100’s of
Dual Stack subnets migrate to a single “IPV6-ONLY” subnet, the overhead DHCPv6
Normal mode messaging becomes exacerbated. The problem with DHCPv6 is that once the “M” managed bit
is set to “1”, all hosts on the subnet cache the M bit and change to DHCPv6 stateful mode.
Higher probability of rouge devices such as printers or other appliances misbehaving with IPv6 enabled by default, now in DHCPv6 mode,
spewing of millions of DHCPv6 messages that can now impact the router control plane processing of packets.
This can be alleviated with special custom Control Plane policer policy, however now adds
complexity and administrative overhead to DHCPv6 deployments. Enterprises and Service Providers
require a viable IPv6 deployment solution that can accommodate the shortfalls of
both static and DHCPv6 addressing. Static addressing due to administrative overhead of
manual assignment does not provide a viable solution for even moderately sized networks.
An arbitrary length prefix solves problems described in detail in section 7 and are
being highlighted here as well as a key part of the problem statement to be addressed.
A site may not be able to delegate sufficient address space from a /64 prefix to all of its internal subnets.
In this case a site may be partially operational as it is unable to number all of its subnets.
An alternative would be to be able to use prefixes longer then /64 to allow multiple subnets
for example /80 for numbering subnets with a mixture of hosts that are static or DHCPv6
without worry of interoperability issues. Some operators would like the ability to have a
hierarchical addressing structure and may require more than 16 bits given with a /48 allocation.
In such instances longer prefix lengths would allow for additional levels of aggregation as required.
It is common for some operators to have security audit requirements where they wish to know all active
hosts on a /64 subnet. As /64 subnets can contain an enormous number of hosts and thus cannot be scanned as can IPv4 subnets.
Operators have argued that one method to be able to scan for active hosts would be by reducing the size of the subnet.
Neighbor discovery cache exhaustion when an attacker sends a large number of messages in rapid succession to
hosts filling the routers ND cache is another problem with fixed length /64 size SLAAC subnets.
Neighbor Discovery cache exhaustion issues are relatively common on IXP (Internet Exchange Points)
where a very large number of Internet Service Providers are full mesh peering to exchange routing updates.
As the number of hosts on a SLAAC subnet can be 2^64, a much smaller subnet size can
drastically reduce the Neighbor Discovery cache exhaustion issues.
The goal of this document is to fix the problems related to stateless address
autoconfiguration (SLAAC), current obscurities of the 64
bit prefix boundary, issues that exist today with current IPv6 addressing using manual and DHCPv6,
and how variable SLAAC can now be used to fill the gaps with static and DHCPv6,
and also update all standards specifications to reflect the new variable SLAAC
standard making the prefix lengths variable.
This section details the problem statement as to what is broken
today with fixed length Stateless Address Autoconfiguration
SLAAC and why it is critical to
resolve this problem. The well known Day 1 isse with SLAAC fixed /64 boundary as it exist today
is that does not provide direct partiy with other provisioning mechanisms such as Static and DHCPv6 which allows for Variable Length Subnet Mask (VLSM).
This has historically been a major problem for deploying DHCPv6 or Static using variable IID due to the incompatibility with SLAAC and thus
has shackled Static and DHCPv6 IPv6 provisioning mechanisms to the fixed /64 boundary as well.
The main problem is that SLAAC RA or PD allocates a /64 by the
wireless carrier 4G, 5G, 3GPP to mobile handset or hotspot,
however segmentation of the /64 via SLAAC is required so that
downstream interfaces can be further sub-netted. The use case
section of this draft discusses this scenario as one of the
use cases for shorter interface identifier, and this use case
is the only one stated here in the problem statement as this
is broken today with the current SLAAC specification , and there is not any workaround for this
use case. The main reason why a /64 is required and a simple shorter /56 prefix solution is not possible is
that provisioning systems have been set to /64 prefix and cannot be changed.
There are two reasons why this was not a problem in the past,
but now with increased bandwidth there are more and more
devices being piled onto a single handset or mobile hotspot.
In the past generations of cellular systems (e.g. 2.5G aka
GPRS and some 3G) the bandwidth available to the User
Equipment was not enough to accommodate several applications;
bandwidth available was roughly 256Kbit/s. For that reason,
users were rarely tempted to use an UE to link other devices
than that UE to the Internet. However, with the arrival of
3G, 3G+ (e.g. HSDPA / HSUPA), and even more so with 4G and 4G+,
the bandwidth made available to UE increased significantly;
this became an average effective of 1Mbit/s and even more.
With this available bandwidth, the users are more and more
tempted to connect several devices to the Internet. This
operation is named 'connection sharing' or 'tethering'.
Another answer to this question is that IPv6
technology that is widely used to 'tether' several IP devices
to a smartphone is '64share' RFC7278. This technology is used
for smartphones but is not so in vehicles. One of the
reasons of not being used in vehicles is the lack of
scalability: a /64 prefix is shared between the UE ptp link
and the subnet (typically Wi-Fi), but can not be further
sub-netted to other subnets in the car.
The reason why all devices in a car cannot remain on a single
/64 are as follows. These devices have different link-layer
technologies, and not all WiFi could be bridged into Ethernet
such as to keep all devices into one /64. They could be on links
that are not bridgeable: devices on 802.11-OCB cannott be bridged,
devices on Bluetooth cannott be bridged, devices on 3GPP cannott
be bridged, and so one. Other than the impossibility to bridge several
such link-layer technologies there is also a problem of
noise: in a vehicle one wants the braking pedal signal to not
be disturbed by entertainment sites such as YouTube. That
physical technical requirement separation of different link
layer technologies segmentation on to different smaller IPv6
subnets cannot be achieved if all devices are on a
single /64, or bridged. Therefore, the only possible
solution to connect these disparate devices onto a 3GPP
network for internet access is to keep these separate link
layer technologies segmented onto separate greater then /64
prefix subnets and breaking the /64 boundary that exists
today with a Variable IID solution. Thus, when the 3GPP
network gives a /64 to the car, and when there are
unbridgeable technologies in the car (e.g. WiFi cant be
bridged to Bluetooth), then the only possibility is to divide
that /64 into two /65s. One /65 would be used on the WiFi
and another /65 would be used on Bluetooth. But in order for
SLAAC to work with /65 then there is a need to have the
shorter interface identifier of length 63. Hence the need of
lengths of PIOs other than 64 (variable plen).
There are three scenarios that require SLAAC to be able to be
routed between two greater then /64 prefix segments as part of
the requirement for variable length IID and what is broken
with the current SLAAC specification defined in .
The first scenario is within a car using car manufacturer
single SIM for internet access and being able to bridge(Route)
other link layer devices like BT via variable IID. In this
scenario the communication between downstream devices are all
located within the car using the car manufacturer built in SIM
card for in-vehicle communication. The in-vehicle scenario
covers both the built-in car manufacturer SIM card scenario, or
if the car manufacturer does not support built-in SIM card then
a single mobile handset providing 3GPP internet access to all
devices in the car.
The second scenario is V2V (vehicle to vehicle) between cars
requiring SLAAC to subnet the >64 prefix so that the two cars
have WiFi connectivity.
This third scenario is a uCPE(Universal Customer Premises
Equipment) device is LTE 4G and Wi-Fi capable, and utilizes
NFV (Network Function Virtualization) framework, providing SFC
(Service Function Chaining), where one VNF (Virtual Network
Function) is a CPE Layer 3 router and is the uCPE device which
will receive a /64 prefix from 4G 3GPP Wireless provider and
would like to be able to provide further segmentation. In
order to provide further segmentation and subdivide the /64
into smaller longer prefix subnets variable IID must be
employed. In this example we would give 1st /66 to Wi-Fi
users, 2nd /66 to Wired connected network device without
security, 3rd /66 prefix to VNF firewall instance, and 4th /66
prefix VNF load balancer instance. The uCPE (Universal
Customer Premises Equipment) defined in draft .
From a segmented bandwidth perspective while breaking up
the /64 subnet into smaller subnets, there is not any
impact to the user experience of the now shared bandwidth,
as long as the cellular signal has adequate enough bars as
far as signal strength to accommodate the now multiple
devices sharing the single cellular signal. These scenarios
described above are the problems that can only be solved
with a variable IID solution. There is no other solution
or workaround for this problem.
This section describes real world use cases of variable slaac
that cannot be done today and with fixed 64 bit prefix
lengths.
Service Providers and Enterprises want to take advantage of VLSM for Access and Data Center subnets and are not able to do so even when using
DHCPv6 or static addressing. The major issue is that VLSM with DHCPv6 and Static addressing is shackled to /64 boundary as well in reality
as there will always be at least one or more SLAAC devices on the same subnet. In a real world scenario as you have all threee addressing options
available on any subnet, Static, DHCPv6 and SLAAC there is a very high probability that there will be a mix and thus in order for the devices
provisioned as DHCPv6 or Static to communicate with any device that is using SLAAC weare now back to the /64 boundary for all devices on any subnet regardless of how the IPv6 address is provisioned.
Opeartors are now stuck with the SLAAC /64 boundary for all subnets across the board and VLSM can never come to fruition with IPv6 even with DHCPv6 or Static address provisioning methods.
Unless the standard changes for SLAAC /64 fixed boundary, DHCPv6 and Static will now be bound to the same rules as SLAAC with the /64 mask for DHCPv6 scope and Static addresging.
The SLAAC /64 fixed boundary impacts the proliforation of IPv6 across the board which are failed to start.
There have been many complaints over the years with IPv6 as to why we cannot have subnet size less /64.
For network designers this makes the case difficult for the move to IPv6 as well as it is very difficult to provide any justification for the /64 boundary other than that is the standard.
Many operators around the world have provisioning systems that have been fixed at /64 boundary for both Access Network (AN), Fixed Broadband (FBB) and Mobile Broadband (MBB) and thus
changing the provisioning systems that have been set for deccades is not possible. Due to this issue being able to extend the /64 further by subtending with further subnets with longer prefix and shorter IID
is not possible. There are many other solutions that provide a larger block allocation to the UE using DHCPv6 PD or other solutions, however in this case none of those
solutions can be used due to the provisioning systems that cannot be changed to accomodate a larger block. This is a MAJOR issue for operators.
Permission-less extensions of the network with new links
(and by implication with new routers) are not supported.
The lack of possibility to realize a permission-less
extension of the network is an important problem, which
appears at the edge of the network. The permission
is 'granted' for end users situated at the edge of the
network, and is 'granted' by advertising a
prefix of length 64 inside the PIO option in a RA typically.
The end user receives this prefix, forms an address, and
is able to connect to the internet.
However, the end user has no permission to further extend
the network. Although the device is able to form subsequent
prefixes of a length of, say 65, and further advertise it
down in the extension of the network, no other Host in that
extension of the network is able to use that advertisement;
a Host cannot form an address with a prefix length 65 by
using SLAAC. The Linux error text reported in the kernel
log upon reception of a plen 65 is "illegal" (or similar).
Private networks such as Service Provider core not
accessible by customers and enterprises where all hosts are
trusted are the primary use case for variable IID as the
shorter interface identifier does not create any security
issues with not having a longer 64 bit interface identifier
for privacy extensions stable interface identifier due to all hosts being inherently
trusted. Private internal networks such as corporate
intranets traditionally have always used static IPv6
addressing for infrastructure. This manual IPv6 address
assignment process for network infrastructure links can take
long lead times to complete deployment. By changing the
behavior of SLAAC to support variable length prefix and
interface identifier allows SLAAC to be used
programmatically to deploy to large scale IPv6 networks with
thousands of point-to-point links. Note that network
infrastructure technically does not require IPv6 addressing
due to IPv6 next hop being a link local address for IGP
routing protocols such as OSPF and ISIS as well as the link
local address can be the peer IPv6 address for exterior
gateway routing protocols such as BGP. However for hop by
hop ping and traceroute capability to have IPv6 reachability
at each hop for troubleshooting jitter, latency and drops it
is an IPv6 recommended best practice to configure IPv6
address on all infrastructure interfaces.
Old MIP6 (Mobile IPv6) Working Group and old Nemo Working
Group's routing solution scenarios related to Mobile IPv6
() (note: nowadays most MIP-related
activity is in DMM WG) where the mobile endpoint can now
obtain from the home agent variable IID address and not 64
bit prefix /64 address. This maybe useful in cases where a
/64 can now be managed from an addressing perspective and
subdivided into blocks for manageability of MIP6 endpoints
instead of allocating a single /64 per endpoint.
Home and SOHO (Small Office and Home Office) environments
where internet access uses a broadband service provider
single or dual homed scenario. In those such Home
networking Homenet environments where HNCP (Home Network
Control Protocol SADR (Source
Address Dependent Routing) are deployed for automatic
configuration for LAN Wi-Fi endpoint subnets can also now
take advantage of variable length IID in deployment
scenarios. In cases where multiple routers are deployed in
a home environment where routing prefix reachability needs
to be advertised where Babel
routing protocol is utilized in those cases variable SLAAC
can also be utilized to break up a /64 into multiple smaller
subnets.
In V2I networking (with 3GPP or with IEEE 802.11bd) the
IP-OBU in the vehicle receives a /64 prefix from the
cellular network (or from a IP-RSU - Road-Side Unit). This
/64 prefix can be used to form one address for the egress
interface of the Mobile Router (MR, which is also termed
'IP-OBU', for IP On-Board Unit, in IPWAVE WG documents such
as RFC8691), but can not be used to form IP addresses for
other hosts in the vehicle. In the following two paragraphs
we explain this problem.
In certain 3GPP V2I networking use cases a /56 is allocated
by the 3GPP infrastructure to the 4G modem of the IP-OBU in
the vehicle. In such use case it is possible that the
IP-OBU sub-divides the allocated /56 into multiple 'result'
/64 prefixes. Such a 'result' /64 prefix could be used to
form addresses for deeper subnets in the vehicle, by
employing existing SLAAC and existing IPv6-over-foo
specifications of Interface ID.
If in other 3GPP V2I networking use-cases the infrastructure
does not allocate a /56 (or 'longer' prefix lengths such as
a /57, /58../63) to the IP-OBU, i.e. a /64 is allocated to
the IP-OBU, then the 'result' prefix obtained after a
sub-divide operation can only be of length /65, or /66, or
longer. A prefix of such length (longer than 64) can not be
used with SLAAC and existing IP-over-foo Interface
Identifiers, because the length of all Interface Identifiers
in all IPv6-over-foo documents must always be 64, and the
length of the IPv6 is always 128bit. The 64bit of an IID
added to the 65bit (or more) of a prefix is larger than
128bit. It is for this reason that a SLAAC with other than
64bit Interface IDs (hence a 'Variable Prefix Length IID')
is needed.
The problem of /64 allocation to the vehicle is mostly
present in V2I use-cases. In V2V use-cases this problem is
less apparent but deserves consideration. Until now there
was no clearcut design and decision about the infrastructure
allocating addresses to several vehicles (just to one, in
V2I, see above). In some use-cases, the prefix allocated to
one vehicle could be further extended by that vehicle to
delegate prefixes to other vehicles nearby which might not
have 3GPP connections, but only 802.11-OCB interfaces. In
such cases it is again necessary that a /64 allocated by the
infrastructure to the first vehicle be further sub-divided
in multiple 'result' longer-than-/64 prefixes; and one of
these longer-than-64 prefixes might be used for the second
vehicle (instead of being used for the internal subnets of
the first vehicle); this latter vehicle will need to use a
form of IID and IP-over-foo that are not limited by the
/64 limit.
Smart traffic lights are traffic lights equipped with a
communication system. Smart traffic lights are deployed at
intersections of roads and serve the purpose of safely
arbitrating the passage of automobiles, pedestrians and
cyclists. A typical smart traffic lights setting is made of
several computers, included but not limited to: a traffic
lights controller, a power controller and a communication
gateway. More advanced smart traffic lights are equipped
with more computers for radars, detection loops, lidars, V2X
wireless capabilities, Wi-Fi, Bluetooth and cellular 4G or
5G. All these computers need to use IP addresses: at least
one IP address per computer. Since smart traffic lights are
deployed in areas where Internet might not be available by
cable, fibre or other Wireless MAN technology the only way
to connect all computers in the smart traffic lights setting
is to employ a 4G (or 5G) gateway. This gateway obtains
typically a /64 prefix from the network operator; there is a
problem in subdividing that /64 prefix into smaller
prefixes, because the obtained prefixes can not be used by
SLAAC, because SLAAC uses Interface IDs of length 64 in
practice. Even if the SLAAC specification is independent of
the prefix length, the length of the Interface ID dictates
the prefix length by side effect (128 minus IID length
imposes the prefix length). SLAAC might work with a plen 65
by specification, but all IIDs in all IPv6-over-foo request
that IIDs be 64; and the sum of IID len plus plen must be
128.
6lo Working IPv6 over Network Constrained nodes working
group use cases. Use cases for IoT devices where have
limited network access requirements could now take advantage
of variable IID longer prefixes lengths /65-/128.
Large ISP backbone POPs such as IXPs where many carriers
share the same backbone and ND cache exhaustion may occur
due to /64 subnet size. One mitigation technique employed is
the use of an ARP Sponge for IPv4 or Layer 2 multicast rate
limiters for IPv6. In those particular cases a longer
prefix static or variable IID subnet could be utilized to
reduce the maximum number of hosts on the subnet.
When one wants to extend the network, one typically wants to
add new computers to it. Currently, there are two ways to
achieve it: (1) ask the network administrator to provide
addresses while also inserting a route towards the new
subnet of devices and (2) use NAT. With IPv6, NAT is not
desirable. In order to extend the network without asking
for permission one needs to obtain addresses and to obtain
that route inserted. In order to obtain addresses, one
might take advantage of the /64 prefix typically advertised
by the network to an edge of it. To do that, one needs to
sub-divide the /64 prefix into /65 sub-prefixes (or longer,
such as /66, /67, etc.) which could be further advertised in
the extension of the network. For the action of inserting a
route, the particular topic is outside the scope of this
document.
Listed below are use cases where the 64 bit prefix length MUST
be adhered to and in these cases variable SLAAC feature should
not be utilized.
The precise 64-bit length of the interface identifier 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
, IPv6 Address Assignment to End
Sites , Reserved interface
identifiers , and ILNP Node
Identifiers . Customer edge routers
impose /64 for their interfaces .
The IPv6 Subnet Model 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 interface identifier
to be used during the Stateless Autoconfiguration. These
documents include (Ethernet), (Fiber Distributed Data Interface (FDDI)),
(Token Ring), (ATM), (ARCnet),
(Frame Relay), (IEEE 1394),
(Fibre Channel), (IEEE 802.15.4),
(PPP), (IEEE 802.16),
(6over4), (Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP)), (Asymmetric Extended Route
Optimization (AERO)),
(BLUETOOTH Low Energy),
(IPv6 over MS/TP), and I-D.ietf-6lo-lowpanz (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 interface
identifier (e.g, for the link-local
addresses, DHCPv6 for the potentially assigned EUI- 64-based
IP addresses, and Optimistic Duplicate Address Detection
that computes 64-bit-based
collision probabilities).
The Multicast Listener Discovery Version 1 (MLDv1) and MLDv2
protocols mandate that all queries be sent with a link-local
source address, with the exception of MLD messages sent using
the unspecified address when the link-local address is
tentative . At the time of
publication of , 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"
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
refer to interface identifiers of length 64 for link-local
addresses; other transition mechanisms such as Teredo assume the use of interface identifiers of
length 64. Similar assumptions are found in 6to4 and 6rd .
Translation-based transition mechanisms such as NAT64 and
NPTv6 have some dependency on prefix length, discussed below.
The proposed method 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 interface identifier, 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 and some examples in "Internet Key
Exchange Version 2 (IKEv2)" .
464XLAT 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.
reserves a number of subnet anycast
addresses by reserving some anycast interface identifiers. An
anycast interface identifier 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 , 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 ; therefore,
applications and their developers would expect it to be
available.
The Mobile IP home network models
rely heavily on the /64 subnet length and assume a 64-bit
interface identifier.
Multicast: 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, , 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.
CGA: The Cryptographically Generated Address format is heavily based on a /64 interface
identifier. 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.
NAT64: Both stateless NAT64 and
stateful NAT64 are flexible for
the prefix length. has defined
multiple address formats for NAT64. In Section 2 of
"IPv4-Embedded IPv6 Address Prefix and Format" , 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.
NPTv6: IPv6-to-IPv6 Network Prefix Translation 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.
ILNP: Identifier-Locator Network Protocol (ILNP) 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.
Shim6: The Multihoming Shim Protocol for IPv6 (Shim6)
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 . 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.
Duplicate address risk: If SLAAC was modified to work with
shorter interface identifiers, the statistical risk of
hosts choosing the same pseudo- random identifier would increase correspondingly. The
practical impact of this would range from slight to
dramatic, depending on how much the interface identifier
length was reduced. In particular, a /120 prefix would
imply an 8-bit interface identifier and address collisions
would be highly probable.
The link-local prefix: While is
careful not to define any specific length of link-local
prefix within fe80::/10, the addressing architecture
does define the link-local
interface identifier length to be 64 bits. If different
hosts on a link used interface identifiers 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 interface
identifier 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 conceivably by manual configuration, which will be
impossible if the host concerned has no local user
interface.
In this section we are providing the justification for longer
prefixes and shorter interface identifiers essentially
variable SLAAC.
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 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 .
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 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 . It is sometimes suggested that
assigning a prefix such as /48 or /56 to every user site
(including the smallest) as recommended by 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 , 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.
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.
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 interface identifier
values without changing the /64 subnet length. Any hosts
inadvertently obtaining addresses via SLAAC can be audited
through Neighbor Discovery (ND) logs.
A site may be concerned that it is open to 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. 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 , 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
.
Ability to utilize the longer than 64 bit prefixes to be
able to embed geographic or other information into the
prefix that could be valuable to the IPv6 addressing
architecture providing more flexibility to the operator.
Static - IPv6 address and Default Gateway:
Deactivation of RA processing
Good resistance against RA attack
Operational impact in configuring interface
manually
Network dynamics might require renumbering which
needs work
Static - IPv6 address and Default Route via RA
Does not require disabling RA processing
Works better with FHRP router redundancy
RA related security issues combat with RA Guard
DHCPv6
Centralized provisioning of IPv6 addressing
IPv6, DNS, NTP can all be distributed
Administrative overhead of managing DHCPv6 server
Caveats with redundancy and split scopes required
for failover. Split scope and failover is resolved with DHCPv6 Failover protocol
RA related security issues combat with RA Guard
SLAAC Stable Random station-id with privacy and Recommendations for Stable interfae identifier
Automatic provisioning IPv6 address to hosts
Stable Random station-id with privacy
extensions
RA related security issues combat with RA Guard
Variable SLAAC with Stable Random station-id with privacy and
Recommendations for Stable interfae identifier
Automatic provisioning IPv6 address to hosts
Stable Random station-id with privacy
extensions
RA related security issues combat with RA Guard
Security is reduced with longer prefixes and shorter stable random station-id
IPv6 address deployment summary statement.
DHCPv6 state machine introduces a large number of messaging packets with Normal mode,
four messages called solicit, advertise, request and reply. DHCPv6 Rapid Commit mode
reduces the messages from four to two messages only solicit and reply. DHCPv6 Normal mode is the Default.
It is recommended to use DHCPv6 Rapid mode in “high mobility” networks where clients come and go often.
The overhead of four messages might not be required so two messages might enough to accommodate.
However, if you have multiple DHCPv6 servers for redundancy then you need to use DHCPv6 Normal mode.
If you have subnets where there are a large flat user subnets with a very large number of hosts and
redundancy is required and DHCPv6 Normal mode is utilized, DHCPv6 messaging is exacerbated exponentially
as the subnets flatten out further and further. As the paradigm shifts and IPv4 is
eliminated as hosts subnets change to “IPv6-ONLY” subnets, the coupling of IPv4 with IPv6 Dual
stack dependency is eliminated, thus removing the shackles pinning IPv6 to smaller many IPv4 subnets.
This change allows IPv6 subnets to become very large and flat with the only limiting factor being the L2 switch infrastructure.
In many cases Dual stacked implementations with 100’s of subnets may change to a single “IPV6 ONLY” subnet.
As “IPV6-ONLY” subnets will soon become the future direction of all user access infrastructure,
we need a viable solution that will accommodate these very large flat subnets.
The problem with DHCPv6 is that once the “M” managed bit is set to “1”, all hosts on the subnet cache
the Managed IP "M bit" and changes host to DHCPv6 stateful mode. Higher probability of rouge devices such as printers or other appliances misbehaving
with IPv6 enabled by default, now in DHCPv6 mode, spewing of millions of DHCPv6 messages that can
now impact the router control plane processing of packets. This can be alleviated with special
custom Control plane policer policy, however now adds complexity and administrative overhead to DHCPv6 deployments.
Enterprises and Service Providers require a viable IPv6 deployment solution that can accommodate the shortfalls
of both static and DHCPv6 addressing. Static addressing due to administrative overhead of
manual assignment does not provide a viable solution for even moderately sized networks.
Variable SLAAC now has the ability to fill the gaps outlined with DHCPv6 and static that can
now be used as a viable ubiquitous all encompassing solution for IPv6 address deployments.
The administrator should be aware to maintain 64 bit interface
identifier for privacy when connected directly to the internet
so that entropy for optimal heuristics are maintained for
security.
Variable length interface identifier shorter then 64 bits
should be only used within corporate intranets and private
networks where all hosts are trusted.
In all cases where the host is on a public network for privacy
concerns to avoid traceability variable interface identifier
MUST never be utilized.
No IANA Considerations.
Brian Carpenter
The changes are listed in reverse chronological order, most
recent changes appearing at the top of the list.
-00: initial version.