[148938] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: using ULA for 'hidden' v6 devices?

daemon@ATHENA.MIT.EDU (Cameron Byrne)
Thu Jan 26 12:10:42 2012

In-Reply-To: <0E87A1C3-17A2-43AD-9395-CD2B359FBD43@delong.com>
Date: Thu, 26 Jan 2012 09:09:53 -0800
From: Cameron Byrne <cb.list6@gmail.com>
To: Owen DeLong <owen@delong.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

On Jan 26, 2012 8:44 AM, "Owen DeLong" <owen@delong.com> wrote:
>
>
> 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.
>

I have a very different opinion. Nat64/ dns64 fits my needs great

Horses for courses.

Cb
>
> Owen
>
>

home help back first fref pref prev next nref lref last post