Unique IPv6 Prefix Per Host – How Complex Do You Want IPv6 to Be?

In December 2017 IETF published RFC 8273 created by the v6ops working group (which means there must have been significant consensus within the working group that we need the solution and that it makes at least marginal sense).

The RFC specifies a mechanism by which the first-hop router allocates a unique /64 IPv6 prefix for every host attached to a subnet and uses unicast and multicast RA responses sent to unicast MAC addresses to give every host the impression that it’s the sole host on its own subnet.

The first thought of anyone even vaguely familiar with how complex IPv6 already is should be “WTF???” Unfortunately, there are good reasons we need this monstrosity.

Why do we need this?

There are legal and commercial reasons why Internet Service Providers need to be able to identify individual customers based on their IPv6 addresses. Whenever the ISP is using a P2P access network (DSL or anything that looks like dialup), each customer gets an IPv6 prefix (or a combo of a /64 access prefix and another delegated prefix) anyway.

There was no such mechanism available for shared access networks like switched Ethernet, PON, or WiFi.

Hey, ever heard of DHCPv6 IA_NA?

Yes, I did. So did everyone else. Unfortunately, ISPs can’t use it to control address allocation to clients due to what can only be viewed as religious opposition from a major mobile OS vendor who refuses to implement DHCPv6 client.

The only way forward considering that OS vendor has a huge market segment was to implement yet another kludge. Hooray!

But isn’t prefix-per-host more secure than IA_NA?


Although RFC 8273 hints at increased customer separation (because it was obviously a non-starter saying we had to do this because $vendor refuses to acknowledge our perfectly valid needs), there’s no real gain in using /64-per-client from the security perspective.

You could always use RA and DHCPv6 to tell the compliant hosts that they should send all traffic through the first-hop router where it could be properly inspected, and non-compliant hosts can always bypass those measures on layer-2 access networks as long as they can figure out the MAC addresses of other hosts (which they can because IPv6 hosts still send multicast ICMPv6 messages during DAD).

So what’s the impact of this idea?

You mean beyond wasting half of the address bits and reverting IPv6 to how it was originally designed (the first proposal used 64 bit addresses) after wasting two decades arguing about nuances of SLAAC and ND?

Admittedly this change keeps the client stack simpler (because there’s no need to run DHCPv6), but does not reduce any complexity on the first-hop router. Someone still needs to keep a stateful mapping between clients and their prefixes, and if you have two or more first-hop routers you still have to synchronize the mapping between them.

Note in the margin

I have a vague feeling that the state synchronization between redundant first-hop routers would be even more complex than it was before, but the margins of this blog post are not wide enough to elaborate… ;)

Want to know more?

I discussed the details of SLAAC and DHCPv6 many times on this blog and in various webinars and workshops, but (as you might have noticed) decided not to spend too much time on a protocol that’s old enough to buy its own beer in most of the world (including US if you consider RFC 1752 to be the birth of IPv6).

You might also enjoy a-bit-less cynical view from Russ White.

An Alternative Perspective

I sent the draft of this blog post to my good friend Gunther Van De Velde (who, among other things, pushed me to participate in writing my one-and-only RFC). Here’s his perspective on the topic

RFC8273 spec created indeed a bit more dust and bits-on-wire-in-v6ops as anticipated, in many different ways… and i agree with your cynicism. This specification is for sure not the result of a protocol beauty contest, but more the complex embodiment of mixed industry support of an incompatible IPv6 address management technologies on UEs (SLAAC vs DHCPv6) bringing operator subscriber management nightmare.

Within the IPv6 community, the consensus for this particular idea has been rather rough, even for v6ops WG. Just count the number of emails exchanged on this topic in last two months and that gives an idea on "roughness". I believe that is mainly because many people are not aware about what is "subscriber management", and what it exactly achieves, what the purpose is of subscriber management or how it works (even for IPv4). For IPv4 this is as you are aware, mainly done by DHCP or PPPoE subscriber management on a WLAN GW or on a BNG. We as vendor would love to use that experience, and apply that almost identical to IPv6. We have been doing subscriber management very well for IPv4 for a very long time already. Reality is however on universal support of DHCPv6 on UEs is different. 

