Draw the lines -mel via cell
> On Jul 8, 2015, at 7:33 PM, Mel Beckman <m...@beckman.org> wrote: > > 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.l...@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. >>
