RE: Regionally aggregatable address space for multihoming

["Tony Hain" <alh-ietf@tndh.net>]

This proposal is not attempting to provide the optimal 'one and only'
solution to addressing in the global Internet, and I specifically don't care
about waste since I know off the top that ~ 2/3 is unusable. What it is
trying to do is provide a specific tool for addressing the impact on routing
by multi-homed sites. It does not require renumbering as devices move,
unless the public demarcation at layer 1 changes as a result. It may not map
well with current topologies, though I would like to have some operators
show specifically where it breaks down.

-----Original Message-----
From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
Sent: Friday, June 08, 2001 3:36 AM
To: Tony Hain
Cc: multi6@ops.ietf.org
Subject: RE: Regionally aggregatable address space for multihoming

On Thu, 7 Jun 2001, Tony Hain wrote:

> Here is the text of a very drafty-draft I have been working on for a
couple
> of weeks to address this specific issue. If things are not aligning right,
> try putting the font in Courier 12.  Comments please.

- you may want to cut some text that isn't specific to this proposal
- integer math would be easier than floating point math with 15 digits
- if you move the 0 meridian to 30 deg west it won't cut through densely
  populated areas in Europe and Africa
- why 2 bit interleave? one bit makes it possible to use arbitrary
boundaries

I made a small program to calculate the geographic address for any given
location, but I got very different addresses for most things, although some
worked. Have a look at http://www.muada.com/ipv6geo.php

But the real question is: do we really want to use such a very direct
relationship between addresses and geography?

I see three major drawbacks:

1. This proposal uses 6.25% of the IPv6 address space and still some areas
may have too few addresses. It is especially wasteful closer to the
poles. There are only a few cities above 60 deg north or below 40 deg south,
and these two areas use 44% of the address space in this proposal and 2.77%
of the IPv6 address space if it is deployed.

2. The strictly geographic aggregation boundaries in this proposal won't fit
current network topologies. So either the networks will have to be changed
or
the aggregation will be less successful.

3. Lots of renumbering: if strictly applied, this proposal means that moving
a workstation from one end of a hallway to another implies renumbering.
While
the support for automatic renumbering are better in IPv6, it is still not
something to take too lightly. Even if the renumbering itself is completely
transparent to the user and applications, there is still the matter of the
DNS.

But what about this: in stead of using individual routes, we could encode
routing information in bitmaps. A 150 km routing precission would take 2^16
=
64k bits = 8 kilobyte to encode. A reachability bitmap for all neighborhoods
within a region would also take only 8k. But a 20 bit prefix would take
128k.

So core routers would take 150 km precission bitmaps of the whole world from
their peers. The next routing level would be the zone level, where 2.5 km
precission bitmaps for a number of adjacent 600x600 km zones are
exchanged. The next level would be able to handle the 10x10 m sites.

This would also permit very fast routing updates because reachability
information can be updated with just a few AND and OR operations on the
bitmaps.