In this post, I’ll discuss configuration approaches for systems that usually have been configured with “static” IP parameters in the IPv4 age/context (for example, servers in data centres). When it comes to IPv6 there are more options and we’ll have a look at their implications and potential advantages/disadvantages.
From my perspective, there’s predominantly four approaches that we see being implemented or considered in our (predominantly enterprise) customer space. Before we take a closer look at those, let’s quickly write down the requirements the involved planners or sysadmins might have in mind when it comes to providing the systems in question.
Some of those requirements might seem obvious but it could still make sense to note them for the discussion to follow. These might include:
- Evident completeness (and correctness) of IP configuration information, particularly taking into account that there might be a certain degree of dynamics in a network (VM mobility…).
- Predictability: we want a given system to have – or at least to use for certain communication acts – a specific [IPv6] address at any given point of time.
- Traceability: to be able to identify systems involved in certain communication acts. This is somewhat interrelated with predictability but it might be other people (like infosec) or different situations (troubleshooting) asking for it.
- Security: the degree of resistance against link-local attacks (namely rogue router advertisements (RAs)) might play a role when opting for one strategy over another.
- Operational feasibility: to be able to achieve the above objectives with a finite amount of operational resources, and keeping in mind that operational complexity negatively impacts security.
Parameters to be provisioned
It’s assumed the following parameters are needed for proper operations of a system:
- Global IPv6 address
- Default gateway/route
- DNS resolver(s)
- NTP server(s)
On the role of the DNS
We argue that it’s a mandatory requirement for the systems in scope to have proper DNS (both forward [AAAA] and reverse [PTR in ip6.arpa]) records, not only for functionality (think mail exchangers) but also for system management and operations hygiene. We know one (quite “IPv6 mature”) environment where static addresses are assigned with random values, in order to force sysowners to use the DNS…
1st Approach: Fully static configuration
In this variant, all of the above parameters are configured in a static manner. This approach can often be found in environments striving to mimic a configuration approach similar to what they did with IPv4.
However, it must be kept in mind here that the mere configuration of static IPv6 parameters does (in contrast to IPv4) not disable the potential concurrent performance of dynamic procedures (such as stateless autoconfiguration/SLAAC). To achieve that objective, all such dynamic IPv6 mechanisms (namely the processing of RAs) have to be disabled on the local systems.
While this can be done from a technical perspective (for example, see slide 18 of this talk), the operational feasibility and the resulting overhead must still be carefully considered. In some cases (for example, after a compilation of a new kernel or the installation of certain patches/service packs in the Windows world), systems might start processing RAs again.
This measure also results in a significant “deviation from default”. What I mean by this is RAs are the core packets of the IPv6 universe (I sometimes compare the reception of RAs to the prince kissing the sleeping beauty). Therefore, keeping a heterogeneous landscape of systems in a state they’re not supposed to be (and doing so over their full lifecycle) might pose operational challenges, and might as well, induce unforeseen side effects.
Advantages of this approach include:
- Accommodates human desire to be in control.
- If applied properly (including deactivation of local RA processing), it provides a high level of predictability and traceability.
- Good resistance against RA-related attacks.
Disadvantages include:
- Requires significant operational effort to be configured in a way to properly achieve the advantages listed above.
- Network dynamics might lead to the need to renumber, which still needs work.
- As stated before, this approach somewhat violates core IPv6 principles (RAs being the “source of life” for an IPv6 stack). Please note that this statement is not about blindly defending a certain protocol architecture; I’m just skeptical as to the long-term operational consequences this might have.
Accompanying configuration of (L3) devices:
- No RAs are needed so those can be suppressed, for example, by means of “ipv6 nd suppress all” on Cisco IOS (“all” includes RS-induced RAs and was introduced in 15.1(3)T3).
- Any occurrence of an RA in the local subnet (for example, those detected by a combination of RA guard on [physical] switch ports and “ipv6 snooping logging packet drop”) would raise suspicion.
To be honest, we don’t like this approach too much (due to the operational implications) but we’re aware that, as of today, most environments have deployed it or consider doing so in their server subnets (like DMZ networks).
2nd Approach: “Hybrid” with Static Address but Default Route via RA
Here, “hybrid” means:
- Configure IP address and NTP server(s) in a static manner.
- Either configure DNS server(s) in a static manner or learn them from RAs (which currently does not work on Windows).
- Learn default gateway from RAs.
Advantages include:
- Does not require disabling of local RA processing with all its heavy operational implications.
- A higher degree of flexibility (for example when changing DNS resolvers).
- Some people think that the interaction of local systems with the first-hop redundancy protocols (for example, HSRP and VRRP) works more smoothly than in “full static [local configuration] mode”, but we cannot confirm this.
Disadvantages:
- High resistance against RA-related security issues can only be achieved by a combination of RA guard and RFC6980 support on the server OSs (which Linux has, even enabled by default, but Windows does not) or alternatively Port- or VLAN-based ACLs, with the latter potentially not being desirable from an operations perspective ;-).
Accompanying configuration of L3 devices:
- Clear prefix information option (PIO) in RAs (for example, “ipv6 nd prefix 2001:db8:1:1::/64 no-advertise”).
- Add option 25 (recursive DNS server, RDNSS) and potentially option 31 (DNS search list, DNSSL) to RAs (for example, “ipv6 nd ra dns server 2001:db8:1:1::53”). See also RFC6106.
Overall we have quite some sympathy for this and we recommend that you consider taking this route if you’re inclined to have static addresses on servers (which most people do – you know humans love [the perception of] being in control…). We are aware of at least one sufficiently complex environment doing this and being happy with the operational aspects.
Stable addresses as of RFC7217 together with dynamic DNS updates
This is an interesting approach that we’ve recently seen being discussed in a customer organization.
The idea here is to generate a SLAAC address that is stable (as long as a system stays within a given subnet) and then populate the DNS with this address (assuming that communication acts with the system only take place via its DNS name anyway). The DNS resolvers have to be distributed by means of RAs here and NTP servers by some other means.
This can (and for the type of networks discussed here: SHOULD) be accompanied by disabling the generation of additional temporary addresses as of RFC4941.
Advantages:
- Doesn’t need much tweaking of RAs.
- Serves the objectives of predictability and traceability.
- Low (if at all) renumbering effort in case of network changes (system moves to another subnet).
Disadvantages:
- Involved operating systems must support RFC7217 (which, to the best of our knowledge, currently is not the case for Windows, but Linux – and some others – do[es]).
- In many cases, unauthenticated DNS updates will be required, which your infrastructure sec guys or DNS admins might like or not, and which can induce some other security issues.
- Given the requirements (support of RFCs 6106 and 7217) this is currently not possible for Windows systems.
- Proper protection from rogue RAs requires RA guard plus a RFC6980 combo (or port-/VLAN-based ACLs).
- NTP servers still have to be distributed by some other means.
Accompanying configuration of L3 devices:
- Pretty much default, but RDNSS must be distributed via RAs.
- Optionally, clear L-flag in PIO for PVLAN-like behavior (it should be noted that the isolation property achieved by clearing the L-flag can easily be circumvented by an attacker having high privileges, who subsequently can actually reach systems in the same segment in a direct manner, by either adding host routes [for systems to-be-attacked] or a “network“ route for the local subnet).
DHCPv6 with reservations
Like the 1st approach laid out above, this one is, to some extent, familiar to the IPv4 world.
Still, it should be noted that configuring reservations on $DHCP_SERVER can be tricky as it might either require manual steps once an initial DHCPv6 procedure took place (for example, on the Windows DHCP server one can convert an existing lease into a reservation in the GUI) or it might require heavy configuration tweaking (because support of RFC6939 is needed) as, for example, laid out in this post.
Advantages:
- The closest you can come to centralized IP parameter provisioning (and administration), which in turn supports predictability and traceability.
- IPv6 Addresses, DNS resolver(s) and NTP server(s) can all be distributed.
Disadvantages:
- DHCPv6 often turns out to be a somewhat unreliable/immature beast.
- The need for RFC6939 support might be a show-stopper. To the best of our knowledge, it’s not supported in Cisco IOS so far (but available and even enabled by default in IOS-XE).
Accompanying configuration of L3 devices:
- All that’s needed to operate DHCPv6 (m-flag in RAs et al).
- Think about setting the L-flag in the PIO if needed (see also this post or this talk from the Troopers15 IPv6 Sec Summit for the intricacies of the flag in the DHCPv6 context).
Original post appeared on Insinuator
Enno Rey is a long-term IPv6 enthusiast with lots of practical experience in the space.
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.