North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: shim6 @ NANOG (forwarded note from John Payne)
On Mar 2, 2006, at 7:49 AM, Michael.Dillon@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: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).