You agree that IPv6 addressing is a much more complex beast as IPv4 addressing. Also, the adoption of DHCPv6 is not as universal as DHCPv4 on host devices. If DHCPv6 would be as popular and supported as DHCPv4, then for sure RFC8273 would serve little value and is obsolete. However, reality is different, and DHCPv6 support is not a given in all UE’s and at same time IPv6 has some fancy addressing methods providing auto-addressing (SLAAC, CGAs, etc…) making subscriber management (legal and commercial) a non-trivial matter. 

In cases where UE subscriber management is executed on a BNG or WLAN-GW, there is a central repository already keeping track and synchronization of UE vs location vs commercial contract vs IP-addresses. This is in this environment already happening, often using some vendor mechanisms or radius attributes. From that perspective, IPv6 is not more or less complex as IPv4. In IPv6 there are however, potentially more addresses to track, because the UE can auto-generate more explicit addresses (CGA, SLAAC, etc).

We started with this work as a solution for community WIFI service at Comcast. For this to be a quality and profitable service, it has to work for the largest denominator of devices trying to make usage of the service. Hence, the simplest method for giving a device an address is found the one that is best supported. This is the plain old simple SLAAC using Neighbor Discovery. So, we decided to tune SLAAC within the limits of the specification without breaking any existing specs of NDP and use that on the WLAN-GW. This was tested successful and worked the best and at scale at Comcast (most devices could do SLAAC and for the UE there is no change at all because all magic happens on the WLAN-GW or the BNG). So we decided to share this experience to the community because Comcast assumed more operators would be looking at exactly the same problem space. 

BTW, a nice summary of the problem that were raised in the many many emails on v6ops mailing list can be seen in an email from OPS area director.


  1. Why not going /127/8 for each host? Why to waste such a large segment for a p2p connection?
    With a summary from the access layer wlc vpn or access switch. And get rid of all this complexity
    1. Because SLAAC works only with /64 prefixes advertised in RA.
    2. Sure let's create a huge 2^64 segments this is exactly what we need.
  2. IPv6 comes in two deployments scenario one is Edge ISP aka Tier 3 ISP facing End Host scenario where generally IPv6 goes with DHCPv6 or DHCPv6 PD Prefix Delegation to the end hosts at the FHR scenario.

    IPv6 in DCs goes with SLAAC to the servers where we dont need DNS entries to the servers.

    Going with DHCPv6 PD on Edge ISPs and First Hop Router ( FHR ) announce /128 to the end hosts which is ideal scenario for DHCPv6.

    Using SLAAC and assigning /64 for each end host would be a waste of an IPv6 Space and the reason would be to differentiate the IPv6 end host to assign B.W rate and QOS/ACL policies via DHCPv6 PD Options configured from the BRAS server.

    Prefix Delegation would assign a bigger prefix /48 to the First Hop Router and from there it will assign /64 to each host for convenience and to assign QOS /ACL policy and that is also being deployed.

    The best practise or the way to look forward would be to assign /128 prefix via SLAAC using /64 prefix per site and not per host following the DC practice in assigning /128 per host using SLAAC where the hosts connected to the same Access Point/FHR/ in both Wireless Access Point or Wired Lines where ISPs get PD assigned from a bigger pool.

    Using SLAAC or DHCPv6 is again it depends on the use case. Usually ISPs prefer DHCPv6 PD [ extension to DHCPv6]

    DHCPv6 without PD gets smaller prefix length /64 and assign host address from the pool using manually assigned cluster files which assigns IPv6 based on Source MAC or any DHCpv6 Options.
    1. Next step: rewrite the RFCs to work the way you want them to work, and persuade Google engineers to implement your code in Android. Good luck.
    2. Ipv6 addressing is a luxury to many people and ideas are vanished because of the luxury.
  3. According to Geoff Houston:

    "If we really needed v6 like we need water, we would’ve died of thirst years ago" He argues that IPv4 and NAT are serving us just fine, and could serve us well for another couple of decades. There is no quick way out of the mess because what we thought we needed 20 years ago has now changed completely.

    With regards to IPv6 address waste, he mentions that after slicing and dicing IPv6 addresses in large blocks per host, rather than thinking the "IPv4 way" of using /128 per host/link, we really don't gain the huge number of IPv6 addresses as we may have initially thought. However, back to the point - I get the fact that ISP's need to uniquely identify an endpoint with a registered device... and searching through loads of NAT logs, etc and correlating it to some sort of date/time is not very fun.

    Ivan, I hope you don't mind me throwing in a link to some IPv6 discussion from the PacketPushers podcast, but I found this one particularly useful for this topic.

Add comment