At first a very happy new year to all readers, and all the best for 2021!
While I wrote a few posts about IPv6-related topics in the past – for many years here and later on the present blog – it seems I never contributed to the ‘classic SLAAC vs. DHCPv6’ debate, besides documenting the behavior of different OSs in a long-expired Internet Draft + in this talk at RIPE70 and besides some ranting about DHCPv6.
Let’s change this today ;-). Here’s a post on those two. It’s a bit inspired by Fernando‘s recent talk on CVE-2020-16898 at the UK IPv6 Council Annual Meeting 2020 (some notes from the event here) in which he briefly covered the differences between both provisioning approaches incl. this slide:
I’d like to add some further perspective on the two. For that purpose I think it’s helpful to differentiate between the (network- or ‘environment level’-) operator point of view and the host perspective, as different parties (potentially pursuing very different objectives) can be responsible for those. Also it might make sense to differentiate between deployment scenarios like data centers or campus networks (some initial discussion of those here).
Let’s first look at the host/the ‘client’ which receives parameters or ‘instructions’ from one of the mechanisms (or from both, in certain settings). From its perspective the following objectives come to mind:
- Completeness: for the IP-level operation of a host certain parameters (some discussion here) and information bits are needed, and those have to be provided by ‘the environment’, that is from network components, additional systems offering certain services and the like.
- Simplicity: whatever happens keep it as simple as possible, from a general configuration perspective but also when it comes to components (like pieces of software, e.g. daemons, which have to be started, configured, maintained, patched etc.).
- Security: the security attributes (or lack thereof) of the two mechanisms can play a role for the provisioning strategy in a given environment. At this point it should be noted that, in general, I think that inherent security issues of RAs and DHCPv6 packets should be addressed on the infrastructure level and not by hosts themselves (hence rules 5 and 6 in this post).
- Support: this is seemingly evident, but still worth a mention/consideration. The configuration approach has to be supported at all (at least in an operationally feasible way, e.g. without installing additional 3rd party components) by the client platform(s) in question for a specific network or use case. Here it should be noted that as of RFC 8504 IPv6 Node Requirements SLAAC is a mandatory element of an IPv6 stack (‘MUST’ be supported, in RFC 2119 terminology) whereas DHCPv6 ‘SHOULD’ be supported (while this capital-letter statement in an RFC is a much stronger claim than a ‘common language’ interpretation of ‘should’, it’s still weaker than a ‘MUST’). For example it’s well known that Android does not support DHCPv6, which might have implications on the overall configuration approach of an environment.
From the perspective of the ‘operator’ (of the network infrastructure and/or of the servers being part of an overall provisioning picture, like DHCPv6 or TFTP servers for UEFI netboot) the following objectives may play a role:
- Functionality: it has to work ;-).
- Simplicity: whatever happens keep it as simple as possible.
- Security: the fewer components involved, the less vulnerability exposure.
- Support: different use cases and client platforms.
- Traceability: in many environments the capability to identify systems involved in security violations (be them security incidents, be them violations of intellectual property regulations, e.g. in university networks) is an important consideration. Traditional thinking often stated DHCPv6 would strictly be needed for this, but this might not be the case.
- Control: for system management and inventory purposes in data centers there’s often the desire to assign IP(v6) addresses to systems in a controlled way. Usually this precludes the use of SLAAC.
Now let’s have a look at both mechanisms in different scenarios.
Client perspective, campus networks
In the vast majority of networks I’ve seen in the last years going with SLAAC (with RDNSS) was/is considered fully sufficient. Recent examples of v6-only Wi-Fi networks like this one or this one) took this route, and I’ve also seen this in large conference networks (e.g. Cisco Live Europe 2019). I’m aware that back in 2019 Chris Werny and I recommended (in our talk on IPv6-only in Wi-Fi networks at Troopers) going with an approach of both SLAAC+RDNSS and stateless DHCPv6 in parallel, but I don’t think this is still needed in 2021, except for networks
- where support for clients without RDNSS abilities is needed (namely Windows before Win10)
- where IP parameters other than address(es), default gateway and DNS resolvers have to be provisioned by the network infrastructure (as opposed to be provisioned via other centralized mechanisms influencing the behavior of hosts like MS Active Directory/Group Policies or the like). VoIP telephones are an often-cited example of systems possibly needing DHCPv6, but I’ve yet to encounter such a deployment irl.
In campus networks going with SLAAC clearly wins with regard to the objectives ‘simplicity’ and ‘support’.
Client perspective, data center networks
Let’s first assume that we usually see a very different mix of operating systems in such networks (than in campus networks). Let’s further assume that from the operator side DHCPv6 might be a preferred option (pursuing the ‘simplicity’ objective and assuming that at least *some* systems in the DC might require DHCPv6 for netboot purposes). From my perspective there’s two aspects/objectives that deserve special attention here:
- Security: while probably most dual-stacked clients in campus networks run a DHCP client, this is not necessarily the case in DC environments. Adding a DHCP(v6) client on systems can increase their vulnerability exposure, e.g. see CVE 2018-1111 in RHEL discovered a while ago by Felix Wilhelm with whom I had the pleasure to work for a few years.
- Support: I have seen a few special-purpose appliances (both virtual and physical ones) commonly found in DC environments which only supported SLAAC, but not DHCPv6. Obviously ‘just installing dhclient’ might not be an option for such systems.
For the above reasons SLAAC might be a viable, or even required, option for hosts in data center networks, too, but this might collide with an organization’s system management & control approach. On the other hand SLAAC and particularly container networks have a lot in common (think existence of ephemeral entities and reliance on DNS).
Operator perspective, campus networks
In case the operator is responsible only for the network infrastructure, but not for the client environments (which is a common case in ISP scenarios), there’s usually a strong focus on ‘support’ (of as many different client platforms as possible) but not on any other of the above objectives. With regard to this one SLAAC is the better option.
A network operator can choose to provide both mechanisms at the same time, in order to support as many heterogenous clients as possible (which can lead to interesting results on the client side, e.g. see the Comcast approach described here. I still don’t understand the reasoning for doing SLAAC [with A-flag] and managed DHCPv6 in parallel).
In case the operator is also responsible for the hosts (e.g. enterprise networks), the picture is usually more nuanced. Here often traceability plays a major role. DHCPv6 is often considered helpful in this context, but it might not be the only option.
I’d hence say that going with SLAAC (only) provides advantages from the (enterprise) operator perspective as well, provided the traceability angle can be solved without DHCPv6. It might also facilitate things in the security context (focus on rogue RAs only instead of addressing DHCPv6 related threats as well).
Operator perspective, data center
As of 2021, UEFI netboot over IPv6 practically always requires DHCPv6 (option 59 et al.) so it’s a fair assumption that DHCPv6 can be found in many data centers.
As I discussed in this post on ‘IPv6 configuration approaches for servers’ there might furthermore be the approach to (ab)use DHCPv6 reservations as a mechanism to assign specific addresses to specific systems, based on a centralized database (or several ;-). In this case the infrastructure (DHCPv6 relay agents running on ToR switches, and the DHCPv6 servers themselves) often needs to support RFC 6939, which, as far as I can see, might still not be easy as of today, given the lack of support of RFC 6939 in network gear. Another potential obstacle: the (from the DHCPv6 process perspective) ‘client’ – which actually is a ‘server’ 😉 – could show up with different MAC addresses during different stages of the netboot process which can create additional challenges… I may discuss intricacies of this in another post ;-). Overall it seems that IPv6-based netboot is a real PITA in many environments, e.g. see this presentation on v6-only at the Imperial College London.
Still, for the purpose of our discussion we have to note that DHCPv6 may very well be a mandatory requirement in many DC environments. The operator then has to decide between pursuing the ‘simplicity’ objective (by going with DHCPv6 as the only possible approach) and prioritizing the ‘support’ objective (by allowing both mechanisms for hosts in the DC, which ofc increases the overall complexity of the environment).
Personally I think that supporting SLAAC in DC environments might be inevitable in the mid-term due to the considerations laid out above in the ‘Client perspective in DCs’ section. As an additional note I have to admit I’ve never been a big fan of DHCPv6 at all as I’ve seen too many interoperability and instability issues during my years performing projects in various large organizations (pre mid-2019), but things might have developed to the better in the interim. Happy (seriously!) to hear your success story of a stable large-scale deployment of DHCPv6, either in a campus network or in a data center.
Thanks for reading so far, and happy IPv6 networking in 2021 to you all!