[148932] in North American Network Operators' Group
Re: using ULA for 'hidden' v6 devices?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jan 26 11:50:38 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAD6AjGTzJ=taP9X4i7YSfD+JPF8bmPB5Vn5T-B3oU0C3-CxAdQ@mail.gmail.com>
Date: Thu, 26 Jan 2012 08:45:39 -0800
To: Cameron Byrne <cb.list6@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 26, 2012, at 7:35 AM, Cameron Byrne wrote:
>=20
> On Jan 26, 2012 5:49 AM, "Owen DeLong" <owen@delong.com> wrote:
> >
> >
> > On Jan 26, 2012, at 2:00 AM, George Bonser wrote:
> >
> > >> Use different GUA ranges for internal and external. It's easy =
enough to
> > >> get an additional prefix.
> > >>
> > >>> As others have mentioned, things like management interfaces on =
access
> > >> switches, printers, and IP phones would be good candidates to =
hide with
> > >> ULA.
> > >>
> > >> Or non-advertised, filtered GUA. Works just as well either way.
> > >>
> > >> Owen
> > >>
> > >
> > > If one is obtaining "another" prefix for local addressing, I see =
no benefit. I am assuming that anyone that is using ULA is using it for =
things that don't communicate off the site such as management interfaces =
of things, etc. This won't be a subnet you are connecting by VPN to =
another organization, usually, but even if you do the chances of =
collision is pretty low if you select your nets properly. But for the =
most absolutely paranoid site, I can see some appeal in using ULA in =
conjunction with DNS64/NAT64 and see them giving the devices internet =
access via v4. Not that I agree with the notion, mind you, just that I =
can see someone looking at that as an appealing solution for some =
things. Even if someone managed to get through the NAT device via v4, =
they would have nothing to talk to on the other side as the other side =
is all v6.
> > >
> >
> > Even if you don't see an advantage to GUA, can you point to a =
disadvantage?
> >
> > IMHO, it would be far less wasteful of addressing overall to =
deprecate fc00::/7 and use unique secondary GUA prefixes for this =
purpose than to use ULA.
> >
> > 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.
> >
>=20
> 1. You don't want to disclose what addresses you are using on your =
internal network, including to the rir
>=20
Seriously?
> 2. You require or desire an address plan that your rir may consider =
wasteful.
>=20
Have you looked at current IPv6 policies? It's pretty hard to imagine =
implementing one.
> 3. You don't want to talk to an rir for a variety of personal or =
business process reasons
>=20
Meh. I have little or no sympathy for this.
> 4. When troubleshooting both with network engineers familiar with the =
network as well as tac engineers, seeing the network for the first =
time, ula sticks out like a sore thumb and can lead to some meaningful =
and clarifying discussions about the devices and flows.
>=20
I can see this, but, to me it seems like a double edged sword. Most =
things that stick out like a sore thumb are inflamed and painful. I =
don't see this as an exception.
> 5. Routes and packets leak. Filtering at the perimeter? Which =
perimeter? Mistakes happen. Ula provides a reasonable assumption that =
the ISP will not route the leaked packets. It is one of many possible =
layers of security and fail-safes.
>=20
Routes only leak if the routes exist on the border routers in the first =
place. If I were using multiple GUA prefixes and one was intended not to =
cross the border, I wouldn't feed it to the border routers to begin =
with. You can't leak what you don't know.
Owen
