IP could be easily widened just by taking IP addresses to 64 bits, allocating some new protocol numbers for that, and keeping everything exactly the same. In applications, the same old quad dot notation would work textually: 0.0.0.0 to 65535.65535.65535.65535, the latter being the broadcast address and so on.
The IPv4 space could be embedded such that 1.2.3.4 is both an IPv4 address made of octets, and an "IPv5" made of four hexadecades. Gateways and protocol stacks could convert the packet formats on the fly: a wide packet with addresses whose four values are below 256 could be narrowed, and then received received by IPv4. An IPv4 packet could be widened to "IPv5".
No stupid "neighbor" protocol; just good old ARP, widended to 64 bit IP addresses.
Machines now have native integers that can hold a 64 bit IP address; great for all the masking operations in routing logic and whatnot.
> The IPv4 space could be embedded such that 1.2.3.4 is both an IPv4 address made of octets, and an "IPv5" made of four hexadecades. Gateways and protocol stacks could convert the packet formats on the fly: a wide packet with addresses whose four values are below 256 could be narrowed, and then received received by IPv4. An IPv4 packet could be widened to "IPv5".
What problem do you imagine this would solve?
IPv4 and IPv6 need to be completely independent, because if an IPv4 router were ever to route an IPv6 packet it would send it to the wrong place, likely into a loop. Worse, such misrouting would be unpredictable as BGP tables shifted, links failed over, etc; you might have packets go around a loop several times and then eventually reach their final destination, you might have packets going fine in one direction but misrouted in the other, etc.. It would be a nightmare to debug.
Given that IPv6 packets can never be routed by IPv4 routers, what value is gained by making it easy to embed IPv4 in IPv6? Hosts where both ends have IPv4 addresses ("narrow" in your terminology) are just going to talk IPv4 anyway. And it's not like 4over6 is particularly complex or delaying deployment.
I guess you can have clients that purely talk IPv6 talk with destinations (edge locations) that only talk IPv4, without requiring the whole end-to-end connection and intermediate routers to talk IPv4? You'll just have a router at the end which translates this IPv4-in-IPv6 packet into a pure IPv4 packet and everything will work.
For a v6-only host to talk to a v4-only host you need a router performing stateful NAT64 at some point (it's fundamentally impossible to statelessly route IPv4 packets to v6 hosts because there aren't enough v4 addresses). While in theory that router could live anywhere on the IPv6 network (and packets are routed to it via normal IPv6), normally you'd have it on the 6-only host's network (and coordinate with their DNS servers if they wanted to be able to connect to 4-only hosts by hostname via DNS64).
It's a little ugly, but it's pretty much the same situation those v6-only hosts would be in if they were v4 hosts without public addresses (behind NAT), and they get to use ordinary direct connections when talking to a v6-enabled host on the outside.
"Just widen the addresses" ideas like that are easy to come up with (though they usually keep the IPv4 address as either the prefix or the suffix of the "new" address), but the elephant in the room is always the same: how would a legacy host which only understands classical IPv4 (with 32-bit addresses) talk to a host which only has "new" (wider than 32-bit) addresses?
> how would a legacy host which only understands classical IPv4 (with 32-bit addresses) talk to a host which only has "new" (wider than 32-bit) addresses?
Hosts with 64 bit addresses would have to support 32 bit addresses also, just like is the case with IPv6 hosts that have to have IPv4 stacks.
Under 64 bit addresses, it's conceivable that in fact there would not necessarily have to be an entire IPv4 stack; just protocol conversion to widen and unwiden the data format.
The stack would have to know that certain connections have IPv4 peers, and so it would parse IPv4 datagrams coming from those hosts, and likewise send them IPv4 datagrams.
It could be designed such that if the source and destination addresses (A.B.C.D) of a connection are such that A <= 255 && B <= 255 && C <= 255 && D <= 255, then the hosts may optionally use the smaller IPv4 packet format.
Start from the other end: how would an IPv4-only host with an IP address of, for instance, 198.51.100.1, initiate a connection to a host with a "new" address of 459.256.369.257? The host at 459.256.369.257 can understand the "198.51.100.1" address, but the host at 198.51.100.1 has no way to represent 459.256.369.257 as the destination address in an IPv4 packet.
And even if the answer is "they can't initiate a connection", the same problem also happens in the opposite direction. When the host at 459.256.369.257 initiates a connection to the IPv4-only host at 198.51.100.1, what should it put in the "source address" field, which only has 32 bits since it's an IPv4 packet? If it puts a dummy address there, how would the reply to that packet reach it?
> how would an IPv4-only host with an IP address of, for instance, 198.51.100.1, initiate a connection to a host with a "new" address of 459.256.369.257?
The destination address obviously makes no sense to the IPv4-only host, being outside of the space that it understands, so a direct connection is obviously impossible. (Are you even asking seriously, or is this just snark?)
The wide-address host would have to have an additional IPv4-compatible address bound to its network interface. Or else some other host would have to have such an IPv4-compatible address on its behalf and do NAT or proxying.
> so a direct connection is obviously impossible. (Are you even asking seriously, or is this just snark?)
I am asking seriously, both because I've seen proposals where the proposer does seem to sincerely believe it to be possible to somehow fit more than 32 bits in a 32-bit field (that was a truly baffling one), and because it is possible with stateful hacks similar to NAT64/DNS64 (that is: when the host at 198.51.100.1 tries to look up the address of the host at 459.256.369.257, it receives a fake but valid address, and a router in the path knows to map the fake address to the real address while doing all the necessary NAT shenanigans).
> The wide-address host would have to have an additional IPv4-compatible address bound to its network interface.
Then you gain nothing other than extra complexity, since the total number of hosts is still limited by the 32-bit IPv4 address.
> Or else some other host would have to have such an IPv4-compatible address on its behalf and do NAT or proxying.
Then not only you gain nothing by making your "new" addresses a superset of IPv4 addresses, but also you start looking like IPv6 ended up being, with all its transition mechanisms.
> I've seen proposals where the proposer does seem to sincerely believe it to be possible to somehow fit more than 32 bits in a 32-bit field.
Ah, well, that's obviously not a computer programmer with more than 2 or 3 years of experience. :)
> Then you gain nothing other than extra complexity, since the total number of hosts is still limited by the 32-bit IPv4 address.
Have we gained nothing?
Consider that the majority of the IP addresses in the network are individual subscriber IP addresses, not servers. So we can have a transitional situation in which major service providers use the old 32 bit address space (so they are reachable by every client, 32 or 64 bit), while we put new subscribers into the 64 bit address space.
The users who remain in the 32 bit space will increasingly find that they can't connect to some servers that are in the beyond-32 parts of 64 space, so they will have to upgrade their systems.
Users in 32 space cannot do peer-to-peer with 64 users outside of that space, of course.
> Consider that the majority of the IP addresses in the network are individual subscriber IP addresses, not servers. So we can have a transitional situation in which major service providers use the old 32 bit address space (so they are reachable by every client, 32 or 64 bit), while we put new subscribers into the 64 bit address space.
> The users who remain in the 32 bit space will increasingly find that they can't connect to some servers that are in the beyond-32 parts of 64 space, so they will have to upgrade their systems.
> Users in 32 space cannot do peer-to-peer with 64 users outside of that space, of course.
i.e. exactly the same situation that we currently have, only it would be less visible whether you've upgraded, and harder to debug when you had?
The hard part of deploying IPv6 isn't that the protocol is different (indeed the protocol is significantly simpler e.g. removing fragmentation). The hard part is that it's necessarily a new global routing table, that you necessarily can't use it between two hosts unless every router in between them supports it and has the routes set up. A more IPv4-like packet format would not change that at all.
You might not have identified the really hard part.
Which is this: reams of application code is hard-coded to the AF_INET address family, and its binary sockaddr_in structure, and related data types and functions.
But that's a problem facing any proposed or actual IP facelift.
> I've seen proposals where the proposer does seem to sincerely believe it to be possible to somehow fit more than 32 bits in a 32-bit field.
If someone seriously brings that to me, I'm gonna try and come up with something witty...
"The thing people forget is that the periods in an IPv4 address take up space, too. If you know anything about data octets, you'd realize that were we're wasting adding 8 bits for EACH period just to make those addresses human readable. Periods are the junk DNA if IP addresses.
Fun fact: the reason Comcast is able to charge more for their Internet is because they got Congress to allow them to charge extra for the dots. You know how some people pay $40 for their Internet and you are paying $70? While they are talking to 32 bit addresses at $10 per 8 bits, you are paying the same $10 per 8 bits, and another $30 for IP addess 'junk DNA'! Pull out your cable bill and look for through the fine print. There's a reason the fine print is so small. That's how they obfuscate how they you charge you 75% and get away with it."
I wish I could remember where I saw it so I could share it with you all, but the argument was something like using more voltage levels to fit more values in each bit of the IP address. (It was probably in one of the ietf mailing lists, this sort of crankery seems to get posted there often for some reason.)
> The wide-address host would have to have an additional IPv4-compatible address bound to its network interface.
Yes, we call that (having v4 and v6 addresses) a "dual stack" configuration. The host gets to choose which protocol to use as it desires. If you have a v4 address, you can even refer to that (v4) address in v6 packets[1] by setting the leading bits to 0. That is, v4 "A.B.C.D" as a v6 address is just "::A.B.C.D". The v4 address space is embedded into the v6 address space; this is generally automatic in dual-stack configurations. You can even refer to a v4-only address in a v6 packet as "::FFFF:A.B.C.D".
However, if you want your packets to convert back to v4 automagically (so you only have to speak a single v6 stack)... if you want to autoconvert between IP versions in transit...
> some other host would have to have such an IPv4-compatible address on its behalf
As jandrese already pointed out, that's called 4to6, setup the proxy (if needed), and use "64:ff9b::A.B.C.D" for your v4 addresses.
The thing you seem to be asking for is already a feature of IPv6. However, the thing that can never happen is doing any of this transparently in a v4 packet. Where, specifically, in the IPv4 header[2], are you going to put extra SRC and DST address bits? You cannot change the location of any existing bit in the header: everything (including IP-aware routing hardware) (including the software/firmware of every v4-speaking device, most of which will never - or cannot ever - receive an update) already assumes that e.g. "the source address is on header octet 12-15 (bit 96-127)". The only remotely hypothetical place anything could be added would be in an IP Option field, which would be a terrible idea. Other options might change the location of the new address bits in the header, meaning routers would have to sequentially parse all of the option fields to parse addresses, which would be a mandatory delay even with legacy pure-v4 packets. Also, most firewalls will probably drop the new, unexpected option as "possibly malicious". To do anything else to the header, you would need to change the version number, which immediately introduces the compatibility issues everyone complains about with IPv6.
That's just dual stacking. You're dual stacked at the instant you have to decide to convert the packet header or not. At the end of the day you need a new packet format regardless, so you might as well clean it up in the process.
Fun fact, there is a canonical way to encode an IPv4 address in an IPv6 packet. It's used by 4to6 gateways. IPv6 address parsers understand when you pass them addresses that look like: 64:ff9b::192.168.0.1
If we convert an IPv4 datagram on the way up into the stack into the IPv4-64 format, and then just feed it to a single implementation of TCP or UDP or other protocol, I do not feel it is accurate to say that I we have two protocol stacks.
The real reason is probably closer to Fred Brooks' "second system effect". A new generation IP was regarded by some over-zealous engineers as an opportunity of putting in all sorts of new requirements.
A real engineer would use no microcontrollers, and leverage the physical properties of the materials at hand to automatically lower and raise the toast. https://youtu.be/1OfxlSG6q5Y
IP could be easily widened just by taking IP addresses to 64 bits, allocating some new protocol numbers for that, and keeping everything exactly the same. In applications, the same old quad dot notation would work textually: 0.0.0.0 to 65535.65535.65535.65535, the latter being the broadcast address and so on.
The IPv4 space could be embedded such that 1.2.3.4 is both an IPv4 address made of octets, and an "IPv5" made of four hexadecades. Gateways and protocol stacks could convert the packet formats on the fly: a wide packet with addresses whose four values are below 256 could be narrowed, and then received received by IPv4. An IPv4 packet could be widened to "IPv5".
No stupid "neighbor" protocol; just good old ARP, widended to 64 bit IP addresses.
Machines now have native integers that can hold a 64 bit IP address; great for all the masking operations in routing logic and whatnot.