Dual stack IPv6 for IPv4 depletion

Thu Jul 9 08:17:19 UTC 2015

> On Jul 8, 2015, at 19:22 , 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.

Poor allocation practice and/or policy in RIPE is something that should be solved through education and policy change where needed.

The fact that such is apparently commonplace in RIPE is probably an artifact of the RIPE region having deployed IPv6 a bit ahead of much of the world. In part, it’s probably cultural artifact.

In any case, since there’s still a lot of networks that haven’t really deployed IPv6, let’s stop teaching bad ways to do things and focus on doing better going forward.

> 
> 
>> 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.

Sure… And if you need larger allocations, they should be very easy to get.

I haven’t yet built anything that needed more than a /24. However, I have now obtained 3 /24s from ARIN for 3 different networks and not had significant difficulty with any of the 3.

> 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.

Yes, but each of those wouldn’t require its own subscription/network. Most of those things would aggregate into one or more of your wireless networks. By subscriptions, I was literally talking about different ISP connections. 32 is massive overkill… Very few people today have more than 5.

Each cellular device is essentially one since there’s no real local aggregation available. However, everything on the wired and wireless networks in your home would probably share a single attachment. Your car might be its own attachment or might use one or more of your cellular attachments. Your soda cans, refrigerators, wearables, etc. would most likely use one of your fixed or mobile attachments.

> 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.

What I think will become more common than refrigerators ordering things is refrigerators providing inventory management capabilities (including load cells in the shelves that work with positional RFID sensors so that you not only know that you have 3 bottles of milk in the  fridge, but can tell where in the fridge and how much in each bottle).

Zap a QR-Code for a recipe with your cell phone, and the fridge checks in with the cabinets and sends back a list of what you need to buy vs. what you already have in inventory.

> 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.

The additional consumptions you’re talking about all fit within the model I described. You’re either expanding the number of things in the house that are hosts or you’re expanding the number of hosts attached to one of the mobile attach points. I used 32 attach points per person on the planet with the full population of planet earth to be deliberately conservative in the potential number of ISP connections required.

> 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).

I don’t think I did. Nor did I talk about individual /48s.

> 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.

Given that prefix length is baked into the protocol and very hard to change, I’m not eager to abandon what progress has been made deploying IPv6 to go chasing a larger bit field any time soon.

If you think you’ve got something that will convince everyone to rewrite all their software again, go for it, but I’m skeptical as to the potential success of such an endeavor. However, if you do, I have just one request… Please add a 64-bit field to the packet header for “routing destination identifier” so we can do something more intelligent than LISP without encapsulation.

Owen