IPv6 Address Allocation Is Operating System-Specific

The breadth of address allocation options available in IPv6 world confuses many engineers thoroughly fluent in IPv4, but it also gives operating system developers way too many options… and it turns out that different operating systems behave way differently when faced with the same environment.

2016-01-21: In the meantime, Luka got further details on Windows behavior, and Enno Rey provided a few additional links.

The Basics

Like in IPv4 world, it’s possible to configure static IPv6 host addresses. However, since every IPv6-enabled interface usually has more than one IPv6 address (at least a link-local address and a global one), some host operating systems decide to go for more than just the statically configured IPv6 address.

IPv6 addresses can also be assigned to hosts via DHCPv6. The hosts could send DHCPv6 request and hope for the best (which might be the action-of-last-resort if everything else fails) or listen to Router Advertisement (RA) messages and use DHCPv6 only if the RA messages contain the Managed configuration (M) flag.

However, you won’t see DHCPv6 requests sent from the hosts just because the RA messages contain the M flag – some host operating systems (like Android) decided not to implement DHCPv6 (in some cases because someone religiously believes in evilness of DHCPv6), or the administrator disabled DHCPv6 client, in which case the M flag has no chance of ever triggering a DHCPv6 request.

Finally, there’s stateless autoconfiguration (SLAAC). Whenever a RA message contains an on-link prefix with the Autoconfiguration (A) flag set, a host can automatically create an IPv6 address within that prefix (using its MAC address or a random generator).

The Differences

I guess you already spotted the vagueness of the previous section – the network devices cannot dictate the host behavior, they can only give hints on what’s available.

Some network operating systems (Linux) decide to use the first available mechanism: if you configure a static IPv6 address on a Linux host, it stops looking for alternatives (at least according to email exchanges on one of the mailing lists I’m tracking – it might be Linux distro specific, in which case please write a comment).

Other operating systems grab all they can: Windows will happily ask for a DHCPv6-assigned address whenever it receives an RA message with the M flag set regardless of whether it already has a static IPv6 address, and will add an autoconfigured address to the mix if the prefixes in the RA messages have the A flag set regardless of whether it already got static and/or DHCPv6-assigned addresses.

The only way to stop a Windows host from getting more addresses than you want it to have is to limit the options – don’t set the M flag in the RA messages if you want hosts to use static IPv6 addressing (or disable DHCPv6 clients on the hosts), and don’t set the A flag on prefixes if you want to use DHCPv6-assigned addresses. Oh, that breaks Android. Too bad – thank the overly biased people who can’t agree on what’s the proper way of doing things.

The Really Hard Part

Having multiple IPv6 addresses on a Windows host doesn’t look like a big deal until you try to figure out which source IPv6 address it will use for outgoing sessions (and source address selection rules are not really helpful in this case).

Here’s what Luka Manojlovič, one of the Slovenian IPv6/Windows gurus found out:

  • If a host has static and/or DHCPv6-assigned + SLAAC addresses, the SLAAC address is used for outgoing sessions;
  • When there’s no SLAAC-assigned address on the host, static address takes precedence over DHCPv6-assigned address.

The Windows behavior is based on RFC 6724 rule 5.5:

If SA or SA's prefix is assigned by the selected next-hop that will be used to send to D and SB or SB's prefix is assigned by a different next-hop, then prefer SA. Similarly, if SB or SB's prefix is assigned by the next-hop that will be used to send to D and SA or SA's prefix is assigned by a different next-hop, then prefer SB.

SLAAC-generated addresses are considered “assigned by the selected next-hop” (because they were generated based on RA which is also used to set the default next-hop information) and thus prevail over any alternate source IPv6 addresses.

Isn’t that wonderful? Try figuring out which source address to use in your firewall filter ;)

On a more serious note, stop stuffing things from multiple security domains into the same subnet (or start using microsegmentation). If all hosts in the same /64 prefix belong to the same security domain, it’s easy to write firewall rules.

More information

For more details, read the excellent test report written by Antonios Atlasis and Enno Rey. They tested several Linux distributions, two versions of Windows, and Mac OSX in eight different scenarios. Enno is also one of the authors of an IETF draft describing the problem.

