using ULA for 'hidden' v6 devices?

Owen DeLong owen at
Thu Jan 26 16:41:58 UTC 2012

On Jan 26, 2012, at 6:39 AM, Jima wrote:

> On 2012-01-26, Owen DeLong wrote:
>> If you can't point to some specific advantage of ULA over secondary
>> non-routed GUA prefixes, then, ULA doesn't have a reason to live.
> My biggest concern with secondary non-routed GUA would be source address
> selection.  If you're trying to talk to something in 2000::/3, it's
> obvious to the OS that it should be using its address in 2000::/3 rather
> than the one in fc00::/7.  When both the "external" and "internal"
> addresses live in 2000::/3, more care has to be taken to ensure the
> system DTRT.

It's very easy to configure SAS to handle this. Frankly, you have the same challenge with ULA in many scenarios.

>> I'm not sure where DNS64/NAT64 comes into play here for v6 to v6
>> communication. For IPv4, I don't see any advantage in ULA+NAT64 vs. the
>> more reliable and easier RFC-1918 with NAT44 possibilities, even if you
>> have to run multiple RFC-1918 domains to get enough addresses, that will
>> generally be less complicated and break fewer things than a NAT64
>> implementation.
> My best guess there is the ability to a) only manage a single-stack
> network (I really wish more software supported IPv6 so this could be a
> more feasible reality), and b) use the same NAT64 prefix across various
> NAT64 instances (64:ff9b::/96 is a blocker if you actually want to allow
> NAT64 to RFC1918 space).  While I can see the potential appeal of the
> second point, I'm not sure I'd agree with it myself.

But with NAT64, you're supporting both stacks, you just move the problem around.

Having done experiments with both methods, I assure you it is a true statement based on experience. NAT64 really offers more problems than it solves, not the least of which is the stateful DNS interaction problem.


More information about the NANOG mailing list