IPv6 Configuration Approaches for Servers

In this post I’ll discuss configuration approaches for systems which usually have been configured with “static” IP parameters in the IPv4 age/context (like servers in data centers). 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 mainly four possible approaches which we see being implemented or considered in our (predominantly enterprise) customer space. Before we have a closer look at those let’s quickly write down requirements that the involved planners or sysadmins might have in mind when it comes to provisioning 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:

• evidently completeness (and correctness) of IP configuration information, particularly taking into account that there might be 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 (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) actually asking for it.
• security: the degree of resistance against link-local attacks (namely rogue router advertisements) might play a role when opting for a strategy or another.
• operational feasibility (be able to achieve to 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 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 & operations hygiene reasons. We know one (quite “IPv6 mature”) environment where static addresses are assigned with random values, in order to force sysowners to use 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 router advertisements) have to be disabled on the local systems. While this can be done from a technical perspective (e.g. see slide 18 of this talk), here the operational feasibility and the resulting overhead must be carefully considered. In some cases, for example after a compilation of a new kernel or the installation of a certain patches/service packs in the Windows world, systems might start again to process router advertisements. Also this measure results in a significant “deviation from default” – I mean router advertisements are the core packets of the IPv6 universe (I sometimes compare the reception of RAs to the prince kissing the sleeping beauty 😉 – so 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 (incl. deactivation of local RA processing) provides high level of predictability and traceability.
• Good resistance against RA-related attacks.

Disadvantages include:

• Requires significant operations effort to be configured in a way to properly achieve objectives listed above under “advantages”.
• Networks 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 sceptical as for the long-term operational consequences this might have.

Accompanying Configuration of (L3) Devices:

• No router advertisements needed at all, so those can be suppressed, e.g. by means of “ipv6 nd ra 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 (e.g. 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.
• 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 (like HSRP, VRRP) works more smoothly than in “full static [local configuration] mode”, but we can not really confirm this.

Disadvantages:

• High resistance against RA-related security issues can only be achieved by a combination of RA guard and RFC 6980 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 router advertisements (e.g. “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 router advertisements, e.g. “ipv6 nd ra dns server 2001:db8:1:1::53”), see also RFC 6106.

Overall we have quite some sympathy for this and we recommend to consider taking this route if you’re inclined to have static addresses on servers (which most people do. you know humans love [the perception] to be 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 RFC 7217 Together with Dynamic DNS Updates

This is an interesting approach which we’ve recently seen being discussed in a customer organization. The idea here is to generate a SLAAC address which is stable (as long as a system stays within a given subnet) and then populate 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 RFC 4941.

Advantages:

• Doesn’t need much tweaking of router advertisements.
• Serves objectives 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 RFC 7217 (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 require RA guard + RFC 6980 combo (or port-/VLAN-based ACLs).
• NTP servers still have to 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 from 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 (e.g. 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 RFC 6939 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 Adresses, DNS resolver(s) and NTP server(s) can all be distributed.

Disadvantages:

• DHCPv6 often turns out to be a somewhat unreliable/immature beast.
• Need of RFC 6939 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).

===

At the end a quick remark in own matters: some people have reached out and asked us if there’ll be another IPv6 Security Summit in the course of next year’s Troopers conference. As we nowadays consider IPv6 a commodity technology (there’s no dedicated IPv4 security events either…) we decided not to run the IPv6 Sec Summit anymore. There will be, however, an IPv6 track in a new Troopers side conference called “Next Generation Internet” (NGI). We think that’s the right frame to discusss the security aspects of one of the core protocols of the future Internet 😉

We wish everybody relaxing holidays; have a Merry Christmas and a Happy New Year!

Enno