For an overview of microsegmentation, see the corresponding section of my SDN Use Cases webinar, or explore the IPv6 Microsegmentation or Virtual Firewalls webinars for more details.


  1. Hi Ivan,

    thank you, very good overview and "problem statement". I've a couple of comments though. Unfortunately (namely from the perspective from environments with heterogenuous clients = all large enterprise) it is yet more complex, including:
    - starting from Win8 Windows even sends DHCPv6 Solicits when the m-Flag is *not* set (which in turn means, amongst others, that you can only prevent DHCPv6 from being used by stopping the local service!).
    - the behavior of Linux actually varies heavily between distros (see also sources below); I've seen/configured Linux systems using DHCPv6 address in addition to SLAAC provisioned ones.
    - as you stated, the interaction with source address selection is a complete mess. At some point even rule 5.5 from RFC6724 might come into play and similar nasty stuff.

    There's an IETF draft on some of this (disclaimer: I'm involved):

    thanks for bringing attention to this space ;-)

  2. and then people wonder why IPv6 adoption is slow.
    1. Well, I expected this comment from another Australian ;))
    2. It must be the sun or the food, or something.. :)
  3. It looks like windows always sends DHCPv6 request as last resort regardless of RA message. Enno Rey has published his observations of effects of RA messages with different operating systems in "IPv6 Router Advertisement Flags, RDNSS and DHCPv6 Conflicting Configurations" paper.
    I found it very interesting.
  4. And this is why I always disable RAs on server nets.
    1. Are you using DHCPv6 for server IPv6 assignments? Aren't server networks the one area you would prefer RAs over DHCP?

      I've built server networks that relied upon DHCP before, primarily using Infoblox redundant appliances with DHCP reserverations, but I've always thought of RAs as being freedom from an risky outside dependency.
    2. We use static assignments for all servers, so no SLAAC or DHCP. DHCPv6 is easy to avoid by simply not doing any DHCP server/relay on the server nets, but to keep servers from generating SLAAC addresses I have to disable RAs. Thank you Windows.

      (With SLAAC addresses creating firewall rules would be... difficult)
  5. Guys, maybe i'm totally wrong but this problem is adressed in RFC 6724 (that replaced RFC 3484) concerning default address selection algorithm (DAS) and Happy Eyeballs (RFC 6555), don't you think ?

    Maybe i'm living in an utopian world but i always been under the impression that source/destination address selection has nothing to do with the method that the OS used to get one (SLAAC, static, DHCPv6), even if each OS has different way to react to flag bit inside RAs...

    Am i totally wrong ?


  6. In theory that actually shouldn't be the case. However, reality is different - you just cannot rely on RFC 6724 today. For example, Windows uses an additional process called NCSI in order to figure out what address to use (at least for IPv4/IPv6) - see Ed Horleys Book on IPv6 Administration on Windows.

    1. Thanks for your reply Michael.

      I was under the impression that NCSI is more a replacement/modification of RFC 6724 for selecting IPv6 or IPv4 but was not related to the selection of a specific IPv6 source address (static ip address preferred over SLAAC address for example).

      I think that i need to make some reading.


    2. Sorry, you should read : replacement/modification of RFC 6555 (Happy Eyeballs) instead of RFC 6724. Sorry.
    3. Hi Martin,

      your impression is correct. I just wanted to say that there is not only RFC6724 but each OS seems to use it's own additional functions to determine what address to use.

  7. ... and all this circus instead of having a way of statically configuring interface ID and getting the prefix from RA.

    Let me explain :
    - server guys like static IP assignments (pretty much the same way we like static IPs on loopbacks).
    - in 99% of cases you can address a whole organisation's infrastructure in 64 bits (because you could do it in less than 32).
    - then how about seeing IPv6 for what it really became : 64 bit (max) routing prefix + 64 bit "something ID" (call it interface ID, host ID or whatever)

    There can always be an argument of how this is not good or how this can be accomplished otherwise (??? DHCP ??? - please NO), but change-wise IPv6 is sometimes already going too far (doesn't matter if it's in the good direction) to scare the hell out of most IT people. Isn't it concievable to give them little breaks on some issues ? Especially if we want deployment...
  8. I always say - do as you would do with IPv4 => DHCPv6 with onlink flag set.
    For datacenters same thing expect vlan where static address is needed => No RA
    You don't have to explain so much and it's much easier to deploy it for those who is beginner in IPv6.
  9. I only want to write that IPv6 is a standart, ¿how ..... the RFC does not force an addressing standart?
Add comment