From: Kevin Day (no email)
Date: Thu Mar 02 2006 - 09:29:01 EST
On Mar 2, 2006, at 7:49 AM, 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).
|
|
|