One difference between our models may be that you seem to be assuming
that if a network has external connectivity, it has connectivity to
the public Internet.  I do not assume that.  So I see GUPIs as a way 
in which networks that aren't connected to the public Internet can
still get addresses which allow them to establish private connections
to external networks.

Another difference is that I see little reason for a network to support
both GUPIs and globals - if a network has globals then it is probably
better off without GUPIs.   Yes, GUPIs might be more stable than globals,
but this is not necessarily the case - the opposite could also be true.

OTOH I wouldn't try to insist that a network that supports globals
not use GUPIs.  If supporting both kinds of prefixes turns out to be 
the best way for that particular network to operate, fine.  I just
don't see that configuration as being of signifcant value.

Keith

> I think your imagined model of how GUPIs would be used might be
> different to mine.
> 
> As I see it, there are only three basic addressing scenarios, assuming a
> network with more than one segment (ie using link local addresses for
> internal connectivity is not covered here) :
> 
> 1) Globals - the address space stability of the global address space
> given by your provider is good enough. You use globals for everything,
> and have decided that coping with a global renumbering event is cheaper
> than the administration of GUPIs. 
> 
> 2) Globals and GUPIs - you don't want to rely on the stability of your
> allocated globals for your internal connectivity, so you roll out GUPI
> address space as well. GUPIs are used for your internal communications
> ie communications that doesn't travel across links that are part of the
> public Internet.
> 
> 3) GUPIs only - you don't have a Internet connection, you need internal
> address space, GUPIs suit. If at a later date you get an Internet
> connection, you leave your GUPI address space in place, and roll out
> your provider allocated globals.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to