using ULA for 'hidden' v6 devices?

[owen at delong.com (Owen DeLong)]

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.


Owen