shim6 @ NANOG (forwarded note from John Payne)

Thu Mar 2 14:29:01 UTC 2006

On Mar 2, 2006, at 7:49 AM, Michael.Dillon at btradianz.com wrote:

>
> Clearly, it would be extremely unwise for an ISP or
> an enterprise to rely on shim6 for multihoming. Fortunately
> they won't have to do this because the BGP multihoming
> option will be available.

Are you *sure* BGP multihoming will be available? This is my  
interpretation of the IPv6 /32 allocation policy:

To receive an allocation of a /32, you must:

"A) Be an LIR". I think you can consider a hosting company an LIR.

"B) Not be an end site". A little less cut and dry, but I'll accept  
that a hosting company doesn't fit the definition of an end site.

"C) plan to provide IPv6 connectivity to organizations to which it  
will assign /48s, by advertising that connectivity through its single  
aggregated address allocation". This is the one where I don't think a  
hosting company fits.

If all of your hosting is "shared", the servers are your  
responsibility, and you're not providing connectivity to anyone but  
yourself. I don't think you qualify at all at this point.

If you're selling dedicated servers or colo space, it's a little  
better, but I still don't think you fit. The average dedicated  
hosting/colo company now runs many customers servers sharing one  
subnet. Each customer gets /32's assigned per server, unless you're a  
huge colo customer, you're not getting space SWIPed to you.

When deciding who gets space out of your /32:

> Assignments are to be made in accordance with the existing  
> guidelines (RFC3177,RIRs-on-48), which are summarized here as:
>
> - /48 in the general case, except for very large subscribers
>
> - /64 when it is known that one and only one subnet is needed by  
> design
>
> - /128 when it is absolutely known that one and only one device is  
> connecting.

One customer on one dedicated server gets a /128. Even if you stretch  
plausibility, they only get a /64. I don't see any way you can  
justify giving colo customers /48s, unless they're deploying huge  
networks in your datacenter.

The final rule for getting a /32 is:

"D) be an existing, known ISP in the ARIN region or have a plan for  
making at least 200 /48 assignments to other organizations within  
five years."

Unless you're providing transit/connectivity to 200 companies/ 
networks, I can't see how you justify assigning even ONE /48, let  
alone 200.

The other PI assignment policies that have been proposed either  
require that you have a /19 already in IPv4 (lots of hosting  
companies don't have anything this size), or have tens/hundreds of  
thousands of devices.

Even if a hosting company does get a /32 or a /44 or whatever, the  
"you can't deaggregate your assignment at all" policy rules out  
having multiple independent POPs unless you somehow arrange to get  
multiple allocations(which isn't possible now).