using ULA for 'hidden' v6 devices?

Cameron Byrne cb.list6 at
Thu Jan 26 17:18:29 UTC 2012

On Jan 26, 2012 8:49 AM, "Owen DeLong" <owen at> wrote:
> On Jan 26, 2012, at 7:35 AM, Cameron Byrne wrote:
>> On Jan 26, 2012 5:49 AM, "Owen DeLong" <owen at> 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
>> > >> switches, printers, and IP phones would be good candidates to hide
>> > >> 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
>> >
>> > 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
>> >
>> > 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.
>> >
>> 1. You don't want to disclose what addresses you are using on your
internal network, including to the  rir
> Seriously?


>> 2. You require or desire an address plan that your rir may consider
> Have you looked at current IPv6 policies? It's pretty hard to imagine
implementing one.

Yes. Think m2m as 1 example

>> 3. You don't want to talk to an rir for a variety of personal or
business process  reasons
> Meh. I have little or no sympathy for this.

Of course. The view from inside the system is different from outside the

>> 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.
> 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
> 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.

Like many things, we can disagree on this too. Net net, folks need to
consider their own requirements. Ula is a tool. If it has a place in your
toolbox, great .

> Owen

More information about the NANOG mailing list