7 ms·

> And regarding compatibility, with ipv4+ if you have a 0.0.0.0.x.x.x.x ip address you would be able to talk to both ipv4+ aware and legacy ipv4 devices nativel

> And regarding compatibility, with ipv4+ if you have a 0.0.0.0.x.x.x.x ip address you would be able to talk to both ipv4+ aware and legacy ipv4 devices natively without any tunneling (because you also own the legacy, non quad 0 ip address). This 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] * https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse... * https://datatracker.ietf.org/doc/html/rfc4291#section-2-5-5 https://datatracker.ietf.org/doc/html/rfc4291#section-2-5-5 You still need to upgrade bit of networking kit between the source and destination to understand "IPv4+", 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 "IPv4+" any more than IPv6?

theamk 4y ago
Mayne RFC exists, but it os not used in teal world anywhere. In all servers, I configure IPv4 and IPv6 separately. Network setup is separate. DHCP daemons are separate. Firewall rules are separate. Network monitoring is separate. 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.
- icedchai 4y ago
  Ok. How do you increase address space without breaking the protocol? IPv4 just doesn't have the space in the header. Something like "v4+" can't happen for this reason. You could argue that pervasive use of NAT beginning in the late 90's was "v4+". It bought us decades of Internet growth, at the expense of true end-to-end connectivity.
- throw0101a 4y ago
  > 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.
  - CountSessine 4y ago
    In theory this could be handled by stuffing the extra 96 bits in an IP extension header. But this solves nothing because then any switch that isn’t IPv4+ aware will route packets incorrectly. Literally every single switch on the internet needs to be updated/replaced before you could start generating IPv4+ traffic otherwise the one outlier will send your IPv4+ packets off to Uzbekistan. OR Maybe you don’t use those 96 bits for routing. But then it becomes nothing but a sort of subnet address and you haven’t fixed the routing table size problem. And actually every endpoint needs to upgrade too because endpoints that don’t recognize the header extension will generate crazy responses and confuse TCP packets from different computers as coming from the same machine. There’s no useful and backward compatible way of extending IPv4.
    - theamk 4y ago
      Or you extend on network level, and even kernel level, but keep programming API compatible. I don't think people like IPv4 packets that much, it is all the APIs which are giving problem. I bet if we kept everything about IPv6 the same, but (1) made IPV6_V6ONLY mandatory and default to zero (2) did not use colon in IP address representation (3) recommended firewalls use same config rules for IPv4/IPv6 address.. then IPv6 would have significantly higher adoption right now.
      - wbl 4y ago
        That mistake was already baked in to the sockaddr_t ABI.
- error503 4y ago
  There are viable transition mechanisms other than dual stack, that put some kind of translation layer between protocols, rather than expect native IPv4 connectivity on all hosts. This is perfectly viable, and is how many mobile networks handle IPv4 (ie. there is no native IPv4 on the handset at all), and how many cloud providers are handling it these days too. You have to do NAT at the border anyway, why not NAT to/from an IPv6 address? The adoption problem doesn't have that much to do with the technology, it's simply that it provides little value to most individual entities participating in the network, even if the benefit in aggregate is clear, so it's difficult to achieve the critical mass to make it valuable. It's the same thing behind climate change and so many other societal issues.
  - unquietwiki 4y ago
    You might appreciate this. Basically, it leverages Babel routing to bridge IPv4 with IPv6. https://datatracker.ietf.org/doc/rfc9229/ https://datatracker.ietf.org/doc/rfc9229/
anthropodie 4y ago
> What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6? I'm pretty sure that those who built new protocol were aware of this and were like "anyway we are gonna have to upgrade network devices. Why don't we build a new protocol while avoiding pitfalls of older one" Any comittee that sat down to solve IPv4 issue would have thought of compatibility first. I am shocked that so many people agree with OP's armchair solution here.
- salmo 4y ago
  They took much more on with IPv6 than IPv4 replacement. The spec goes much deeper than IPv4 did, replacing ARP, DHCP, etc. It's a product of its time, including a lot of over-engineering by committee. Many of the problems they tried to address didn't pan out to be real issues. You can read the RFCs and compare. IPv4 w/ more bits is a lot more simple. Yes, older network gear wouldn't deal with it well, but that's not a real issue today because that same network gear supports IPv6. Buuut, one of the biggest problems with app-level issues is just that the app doesn't bother dealing with IPv6 addresses and AAAA records. It would be the same issue with an imaginary IPv4*2.
  - theteapot 4y ago
    Agree. Second system effect in action -- https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect.
  - onphonenow 4y ago
    No kidding - they got rid of dhcp and more but it’s a nightmare getting networks to work with just ipv6 concepts- everything from provisioning phones (dhcp options to push config / NetBoot stuff) and more. Layer in privacy extensions, renumbering on uplink wan flapping (slow too - the failover is pathetic compared to NAT wan failover) - icmp traffic differences - firewalls need to be much more careful with ipv6 and related protocols because things can easy break (it’s fragile) or you create risks. Even min subnet sizes mean crazy 2 node subnet sizes (think isp and cpe management subnet for a customer). Also curious why not 48 or 64 bits or 96 bits? 128 bits is ludicrous
