[address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria

On Mon, 4 Apr 2005 19:46:32 -1000, Randy Bush wrote:
>by changing the addressing.  and that is exactly where we got
>into trouble last time.  and our grandchildren will have the
>same problem again.
What trouble ?

The IPv4 is a *success story*, there are *few* products with
more success. The whole world adoped this protocol and
addressing and it is and still will be *functional* for a long time.

Compared to this success the few "we need CIDR and
some address assignment policy" issues are *minor*
and can be seen as small corrections implied with every
success story. Even the FA board does apply minor
changes to the >100 years old football rule after regulary
scheduled meetings ...

Compared with these IPv6 is currently *not* a success story,
it is over ten years old and still experimental.

For the technology of the '90s it makes indeed sense to use
a 32 bit address space with 24 bit international routing:

- The address can be handled in one step by standard
  processors designed for 32 bit

- 32 bit as a reasonable 2^n multiple of an 8 bit byte
  (character unit and again 2^k) is
  => large enough to provide at least one IP adddress per
       stationary end user site on this world
  => small enough for efficiently wirable bus widths
       and *fast* handling by ALU's (carry lock ahead etc.)
       ( remember the market failure of the Itanium,
         a pure/mainly 64 bit engine has no market,
         as 32 bit is a reasonable integer and pointer width
         in *most* cases, 16 bit is too small for pointers,
         on the other side more than 4GB address space
         per task is required just by very few programming tasks )

- 24 bit can be completely internationally forwarded by a
  very fast radix tree structure:
  - Take the first byte, look up in a table, either find a
    next hop or a pointer to the next second level table.
    If there is a next hop, you are done.
  - Repeat this for the second, third byte and the second
    and third level table.
  This requires 3 table accesses, an easy job for even
  a small microprocessor. An access list is much more
  complicated.

  This means: Worst case is 1 + 256 + 256*256 tables
  with e.g. four bytes per entry (ptr.) and 256 entries each,
  this means *worst case* 65793 tables or appx. 67MByte
  RAM, typical case about one third due to many /16's,
  unused /8s, multicast space etc.  and hopefully a good
  next hop aggregation algorithm for /16's splitted into
  same destination /24's by clueless operators.

  Which means: This lookup can even be done in SRAM
  or by microcode compiled from the BGP info in real time,
  a static RAM area with 8...16 MWords (32 Bit/word)
  is affordable today, the same with DRAM is *really cheap*
  and even was cheap in the last century ...

The 32 bit address makes absolutely sense from a technical
and economical point of view and you need *very good reasons*
and a *much* better performance to sell something else.

At the end the customers decides, not the address-policy-wg,
and if we can't provide an interesting IPv6, the customer will
stay with IPv4 for the next 20 years. After that, the chance
is high that there will be some completly new (intelligent,
on the fly search, combined-multi-any-whatever-cast) IPv_new.

If you want make IPv6 an success, it must be *better*
than IPv4, not worse and more restricted.

Arguments could be (Ceterum Censeo ;-)
- no renumbering pain due to get-once-stay-with-them
  addresses *regardless* which ISP doing the service
- easy multihoming
- easy VPN's
- a *globally* unique *constant* address for each mobile
  (which again means global routing, *not* dynamic
   assignment, this and NAT is what we have today)
and not
- total dependency on your ISP or upstream due to
  an restrictive and pseudo-geographical addressing

Think of: IPv6 was created with nearly *unlimited*
address space in mind, either it can keep this promise
(which means usable, thus *routable* address space)
or it is dead.

Greets
Oliver



Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany
oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0