In the 6MAN working group, the hot topic on the floor was the /64 boundary. There is a sense the operations community doesn’t want proscriptive and hard limits put in place, which runs counter to some views in the documentation being worked on.
It wouldn’t alter how we do address management—it’s not aimed at altering the /56 or /48 model under H/D ratio—but it does raise interesting questions about internal network management methods. Several voices here are in the business of writing code that winds up in Android or Microsoft Windows, so this is not a marginal question for them!
There is quite a long history behind the decision to embed a /64 boundary for some forms of address management, because it allowed people to design to sources of identity on the host, such as the E.164 device identifier, which naturally encodes into a /64 host identity part, and then subsequently the design of privacy-mode addressing has leveraged this to use a large bitfield as a random number space to encode in.
It’s a small but important point, because what’s supported by a host doing network address assignment has a huge impact on how operating networks are designed and built.
So if we build to a model of a /64, there is a concern some networks will allocate a /64 to people in a belief this binds to a ‘single customer’. Now, we know as IPv6 users that we actually want people to be empowered to have subnets, and construct more concrete complex home networks, and that we expected people to be given a /60 or a /56, which permits that kind of structure over a /64.
But now, we see in address architectures with a concrete /64, people constructing that home network inside the single /64 and so end up wanting to identify each subnet by a longer prefix. This isn’t ideal, but it’s also a problem that isn’t going to just go away.
In some ways, this is competing-standards time. We have RFC4941 defining SLAAC and it says some things that tend to enshrine the /64. But this is in itself a bit up in the air — not everyone is happy with this. And we have RFC4291, which is the fundamental addressing architecture. And, again, it has some language that is contentious.
We’re now down in the field of disagreeing about what SHOULD be considered against what MUST be, in what is called ‘normative’ language, the bits of the RFC that are trying to say formally what has to be adhered to.
Part of this discussion is also exploring the difference between DHCP and SLAAC: the difference between managed, stateful address assignment, and stateless, changing, auto-configuration models of address management.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.