Re: Dual stack IPv6 for IPv4 depletion

[Mel Beckman <mel () beckman org>]

Matthew,

This is where we have to excise our IPv4 "fear of waste" reflex.  A /64 subnet, for example, doesn't waste anything 
material -- these are just integers, 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 carefully considered practical IP allocation 
requirements before deciding on 128 bit addresses. It's enough. Really. 

 -mel beckman

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