Too little too late. Even in 2012 it was obvious that ipv6 is the future; pretty much everything already supported it, maybe the hardest obstacle was overcome. Maybe 15 years earlier some alternative format could have gotten traction, but then dot-com boom was in full swing and nobody worried about future and ipv4 exhaustion.

It's fun with all these proposals that so many people think they make sense, presumably including their authors.

This one has a bunch of grave problems.

1. Notice that the address space shortage is not in fact alleviated although it is shy about admitting that. Nobody who doesn't have addresses gets addresses from this scheme. Instead, everybody who already has addresses gets even more of the new addresses and the author simply hopes they'll choose to give them away to those who don't have any. You know, like that time Bobby Kotick got a huge bonus and so he gave the money to er... oh right, he just kept the money.

2. But wait, how would they give away these addresses? The author proposes they can just give away a /29 at a time. In fact, a IPv4 /29 is not routable as a global route, so this will not work. The smallest size you can carve out from the global routes is a /24 and every time you do this you're making things worse for everybody in the backbone game by increasing fragmentation, gosh they're going to be pleased about so much of this "charity".

3. OK, well maybe instead of giving away addresses, our Good Samaritans will give back their existing allocation and take only one /24 for their own network now that is plenty big enough with the new addresses. But that means they must renumber absolutely everything which is one of the things this proposal was supposed to avoid and all their services lose the ability to interoperate properly with everybody who didn't upgrade yet, getting a degraded "sort of like NAT" mode until everybody in the world upgrades. Suckers.

4. It doesn't bother fixing all the other related infrastructure. That work was done for IPv6. PKIX works for IPv6 (certificates for e.g. the DNS service 1.1.1.1 contain IPv6 addresses, no you can't just write any arbitrary text, that's not how it works at all), DNS works for IPv6, all the fancy modern stuff works for IPv6, but you need to begin over for this "Enhanced IP" and the paper neither proposes any way to avoid that, nor does it include all that work, so you're beginning very late in 2012.

Still, there have been much worse attempted solutions written up. My favourites are the ones which don't realise addresses are just bits and propose we can fix everything by writing bigger numbers like 300.400.500.600 ...

> My favourites are the ones which don't realise addresses are just bits and propose we can fix everything by writing bigger numbers like 300.400.500.600 ...

My favorite was one which "realized" that addresses are just bits in the physical wire and proposed to use intermediate values for these bits (that is, using more than two voltages). I wish I had bookmarked that one, it was truly baffling. It was wrong on so many levels that it was hard to know where to start.

> […] but can easily be traversed if you understand the extension.

You need new code to "understand the extension". Any old network stack will not, and will thus not be able to send packets to it… just like old code does not understand IPv6 addresses.

> What am I misunderstanding / oversimplifying?

IPv4 is 32 bits, and all the data structures are 32 bits. We are running out of 32 bit addresses. If you want more address space you have to have more than 32 bits, and it is impossible to squeeze >32 bits in a 32 bit data structures, last time I checked.

So you need to ship code on every single Internet device to update it to handle >32 bits.

We've just spent the last few years shipping new code for larger address data structures, i.e., the 128 bits of IPv6. Look how long that's taken.

And you you want to do that again?

IPv4 options stopped being viable on the internet (everyone drops packets with options) sometime in early 2000s (the quickest doc with references I could find is [0] dated 2014, but I remember the practice started much earlier…), otherwise it looks like an interesting proposal at first sight.

Edit: I didn’t read much into detail, assuming that the hosts that do not understand this extension could just ignore the option. If the scheme doesn’t work in this case as sibling comment suggests, then yeah that’s a problem indeed :)

[0] https://datatracker.ietf.org/doc/html/rfc7126

Because it's not forward compatible - every existing device which speaks IP would need to be upgraded to talk the new way.

Which means that, as you have to start over in a non-compatible manner, you might as well use the opportunity to make other improvements.

Literally everything about IPv6 is easier and better. IPv4 is already much slower than IPv6, now you're adding another layer of complexity on top of it? That doesn't sound too good. IPv6 is and has been ready to go forever now.

> Literally everything about IPv6 is easier and better

That's not true, at a simple level typing "ping 10.34.56.22" is far easier than "ping df99:eff2:245a:46vv:2cmm:dfaa:41ff:2211"

The benefits of ipv6 may outweigh ipv4, but by claiming "everything is easier and better" is disingenuous and a reason so many still refuse to move.

Your example is mostly a non-issue if you have working DNS. Which ... I know is a big assumption in a lot of networks, especially small to medium sized businesses, it seems. I don't know why DNS is such an issue for so many companies, but I can't help but think people would be more positive about ipv6 if we could get internal DNS solved first.

You may think it's a none issue, however it simply disproves the "literally everything" hyperbole

The only difference I see between EnIP and NAT is that both ends have to understand it instead of one end. It's almost exactly NAT but with an extension to store the private-side IP in a header so the router doesn't have to track state.