Dual stack IPv6 for IPv4 depletion

Mel Beckman mel at beckman.org
Thu Jul 9 02:32:35 UTC 2015


Israel,

You have to draw the limbs somewhere. Why not 512 bits? 1024? The IETF engineers that thought about this long and hard and discussed the topic we've just had, and a thousands of other topics, decided on 128. I'm inclined to give them the benefit of the doubt. :)

-mel via cell

> On Jul 8, 2015, at 7:23 PM, Israel G. Lugo <israel.lugo at lugosys.com> wrote:
> 
> 
> 
>> 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