Dual stack IPv6 for IPv4 depletion

Israel G. Lugo israel.lugo at lugosys.com
Thu Jul 9 02:22:21 UTC 2015



On 07/09/2015 02:31 AM, Owen DeLong wrote:
> Here’s the problem… You started at the wrong end and worked in the wrong direction in your planning.
>
> [...get larger allocation...]
>
> We are now left with only 1,041,888 /20s remaining. You still haven’t put a dent in it.

I am aware of the math, and how it can fit. I will concede that a /20 is
sufficient.

Note, however, the difference in orders of magnitude for typical
allocations. I realize in ARIN side you've got e.g. Comcast with
multiple /20s, but in RIPE that is not so common. My home ISP has 3x
/32s. As I said, default ISP/LIR allocation here is from /32 to /29.
Yes, shorter prefixes can be justified and obtained, but it's not the norm.


> It’s not… It’s a great example of how not to plan your address space in IPv6.
>
> However, if we repeat the same exercise in the correct direction, not only does each of your end-sites get a /48, you get the /20 you need in order to properly deploy your network. You get lots of space left over, and we still don’t make a dent in the IPv6 free pool. Everyone wins.

You basically just said "get a larger allocation"... Which was my point
all along. /32 is not enough, and even /24 could be made much roomier.

Speaking of IPv6's full potential: we're considering 32 subscriptions
per client. I've read people thinking of things like IPv6-aware soda
cans. Refrigerators. Wearables. Cars and their internal components...
You could have the on-board computer talking to the suspension via IPv6,
and reporting back to the manufacturer or whatnot.

Personally, I'm not particularly fond of the whole "refrigerators
ordering milk bottles" craze, but hey, it may very well become a thing.
And other stuff we haven't thought of yet.

My point is: we're changing to a brand new protocol, and only now
beginning to scratch its full potential. Yes, everything seems very big
right now. Yes, 128 bits can be enough. Even 64 bits could be more than
enough. But why limit ourselves? Someone decided (corretly) that 64
would be too limiting.

Please don't fall into the usual "you've got more addresses than
atoms"... I've heard that, and am not disputing it. I'm not just talking
about individual addresses (or /48's).

What I am proposing here, as food for thought, is: what if we had e.g.
192 bits, or 256? For one, we could have much sparser allocations. Heck,
we could even go as far as having a bit for each day of the month. What
would this be good for? I don't know. Perhaps someone may come up with a
use for it.




More information about the NANOG mailing list