nikanj 4y ago
> What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6? Way less resistance from tech teams. Ultimately companies are made of people, and ipv6 is partly a failure because working with it requires a wholly new skillset
- zamadatix 4y ago
  Maybe it’s different on the software side but coming from a network VAR it’s the same skill set. You still have subnets and routes and netmasks and DHCP or automatic assignments the difference is the size. If you know IPv4 all you need to learn is “the subnets are all /64 in size, addresses are 128 bits, and you don’t need DHCP if you don’t want”.
  - anyfoo 4y ago
    Yeah, but I have to say, even as someone who wants IPv6 to succeed and supersede IPv4, from the perspective of building that network infrastructure software, I think this "IPv4+" would have been massively simpler to add, extremely so, and that may have aided adoption a lot. It's really hard to overstate how much simpler tacking on 128bit IP addresses to an otherwise unmodified protocol would have been in the software stack of network infrastructure. But, as I also said a few times here, the time to make desirable compatibility-breaking changes was exactly then, when every piece of network equipment needed massive alteration or replacement anyway. And I look forward to the day IPv6 hopefully becomes predominant, and the advantages it brings.
    - Dagger2 4y ago
      The majority of the problems seem to come from the fact that v6 addresses are longer than v4 ones. That's why we need socket(AF_INET6)s and AAAA records and a DNS API that supports multiple address families and dual stack and new firewalling and updates to all protocols that embed v4 addresses. You're going to have the exact same problems with any protocol that has addresses longer than v4's.
      - 4y ago
nightfly 4y ago
We've tried to roll out IPv6 at my work, and after several years of it causing more issues than it help we turned it all off again... We're gonna get back to it again this year, but I can see many organizations just not doing that until absolutely forced.
- throwaway2037 4y ago
  Thank you to share a real world story. Failure is usually more interesting to study than success. Real question (no trolling): Is there any business value upgrading to IPv6 or is this a forced upgrade? I think that is number one reason that delays IPv6 upgrades: no business value (or so limited compared to cost of IPv6 impl).
  - krageon 4y ago
    If you're running something that isn't absolute shit it's not this much of an issue to upgrade to ipv6. There's business value in that simply because ipv4 addresses are expensive.
solarkraft 4y ago
> What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6? That it's much easier to set up.
butlerm 4y ago
> 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.

theamk 4y ago

Mayne RFC exists, but it os not used in teal world anywhere. In all servers, I configure IPv4 and IPv6 separately. Network setup is separate. DHCP daemons are separate. Firewall rules are separate. Network monitoring is separate. 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.

icedchai 4y ago
Ok. How do you increase address space without breaking the protocol? IPv4 just doesn't have the space in the header. Something like "v4+" can't happen for this reason. You could argue that pervasive use of NAT beginning in the late 90's was "v4+". It bought us decades of Internet growth, at the expense of true end-to-end connectivity.
throw0101a 4y ago
> 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.
- CountSessine 4y ago
  In theory this could be handled by stuffing the extra 96 bits in an IP extension header. But this solves nothing because then any switch that isn’t IPv4+ aware will route packets incorrectly. Literally every single switch on the internet needs to be updated/replaced before you could start generating IPv4+ traffic otherwise the one outlier will send your IPv4+ packets off to Uzbekistan. OR Maybe you don’t use those 96 bits for routing. But then it becomes nothing but a sort of subnet address and you haven’t fixed the routing table size problem. And actually every endpoint needs to upgrade too because endpoints that don’t recognize the header extension will generate crazy responses and confuse TCP packets from different computers as coming from the same machine. There’s no useful and backward compatible way of extending IPv4.
  - theamk 4y ago
    Or you extend on network level, and even kernel level, but keep programming API compatible. I don't think people like IPv4 packets that much, it is all the APIs which are giving problem. I bet if we kept everything about IPv6 the same, but (1) made IPV6_V6ONLY mandatory and default to zero (2) did not use colon in IP address representation (3) recommended firewalls use same config rules for IPv4/IPv6 address.. then IPv6 would have significantly higher adoption right now.
    - wbl 4y ago
      That mistake was already baked in to the sockaddr_t ABI.
