[148926] in North American Network Operators' Group
Re: using ULA for 'hidden' v6 devices?
daemon@ATHENA.MIT.EDU (Jima)
Thu Jan 26 09:40:58 2012
In-Reply-To: <C2A511E3-CB4D-43BF-9C51-505D81C31E8A@delong.com>
Date: Thu, 26 Jan 2012 07:39:58 -0700 (MST)
From: "Jima" <nanog@jima.tk>
To: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
> 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.
Jima
