> A much better solution here would have been an incredibly conservative change to ipv4 to expand the number of available address space
"And what do you base this belief on?
Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6)."[0]
> Fact is you'd run into exactly the same problems as with IPv6.
If you treat IPv4 addresses as a routable prefix (same as today), then the internet core routers don't change at all.
Only the edge equipment would need to be IPv4+ aware. And even that awareness could be quite gradual, since you would have NAT to fall back on when receiving an IPv4 classic packet at the network. It can even be customer deployed. Add an IPv4+ box on the network, assign it the DMZ address, and have it hand out public IPV4+ addresses and NAT them to the local IPv4 private subnet.
IPv6 seems to be a standard that suffered from re-design by committee. Lots of good ideas were incorporated, but it resulted in a stack that had only complicated backwards compatibility. It has taken the scale of mobile carriers to finally make IPv6 more appealing in some cases than IPv4+NAT, but I think we are still a long way from any ISP being able to disable IPv4 support.
> Only the edge equipment would need to be IPv4+ aware.
"Only"? That's still the networking stack of every desktop, laptop, phone, printer, room presentation device, IoT thing-y. Also every firewall device. Then recompile every application to use the new data structures with more bits for addresses.
And let's not forget you have to update all the DNS code because A records are hardcoded to 32-bits, so you need a new record type, and a mechanism to deal with getting both long and short addresses in the reply (e.g., Happy Eyeballs). Then how do you deal with a service that only has a "IPv4+" address but application code that is only IPv4-plain?
Basically all the code and infrastructure that needed to be updated and deployed for IPv6 would have to be done for IPv4+.
But the desktop/laptop/phone/printer was the EASIEST thing to change in that 30 year history. And it would have been the easiest thing to demand a change req from a company for.
Yes: but the process would have been exactly the same whether for a hypothetical IPv4+ or the IPng/IPv6 that was decided on; pushing new code to every last corner of the IP universe.
How could it have been otherwise given the original network structures were all of fixed lengths of 32 bits?
If we have IPv4 address 1.2.3.4, and the hypothetical IPv4+ adds 1.2.3.4.1.2.3.4 (or longer), how would a IPv4-only router handle 1.2.3.4.1.2.3.4? If an IPv4-only host or application gets a DNS response with 1.2.3.4.1.2.3.4, how is it supposed to use it?
As I see it, the transition mechanism for some IPv4+ that 'only' has longer addresses is exactly the same as for IPv6: new code paths that use new data structures, with a gradual rollout with tech refreshes and code updates where hosts slowly go from IPv4-only to IPv4-and-IPv4+ at different rates in different organizations.
If you think it's somehow different, can you explain how it is so? What proposal available (especially when IPng was being decided on in the 1990s) would have allowed for a transition that is different than the one described above (gradual, uncoördinated rollout)?
The proposal is that IPv4+ would be interpretable as an IPv4 packet. Either the IP header is extended, or we add another protocol layer for the IPv4+ bits (IPv4+ is another envelope for the user payload).
DNS is like today: A and AAAA records for IPv4 and IPv4+ respectively.
Core routers do not need to know about IPv4+, and might never know.
The transition is similar to 6to4. The edge router does translation to allow IPv4+ hosts to connect to IPv4 hosts. IPv4 hosts are unable to connect to IPv4+ directly (only via NAT). So it has the similar problem to IPv6 that you ideally want all servers to have a full IPv4 address.
What you don't have is a completely parallel addressing system, requirements to upgrade all routers (only edge routers for 4+ networks), requirements to have your ISP cooperate (they can just give you an IPv4 and you handle IPv4+ with your own router), and no need that the clients have two stacks operating at once.
It's essentially a better NAT, one where the clients behind other NATs can directly connect, and where the NAT gradually disappears completely.
If you hand UTF-8 that actually uses anything added by utf-8 to something that can only render ASCII, the text will be garbled. People can read garbled text ok if it’s a few missing accented characters in a western language, but it’s no good for Japanese or Arabic.
In networking terms, this is like a protocol which can reach ipv4 hosts only but loses packets to the ipv4+ hosts randomly depending on what it passes through. Who would adopt a networking technology that fails randomly?
v6 has nearly 3 billion users. How is that abysmal?
We've never done something like the v4->v6 migration before, on this sort of scale. It's not clear what the par time for something like this is. Maybe 30 years is a normal amount of time for it to take?
HTTP->HTTPS was this kind of scale, and it was smooth because they changed as little as possible while also being very careful about default behaviors.
3 billion people sorta use ipv6, but not really, cause almost all of those also rely on ipv4 and no host can really go ipv6-only. Meanwhile, many sites are HTTPS-only.
And because it's a layer 7 thing, so it only required updating the server and client software, not the OS... and only the client and server endpoints and not the routers in between... and because we only have two browser vendors who between them can push the ecosystem around, and maybe half a dozen relevant web server daemons.
Layer 3 of the Internet is the one that requires support in all software and on all routers in the network path, and those are run by millions of people in hundreds of countries with no central entity that can force them to do anything.
HTTP->HTTPS is only similar in terms of number of users, not in terms of the deployment itself. The network effects for IP are much stronger than for HTTP.
They don't "sorta" use v6, they're properly using it, and you can certainly go v6-only. I'm posting from a machine with no v4. Also, if you want to go there: HTTPS was released before IPv6, and yet still no browser is HTTPS only, despite how much easier it is to deploy it.
I know they aren't very comparable in a technical way, but look at the mindset. IPv6 included decisions that knowingly made it more different from v4 than strictly needed, cause they wanted it to be perfect day 1. If they did HTTPS like this, it'd be tied to HTTP/2.
Most browsers now discourage plain HTTP with a warning. Any customer-facing server basically needs to use HTTPS now. And you're rare if you actually have no ipv4, not even via a tunnel.
The compromised "ipv4+" idea a bunch of people keep asking for wouldn't require changing the spec down the road. ISPs would just need to clean up their routes later, and SLAAC could still exist as an optional (rather than default) feature for anyone inclined to enable later. Btw, IPv6 spec was only finalized in 2017, wasn't exactly one-shot.
I don't know if HTTP's job is easier. Maybe on the client side, since there were never that many browsers, but you have load-balancers, CDNs, servers, etc. HTTP/2 adoption is still dragging out because of how many random things don't support it. Might be a big reason why gRPC isn't so popular too.
> HTTP->HTTPS was this kind of scale, and it was smooth because they changed as little as possible while also being very careful about default behaviors.
HTTP->HTTPS is not equivalent in any way. The payload in HTTP and HTTPS are exactly the same; HTTPS simply adds a wrapper (e.g., stunnel can be used with an HTTP-only web server). Further HTTP(S) is only on the end points, and specifically in the application layer: your OS, switch, firewall, CPE, ISP router(s), etc, all can be left alone.
If you're not running a web browser or web server (i.e., FTP, SMTP, DNS, database) then there are zero changes that need to be made to any code on a system. This is not true for changing the number of bits the addressing space: every piece of code that calls socket(), bind(), connect(), etc, has to be touched.
Whereas the primary purpose of IPng was to expand the address space, which means your OS, switch, firewall, CPE, ISP router(s), etc, all have to be modified to handle more address bits in the Layer 3 protocol data unit.
Plus stuff at the application layer like DNS (since A records are 32-bit only, you need an entire new network type): entire new library functions had to be created (e.g., gethostbyname() replaced by getaddrinfo()).
I hear people say the IETF/IP Wizards of the 1990s should have "just" picked an IPng that was a larger address space, but don't explain how IPv4 and hypothetical IPv4+ would actually work. Instead of 1.1.1.1, a packet comes in with 1.1.1.1.1.1.1.1: how would a non-IPv4+ router know what to do with that? How would non-updated routers and firewalls be able to handle longer addresses? How would non-updated DNS code be able to handle new record types with >32 bits?
HTTP->HTTPS looks easy in hindsight, but there were plenty of ways it could have gone wrong. They took the path of least resistance, unlike ipv6. I know they're different layers ofc.
To answer the last question, routers would need IPv4+ support, just like ipv6 which already happened. The key is it's much easier for users to switch after. No dual stack, you get the same address, routes, DNS, and middleboxes like NAT initially. ISPs can't hand out longer addrs like /40 until things like DNS are upgraded in-place to support that, but again those are pretty invisible changes throughout the stack.
> To answer the last question, routers would need IPv4+ support, just like ipv6 which already happened.
So exactly like IPv6: you need to roll out new code everywhere.
> The key is it's much easier for users to switch after. No dual stack, you get the same address, routes, DNS, and middleboxes like NAT initially. ISPs can't hand out longer addrs like /40 until things like DNS are upgraded in-place to support that, but again those are pretty invisible changes throughout the stack.
So exactly like IPv6: you need to roll out new code everywhere.
Would organization have rolled out in IPv4+ any differently than IPv6? Some early, some later, some questioning the need at all. It's the exact same coördination / herding cats problem.
It's a simple toggle on vs asking orgs to redo their entire network. In both cases you need routers and network stacks to support the new packet format, but that isn't the hard part of ipv6, we already got there and people still aren't switching.
Sorry, I'm still not seeing how a IPv4+ would be any less complicated (or as simple) as IPv6. In either case you would still have to:
* roll out new code everywhere
* enable the protocol on your routers
* get address block(s) assigned to you
* put those blocks into BGP
* enable the protocol on middleware boxes
* have translation boxes for new-protocol hosts talk to old-protocol-only hosts
* enable the protocol on end hosts
And just because you do it, does not mean anyone else would do in the same timeframe (or ever). You're back in the chicken-and-egg of whether servers/services do it first ("where are the clients?"), or end-devices ("where are the services?").
Redo all your addresses and routes, reconfigure or replace NAT and DHCP, reconfigure firewall, change your DNS entries at minimum. If it's a home or small business and you don't want to fight the defaults, you go from NAT to NATless.
No, routers would have to be fixed anyway, because even if you put extra bits into extension header we have 30 years of experience that routers and ISPs will regularly fuck around with those extra bits - it's related to why we have TLS GREASE option.
Application rework would be exactly the same as with v6, because the issue was not with v6 but with BSD Sockets API exposing low-level details to userland.
> Only the edge equipment would need to be IPv4+ aware. And even that awareness could be quite gradual, since you would have NAT to fall back on when receiving an IPv4 classic packet at the network. It can even be customer deployed. Add an IPv4+ box on the network, assign it the DMZ address, and have it hand out public IPV4+ addresses and NAT them to the local IPv4 private subnet.
Congratulations, you’ve re-invented CGNAT, with none of the benefits, and the additional hassle of it being an entirely new protocol!
No. No “extra bits” on an IPv4 address would have ever worked. NAT itself is a bug. Suggesting that as an intentional design is disingenuous.
I have not "reinvented CGNAT". It is hierarchal public addressing similar to IPv4 and IPv6.
The edge router has an IPv4+ subnet (either a classic v4 address, or part of a v4+ address). It maintains an L2 routing table with ARP+, and routes IPv4+ packets to the endpoint without translation. Private subnetting and NAT is only needed to support legacy IPv4 clients.
CGNAT pools IPv4 public addresses and has an expanded key for each connection, and translates either 4 to 6 or into a private IPv4 subnet. My proposal needs no pooling and only requires translation if the remote host is IPv4 classic and the edge router is not assigned a full IPv4+/24.
Not just the edge router. Every router between the ISP edge and the destination edge.
And since the goal is “backwards-compatability”, you’d always need to poll, because a “legacy” IPv4 client would also be unable to send packets to the IPv4+ destination. Or receive packets with an IPv4+ source address.
And it would be an absolute nightmare to maintain. CGNAT + a quasi backwards-compatible protocol where the backwards-compatability wouldn’t work in practice.
So you would have exactly the same problem as IPv6. I can say the same about v4 and v6 today. You could just turn off IPv4 on the internet, and we’d only need to do translation on the edge for the legacy clients that would still use IPv4. You can even put IPv4 addresses in IPv6 packets!
I think you've actually reinvented 6to4, or something morally very close to it.
Each v4 address has a corresponding /48 of IPv6 tunnelled to it. The router with that IP receives the tunnelled v6 packets, extracts them and routes them on natively to the end host. This is something that v6 already does, so you don't need to make posts complaining about how dumb they were for not doing it.
That's quite true, but in this counterfactual, IPv4+ doesn't pretend that 6to4 is just a transition mechanism to an all-IPv6 future. That is, IPv4+ is as-if 6to4 was the default, preferred, or only mechanism, and core routers were never demanded to upgrade.
It's an edge based solution similar to NAT, but directly addressable. And given that it extends IPv4, I think it would have been much more "marketable" than IPv6 was.
But again, this is all counterfactual. The IETF standardized IPv6, and 30 years on it's still unclear that we will deprecate IPv4 anytime soon.
I agree with that belief, and I've been saying it for over 20 years.
I base it on comparing how the IPv2 to IPv4 rollout went, versus the IPv4 to IPv6 rollout. The fact that it was incredibly obvious how to route IPv2 over IPv4 made it a no-brainer for the core Internet to be upgraded to IPv4.
By contrast it took over a decade for IPv6 folks to accept that IPv6 was never going to rule the world unless you can route IPv4 over it. Then we got DS-Lite. Which, because IPv6 wasn't designed to do that, adds a tremendous amount of complexity.
Will we eventually get to an IPv6 only future? We have to. There is no alternative. But the route is going to be far more painful than it would have been if backwards compatibility was part of the original design.
Of course the flip side is that some day we don't need IPv4 backwards compatibility. But that's still decades from now. How many on the original IPv6 will even still be alive to see it?
The IPv2 to IPv4 migration involved sysadmins at less than 50 institutions (primarily universities and research labs), updating things they considered to be a research project, that didn’t have specialised network hardware that knew anything about IP, and any networked software was primarily written either by the sysadmins themselves or people that one of them could walk down the corridor to the office of. Oh, and several months of downtime if someone was too busy to update right now was culturally acceptable. It’s not remotely the same environment as existed at the time of IPv6 being designed
Hardware would catch up. And IPv4 would never go away. If you connect to 1.1.1.1 it would still be good ole IPv4. You would only have in addition the option to connect to 1.1.1.1.1.1.1.2 if the entire chain supports it. And if not, it could still be worked around through software with proxies and NAT.
So... just a less ambitious IPv6 that would still require dual-stack networking setups? The current adoption woes would've happened regardless, unless someone comes up with a genius idea that doesn't require any configuration/code changes.
I disagree. The current adoption woes are exactly because IPv6 is so different from IPv4. Everyone who tries it out learns the hard way that most of what they know from IPv4 doesn't apply. A less ambitious IPv4 is exactly what we need in order to make any progress
It’s not _that_ different. Larger address space, more emphasis on multicast for some basic functions. If you understand those functions in IPv4, learning IPv6 is very straightforward. There’s some footguns once you get to enterprise scale deployments but that’s just as true of IPv4.
Lol! IPv4 uses zero multicast (I know, I know, technically there's multicast, but we all just understand broadcast). The parts of an IPv4 address and their meaning have almost no correlation to the parts of an IPv6 address and their meaning. Those are pretty fundamental differences.
IP addresses in both protocols are just a sequence of bits. Combined with a subnet mask (or prefix length, the more modern term for the same concept) they divide into a network portion and a host portion. The former tells you what network the host is on, the latter uniquely identifies the host on that network. This is exactly the same for both protocols.
Or what do you mean by “parts of an IPv4 address and their meaning”?
That multicast on IPv4 isn’t used as much is irrelevant. It functions the same way in both protocols.
The biggest difference is often overlooked because it's not part of the packet format or anything: IPv4 /32s were not carried over to IPv6. If you owned 1.1.1.1 on ipv4, and you switch to ipv6, you get an entirely different address instead of 1.1.1.1::. Maaybe you get an ipv6-mapped-ipv4 ::ffff:1.1.1.1, but that's temporary and isn't divisible into like 1.1.1.1.2.
And then all the defaults about how basically everything works are different. Home router in v6 mode means no DHCP, no NAT, and hopefully yes firewall. In theory you can make it work a lot like v4, but by default it's not.
> The current adoption woes are exactly because IPv6 is so different from IPv4. Everyone who tries it out learns the hard way that most of what they know from IPv4 doesn't apply.
In my experience the differences are just an excuse, and however similar you made the protocol to IPv4 the people who wanted an excuse would still manage to find one. Deploying IPv6 is really not hard, you just have to actually try.
Part of the ipv6 ambition was fixing all the suboptimally allocated ipv4 routes. They considered your idea and decided against it for that reason. But had they done it, we would've already been on v6 for years and had plenty of time to build some cleaner routes too.
I think they also wanted to kill NAT and DHCP everywhere, so there's SLAAC by default. But turns out NAT is rather user-friendly in many cases! They even had to bolt on that v6 privacy extension.
> I said it's different from IPv4. At the IP layer.
In what way? Longer addresses? In what way is it "so different" that people are unable to handle whatever differences you are referring to?
We used to have IPv4, NetBEUI, AppleTalk, IPX all in regular use in the past: and that's just on Ethernet (of various flavours), never mind different Layer 2s. Have network folks become so dim over the last few years that they can't handle a different protocol now?
Current statistics are that a bit over 70% of websites are IPv4 only. A bit under 30% allow IPv6. IPv6 only websites are a rounding error.
Therefore if I'm on an IPv6 phone, odds are very good that my traffic winds up going over IPv4 internet at some point.
We're 30 years into the transition. We are still decades away from it being viable for servers to run IPv6 first. You pretty much have to do IPv4 on a server. IPv6 is an afterthought.
> We are still decades away from it being viable for servers to run IPv6 first.
Just put Cloudflare in front of it. You don’t need to use IPv4 on servers AT ALL. Only on the edge. You can easily run IPv6-only internally. It’s definitely not an afterthought for any new deployments. In fact there’s even a US gov’t mandate to go IPv6-first.
It’s the eyeballs that need IPv4. It’s a complete non-issue for servers.
Listen, you can be assured that the geek in me wants to master IPv6 and run it on my home network and feel clever because I figured it out, but there's another side of me that wants my networking stuff to just work!
If you don’t want to put Cloudflare in front of it, you can dual-stack the edge and run your own NAT46 gateway, while still keeping the internal network v6 only.
You have a point. But you still need DNS to an IPv4 address. And the fact that about 70% of websites are IPv4 only means that if you're setting up a new website, odds are good that you won't do IPv6 in the first pass.
Cloudflare proxy automatically creates A and AAAA records. And you can’t even disable AAAA ones, except in the Enterprise plan. So if you use Cloudflare, your website simply is going to be accessible over both protocols, irrespective of the one you actually choose. Unless you’re on Enterprise and go out of your way to disable it.
Actually, my bad. NAT was NEVER standardized. Not only NAT was never standardized, it’s never even been on standards track. RFC 3022 is also just “Informational”
Plus, RFC 1918 doesn’t even mention NAT
So yes, NAT is a bug in history that has no right to exist. The people who invented it clearly never stopped to think on whether they should, so here we are 30 years later.
That doesn't really mean much. Basic NAT wasn't eligible to be on the standards track as it isn't a protocol. Same reason firewall RFCs are informational or BCP.
The protocols involving NAT are what end up on the standards track like FTP extensions for NAT (RFC 2428), STUN (RFC 3489), etc.
It didn’t speed up adoption and people then tried most of the other solutions people are going to suggest for IPv4+. Want the IPv4 address as the network address instead? That’s 2002:a.b.c.d/48 - many ISPs didn’t deploy that either
Think of it like phone numbers. For decades people have accepted gradual phone number prefix additions. I remember in rural Ireland my parents got an extra digit in the late 70s, two more in the 90s, and it was conceptually easy. It didn't change how phones work, turn your phone into a party line or introduce letters or special characters into the rotary dial, or allow you to skip consecutive similar digits.
For people who deal with ip addresses, the switch from ipv4 to ipv6 means moving from 4 digits (1.2.3.4) to this:
Yes, the ipv6 examples are all the same address. This is horrible. Worse than MAC addresses because it doesn't even follow a standard length and has fancy (read: complex) rules for shortening.
Plus switching completely to ipv6 overnight means throwing away all your current knowledge of how to secure your home network. For lazy people, ipv4 NAT "accidentally" provides firewall-like features because none of your home ipv4 addresses are public. People are immediately afraid of ipv6 in the home and now they need to know about firewalls. With ipv4, firewalls were simple enough. "My network starts with 192.168, the Internet doesn't". You need to learn unlearn NAT and port forwarding and realise that with already routable ipv6 addresses you just need a firewall with default deny, and then add rules that "unlock" traffic on specific ports to specific addresses. Of course more complexity gets in the way... devices use "Privacy Extensions" and change their addresses, so making firewall rules work long-term, you should use the device's MAC Address. Christ on a bike.
I totally see why people open this bag of crazy shit and say to themselves "maybe next time I buy a new router I'll do this, but right now I have a home with 4 phones, 3 TVs, 2 consoles, security cameras, and some god damn kitchen appliances that want to talk to home connect or something". Personally, I try to avoid fucking with the network as much as possible to avoid the wrath of my wife (her voice "Why are you breaking shit for ideological reasons? What was broken? What new amazing thing can I do after this?").
What is confusing about that? That's like complaining that you can write an IPv4 address as 001.002.003.004 or 1.2.3.4. Even the :: isn't much different from being able to write 127.0.0.1 as 127.1 (except it now becomes explicit that you've elided the zeroes).
While it's possible to write an ipv4 address in a bunch of different ways (it's just a number, right?) nobody does it because ipv4 standard notation is easy to remember. Ipv6 is not, and none of these attempts to simplify it really work because they change the "format". I understand it and you understand it, but the point here is that it's unfriendly to anyone who isn't familiar with it.
These are all the same address too:
1.2.3.4, 16909060, 0x1020304, 0100401404, 1.131844, 1.0x20304, 1.0401404, 1.2.772, 1.2.0x304, 1.2.01404, 1.2.3.0x4, 1.2.0x3.4, 1.2.0x3.0x4, 1.0x2.772, 1.0x2.0x304, 1.0x2.01404, 1.0x2.3.4, 1.0x2.3.0x4, 1.0x2.0x3.4, 1.0x2.0x3.0x4, 0x1.131844, 0x1.0x20304, 0x1.0401404, 0x1.2.772, 0x1.2.0x304, 0x1.2.01404, 0x1.2.3.4, 0x1.2.3.0x4, 0x1.2.0x3.4, 0x1.2.0x3.0x4, 0x1.0x2.772, 0x1.0x2.0x304, 0x1.0x2.01404, 0x1.0x2.3.4, 0x1.0x2.3.0x4, 0x1.0x2.0x3.4, 0x1.0x2.0x3.0x4
v6 has optional leading zeros and ":: splits the address in two where it appears". v4 has field merging, three different number bases, and it has optional leading zeros too but they turn the field into octal!
"Why are you breaking shit for ideological reasons? What was broken? What new amazing thing can I do after this?"
LOL. Yup. What can I do after this? The answer is basically "nothing really" or "maybe go find some other internet connection that also has IPv6 and directly connect to one of my computers inside the network (which would have been firewalled I'd hope so I'd, what, have to punch open a hole in the firewall so my random internet connection's IPv6 can have access to the box? how does that work? I could have just VPN'd in with the IPv4 world).
Seriously though, how do I "cherry pick hole punch" random hotel internet connections? It's moot anyway because no hotel on earth is dishing out publicly accessable IPv6 addresses to guests....
Hardware support for ipv6 hasn't been the limiting factor in a long time. Users higher on the stack don't want to adopt something that makes so many unnecessary changes.
You’re focusing on the technical difficulty of implementing it in software. This is not the problem. IPv6 support is now present in almost every product, but people still refuse to set it up because it’s so different to what they’re used to (I’m not arguing whether the changes are good - they’re just changes). IPv4+ would’ve solved this social problem.
There’s absolutely, utterly zero chance IPv4+ would be adopted. CGNAT is the solution to the social problem.
I don’t even buy your way of thinking - unlike an “engineering” solution or an “incentives” solution, the problem with “social solutions I speculate about” is: they offer nothing until implemented. They are literally all the same, no difference between the whole world of social solutions, until they are adopted. They are meaningless. They’re the opposite of plans.
Like what’s the difference between IPv4+, which doesn’t exist, and “lets pass a law that mandates ipv6 support”? Nothing. This is what the mockery of “just pass a law” is about. I don’t like those guys, but they are right: it’s meaningless.
This is a good point. The same “why should I migrate” would affect it. However, it being so close to the predecessor, it would be much easier to do so, catching way more people who are on the fence.
The IPv4+ could pass through a router that doesn't know about it - the cloud host that receives that packet could interpret it in a special way, in fact you could stuff additional data into the next layer of the stack for routing - it's not like many services beyond TCP would need to support the scheme.
> The IPv4+ could pass through a router that doesn't know about it
It couldn't do that reliably. We don't have any flags left for that that. Options are not safe. We've got one reserved flag which is anyways set to 0, so that's not safe either.
There's the reserved bit (aka the evil bit[1]). Are you saying gear out there drops packets with reserved bit set to 1? Wouldn't surprise me, just curious.
Seems like IPv4+ would have been a good time to use that bit. Any IPv4+ packets could have more flags in the + portion of the header, if needed.
That bit is currently defined as "Bit 0: reserved, must be zero", so there will be network gear out there, that either drops the packet otherwise or resets the bit to 0 when forwarding.
That makes it effectively impossible to ever use then, so a waste of a bit. Too bad they made that mistake when writing the spec. Would have been better if they specified it like most APIs, ie ignore if you get it, carry it if you forward, and set it to zero if you send it.
It depends what you want to achieve. If we had some feature which is actually incompatible and needed everything else to set it to 0, then it would be perfect. It's not a mistake when you don't predict the future.
"And what do you base this belief on?
Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6)."[0]
0: https://news.ycombinator.com/item?id=37120422