Waste will kill ipv6 too

Large Hadron Collider large.hadron.collider at gmx.com
Fri Dec 29 02:51:50 UTC 2017


IPv6 space is being wasted.

We know that much.

No one needs more than 8 bits for site-local global addresses in the 
upper 64 (2/3xxx:xxxx:xxxx:xxxx::/64) of the address.

I'm about to propose the most harebrained idea NANOG has ever seen.

I feel like supersites are getting more addresses than they really need. 
For this purpose, an address is an upper 56, not a full 128-bit address 
(that's a device address, for this purpose...)

A supersite is an ISP, or some other autonomous system fragment.

The current system I've seen, where Sprint's address group appears to 
literally be 2600:0::/29... Sure that anticipates future growth of 
Sprint's network, but it doesn't take into account the needs of other 
supersites.

My proposal is that all addresses be assigned in groups of /48s or even 
/52s (xxxx:xxxx:xxxx:yy00:) for supersites that don't anticipate much 
growth, and that supersites should have to forfeit all upper 56 or 
something addresses they haven't had one routable device address on for 
over 6 months.


On 28/12/2017 15:35, bzs at theworld.com wrote:
> On December 28, 2017 at 13:31 owen at delong.com (Owen DeLong) wrote:
>   >
>   > > On Dec 28, 2017, at 11:14 , bzs at theworld.com wrote:
>   > >
>   > >
>   > > Just an interjection but the problem with this "waste" issue often
>   > > comes down to those who see 128 bits of address vs those who see 2^128
>   > > addresses. It's not like there were ever anything close to 4 billion
>   > > (2^32) usable addresses with IPv4.
>   >
>   > Part of this is correct (the last sentence). There were closer to 3.2 billion
>   > usable IPv4 unicast addresses.
>
> Maybe "usable" doesn't quite express the problem. If someone grabs a
> /8 and makes little use of it (as happened I believe several times)
> the issue wasn't only usable but available to anyone but the /8
> holder.
>
> Whatever, not sure where that goes other than noting that address
> space allocations are often sparsely utilized.
>
>   >
>   > > We have entire /8s which are sparsely populated so even if they're 24M
>   > > addrs that's of no use to everyone else. Plus other dedicated uses
>   > > like multicast.
>   >
>   > Well, a /8 is actually only 16.7 million, not 24M, but I’m not sure that
>   > matters much to your argument.
>
> Oops, right, 24 bits, 16M.
>
>   >
>   > > So the problem is segmentation of that 128 bits which makes it look a
>   > > lot scarier because 128 is easy to think about, policy-wise, while
>   > > 2^128 isn’t.
>   >
>   > Sure, but that’s intended in the design of IPv6. There’s really no need
>   > to think beyond 2^64 because the intent is that a /64 is a single subnet
>   > no matter how many or how few machines you want to put on it.
>   >
>   > Before anyone rolls out the argument about the waste of a /64 for a point
>   > to point link with two hosts on it, please consider that the relative
>   > difference in waste between a /64 with 10,000 hosts on it and a /64 with
>   > 2 hosts on it is less than the rounding error in claiming that a /64 is
>   > roughly 18 quintillion addresses. In fact, it’s orders of magnitude less.
>
> My worry is when pieces of those /64s get allocated for some specific
> use or non-allocation. For example hey, ITU, here's half our /64s,
> it's only fair...and their allocations aren't generally available
> (e.g., only to national-level providers as is their mission.)
>
> So the problem isn't for someone who holds a /64 any more than people
> who are ok w/ whatever IPv4 space they currently hold.
>
> It's how one manages to run out of new /64s to allocate, just as we
> have with, say, IPv4 /16s. If you have one or more /16s and that's
> enough space for your operation then not a problem. If you need a /16
> (again IPv4) right now, that's likely a problem.
>
> That's where 128 bits starts to feel smaller and 2^128 addresses a
> little superfluous if you can't get /bits.
>
>   >
>   > > My wild guess is if we'd just waited a little bit longer to formalize
>   > > IPng we'd've more seriously considered variable length addressing with
>   > > a byte indicating how many octets in the address even if only 2
>   > > lengths were immediately implemented (4 and 16.) And some scheme to
>   > > store those addresses in the packet header, possibly IPv4 backwards
>   > > compatible (I know, I know, but here we are!)
>   >
>   > Unlikely. Variable length addressing in fast switching hardware is “difficult”
>   > at best. Further, if you only use an octet (which is what I presume you meant
>   > by byte) to set the length of the variable length address, you have a fixed
>   > maximum length address of somewhere between 255 and 256 inclusive unless you
>   > create other reserved values for that byte and depending on whether you interpret
>   > 0 to be 256 or invalid.
>
> I was thinking 256 (255, 254 probably at most) octets of address, not
> bits.
>
> One could effect sub-octet (e.g., 63 bits) addresses in other ways
> when needed, as we do now, inside a 128 bit (anything larger than 63)
> address field.
>
>   >
>   > I think that 256 octet addressing would be pretty unworkable in modern hardware,
>   > so you’d have to find some way of defining and then over time changing what the
>   > maximum allowed value in that field could be.
>
> Yes, it would be space to grow. For now we might say that a core
> router is only obliged to route 4 or 16 octets.
>
> But if the day came when we needed 32 octets it wouldn't require a
> packet redesign, only throwing some "switch" that says ok we're now
> routing 4/16/32 octet addresses for example.
>
> Probably a single router command or two on a capable router.
>
>   >
>   > Now you’ve got all kinds of tables and datastructures in all kinds of software
>   > that either need to pre-configure for the maximum size or somehow dynamically
>   > allocate memory on the fly for each session and possibly more frequently than
>   > that.
>
> That's life in the fast lane! What can I say, the other choice is we
> run out of address space. One would hope there would be some lead-in
> time to any expansion, probably years of warning that it's coming.
>
> Or we have to implement IPvN (N > 6) with new packet designs which is
> almost certainly even more painful.
>
> At least that variable length field would be a warning that one day it
> might be larger than 16 octets and it won't take 20+ years next time.
>
>   >
>   > You don’t have to dig very deep into the implementation details of variable
>   > length addressing to see that there’s still, even today, 20 years after the
>   > decision was made, it’s not a particularly useful answer.
>
> It's only important if one tends to agree that the day may come in the
> foreseeable future when 16 octets is not sufficient.
>
> One only gets choices not ideals: a) run out of address space? b)
> Redesign the packet format entirely? c) Use a variable length address
> which might well be sufficient for 100 years?
>
> Each would have their trade-offs.
>
>   >
>   > > And we'd've been all set, up to 256 bytes (2K bits) of address.
>   >
>   > Not really. There’s a lot of implementation detail in there and I don’t think
>   > you’re going to handle 2Kbit addresses very well on a machine with 32K of RAM
>   > and 2MB of flash. (e.g. ESP8266 based devices and many other iOT platforms).
>
> Today's smart phones are roughly as powerful as ~20 year old
> multi-million dollar supercomputers. No one thought that would happen
> either.
>
> But as I said it comes down to choices. Running out of address space
> is not very attractive either as we have seen.
>
>   >
>   > > If wishes were horses...but I think what I'm saying here will be said
>   > > again and again.
>   >
>   > Not likely… At least not by anyone with credibility.
>   >
>   > > Too many people answering every concern with "do you have any idea how
>   > > many addresses 2^N is?!?!" while drowning out "do you have any idea
>   > > how small that N is?
>   >
>   > We may, someday, wish we had gone to some value of N larger than 128,
>   > but I seriously doubt it will occur in my lifetime.
>
> I'll hang onto that comment :-)
>
>   >
>   > Owen
>   >
>




More information about the NANOG mailing list