Subject: Summary & some possible long term consequences of GUPI prefixes

From: Pekka Nikander <[email-masked]>
Date: Mon, 25 Nov 2002 11:04:31 +0200

I'm trying to understand this whole GUPI prefix business.
I have to say that I'm fairly confused, and therefore
this attempt to summarize and envision the case.
Please correct wherever I've mistaken.

The GUPI proposal seems to have grown from the concerns
regarding site locals.  (I have to confess that I still
do not quite understand why some people think that site
locals are that bad; I guess there have been too many
messages.  I am still looking for the pro and cons drafts
Margaret(?) suggested/asked for a few hundred messages
back.  Anyway, that's not the point here.)

The GUPI prefixes seem to have a lot of desirable
properties.  Leaking GUPI addresses are less likely to
cause confusion than leaking SL addresses.  Site
merger is easier with GUPI prefixes than without.
GUPI prefixes allow limited inter-site communication
through direct peering or tunneling.  Statistically
unique GUPI prefixes would be easy to generate.  etc.

Some people seem to think that GUPIs would reduce the
need for IPv6 NAT.  Maybe so, maybe not.  More below.

Requiring mandatory registration for GUPIs may make
it easier to track down people leaking GUPI routes,
but not necessarily so.  But at least that would give
us a scape goat, someone to yell at if a prefix is
leaked.  OTOH, mandatory registration would make it
very hard to use them at non-connected sites.

Now, suppose for a moment that we do have such GUPI
prefixes.  That is, prefixes that are (statistically)
globally unique, provider independent, free, forever
valid requiring never renumbering, and easy to generate
even for non-connected sites.

I guess almost everyone would start using them.  At least
I would personally, just for my personal VPN between my
office and home.  Thus, there would be millions of these
prefixes in use.  With some more invention, such as using
them for PANs or semi-stable ad hoc networks, there would
be billions of dynamic sites using these prefixes.

 From a site multi-homing (multi6) perspective, it might
become again a (not so) good idea to perform prefix translation
at the site exit routers.  If you configure your network
so that all hosts defend the same IID with the GUPI prefix
and the global prefixes, thereby making IIDs unique
within the site, you could fairly safely translate a GUPI
prefix in source addresses into your global prefix for
outgoing packets and vice versa for incoming packets.
MULTI6 solved :-)

 From a mobile networks (nemo) perspective, you could use
your GUPIs inside your mobile network (airplane, car),
and again perform prefix translation at the site exit
router.  NEMO solved :-)

(For those you missed the irony:  I know pretty well
that prefix translation would not solve the problems
multi6 or nemo are addressing.  I just want to point out
that GUPIs might make people to consider prefix translation
more seriously, since it would look "safer" with GUPIs.)

More seriously, there would be a tendency to consider
GUPI addresses as immutable identifiers for hosts,
making the aggretable global PA addresses mere locators.
Thus, it might form a step towards an architecture
where identifiers and locators are separated.

Now, honestly, I do not know if that would be a good
step or not.  We just have to understand that there would
be a strong temptation to view the situation so.
Furthermore, I guess that many people might just start
using the GUPI addresses so, without thinking too much
about the architectural consequences.

--Pekka Nikander

--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Nov 2002 10:39:44 +0100

Pekka Nikander wrote:
....
> step or not.  

It would be an excellent step, as long as we simultaneously
architected a way to use this separation that is more
attractive to enterprises and ISPs than NAT.

   Brian