BCP for multisite multihoming

Gert Doering gert at space.net
Wed May 23 10:17:48 CEST 2007


On Mon, May 21, 2007 at 04:35:20PM -0400, Leo Vegoda wrote:
> Yes, a /32 is far more than many sites will need.
> The first requires a new, scalable approach to routing and the latter  
> can be solved by changing the minimum allocation size. The latter is  
> relatively easy.

Technically, this is the wrong forum, but I want to make this heard
anyway.  I consider every thought of reducing the /32 to a smaller 
minimum allocation size fundamentally flawed - this is IPv4 thinking.

IPv6 allocation policies should aim at

 - a single enterprise should be happy with a *single* IPv6 prefix,
   for as long as the network exists  (so it needs to be big enough for
   your typical small-to-medium sized ISP - and a /32 just meets that)

 - it is not much use to squeeze out address space on things that need to 
   go to the routing table anyway (ISP prefixes, that is) - what do you win 
   if you force /40s on ISPs, and then end up with 99% of the address space
   unused because your routing table cannot take more entries?

   Giving /32s to ISPs means, theoretically, 500 million /32s out there -
   which everybody agrees that routers cannot take.  So, reducing this to
   "smaller blocks", whill indeed save space - but what can you use it for?

The /32s are already a compromise, and as soon as an ISP has an internal
network hierarchy, needs to do internal aggregation etc., this isn't so
spacious anymore.  I would have preferred a /28 or similar "no questions

Please stop thinking in IPv4 trains.

The real question is "who needs/deserves a global routing table slot", 
not "how many bits can you haggle for".

Gert Doering
        -- RIPE APWG chair
Total number of prefixes smaller than registry allocations:  113403

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

More information about the ipv6-ops mailing list