Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Stephen Satchell <list () satchell net>]

On 10/02/2015 12:44 AM, Valdis.Kletnieks () vt edu wrote:
> On Fri, 02 Oct 2015 02:09:00 -0400, Rob McEwen said:
>
> > Likewise, sub-allocations can come into play, where a hoster is
> > delegated a /48, but then subdivides it for various customers.
>
> So they apply for a /32 and give each customer a /48.
>
> A hoster getting *just* a /48 is about as silly as a hoster
> getting a /32 of IPv4 and NAT'ing their customers.

I agree, for a web hosting operation, getting an allocation smaller than 
a /32 doesn't make sense.

But...now I ask this question:  WHY a /48 per customer?  I used to be a 
web host guy, and the rule was one IPv4 address per co-location customer 
or dedicated-server customer -- maybe two -- and shared-IP HTTP for 
those customers hosted on "house" servers with multiple sites on them. 
We had a couple of shared-hosting server with 64 IPv4 addresses each to 
support SSL sites with customer-provided SSL certificates..

OLD STYLE

If a customer wanted more than one IPv4 address, he had to justify it so 
we could copy the justification to our ARIN paperwork.  A /24 was right 
out, because the *only* people requesting that much IPv4 space were 
spammers.

The largest legit co-location IPv4 customer allocation, because he had 
enough servers in his cage and sufficient justification to warrant it, 
was a /26 .  Which I SWIPped.  Which I treated as a completely separate 
subnet.  Which was on its own VLAN.  Which used separate 10base-T 
Ethernet interfaces on my edge routers to provide hard flow control and 
traffic monitoring.

THAT WAS THEN, THIS IS NOW

I can see, in shared hosting, where each customer gets one IPv6 address 
to support HTTPS "properly".  Each physical server typically hosts 
300-400 web sites comfortably, so assigning a /112 to each of those 
servers appears to make sense.  This is particularly true now that there 
is a push for "https everywhere".

Web hosting isn't going to be a downstream link for IoT, so the need for 
"massive" amounts of IPv6 addressing space is simply not there.