[181964] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jul 9 04:09:00 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <1809162078.8261.1436403479285.JavaMail.mhammett@ThunderFuck>
Date: Wed, 8 Jul 2015 18:32:13 -0700
To: Mike Hammett <nanog@ics-il.net>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Only if you are trying to prevent IPv6 from reaching its full potential.
Owen
> On Jul 8, 2015, at 17:57 , Mike Hammett <nanog@ics-il.net> wrote:
>=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
> 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 =
subnets.=20
>>> Not a very large ISP.=20
>> /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
>=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 =
individual=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.=20
>> No. People look at /48's for sites. 35,184,372,088,832 /48 sites out =
of the=20
>> 1/8th of the total IPv6 space currently in use. That is 35 trillion =
sites=20
>> and if we use that up we can look at using a different default size =
in the=20
>> next 1/8th.=20
> 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
