> Date: Mon, 09 Dec 2002 09:50:04 -0500
> From: Margaret Wasserman <[EMAIL PROTECTED]>
> Subject: Re: "unique enough" [RE: globally unique site local addresses]
...
> I have the following things running around in my brain, and they aren't
> converging:
>
> - We need to provide PI addressing in IPv6, or we will
> see wide deployment of IPv6 NAT in enterprises
> and homes. No one seems to be disagreeing with
> this.
>
> - We think that the use of NAT is one of the serious
> architectural problems facing the Internet today,
> and that NAT is blocking the advancement of the
> Internet in many ways. For an IPv6 Internet to
> be a "success", we must avoid the wide-scale
> deployment of IPv6 NAT.
By themselves, GRUPI addresses might prevent NAT6. But currently we
can't handle the scaling issues with GRUPI addressess in the global
routing structure, so that's a non-starter. And non-globablly-routable
PI addresses won't by themselves prevent NAT6 (see below).
...
> So, where do we go from here?
1) We define a block for allocating GUPI addresses, and
figure out how they will be allocated.
2) We define methods for allocating Site Local prefixes,
possibly splitting up the SL address space into different
blocks for different scenarios.
I'm not convinced of the absolute need for GUPI addresses, since
they are not going to be globally routable. But they do simplify
some edge cases of merging/moving networks, make it easier to
identify the offender when they leak into the global internet, and
they might be a bit easier to deal with (than SL) in DNS. So, I don't
have any objection to them.
At the same time:
3) Start listing the issues with using local addressing on
networks that are connected to the global internet (either
GUPI or SL, the issues should the same), and then work to
solve those issues. These are things like the DNS issues,
and private routing between consenting sites.
I think that preventing NAT6 is a big challenge. Neither SL nor GUPI
addresses do anything to help us there. In fact, I think that GUPI
addresses have the potential to justification of NAT6 worse. To properly
run run an IPv6 network with global connectivity and with SL and/or GUPI
addresses, each machine will need to be configured with at least two
addresses. If it is perceived that this is difficult to do or not the
proper way to do things (don't we keep discouraging running dual IPv4
networks over the same wire?), then I could see network administrators
opting to use the private addresses on their networks, and using NAT6 to
provide the global connectivity. And if you've *sold* them a guaranteed
unique block of private address space (as opposed to them picking a SL
network), I'd see them feeling even more justified in using that block.
So, I don't think that providing GUPI addresses alone will do anything
to prevent the use of NAT6. What will prevent NAT6 is to make sure
that it is simple and easy to configure both globally routable and
SL/GUPI addresses on the same network, and address the problems caused
by having that configuration. Also anything to provide education about
how using a firewall to protect your network is vastly superior to
thinking that NAT provides security would be helpful.
And lastly:
4) At this time, do not allocate globally routable/unique provider
independent (GRUPI) addresses.
The routing issues *have* to be figured out first. Once that happens,
then I'm all for GRUPI addresses. But until there is some hope that the
scaling issues can be overcome, we'd best not even start down that path.
As for how far and wide SL/GUPI addresses should be used, I don't think
we need to answer that up front. I think it really depends on how well
we can address the issues caused by having them on networks connected to
the global internet. The less we have solved, the more they should be
restricted.
-David Borman
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
