[148971] in North American Network Operators' Group
Re: using ULA for 'hidden' v6 devices?
daemon@ATHENA.MIT.EDU (Tim Chown)
Thu Jan 26 18:32:22 2012
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <26066EA7-A326-4CD2-BF88-F31D2BBE5F0A@delong.com>
Date: Thu, 26 Jan 2012 23:31:41 +0000
To: NANOG list <nanog@nanog.org>
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 26 Jan 2012, at 16:53, Owen DeLong wrote:
> On Jan 26, 2012, at 8:14 AM, Ray Soucy wrote:
>=20
>> Does this mean we're also looking at residential allocations larger
>> than a /64 as the norm?
>>=20
>=20
> We certainly should be. I still think that /48s for residential is the =
right answer.
>=20
> 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.
>> 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?
>=20
> 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.
>> 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).
>=20
> 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.
>> 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.
>=20
> I don't believe it adds visible complexity. I think it should be =
relatively transparent to the end-user.
>=20
> 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.).
>=20
> 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.
>=20
> 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. =20
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.
Tim=
