[148944] in North American Network Operators' Group
RE: using ULA for 'hidden' v6 devices?
daemon@ATHENA.MIT.EDU (George Bonser)
Thu Jan 26 14:53:59 2012
From: George Bonser <gbonser@seven.com>
To: Owen DeLong <owen@delong.com>
Date: Thu, 26 Jan 2012 19:53:18 +0000
In-Reply-To: <C2A511E3-CB4D-43BF-9C51-505D81C31E8A@delong.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> 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 o=
f 10,000 sensors or something) you don't need to dip into your global alloc=
ation to address them. If it is routed within the organization but never g=
oes to the Internet, ULA is ok. If it doesn't get routed at all, link loca=
l 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 addresse=
s 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 th=
e 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 t=
raffic destined for that address range doesn't leave the site regardless of=
any configuration errors someone might make in filtration. =20
> 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 addresse=
s can be reliably routed, that's their purpose. While there is a possibili=
ty 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 UL=
A routes at my peering/transit routers and I would imagine most other netwo=
rks 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 direc=
tion, in or out), it just goes into the hole. =20
> I'm not sure where DNS64/NAT64 comes into play here for v6 to v6
> communication.=20
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 somethin=
g. You could arrange to do that using NAT64/DNS64 to a v4 destination. Ag=
ain, I am not advocating configuring such a thing, it's just a thought expe=
riment where I'm trying to anticipate what some "clever" network might do a=
t some point and the sorts of issues we might run into.
For example, there are a lot of places that have policies that mandate cert=
ain systems may not use public address space. Those policies were develope=
d by corporate bureaucrats, not engineers. The engineers don't make policy=
but are tasked to implement policy and there are probably many creative wa=
ys in which those policy goals will be met.
If they use v6 ULA but infrequently need to reach someone offsite, they mig=
ht 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 ro=
ute. If you pick an address range that isn't routable in a predictable fas=
hion, it just adds another barrier of entry. It is like living in a town n=
amed "One Way Street". People see signs pointing toward it all over the pl=
ace but following them leads you no closer to your destination. If you use=
GUA, one mistake could make something very reliably reachable by the entir=
e world. That scares some people. The consensus should be that the contin=
gency plan be, as someone else mentioned, "don't make mistakes". Well, peo=
ple make em all the time. I would rather get a call from a peer complaini=
ng 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. =20
> 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.
