> I would switch to that "IPv4+" system if it existed.. I am willing to use latest software/standards to future-proof my setup, but duplicating all the work is too much for me.
And exactly how would you accomplish this switch to a larger address space? Please explain the steps exactly how they would be done.
Because IPv4 has 32 bits of address. Anything after IPv4 needed >32 bits of address. How exactly do you fit in >32b in a data structure that is only 32b? You cannot.
So you have to go and replace every bit of networking code out there to change the data structures. You know, like was done to deploy IPv6.
> It seems that the biggest thing the TCP/IP folks got 'wrong' was the 32 bit address space, and even that small change is taking forever to be deployed.
i guess you are alluding to ipv6 here. and imho, ipv6 provides quite a large number of changes from vanilla ipv4. it is not just a much larger address space...
> I know this idea has long missed the boat, but why wasn't IPv4 address space extended by adding an IPv4 Option header that could carry extra address bits?
Because that wouldn't be compatible with existing IPv4 deployments and would cause a reliability havoc when a node not configured to deal with it mangled packets transparently somewhere in between your source and destination end-points.
I don't get the resistance against IPv6. It works. It's a fresh take. Yes it requires some new stuff to be deployed and configured here and there, maybe even requires you to learn something new, but if you thought extending IPv4 would have been any other way you are deluding yourself.
If you're going to do a significant change to something as big as the internet (and introducing a new address scheme is that, no matter how you implement it), you might as well step back and think it all through instead of applying yet another hack.
So tell me. Why are you opposed to IPv6? Why do you want to hang on to this old IPv4-thing which is already at the bursting point, at the edge of what it can take?
> Every year I secretly hope some major consortium with traction release "IPv4 2.0" with 8 bytes and get done with it.
How exactly would this work?
IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.
And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.
But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.
Those are the exact same challenges as with the IPv6 roll-out.
And of course "IPv4 1.0" continues to work, so what motivation is there for going to your "2.0"—just like what motivation is/was there for going to IPv6 when IPv4 is/was 'working'?
See "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993):
> What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6?
The hallmark of a good IPv4+ solution is that it autodeploys without anyone at the network configuration and administration level having to think too much about it. IPv6+IPv4 by contrast generally doubles the configuration complexity of more things than you can count.
It is true that for IPv4+ to be successful nearly everyone currently using IPv4 would need some sort of behind the scenes upgrade to be IPv4+ compatible first before the extended address space would be portable. And that includes incremental upgrades of just about everything that touches IPv4 or IPv4 compatible addresses.
It's not really about whether or not IPv6 is simpler than IPv4, though. It's about how painful moving from IPv4 to IPv6 is. And it's very painful. If the only thing that changed between the two was that the IP address space is bigger, it would reduce the pain of changing.
I'm certainly not going to claim that my experience is representative of anyone except for me, but the reason that I'm not going to shift to IPv6 until I literally have no other choice is because doing so is an enormous undertaking. Since IPv6 doesn't bring me any benefit that I care about, there is no reason to do so unless I simply can't get on the internet without it anymore.
Please note: I am not bashing IPv6 here, and I'm not saying that a change isn't needed. I'm just expressing some of the reasons I've seen why people resist changing to it, and that I think adopting it would have happened within a reasonable timeframe if it weren't as ambitious.
> Why would you make everything gratuitously complicated by having two separate forms of addressing?
If it ain't broke, don't fix it? If IPv6 brings no benefit to my LAN, why should I spend all the effort needed to shift it to IPv6? I can just make the connection to the internet IPv6 and leave everything else alone.
Although I have additional friction in my case, in that I have numerous devices that are IPv4-only. So no matter what, I'd have to at least have one LAN segment that is IPv4.
> There's a surprising number of people who think you could magically expand the IPv4 address space in a backwards compatible manner.
There is a (somewhat) backward-compatible way to do this at least for TCP and UDP:
Instead of assigning an IPv4 network prefix (or one single IP address as a special case), assign a tuple (IPv4 network prefix, port prefix), i.e. by firewall rules not every source port can be used from every IP address for TCP and UDP connections.
Is this a better solution than IPv6? I clearly don't think so. But it is an ugly, hacky solution that is theoretically possible if one really insists that one wants to keep using IPv4 (only), and needs to magically expand the address space.
> Once you go IPv6, you never go back. After dealing with the hell that is limited IPv4 address space, everything just seems so easy.
When I first looked at IPv6, I found it odd that it used 128-bit addresses, when 64 bits would uniquely identify every device (and MAC addresses in practice were 48 bits, because almost nothing uses EUI-64).
Now I look at IPv6 and wish the address was large enough to hold a cryptographic hash.
> Imagine I own a company and I already have a bunch of IP4. I upgrade my network equipment to IP4+, and then keep all my routing and firewall configs. Everything just works the same as before. Now I want to access IP4+, so I add a route entry for all the IPs above 255.255.255.255.
It does not. Because 255.255.255.255 only covers 32 bits and "IP4+" is >32 bits. You'd still have to touch every rule to to tweak the mask.
Oh, and your IP4+ idea already exists:
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[61]
You still need to upgrade bit of networking kit between the source and destination to understand "IP4+", and this (lack of) upgrading and enabling is what is hampering deployment.
What makes you think that companies would have been willing to make the effort to deploy "IP4+" any more than IPv6?
> 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.
> critical flaw of IPv6 being incompatible with IPv4
What other choice do we/did we have? I've responded in the past to a different commenter, who lamented IPv6 not being backwards compatible. You can read my response[1] to that comment; essentially, I don't see a way to make IPv6 happen, aside from the introduction of a new, separate network, mostly due to the pigeonhole principle: IPv4 only has 2 ^ 32 addresses, so how do you fit the 2 ^ 128 IPv6 addresses into that scheme?
You can introduce a legitimately new protocol, like v6 did. You could perhaps add a special flag, or special block of addresses, or a special option — but whatever mutation you perform on IPv4 packets to "upgrade" them, the intermediate routers would still have to understand that flag in order to properly route packets — no? And thus, since they must understand that flag, you're still upgrading the entire infrastructure, and building out a completely separate network, even if it is just IPv4.1.
I do think the IPv4 sunset is far, far out in the future. There will be stragglers for a long time to come, and I'm not sure it's really worth considering when IPv6 isn't deployed to a majority of people yet. But I do think it's possible; at some point, I hope someone realizes that the maintenance of that code is benefiting so few people as to sunset it, perhaps at an ISP-ish level first. No doubt this will break somebody's workflow, though.
> In the end, I think the idea of making all subnets /64's may have been a mistake.
True, but just imagine the subnets are only 64k hosts, with ipv6's address space as a /80.
My own ipv4 routed network (which is currently routed across 5 continents) is based on a space in the 172.16/12 range comprising 5 /16s. A lot of the subnets I use are chopped down to /27, /28 and /29 (and of course /30 and /31s for links and /32s for loopbacks).
That said it's a bit of a squeeze at the moment.
To implement that in an ipv6 world, I'd make every subnet currently sizing between /29 and /25 into a /64. At most it's 8 subnets per /24 at the moment, so call it 16.
As such every /24 I currently allocate would be a /60.
and I have 1280 of those /24s, so 11 bits, which means I need a /49.
Add some expansion space (which I'm currently looking at) and that seems quite neat as a /48.
That's a fairly big network. At some point in the future I could see justifying a second /48.
My company as a whole certainly has more requirement than that, but we have a /32 allocated (we also have a /16 and /19 in ipv4 land and 2 ASes). That /32 could allocate 65,000 of my continent spanning networks. I think we have about 8, and only a couple are really large. The main one is based on the 10/8 network range, which would probably fit into a single /48, but certainly in a handful of them.
> where anyone can grab a /32.
If the requirement to grab a single /32 is an ability to fill in a form asking for it, we aren't going to be running into any issues any time in the next 100 years.
> 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.
> Edit: To make everything a bit clearer, the idea with this "ipv4+" is that you don't need the complexity of running both ipv4 and ipv6 as you do now.
I find that very wild optimism.
- You will still get two incompatible address space V4 and V4+ and that would imply:
-> You still need to modify your software to adapt for V4+ for the transition.
-> Most of your middlebox and firewall rules will get in the way for anything served over V4+. Exactly like for V6
-> DNS would still need to be updated with new record and it will be the same mess
It would be mostly the same mess.
IPv6 has its quirks, but let's be honest: the main problem with Ipv6 is not technical any-more.
The main reason the switch does not happen is that there is no business incentive to switch to IPv6 for most companies and consequently, most companies do not give a fuck.
It wouldn't be trivial in practice. You'd still end up needing to replace everything in between. And if you're going to replace everything in between, you might as well upgrade it to something much larger instead of taking little half steps that will need to be repeated again and again.
> preserving the existing IPv4 addresses
But it wouldn't really in the end. 0.0.1.2.3.4 is still a different address than 1.2.3.4. You'd still end up needing to translate 0.0.1.2.3.4 to 1.2.3.4, aka a 6to4 tunnel. So, you're in the same place in the end as where we are with the current IPv6, just with only a baby step in changes that will probably need to be upgraded again in the future.
> So if all the IPv4 code is written to handle 32-bit addresses, how do you create an addressing system that has more than 32-bits of data, but fits with-in a 32-bit data structure?
IETF also asked that for AS numbers (which were only ~60,000 originally!) Sure enough, there were some reserved bits actually on the spec, which they used to add an extended address. Nowadays, the original BGP actually operates on a single number: AS23456 and the actual AS number is on that reserved spot.
> To me this idea sounds a lot like "why do we need IPV6? Why not keep IPV4 and add a few bytes?" except it's effectively almost the same amount of breakage.
>The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
> Either you're C-compatible or you're not.
If we take this black and white approach then we must say that C++ is not C compatible just like Ada isn't C compatible.
The reality is that C++ being broadly a superset of C was integral to its adoption, even though that compatibility isn't perfect. It enabled easy incremental porting of projects.
This is really just a nit though. I do agree with your conclusions.
Certainly some people didn't like the changes of ND vs ARP and such, but once you're changing the address length, you have to alter the data structure on every bit of networking code, and any transition is going to be a slog.
IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.
And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.
But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.
And of course as long as IPv4 works there's little inherent motivation to go to any kind of IPng.
See "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993):
And exactly how would you accomplish this switch to a larger address space? Please explain the steps exactly how they would be done.
Because IPv4 has 32 bits of address. Anything after IPv4 needed >32 bits of address. How exactly do you fit in >32b in a data structure that is only 32b? You cannot.
So you have to go and replace every bit of networking code out there to change the data structures. You know, like was done to deploy IPv6.
reply