error503 4y ago
There are viable transition mechanisms other than dual stack, that put some kind of translation layer between protocols, rather than expect native IPv4 connectivity on all hosts. This is perfectly viable, and is how many mobile networks handle IPv4 (ie. there is no native IPv4 on the handset at all), and how many cloud providers are handling it these days too. You have to do NAT at the border anyway, why not NAT to/from an IPv6 address? The adoption problem doesn't have that much to do with the technology, it's simply that it provides little value to most individual entities participating in the network, even if the benefit in aggregate is clear, so it's difficult to achieve the critical mass to make it valuable. It's the same thing behind climate change and so many other societal issues.
- unquietwiki 4y ago
  You might appreciate this. Basically, it leverages Babel routing to bridge IPv4 with IPv6. https://datatracker.ietf.org/doc/rfc9229/ https://datatracker.ietf.org/doc/rfc9229/

anthropodie 4y ago

> What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6? I'm pretty sure that those who built new protocol were aware of this and were like "anyway we are gonna have to upgrade network devices. Why don't we build a new protocol while avoiding pitfalls of older one" Any comittee that sat down to solve IPv4 issue would have thought of compatibility first. I am shocked that so many people agree with OP's armchair solution here.

salmo 4y ago
They took much more on with IPv6 than IPv4 replacement. The spec goes much deeper than IPv4 did, replacing ARP, DHCP, etc. It's a product of its time, including a lot of over-engineering by committee. Many of the problems they tried to address didn't pan out to be real issues. You can read the RFCs and compare. IPv4 w/ more bits is a lot more simple. Yes, older network gear wouldn't deal with it well, but that's not a real issue today because that same network gear supports IPv6. Buuut, one of the biggest problems with app-level issues is just that the app doesn't bother dealing with IPv6 addresses and AAAA records. It would be the same issue with an imaginary IPv4*2.
- theteapot 4y ago
  Agree. Second system effect in action -- https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect.
- onphonenow 4y ago
  No kidding - they got rid of dhcp and more but it’s a nightmare getting networks to work with just ipv6 concepts- everything from provisioning phones (dhcp options to push config / NetBoot stuff) and more. Layer in privacy extensions, renumbering on uplink wan flapping (slow too - the failover is pathetic compared to NAT wan failover) - icmp traffic differences - firewalls need to be much more careful with ipv6 and related protocols because things can easy break (it’s fragile) or you create risks. Even min subnet sizes mean crazy 2 node subnet sizes (think isp and cpe management subnet for a customer). Also curious why not 48 or 64 bits or 96 bits? 128 bits is ludicrous

nikanj 4y ago

> What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6? Way less resistance from tech teams. Ultimately companies are made of people, and ipv6 is partly a failure because working with it requires a wholly new skillset

zamadatix 4y ago
Maybe it’s different on the software side but coming from a network VAR it’s the same skill set. You still have subnets and routes and netmasks and DHCP or automatic assignments the difference is the size. If you know IPv4 all you need to learn is “the subnets are all /64 in size, addresses are 128 bits, and you don’t need DHCP if you don’t want”.
- anyfoo 4y ago
  Yeah, but I have to say, even as someone who wants IPv6 to succeed and supersede IPv4, from the perspective of building that network infrastructure software, I think this "IPv4+" would have been massively simpler to add, extremely so, and that may have aided adoption a lot. It's really hard to overstate how much simpler tacking on 128bit IP addresses to an otherwise unmodified protocol would have been in the software stack of network infrastructure. But, as I also said a few times here, the time to make desirable compatibility-breaking changes was exactly then, when every piece of network equipment needed massive alteration or replacement anyway. And I look forward to the day IPv6 hopefully becomes predominant, and the advantages it brings.
  - Dagger2 4y ago
    The majority of the problems seem to come from the fact that v6 addresses are longer than v4 ones. That's why we need socket(AF_INET6)s and AAAA records and a DNS API that supports multiple address families and dual stack and new firewalling and updates to all protocols that embed v4 addresses. You're going to have the exact same problems with any protocol that has addresses longer than v4's.
    - 4y ago

nightfly 4y ago

We've tried to roll out IPv6 at my work, and after several years of it causing more issues than it help we turned it all off again... We're gonna get back to it again this year, but I can see many organizations just not doing that until absolutely forced.

throwaway2037 4y ago
Thank you to share a real world story. Failure is usually more interesting to study than success. Real question (no trolling): Is there any business value upgrading to IPv6 or is this a forced upgrade? I think that is number one reason that delays IPv6 upgrades: no business value (or so limited compared to cost of IPv6 impl).
- krageon 4y ago
  If you're running something that isn't absolute shit it's not this much of an issue to upgrade to ipv6. There's business value in that simply because ipv4 addresses are expensive.

solarkraft 4y ago

> What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6? That it's much easier to set up.

butlerm 4y ago

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