[148931] in North American Network Operators' Group
Re: using ULA for 'hidden' v6 devices?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jan 26 11:44:44 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <57748.2001:49f0:a057:0:e445:864a:3cd0:5c9a.1327588798.squirrel@laughton.us>
Date: Thu, 26 Jan 2012 08:41:58 -0800
To: Jima <nanog@jima.tk>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>=20
> 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.
>=20
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.
>=20
> 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.
>=20
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
