RE: using ULA for 'hidden' v6 devices?

[George Bonser <gbonser () seven com>]

> Even if you don't see an advantage to GUA, can you point to a
> disadvantage?

Just a matter of convenience.  If you have a lot of management IPs or some other IP addresses that are never going to 
need internet access (an array of 10,000 sensors or something) you don't need to dip into your global allocation to 
address them.  If it is routed within the organization but never goes to the Internet, ULA is ok.  If it doesn't get 
routed at all, link local will do fine.   It's good to keep in mind that more things than computers with web browsers 
are going to get an IP address.

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

Possibly so.  I do, however, see some utility in having a block of addresses that can't be reliably routed over the 
Internet.  Heck, for traffic that might get routed within a site between local networks but not routed off the site 
(even within the organization's network between sites), there's some utility of having each site use the same subnet.  
That would ensure that traffic destined for that address range doesn't leave the site regardless of any configuration 
errors someone might make in filtration.  

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

The only advantage is using an address range that can't be reliably routed over the Internet and that is important in 
the minds of some.  GUA addresses can be reliably routed, that's their purpose.  While there is a possibility ULA could 
possibly be routed over the internet, the cascade of mistakes that it would take for that to happen makes it unlikely.  
I don't accept ULA routes at my peering/transit routers and I would imagine most other networks are configured the 
same.  In addition, I have the entire block of space static routed to null0 so even if I do get traffic for it (in 
either direction, in or out), it just goes into the hole.  

> I'm not sure where DNS64/NAT64 comes into play here for v6 to v6
> communication. 

No, I wasn't intending that for v6 to v6.  Let's say you have some devices that you want to give ULA but they *will* 
need Internet access infrequently for something such as software updates or statistics reporting or something.  You 
could arrange to do that using NAT64/DNS64 to a v4 destination.  Again, I am not advocating configuring such a thing, 
it's just a thought experiment where I'm trying to anticipate what some "clever" network might do at some point and the 
sorts of issues we might run into.

For example, there are a lot of places that have policies that mandate certain systems may not use public address 
space.  Those policies were developed by corporate bureaucrats, not engineers.  The engineers don't make policy but are 
tasked to implement policy and there are probably many creative ways in which those policy goals will be met.

If they use v6 ULA but infrequently need to reach someone offsite, they might be tempted to use NAT64 to reach it.  It 
isn't so much about providing "security" as it is providing barriers to making unwanted traffic easy to route.  If you 
pick an address range that isn't routable in a predictable fashion, it just adds another barrier of entry.  It is like 
living in a town named "One Way Street".  People see signs pointing toward it all over the place but following them 
leads you no closer to your destination.  If you use GUA, one mistake could make something very reliably reachable by 
the entire world.  That scares some people.  The consensus should be that the contingency plan be, as someone else 
mentioned, "don't make mistakes".  Well, people make em all the time.   I would rather get a call from a peer 
complaining about receiving a ULA route than learning that someone accidently opened up an important internal FTP site 
to the world.

Let me turn it around.  What advantage does GUA give you for a subnet that is never going to communicate outside the 
organization?  Configuring LUA is no more or less difficult than GUA.  

> For IPv4, I don't see any advantage in ULA+NAT64 vs. the
> more reliable and easier RFC-1918 with NAT44 possibilities, even if you
> have to run multiple RFC-1918 domains to get enough addresses, that
> will generally be less complicated and break fewer things than a NAT64
> implementation.

Agreed.  For v4 to v4 that will likely be the case for years.