|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: shim6 @ NANOG (forwarded note from John Payne)
> 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
|