Check out: http://www.ietf.org/internet-drafts/draft-savola-multi6-asn-pi-00.txt the drawback seems obvious: at least I don't want to encourage anything that would hasten the move to 32-bit AS numbers, and definitely don't want to change the problem of end-site multihoming to AS-number exhaustion problem. On Wed, 5 Mar 2003, Måns Nilsson wrote:
--On Tuesday, March 04, 2003 16:14:57 +0100 Poul-Henning Kamp <phk@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.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings