[ipv6-wg at ripe.net] Re: [lir-wg] IXP networks routing

--On Tuesday, March 04, 2003 16:14:57 +0100 Poul-Henning Kamp
<phk at phk.freebsd.dk> wrote:

> I'm mainly talking about the lack of a feasible way for end-customers
> to get working multi-homing.  This ties directly into the "PI" space
> question.

Multihoming today depends on the possession of an AS number. I see no
alternative to that prerequisite.

Size of current v4 routing table: roughly 120000 entries
Number of ASen visible		: roughly 15000

So, if we simply give every AS number holder currently present in the v4
table a /32 or so, with STRICT instructions to forget getting another
prefix until half that prefix is pingable, we attain several things:

* This makes the PI/PA distinction moot, or rather, we have PI only. 
  Perhaps the mootness is temporary, but I hope not. It might be 
  replaced with AA -- AS Allocated, ie "these addresses belong to AS1653, 
  and cannot be placed under any other AS". 

* The "v6 for services" problem will disappear. End of this discussion. 

* The routing table will shrink to 12.5% of its present size. 

* We will have a minor chunk of v6 space used, and all present users of 
  v4 will be able to migrate without lack of address space. 

* If the number of ASen (with one /32 per AS) visible in the v6 table
  increase 100% compared to todays v4 figures, the table will still be only 
  25% of today. 

* Everybody will hunt me with both sharp and blunt objects for being 
  a filthy pragmatic person with blasphemous opinions. 

Now, please tell me why this does not work. Purity reasons will have no
effect, for I am too shortsighted. 
-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://www.ripe.net/ripe/mail/archives/lir-wg/attachments/20030305/a235b1e8/attachment.sig>