[148933] in North American Network Operators' Group
Re: using ULA for 'hidden' v6 devices?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jan 26 11:56:49 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CALFTrnOr+uvZFpW3hUoMpEs3cdf9X+SUygn1z=K8ZFEAnsGcDg@mail.gmail.com>
Date: Thu, 26 Jan 2012 08:53:28 -0800
To: Ray Soucy <rps@maine.edu>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 26, 2012, at 8:14 AM, Ray Soucy wrote:
> Inline
>=20
> On Thu, Jan 26, 2012 at 9:05 AM, Tim Chown <tjc@ecs.soton.ac.uk> =
wrote:
>> Thanks for the comments Ray, a couple of comments in-line.
>>=20
>> On 26 Jan 2012, at 12:43, Ray Soucy wrote:
>>=20
>>> Local traffic shouldn't need to touch the CPE regardless of ULA or
>>> GUA. Also note that we already have the link local scope for =
traffic
>>> between hosts on the same link (which is all hosts in a typical home
>>> network); ULA only becomes useful if routing is involved which is =
not
>>> the typical deployment for the home.
>>=20
>> The assumption in homenet is that it will become so.
>=20
> Does this mean we're also looking at residential allocations larger
> than a /64 as the norm?
>=20
We certainly should be. I still think that /48s for residential is the =
right answer.
My /48 is working quite nicely in my house.
>>> ULA is useful, on the other hand, if NPT is used. NPT is not NAT, =
and
>>> doesn't have any of the nastiness of NAT.
>>=20
>> Well, you still have address rewriting, but prefix-based.
>=20
> I think that the port rewriting, and as a consequence not being able
> to map to specific hosts easily, was the bigger problem with NAT.
>=20
No, the need for ALGs is the biggest problem with NAT. NPT does not =
resolve that issue.
Yes, port rewriting and other issues are also problematic, but, they are =
less problematic than the need for ALGs.
> As for the comments made by others regarding "helpers" for NAT, there
> really aren't many that are needed aside from older pre-NAT protocols
> like H.323 which decided it would be a good idea to use the IP in the
> packet payload for authentication. Thankfully, over a decade of NAT
> has helped end this practice.
Yes, it has blocked innovation in protocols that can't easily engineer =
around NAT. Hopefully we can stop doing that soon.
>=20
>>> I think a lot of the question has to do with what the role of CPE =
will
>>> be going forward. As long as we're talking dual-stack, having
>>> operational consistency between IPv4 and IPv6 makes sense. If it's =
an
>>> IPv6-only environment, then things become a lot more flexible (do we
>>> even need CPE to include a firewall, or do we say host-based =
firewalls
>>> are sufficient, for example).
>>=20
>> The initial assumption in homenet is a stateful firewall with hosts =
inside the homenet using PCP or something similar.
>>=20
>> Tim
>=20
> 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.
> 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.
> 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.
Owen
