> > I think this WG needs to define GUPIs - because that seems like the best
> > way to take the pressure off of SLs to be misused.  however I don't think
> > we should try to make them globally routable, at least not now.
> 
> I don't really agree that this is what we should be doing.
> 
> I think:
>  - if we specify global-scope GUPI's they will also be used when regular
> global-scope addresses would be better (and we should encourage PA
> addresses, because they actually _work_); ie. they will cause trouble and
> may eventually result in prefix/address translation (NAT-like) problems.

mumble.  all we can do is give people good tools, explain how they were
intended to be used, and hope they use them in an optimal fashion.   
right now we are in a situation where SLs will be used for situations
where they are not good tools.  the only way to solve this problem is
to give people better tools, and GUPIs seem to be a good fit.

yes, some people will probably try to use GUPIs where PA globals would
be a better choice.  eventually, they'll learn.  they'll have to renumber
to fix that problem, but it won't be more difficult than any other kind
of IPv6 renumbering, and we have to solve that problem anyway.

>  - if we instead specify site-local, near-unique addresses, folks still
> treat them as site-locals; they are used less than GUPI's would be, in
> site-local contexts only.  Near-uniqueness removes the problems with
> ambiguity of site-locals.

yes, but that's not the only problem with site-locals.  another problem
is that it's widely believed that they are some kind of security mechanism.  
another problem is that it's widely believed that hosts and applications
should treat them differently than other addresses, either by filtering them
or by preferring them over other addresses.  in other words, there are 
lots of dubious assumptions about site-locals that are more easily and
more effectively fixed by discouraging many uses of site-locals, and 
providing an alternative for the valid use cases, than by trying to 
change people's mindsets about what site-locals means.

>  - I think it's better to deal with reality (provider assigned addresses)
> than try to escape it (provider independent addresses), even though how
> enticing it could be...

"reality" is subjective.

I think it's fair to say that we know how to make PA addresses routable
on a large scale, and we don't know how to make PI addresses routable
on a large scale.  On the other hand, I think it's also fair to say that
PA addresses don't do everything that people need - they don't support
multi-provider multihoming, and they don't support networks that aren't 
connected directly to the global internet.  So PA addresses are desirable
but not sufficient.

> Following my thinking, site-locals could of course be used as an aid for
> e.g. renumbering or intermittently connected sites, but that should be
> better than having delusions that using global-scope addresses there would
> somehow make such addresses "global" or "globally usable".

I guess we are concerned about different anticipated delusions.  I'm much
more concerned about the delusions that already seem to exist about the 
applicability of site-locals than about the delusions that might exist
about the applicability of PI globals.

I do think that an addressing architecture that simplifies 
decision-making would minimize the potential for delusions.  From 
that perspective, a simple table is quite attractive:

case                            | recommendation
--------------------------------+-----------------------
network connected to the        | PA global addresses
public internet                 |
                                |
network not connected to the    | PI global addresses
public internet, but            |
connected to other IP networks  |
via private arrangements        |
                                |
isolated stable network         | PI global addresses or 
                                | site-local addresses
                                |
isolated ad hoc network         | site-local addresses


Keith
--------------------------------------------------------------------
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