Jeroen Massar wrote:
The above hosts are Internet connected and most likely will thus also
end up
talking to the Internet at one point or another. I can thus only guess that
they will be wanting to fully connect to the Internet one day and the
generic solution to that problem is NAT. We wanted to get rid of NAT for
IPv6. If NAT is again being done for IPv6 then we can just as well give up
and just keep on using IPv4 as there really is not a single advantage then
anymore to IPv6.
I think what we wanted to get rid of in IPv6 was one-to-many NAT, also
know as PAT (among other names). In IPv6, we can stick to one-to-one
NAT, which eliminates most of the nastiness we associate with NAT in
today's IPv4 world.
But see below for a scenario that might have actual merit here.
**SCENARIO**
One possible scenario could maybe be: use ULA-C local in your local site,
use global (PA) addresses from the upstream ISP, from whom you get a /48
too, thus the number plan is the same, just different first 48 bits. Every
host gets a ULA and a PA address. The PA address might change when changing
ISP. RFC3484 and related work can be used to configure preferring what
address to use. Then you never need to reconfigure your local network and
local addresses are globally unique and can use the Internet.
The big thing there is though: configure your firewalls correctly as the
public addresses do also allow access to everything.
I don't think routers are at the point yet where you can easily renumber
your routers' interfaces when your PA addresses change. As a result,
networks wanting to avoid the pain of renumbering, but who don't qualify
for PI and a global routing slot, might want to do something similar:
Say a network gets a ULA-C block, and numbers everything on their
network out of that block. They later connect to the Internet, and get
a PA block from their upstream, and configure it on their border
routers. To avoid reconfiguring all their routers every time they
change upstreams, they configure one-to-one NAT on their border routers,
such that every address on their internal network (which is ULA-C) maps
to the same address, except with different first 48 bits, in their
provider-allocated block.
This wouldn't present the same kinds of problems you'd get from
one-to-many NAT, but I'm sure there are some ways where this wouldn't be
as good as PI space. However, my first-order evaluation is that it
would be better to have small networks achieve their provider
independence this way, rather than by relaxing the PI rules and
threatening the scalability of the current routing system with a large
number of additional non-aggregatable netblocks.
Now as expressed earlier, most ULA-C use cases probably won't involve
NAT. But if people do elect to use NAT with ULA-C, what problems do you
see with this kind of use of NAT? Do you see those problems as worse
than the problems caused by completely rejecting the original PA-only
architecture of IPv6 in favor of PI-for-everyone?
Still, the above can also be accomplished perfectly fine with PI space and
that doesn't require any changes (except RIPE+APNIC policy) to be done.
I agree that PI space, if it were widely available, would meet the same
needs as ULA-C. However, I think we need to be realistic that
PI-for-everyone won't fly, and need to think creatively about ways to
achieve the same goals (such as provider independence) in such a way
that we don't impose more public cost than private benefit.
Another thing to consider when evaluating whether to specify something
like ULA-C is that we can't know what kind of innovation it will make
possible in the future. Therefore, the question we should be asking is,
is there any remaining reason *not* to allow networks to register ULA-C
space? When it was last proposed there was: it was thought that
networks would get ULA-C and use it as PI space. Now, since PI space is
readily available to multihomed networks, that is much less likely. As
a result, I am in favor of allowing small networks to register their own
unique private space, as this draft would do. I can't predict how ULA-C
will be used, but I'm confident that innovation is a good thing, and
that we can safely open up the ULA-C sandbox to networks who wish to use it.
-Scott
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
