[181899] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Mel Beckman)
Thu Jul 9 03:19:00 2015
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: Matthew Kaufman <matthew@matthew.at>
Date: Thu, 9 Jul 2015 01:51:32 +0000
In-Reply-To: <D90769BA-F449-4529-99CB-5167BA7C4D8B@matthew.at>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Matthew,
This is where we have to excise our IPv4 "fear of waste" reflex. A /64 sub=
net, for example, doesn't waste anything material -- these are just integer=
s, after all. If the number of integers was scarce, as they are with IPv4, =
then yes, we must conserve. But IPv6 is well thought out and it's design ca=
refully considered practical IP allocation requirements before deciding on =
128 bit addresses. It's enough. Really.=20
-mel beckman
> On Jul 8, 2015, at 6:46 PM, Matthew Kaufman <matthew@matthew.at> wrote:
>=20
> What's excessive is >32 bits for a subnet.
>=20
> No reason subnets should have been as big as they are. Bad for local forw=
arding decisions, waste of bits, etc.
>=20
> Nobody has a physical subnet technology that works for more than a few th=
ousand hosts anyway.
>=20
> Matthew Kaufman
>=20
> (Sent from my iPhone)
>=20
>> On Jul 8, 2015, at 6:19 PM, Mike Hammett <nanog@ics-il.net> wrote:
>>=20
>> /56 even seems a bit excessive for a residential user, but *shrugs*=20
>>=20
>>=20
>>=20
>>=20
>> -----=20
>> Mike Hammett=20
>> Intelligent Computing Solutions=20
>> http://www.ics-il.com=20
>>=20
>>=20
>>=20
>> Midwest Internet Exchange=20
>> http://www.midwest-ix.com=20
>>=20
>>=20
>> ----- Original Message -----
>>=20
>> From: "Mel Beckman" <mel@beckman.org>=20
>> To: "Mike Hammett" <nanog@ics-il.net>=20
>> Cc: "NANOG" <nanog@nanog.org>=20
>> Sent: Wednesday, July 8, 2015 8:11:05 PM=20
>> Subject: Re: Dual stack IPv6 for IPv4 depletion=20
>>=20
>> Yes. The v6 allocation standards are simple, but can alarming to old-sch=
oolers who have not really thought through the math.=20
>>=20
>> A customer gets a /56, which gives them 256 /64 subnets for their own in=
ternal use. That accommodates all except the largest customers, and those h=
ave the option of getting a /32, which gives them 4.2 billion /64s.=20
>>=20
>> ISPs each get a /32 by default, which supports 16.7 million /56 customer=
s. And, of course, the /32 ISP allocation accommodates 4.2 billion ISPs.=20
>>=20
>> I don't see the fear. These are just integers, after all. Nothing is rea=
lly "going to waste".=20
>>=20
>> -mel beckman=20
>>=20
>>> On Jul 8, 2015, at 5:58 PM, Mike Hammett <nanog@ics-il.net> wrote:=20
>>>=20
>>> Isn't /56 the standard end-user allocation?=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> -----=20
>>> Mike Hammett=20
>>> Intelligent Computing Solutions=20
>>> http://www.ics-il.com=20
>>>=20
>>>=20
>>>=20
>>> Midwest Internet Exchange=20
>>> http://www.midwest-ix.com=20
>>>=20
>>>=20
>>> ----- Original Message -----=20
>>>=20
>>> From: "Israel G. Lugo" <israel.lugo@lugosys.com>=20
>>> To: "Mark Andrews" <marka@isc.org>=20
>>> Cc: "NANOG" <nanog@nanog.org>=20
>>> Sent: Wednesday, July 8, 2015 7:45:50 PM=20
>>> Subject: Re: Dual stack IPv6 for IPv4 depletion=20
>>>=20
>>>=20
>>>>> On 07/09/2015 12:59 AM, Mark Andrews wrote:=20
>>>>> In message <559DB604.8060901@lugosys.com>, "Israel G. Lugo" writes:=20
>>>>> Doesn't seem to make sense at all for the ISP side, though. Standard=
=20
>>>>> allocation /32. Giving out /48s. Even if we leave out proper subnet=20
>>>>> organization and allocate fully densely, that's at most 65,536 subnet=
s.=20
>>>>> Not a very large ISP.
>>>> /32 is not the standard allocation. It is the *minimum* allocation=20
>>>> for a ISP. ISPs are expected to ask for *more* addresses to meet their=
=20
>>>> actual requirements.
>>>=20
>>> Thank you for pointing that out. When speaking of /32 I was referring=20
>>> specifically to RIPE policy, with which I am more familiar: "Initial=20
>>> allocation size" for a LIR is /32, extensive to a /29 with minimal=20
>>> bureaucracy. Perhaps I should have said "default allocation".=20
>>>=20
>>> I understand ISPs should ask for more addresses; however, even e.g. a=20
>>> /24 (8x /32) seems to me like it could be "roomier".=20
>>>=20
>>>=20
>>>>> People usually look at IPv6 and focus on the vast numbers of individu=
al=20
>>>>> addresses. Naysayers usually get shot down with some quote mentioning=
=20
>>>>> the number of atoms in the universe or some such. Personally, I think=
=20
>>>>> that's a red herring; the real problem is subnets. At this rate I=20
>>>>> believe subnets will become the scarce resource sooner or later.
>>>> No. People look at /48's for sites. 35,184,372,088,832 /48 sites out o=
f the=20
>>>> 1/8th of the total IPv6 space currently in use. That is 35 trillion si=
tes=20
>>>> and if we use that up we can look at using a different default size in=
the=20
>>>> next 1/8th.
>>> Yes, if we look at end sites individually. My hypothesis is that these=
=20
>>> astronomic numbers are in fact misleading. There isn't, after all, one=
=20
>>> single ISP-Of-The-World, with The-One-Big-Router.=20
>>>=20
>>> We must divide the addresses by ISPs/LIRs, and so on. Several bits in=20
>>> the prefix must be used for subaddressing. A larger ISP will probably=20
>>> want to further subdivide its addressing by region, and so on. With=20
>>> subdivisions comes "waste". Which is something we don't need to worry=20
>>> about at the LAN level, but it would be nice to have that level of=20
>>> comfort at the subaddressing level as well.=20
>>>=20
>>> Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so:=
=20
>>>=20
>>> - I reserve 1 bit for future allocation schemes, leaving me a /33;=20
>>> - 2 bits for network type (infrastructure, residential, business, LTE):=
/35=20
>>> - 3 bits for geographic region, state, whatever: /38=20
>>> - 5 bits for PoP, or city: /43=20
>>>=20
>>> This leaves me 5 bits for end sites: no joy.=20
>>>=20
>>> Granted, this is just a silly example, and I don't have to divide my=20
>>> address space like this. In fact, I really can't, unless I want to have=
=20
>>> more than 32 customers per city. But I don't think it's a very=20
>>> far-fetched example.=20
>>>=20
>>> Perhaps I'm missing something obvious here, but it seems to me that it=
=20
>>> would've been nice to have these kinds of possibilities, and more. It=20
>>> seems counterintuitive, especially given the "IPv6 way of thinking"=20
>>> which is normally encouraged: "stop counting beans, this isn't IPv4".=20
>>>=20
>>> Regards,=20
>>> Israel G. Lugo
>>=20
