[ale] Slides from my IPv6 talk.

Fri Apr 10 15:53:59 EDT 2009

On Fri, 2009-04-10 at 09:19 -0400, Chris Woodfield wrote:
> Interesting read...thanks for posting this.
> 
> One phrase that I'll take the opportunity to comment on:
> 
> "IPv4 allocations were a paradigm of scarcity
>    –Use of dense allocations to optimize utilization
>   IPv6 allocations are a paradigm of abundance
>    –Use of sparse allocations to optimize versatility
> "
> 
> I'd add some color here to note that there was a time that the IPv6  
> paradigm *was* the paradigm for IPv4 - remember "classful" networking?

	I remember the classful system very well.

> My point being, IMO while the v6 address space is impossibly, hugely,  
> stupendously large, large enough that no one could ever conceive of a  
> time where that address space might ever become scarce, there was a  
> time Way Back In The Day where exactly the same things were said about  
> IPv4.

	Not in my recollection.  Even back in the days when I obtained my Class
B, nobody was claiming that.  That was prior to the NSF taking over the
Internic.  At least nobody who was really involved in the IETF and the
protocols or the allocations.  Even back in the 80's when we still had 3
digit RFC numbers (IPv4 was rfc791 in 1981), it was well understood that
the address pool was a finite, limited, resource.  That's why it had
this variable class structure introduced with IPv4.  We knew we couldn't
just allocate everyone a class A (effectively the previous system of the
first octet being the network number) and that a class C would be
insufficient for many.  One fixed pattern for allocation was just not
going to cut it, either way.  It was the limitation in that address
space that gave rise to the classful system.  It's just that even that
proved to be insufficient to the task of managing that limited resource.

> Back to the specifics of classful networking, there was a time where  
> if you had 1 to 254 hosts, you got a /24 (254 addresses), and if you  
> had more than 254 hosts, you got a /16 allocation (~65,000 addresses).  
> And if you had more than that, you got a /8 - 1.6 million addresses.  
> This is why companies like Xerox, GE, and Interop (yes, the trade show  
> company) now have /8 allocations that they'll never come close to  
> utilizing, but will never give up - which is part of the reason IPv4  
> space is scarce today.

	There have been plenty of discussions at IANA and ARIN and NANOG over
these vary things over the years.  All the IPv6 naysayers drag the old
address recovery and recycling thing out.  All of that fails to address
the OTHER problems of IPv4 and even aggravates some of them (like the
routing table mess) and would only delay the inevitable that was seen
over a decade ago.  And we would still be stuck with this abomination
we've learned to hate called NAT.

> I know this is turning into something of a rant, but the point I'm  
> trying to make is that at some point, some attention must be paid to  
> efficient allocations even in the 128-bit-wide IPv6 space. If not, we  
> risk being in exactly the same situation as we are today with v4 - it  
> will take longer, but it will happen.

	Here we will just have to disagree.  We have to lose the "IPv4 mind
think".  If we don't then we fail to take advantage of many of the
security features and capabilities that are now available to us.

	These numbers are mind boggling huge.

	A single subnet contains 18446744073709551616 host addresses.

	A full network contains 1208925819614629174706176 host addresses across
its 65536 subnets.

	One estimate of the number of neurons in the human brain to be
something on the order of 10^11.  So we could assign 10^14 IPv6
addresses to each neuron and then we would have to be worried about
efficient use of the address space in the IPv6 network in our heads.

	Each TLA (the first 16 bits) has enough addressing capacity to assign
an entire IPv6 /48 network to every IPv4 address (that's exactly what
2002::/16 does, in fact).  We may, one day, have to worry about
efficient allocations in the TLA/NLA space and, who knows, maybe some
huge installations might actually have more that 65536 subnets and need
more networks.  We are seeing some providers supplying non-standard /56
allocations (256 subnets) so they can squeeze 256 allocations out of
each /48 full net.  I don't see it happening in the EUI field, though.
Not in my life time or that of my grandchildren.

	During the development of IPv6 there was extensive discussion over how
big to make those address fields and why.  Just for blind capacity sake,
we could have comfortably gone with half the number of bits.  We don't
need that many addresses but we can really use that addressING to do
more than blindly plug hosts to addresses.  Efficient allocations != BCP
in IPv6.  That was by intent and by design.

	Mike

> -C
> 
> On Apr 9, 2009, at 10:26 PM, Michael H. Warfield wrote:
> 
> > Hello All!
> >
> > 	As promised (though not as FAST as promised) here are my slides from
> > the ALE talk "The Brave New World of IPv6".  They are available in 3
> > formats from my sight, .odp, .ppt, and .pdf.  They are available here:
> >
> > 	http://www.wittsend.com/mhw/2009/IPv6-BNW-ALE-2009.odp
> > 	http://www.wittsend.com/mhw/2009/IPv6-BNW-ALE-2009.ppt
> > 	http://www.wittsend.com/mhw/2009/IPv6-BNW-ALE-2009.pdf
> >
> > 	If you are on IPv6 you can pull them from the IPv6 side of the house
> > here:
> >
> > 	http://www.ip6.wittsend.com/mhw/2009/IPv6-BNW-ALE-2009.odp
> > 	http://www.ip6.wittsend.com/mhw/2009/IPv6-BNW-ALE-2009.ppt
> > 	http://www.ip6.wittsend.com/mhw/2009/IPv6-BNW-ALE-2009.pdf

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20090410/3b1fe7c0/attachment.bin