Brian Zill wrote:
> 
>  
> 1. They're free.
> 2. They can be (auto)configured without having
>   to co-ordinate with some outside entity.
> 3. They cannot be externally routed (Some would
>    consider this to be a minus as well).
> 
>  An IETF edict not to route some new form of
> non-ambiguous addresses will be ignored by those who wish to route them.
> This will likely lead to pressure to turn these new addresses into
> yet-another type of global address with all the associated routing table
> explosion inherent to non-aggregatable address space.  Another way to
> look at it is that the current ambiguity in site-locals is a means for
> protecting the global routing space.  If we do away with the ambiguity,
> we need another method for keeping the global routing tables sane.
> 
I can understand that users of the non-aggregatable address space will
try and pressure their ISPs to route it, but they won't have any
contract with the upstream ISPs who _should_ be only too happy to filter
non-aggregatable addresses from the routing tables.  Do you think that
this + a really strong statements and specification up front has no
chance of working?

> The only class of solution which I think will truly make everyone happy
> is to come up with an *aggregatable* globally unique address space that
> still has properties 1 and 2.  In other words, some sort of
> provider-independent global address space.  Properties 1 and 2 are much
> easier when the aggregatable property is not required.  The reason we're
> in the state we are today is because this is a hard problem.

Well if you are connected then you should have enough PA addresses that
1. is not a problem and given SAA, configuration is not much more work
than configuring a few 
I
Pv4 addresses on to a NAT box so 2 isn't such a big deal either.  The
only real advantage is 3.  This solution really only has the advantage
of long term stability.  I think that inherent non routability would be
as much of a desirable feature of such addresses.

Richard.
> 
> --Brian
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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