[184454] in North American Network Operators' Group
Re: How to wish you hadn't forced ipv6 adoption (was "How to force
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Oct 3 15:05:04 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <560E8A59.2080205@satchell.net>
Date: Sat, 3 Oct 2015 12:03:58 -0700
To: Stephen Satchell <list@satchell.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
> On Oct 2, 2015, at 06:44 , Stephen Satchell <list@satchell.net> wrote:
>=20
> On 10/02/2015 12:44 AM, Valdis.Kletnieks@vt.edu wrote:
>> On Fri, 02 Oct 2015 02:09:00 -0400, Rob McEwen said:
>>=20
>>> Likewise, sub-allocations can come into play, where a hoster is
>>> delegated a /48, but then subdivides it for various customers.
>>=20
>> So they apply for a /32 and give each customer a /48.
>>=20
>> A hoster getting *just* a /48 is about as silly as a hoster
>> getting a /32 of IPv4 and NAT'ing their customers.
>>=20
>=20
> I agree, for a web hosting operation, getting an allocation smaller =
than a /32 doesn't make sense.
>=20
> 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..
>=20
> OLD STYLE
>=20
> 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.
>=20
> 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.
>=20
> THAT WAS THEN, THIS IS NOW
>=20
> 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".
>=20
> 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.
>=20
So there are a number of reasons.
First, unless you want to be chasing ND Cache Overflow problems, you put =
each customer on a small link (/127) to your router and then route at =
least a /64 to their router if they just have one subnet. If they have =
more than one, then you certainly want to route them a larger prefix =
(/48).
With virtualization and network virtualization, containers, and the like =
these days, treating each customer as a separate end-site is just good =
practice. You=92re not going to have any problem explaining that to the =
RIRs.
Owen
