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.
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.
The default source IPv6 address selection rules solve the ULA/global address selection challenge. These rules result in the following behavior:
- 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.
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...
best
Enno
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 ;)
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.
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 http://njetwork.wordpress.com/2014/01/19/ipv6-scopes-and-zones/.
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)?
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?