using ULA for 'hidden' v6 devices?
owen at delong.com
Thu Jan 26 21:47:15 CST 2012
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.
More information about the NANOG