Re: Just an idea for a self organiziong IPv6 address space network

In message <DED9C2BCA57FC544ABF93CD5EE01F28C1FEEE0@um-mailnode1.um.umsystem.edu
>, "Pepmiller, Craig E." writes:
> Thanks for the lead on an interesting presentation.  I get the feeling that s
> ome consideration needs to be made to break out address blocks along AS bound
> aries.  Possibly each AS should get it's own seed.
> 
> Thanks-
> -Craig Pepmiller


Each of the over 10,000 ASs should get its own seed?  With 250,000
routes, thats an average of 25 (IPv4) per AS (less since there are
closer to 14,000 AS).  This would seem to not be a candidate for a
"self organizing" protocol IMHO.  Of these (of the 25 prefixes on
average per AS) many, possibly the majority, are multihomed customer
sites that don't have their own AS.  As a rule, a multihomed provider
will get an AS number and a multihomed enterprise will not (not
serving as transit).  The only way to estimate that would be to look
at multiple route views for prefixes that are announced with more than
one origin AS.  You'll find a lot.  The only other reason to get an
address assignment outside of an aggregate is when an enterprise or
provider insists that they want to keep open their option to move
within the topology (get a new provider if they are dissatisfied with
service) and they consider renumbering to be infeasible.

The whole IPv6 community is engaged in a charade about IPv6 magic
cleaning up the address allocation.  Some residual messiness will go
away with any second iteration of numbering.  Some resistance to
renumbering will go away since it is easier.  The organizational
relationships will not change just because the protocol changed and
all we'll have for it is much longer prefixes to deal with.  It may
also remain hard to get organizations to take numbers dynamically from
an upper level organization.

Allocation today requires justification that the address space will be
used for some legitimate purpose.  There have already been plenty of
wild plans to assign an IP address to every car on the road of a given
make, or every cell phone in a country (or more) with vague plans that
begin with allocating the address space.  With much more address space
in IPv6 there is the luxury of being able to humor these fantacies as
long as they remain few enough in number, but the need to somehow
justify use of address space will probably still remain at some level.

A beauty of IPv6 wrt address space allocation is that we have enough
address space to try multiple approaches and abandon the ones that
don't work.  If a "self organizing" protocol works for some community
of users, the benefit of not having to configure may make it
desireable.  For others, the potential drawback of removing autonomy
from network elements (creating dependencies on other systems for
allocation) may outweigh any convenience unless the allocation is
fairly static and does not require any sort of refresh.

You could consider the distrubuted routing registry idea to be almost
in the problem/solution space you are looking at.  This is fairly
static and requires messages signed by people to initiate change but
then automates the distribution and application of AS allocation,
address allocation and related information.  The proposal was even
made to be able to push this information directly onto the routers
rather than generate router configurations offline.  This may be as
close as you'd get to a dynamic protocol used in practice.

Curtis


> -----Original Message-----
> From: Dmitri Krioukov [mailto:[email protected]]
> Sent: Tuesday, October 29, 2002 3:24 PM
> To: Pepmiller, Craig E.
> Cc: [email protected]
> Subject: RE: [Irtf-rr] Just an idea for a self organiziong IPv6 address
> space network
> 
> 
> I perfectly understand Curtis's reply.
> It would be quite surprising to know
> how anything like this could work on
> meshy networks. Some preliminary
> calculations based on fundamental
> Kleinrock's results on hierarchical
> routing are included in:
> http://www.krioukov.net/~dima/pro/lulea/lulea-msrw.ppt
> --
> dima.
> 
> _______________________________________________
> irtf-rr mailing list
> [email protected]
> http://puck.nether.net/mailman/listinfo/irtf-rr
> 
_______________________________________________
irtf-rr mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/irtf-rr