Subject: RE: "unique enough" [RE: globally unique site local addresses]

From: "Michel Py" <[email-masked]>
Date: Sun, 1 Dec 2002 14:44:24 -0800

Keith,

>> Michel Py wrote:
>> 1. Local, private addresses that do not communicate
>> outside of their site. Site-locals are perfect for
>> this, if they are not limited to disconnected sites.
>> 2. Unique addresses that do not need public Internet
>> access but do need to communicate with selected
>> external sites (example customer/supplier VPN). This
>> is GUPI.
>> 3. Global network layer PI identifiers. Although
>> this is not directly linked to the multihoming issue,
>> it is likely that a scalable multihoming solution
>> would provide it.

> Keith Moore wrote:
> why doesn't #2 suffice for #1?
[I transposed it back the way you meant]

Because #2 does not exist today. You must provide #2 before you try to
kill #1. Network administrators do not design production networks with
promises.

Michel.

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: David Borman <[email-masked]>
Date: Mon, 9 Dec 2002 10:09:03 -0600 (CST)

> Date: Mon, 09 Dec 2002 09:50:04 -0500
> From: Margaret Wasserman <[email-masked]>
> 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-masked]
--------------------------------------------------------------------

---

From: "Michel Py" <[email-masked]>
Date: Wed, 11 Dec 2002 12:13:10 -0800

Margaret,

> Margaret Wasserman wrote:

Little disgression about the meaning of "PI": in many people minds, it
means "PI as we know it today for IPv4", which is exactly what we don't
want for IPv6. It would be better to use another acronym such as GRUPI
or GAPI.

> - We don't currently have a fully developed plan for
>   aggregable, scalable IPv6 PI addressing.  Some
>   folks are working on this problem, but no one
>   has claimed to have a full answer yet.
> - We know that providing widely-used PI addresses in IPv6
>   will result in substantially larger routing
>   tables than doing straight PA addressing.
> - We also know that routing table size is a real scaling
>   factor in the IPv4 Internet, for which we have not
>   determined an adequate solution.
> - Routing table growth is not (yet) a scaling problem
>   for IPv6, because of limited deployment.  However,
>   wide deployment of IPv6 is also a criteria for
>   "success", so we need to build a scalable
>   solution...
> - However, "success" must also include the avoidance of
>   wide-scale IPv6 NAT deployment, which we can only
>   achieve if we provide PI addresses...
> [Ad infinitim.]

Good summary, IMHO.

> So, where do we go from here?

Two-prong approach, see
http://arneill-py.sacramento.ca.us/ipv6mh/roadmap.txt

Michel.