Re: using ULA for 'hidden' v6 devices?

[Owen DeLong <owen () delong com>]

On Jan 26, 2012, at 3:31 PM, Tim Chown wrote:

> On 26 Jan 2012, at 16:53, Owen DeLong wrote:
>
> > On Jan 26, 2012, at 8:14 AM, Ray Soucy wrote:
> >
> > > Does this mean we're also looking at residential allocations larger
> > > than a /64 as the norm?
> >
> > We certainly should be. I still think that /48s for residential is the right answer.
> >
> > My /48 is working quite nicely in my house.
>
> There seems to be a lot of discussion happening around a /60 or /56.  I wouldn't assume a /48 for residential 
> networks, or a static prefix.

I wouldn't assume anything. That doesn't change the fact that it is, really, the best thing to do.

> > > So a CPE device with a stateful firewall that accepts a prefix via
> > > DHCPv6-PD and makes use of SLAAC for internal network(s) is the
> > > foundation, correct?
> >
> > I would expect it to be a combination of SLAAC, DHCPv6, and/or DHCPv6-PD. Which combination may be vendor dependent, 
> > but, hopefully the norm will include support for downstream routers and possibly chosen address style configuration 
> > (allowing the user to pick an address for their host and configure it at the CPE) which would require DHCP support.
>
> Yes, the assumption is multi-subnet in the homenet, with a method for (efficient) prefix delegation internally.

Where the definition of (efficient) is highly flexible and almost certainly does not refer to bit conservation.

> > > Then use random a ULA allocation that exists to route internally
> > > (sounds a lot like a site-local scope; which I never understood the
> > > reason we abandoned).
> >
> > I can actually see this as a reasonable use of ULA, but, I agree site-local scope would have been a better choice. 
> > The maybe you can maybe you cant route it nature of ULA is, IMHO it's only advantage over site-local and at the same 
> > time the greatest likelihood that it will be misused in a variety of harmful ways, not the least of which is to 
> > bring the brain-damage of NAT forward into the IPv6 enterprise.
>
> Site-locals didn't include the "random" prefix element, thus increasing the chance of collision should two site-local 
> sites communicate.  See RFC3879 for the issues.

True, but, it would have been easy enough to correct that or provide registered site-specific site local addressing if 
that was desired.

> > > I'm just not seeing the value in adding ULA as a requirement unless
> > > bundled with NPT for a multi-homed environment, especially if a
> > > stateful firewall is already included.  If anything, it might slow
> > > down adoption due to increased complexity.
> >
> > I don't believe it adds visible complexity. I think it should be relatively transparent to the end-user.
> >
> > Basically, you have one prefix for communications within the house (ULA) and another prefix for communications 
> > outside. The prefix for external sessions may not be stable (may change periodically for operational or German 
> > reasons), but, the internal prefix remains stable and you can depend on it for configuring access to (e.g. printers, 
> > etc.).
> >
> > Sure, service discovery (mDNS, et. al) should obviate the need for most such configuration, but, there will likely 
> > always be something that doesn't quite get SD right somehow.
> >
> > Also, the ULA addresses don't mysteriously stop working when your connection to your ISP goes down, so, at least 
> > your LAN stuff doesn't die from ISP death.
>
> Consider also long-lived connections for example.  

Long lived connections are still doomed unless you go to the complexity of BGP-based multihoming, LISP, or something 
similar to one of those two. Personally, I use BGP multihoming for my home and it's working pretty well. YMMV.

> I don't think there's a conclusion as yet in homenet about ULAs, nor will a conclusion prevent people doing as they 
> please if they really want to.

Sad, but true.

Owen