On Jul 15, 2015, at 13:55 , Barry Shein <bzs@world.std.com> wrote:
On July 15, 2015 at 09:20 owen@delong.com (Owen DeLong) wrote:
There are two ways to waste addresses. One is to allocate them to users who don,Abt actually use all of them.
The other is to keep them on the shelf in the free pool until well past the useful life of the protocol.
I'd add a third which is segmentation and I think that's a real threat. That is, assigning large chunks to specific functions by policy usually in support of technical needs. For example IPv4's multicast block. Poof, 224/4 gone. Or similar.
Suddenly it's not 2^N bits it's just N bits.
My claim is that such segmentation tends to grow over time as people find good arguments to segment.
fd00::/8 is already wasted on ULA. fe80::/10 (effectively fe00::/8) is already allocated (somewhat wastefully, as a /64 probably would do the trick) to link local ff00::/8 is already allocated to multicast. That covers multicast and RFC-1918. Are there any other IPv4 segmentations that you can think of? I’m not being snarky… I’m genuinely interested. Given that we came up with 3 total segmentations in IPv4 over the course of 30 years of IPv4 protocol use, which consumed a total of /4(multicast)+/8+/12+/16(RFC-1918)+/16(link local) of IPv4 and 3 /8s of IPv6. Even if we toss 5 more /8s to segmentation over the next 30 years, I think we’re OK, though we would have burned through a /5 at that point in segmentation. I think effectively, we can consider that e000::/3 is essentially set aside for such purposes and we still have 5/8ths of the address space after burning through the current /3 of unicast and a second /3 of unicast while we contemplate a more restrictive policy. Owen
-- -Barry Shein
The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*