shim6 @ NANOG (forwarded note from John Payne)

Kevin Day toasty at
Thu Mar 2 14:29:01 UTC 2006

On Mar 2, 2006, at 7:49 AM, Michael.Dillon at 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).

More information about the NANOG mailing list