shim6 @ NANOG (forwarded note from John Payne)

Michael.Dillon at Michael.Dillon at
Thu Mar 2 16:05:47 UTC 2006

> 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.

If your current business model means that your business
cannot continue in an IPv6 world, then a competent
business manager will change that model. If the IPv6
address policy requires hosting providers to sell the
blades in their servers, and to SWIP a /48 per customer
end-site (i.e. blade) then they will do so. There is
precedent for this when IPv4 addressing policy drove
hosting providers to name-based virtual hosting.

I'm not terribly worried about situations like this 
because I know the applicants can adjust their business
plans, and future business models, to work with the policy.
A while back on PPML I noted that RIPE had allocated 
IPv6 space to several organizations with no IPv4 allocations.
Under the assumption that these were not existing IPv4
ISPs, I had a look into several of these organizations.
One of them was the IT function of a retail chain operating
in Germany, Poland and Turkey. If they could qualify as
an LIR by organizing their business with a separate 
IT and network services function, then I think the rules
are less restrictive than most people think.

If you feel you should qualify as an LIR, then apply
for your /32. If you get rejected, asked for detailed
reasons why. If the reasons are due to misunderstanding
or a lack of information, then remedy the situation and
reapply. If the reasons have to do with your structure or
your plans, then change them and reapply. If you can't do
that then I would question whether you have a serious
intention to be an IPv6 service provider.

> > - /128 when it is absolutely known that one and only one device is 
> > connecting.
> One customer on one dedicated server gets a /128.

You know, the problem with those blade servers is that
they generate too much heat and use too much electricity
in one place. This increases HVAC costs and increase the
risk of power problems. It also creates a massive downside 
during a power outage if you can't keep the HVAC running.
Much better to find a cheaper real-estate location where 
you can rent rack positions rather than blades. Customers
can put whatever they want in their rack positions. Maybe
it's a WLAN proxy relay station or their own blade server.
You can't know how many devices will be at the rack position
therefore you should allocate them a /48. After all, you
are a hotel. You rent rooms, you don't police what goes on
inside the room.

> 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.

It has also been suggested that the simple presence of
multihoming should be sufficient justification for PI space.

> 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).

People have done creative things with tunnels in the past. 
The widespread existence of MPLS backbones makes that 
even easier. You will always be able to find one situation
that simply will not fit a given policy. Regardless, we still
need to have some reasonable policy that creates a level
playing field, does not unecessarily restrain trade, and
creates possibilities that smart entrepreneurs can exploit
to expand the network.

--Michael Dillon

More information about the NANOG mailing list