Source IPv6 Address Selection Saves the Day

My recommendation to use ULA addresses for internal communications within organizations that don’t have their own provider-independent address space resulted in the following comment:

[…] Having ULA for internal company communication and global IPv6 addresses for communication with the Internet will cause lots of issues with application guys since now application has to bind to specific IPv6 address for internal communications and another IPv6 address to go to the Internet.

Numerous aspects of IPv6 may still be broken, but fortunately this is not one of them.

I missed a crucial detail: because RFC 6724 prefers IPv4 addresses over ULA addresses, impossible to use ULA addresses in dual-stack networks. Even this aspect of IPv6 is broken :(

Client-Side Behavior

Every major IPv6 protocol stack includes source IPv6 address selection functionality specified in RFC 6724 (or its predecessor, RFC 3484). These rules select source IPv6 address of an outgoing TCP session or UDP packet in instances when the application doesn’t specify it.

Things were simpler in the IPv4 world as most hosts had a single IPv4 address on each interface. Every IPv6 host able to communicate beyond the local subnet has at least two operational IPv6 addresses, one of them being link-local address.

The default source IPv6 address selection rules solve the ULA/global address selection challenge. These rules result in the following behavior:

This is a good-enough oversimplified description. Read the RFC 6724 for details.
  • If the destination IPv6 address is ULA, and the source host has an ULA address, the ULA source address is used;
  • If the destination IPv6 address is a global address, and the source host has a global IPv6 address, the global source IPv6 address is used;
  • If the destination IPv6 address is ULA, and the source host doesn’t have an ULA address, it uses whatever other IPv6 address is available (preferring global IPv6 addresses over alternatives);
  • If the destination IPv6 address is a global IPv6 address and the source host has an ULA address but no global IPv6 address, it tries to use the ULA source IPv6 address (and might reach the destination or not).

Summary: no problem on the client side. No additional administrative burden (read: default address selection policies built into major operating systems work just fine) if you use ULA+global addresses.

Server-Side Behavior

Many applications bind themselves to a wildcard socket address – they accept incoming connections addressed to any IPv4/IPv6 address available on the destination host. These applications would accept incoming connections addressed to global or ULA addresses configured on a server. Is that a problem? Usually it isn’t (but of course it all depends).

Security aspects: You might want to block incoming connections to global IPv6 address configured on the server. No problem, use a host firewall available in every major operating system, or an ACL on the first-hop layer-3 switch. Security by obscurity (using internal addresses only) or partial reachability has never been a good idea anyway.

Service reachability aspects: Even though a server accepts incoming connections to its ULA and global IPv6 addresses doesn’t mean the clients will use them. If the internal DNS contains ULA addresses of internal servers, most clients won’t use servers’ global IPv6 addresses anyway. If you’re worried about potential intruders, read the preceding paragraph.

Finally, do we need global IPv6 addresses on internal servers? It depends on whether the servers have to reach the global Internet. You might decide to use only ULA addresses on these servers and connect the public-facing servers to the global Internet through a load balancer (a stateful NAT66 implementation with no religious connotations).

Summary: a combination of global IPv6+ULA addresses on the servers does not introduce new problems (but might expose shoddy practices used in the past).

Need More IPv6 Information?

My IPv6 webinars and public presentations will help you plan, design and deploy IPv6 in your network.


  1. Hi Ivan,

    I strongly disagree. In real-life we regularly see problems with source address selection (granted: usually in cases where, for whatever reasons, several GUAs exist in parallel on $INTERFACE). I've had several cases where going through RFC 6724 rule-by-rule did not explain why $CLIENT acted the way it actually did and I've even seen cases where this changed "by minute".
    Personally I don't expect source address selection to be fully solved in the near future, which is one of the reasons why we strongly recommend to keep the number of addresses on a given interface as small as possible. "if there's a decision problem, reduce the number of choices" [can help in other parts of life, too ;-)]

    For interest: can anybody confirm source address selection as of RFC 6724 (3484) to properly work in a sufficiently heterogeneous/complex network? I'd be very interested...


    1. I would never recommend having multiple GUAs (from different prefixes) per interface - that's asking for trouble (I wouldn't expect host stack vendors to test that scenario).

      If you ever find a host stack where ULA+GUA combination doesn't work as expected, shout about it - they deserve to get the heat ;)
    2. There actually are cases of multiple GUAs, such as with full dual stack DSL connections. One GUA prefix is recent, while a second GUA prefix is being phased out over the course of the next 4 hours or so. However, at least the RFCs are designed to properly handle this and so far I didn't see any issues in a heterogenious environment with Linux Kubuntu, various Androids, Win7 and Win8.
  2. What happens with address selection when client joins a multicast address. Which one is used ULA or GUA?
    1. ... and here's another reason I avoid multicasts as much as I can ;=)

      No idea - you might find the answer in the IPv6 Source Address Selection RFC (there's also a pretty good document describing Windows behavior), and then I'd strongly recommend you verify the actual OS behavior with a few tests.
  3. Hi Ivan!
    I strongly support your recommendation, specially in the environment where IPv6 addressing relies on external and centralised DHCPv6. Usage of ULA can solve many problems in case of DHCP-server isolation, at least it reduces the impact to internal services during the outage.
    And yes, in principle a packet with ULA source should reach a global destination within the administrative scope and vice versa. I've tried to explain this issues here
  4. A basic discussion I am missing is about how to assign ULA and GUA to a client. DHCPv6 cannot do the job. Therefore, you need - that´s my oppinion - a combination of SLAAC (e. g. Router advertising ULA Prefix and M-Flag =1) and DHCPv6 (responsible for the GUA prefix) ... or SLAAC is doing tha job alone (because it can advertise ULA and GUA prefix). Nevertheless, SLAAC is is like a red rag to a bull for administrators of big networks like NAT is for IPv6 purists ;-)

    Any best practices here. Technically the combination of DHCPv6 with SLAAC will work (even if M-Flag is 1 the client will learn the prefix from a router advertisement as well). But isn´t this one more step to make IPv6 again a liitle bit more complicated (not complex)?
  5. By itself, the notion of having ULA and GUA, on the same system, makes little sense. Clearly it can be done, even just with slaac and multipIe advertised prefixes.

    I think one thing you might be reaching for is privacy extensions with SLAAC RFC 4941? But, I'm not really sure what problem you're trying to solve. Why would you want to have two addresses where one address routes over all of the same networks and more, but the other only routes over a subset of those? The only reasons I can think of would be based on an application requirement.

    I suspect the other concept you're trying to reach for is a firewall to allow only the traffic you want through the GUA address that you ultimately use.

    Again, what does it gain you?
    1. Have you read the blog post I linked to in the intro paragraph?
Add comment