5 ms·

> If IPv6 were IPv4 with more octets, then we would all have been using it for like a decade. I don't really think so: it woulds still be completely backward i

> If IPv6 were IPv4 with more octets, then we would all have been using it for like a decade. I don't really think so: it woulds still be completely backward incompatible and still require replacing a lot of costly network equipment. I think that's the main reason why large ISPs and enterprises have been postponing the upgrade since forever but operating systems, smartphones and other new devices didn't really have a problem with it.

redox99 4y ago
It's been decades. The vast majority of network equipment already has been replaced multiple times since IPv6 became a thing that people "understood" we would switch in the future. The difference is that instead of their ipv6 being broken, partial, or correct but non functioning because it needs additional configuration, it would properly work and support with the much simpler "ipv4+"
- rnhmjoj 4y ago
  But IPv4+ is incompatible, so it requires to maintain two network stacks until reasonably everything has moved over to it. You need to duplicate the configuration for DNS, routing, firewalls etc., exactly as for dual stack IPv6. I don't really see a difference.
  - jedberg 4y ago
    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. In fact, if that entry is just "send everything to my upstream" it might already work! Now I want to add some new resources but I'm out of IPv4 space. So I get some IP4+ space and a new host with a new firewall rule for the new octet and a DNS entry. Of course only other people on IP4+ can reach it, so I use it for my internal tools since I know all of my clients support IP4+. Then I want to use it for a public service, so I add a dual DNS entry of 0.0.0.0.1.2.3.4 and 1.2.3.4. IPv4 clients get 1.2.3.4 and IP4+ clients get 0.0.0.0.1.2.3.4. Now I can start collecting data on how many people support IP4+. When it gets high enough, I can shut off the v4 address and move it to IP4+ only. It would make the transition just soooo much easier, because the changes are much more incremental. I don't have to set up a whole new dual stack. I can just make a few dual entries.
    - deleted 4y ago
      [deleted]
    - throw0101a 4y ago
      > 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] * 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 "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?
      - jedberg 4y ago
        > You'd still have to touch every rule to to tweak the mask. No you wouldn't. 0.0.0.0.1.0.0.0/40 and 1.0.0.0/8 are the same thing. If the rule says 1.0.0.0/8 then the router converts it to 0.0.0.0.1.0.0.0/40. If you happen to have 1/8 as your rule, then an easy fix is to say ip4+ translates shorthand rules at ipv4 if the mask is under /32. > What makes you think that companies would have been willing to make the effort to deploy "IP4+" any more than IPv6? Because when they went to upgrade their router, as they often do every decade, it would just support IP4+ with no config changes on their end. They would pull their config from their old router and it would just work. Then they would discover they had IP4+ support and maybe start using it. The reason it is easier is because it's a small incremental change.
  - yyyk 4y ago
    IPv6 is a slightly different model, different enough that you can't just copy the configuration from IPv4, and that adds a significant implementation burden. If IPv4+ had been created instead, we'd probably all be already using it. That said, it's obviously way too late to go that direction. The only successor to IPv4 is IPv6. Choosing the wrong model just made sure we'd have to go dual-stack for a loong time.
  - andix 4y ago
    IPv4+ would be backwards compatible as long as the first 4 bytes are zero. So you could just replace the existing ipv4 stack. Ipv6 is not backwards compatible at all.

redox99 4y ago

It's been decades. The vast majority of network equipment already has been replaced multiple times since IPv6 became a thing that people "understood" we would switch in the future. The difference is that instead of their ipv6 being broken, partial, or correct but non functioning because it needs additional configuration, it would properly work and support with the much simpler "ipv4+"

rnhmjoj 4y ago
But IPv4+ is incompatible, so it requires to maintain two network stacks until reasonably everything has moved over to it. You need to duplicate the configuration for DNS, routing, firewalls etc., exactly as for dual stack IPv6. I don't really see a difference.
- jedberg 4y ago
  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. In fact, if that entry is just "send everything to my upstream" it might already work! Now I want to add some new resources but I'm out of IPv4 space. So I get some IP4+ space and a new host with a new firewall rule for the new octet and a DNS entry. Of course only other people on IP4+ can reach it, so I use it for my internal tools since I know all of my clients support IP4+. Then I want to use it for a public service, so I add a dual DNS entry of 0.0.0.0.1.2.3.4 and 1.2.3.4. IPv4 clients get 1.2.3.4 and IP4+ clients get 0.0.0.0.1.2.3.4. Now I can start collecting data on how many people support IP4+. When it gets high enough, I can shut off the v4 address and move it to IP4+ only. It would make the transition just soooo much easier, because the changes are much more incremental. I don't have to set up a whole new dual stack. I can just make a few dual entries.
  - deleted 4y ago
    [deleted]
  - throw0101a 4y ago
    > 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] * 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 "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?
    - jedberg 4y ago
      > You'd still have to touch every rule to to tweak the mask. No you wouldn't. 0.0.0.0.1.0.0.0/40 and 1.0.0.0/8 are the same thing. If the rule says 1.0.0.0/8 then the router converts it to 0.0.0.0.1.0.0.0/40. If you happen to have 1/8 as your rule, then an easy fix is to say ip4+ translates shorthand rules at ipv4 if the mask is under /32. > What makes you think that companies would have been willing to make the effort to deploy "IP4+" any more than IPv6? Because when they went to upgrade their router, as they often do every decade, it would just support IP4+ with no config changes on their end. They would pull their config from their old router and it would just work. Then they would discover they had IP4+ support and maybe start using it. The reason it is easier is because it's a small incremental change.
- yyyk 4y ago
  IPv6 is a slightly different model, different enough that you can't just copy the configuration from IPv4, and that adds a significant implementation burden. If IPv4+ had been created instead, we'd probably all be already using it. That said, it's obviously way too late to go that direction. The only successor to IPv4 is IPv6. Choosing the wrong model just made sure we'd have to go dual-stack for a loong time.
- andix 4y ago
  IPv4+ would be backwards compatible as long as the first 4 bytes are zero. So you could just replace the existing ipv4 stack. Ipv6 is not backwards compatible at all.