5 ms·

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 configurati

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.
    - jeroenhd 4y ago
      > No you wouldn't. 0.0.0.0.1.0.0.0/40 and 1.0.0.0/8 are the same thing. I don't see why the CIDR would make a direct difference. Whether it's converting 1.0.0.0/8 to 0.0.0.0.1.0.0.0/40 or 2002:c000:0204::1.0.0.0/96 doesn't seem to matter to me. The only difference I can think of is local networks (10/8, 192.168/16, 172.16/12) but your suggestion would fail in the same way. Several compatibility systems for IPv6 exist. 6to4 is the most common one I've seen. It all works on a technical level until DNS gets involved. > Then they would discover they had IP4+ support and maybe start using it. If your business network is managed by "hey, this feature exists, let's see what happens if we turn it on" then your network admin needs to be more professional.
      - jedberg 4y ago
        > If your business network is managed by "hey, this feature exists, let's see what happens if we turn it on" then your network admin needs to be more professional. I think this is why you don't understand how IP4+ would be easier. 99% of companies make their "IT guy" manage the network. They aren't network professionals. They are mostly desktop professionals who also get forced to manage the network and firewall. Same with most schools -- they can't afford to hire network professionals. Sometimes they get lucky and someone is excited about learning networking, but that's not true in most cases. If they already have a bunch of IPv4 rules that some contractor wrote once, and they have a vague understand of how those rules work and why, they don't want to learn a new scheme or run 6to4 or anything else. They just want it to work by copying the old config and then maybe if they have time they can explore the new features of their new equipment.
- rnhmjoj 4y ago
  If you really wanted you to could keep you old addressing scheme in IPv6 (arbitrary IPv4 addresses can be embedded into IPv6), you can disregard all best IPv6 practices about subnetting and do everything like you did for IPv4, DHCP and all, heck even NAT. The problem is that as soon as you're turning it on you need to maintain two sets of routing and firewall configs, even if they were identical. Also you need proper support from all those lazy vendors (both hardware and software) that did the absolutely minimal amount of work to advertise their products as IPv6 ready when it fact the support ranges from subpar to practical unusable. As soon as you make a one bit incompatible change to the protocol routers aren't able to communicate anymore: it's the same situation again. It doesn't matter how similar the two protocols are, they're incompatible.
- jcranmer 4y ago
  The evidence at this point I think refutes your argument. It's been the case for a while now that basically all the hardware, all the networking stacks, all the major libraries and software supports IPv6. So the reason people haven't switched to IPv6 as quickly is because there's all sorts of hidden IPv4 assumptions that take significant effort and energy to get rid of--and there's relatively little resources being devoted to rooting those out. The kinds of things I'm talking about are places where an IP address is stored in a uint32_t in the middle of your core business app somewhere. Or maybe you've got some log sniffing that only looks for four dotted octets and can't pick an IPv6 address. Those are the sorts of things that if you move to any system that's not IPv4, it's just not going to work period. And you're often not going to discover that you have these issues until you try forcing things to use not-IPv4. A migration I've been working on--admittedly not in networking--has been LLVM's opaque pointer migration, and the vast majority of the time has been spent not figuring out how to get rid of every "pointer_type->getPointerElementType()" call, but in quashing all of the assumptions like "this input operand has to be a bitcast of a global variable" that is violated by the pointer migration. I have no reason to expect that the IPv4-to-IPv6 migration is not similar, in that most of the effort is going to be spent on code that you didn't think would assume it is using IPv4.
- pas 4y ago
  This comes up every few years. I remember there was even a link about it, but I can't remember what to search for :) Naive approaches all assume that there is some incremental step, and IETF was just too idealistic to go with a completely new second system. But as others mentioned, it's a coordination problem. Since IPv4 does not have any signaling mechanism for upgrade, or for somehow encapsulating variable/longer length addresses ... adding that is the minimal change size. Of course if your argument is that the RFCs and the whole v6 world is just a big unfriendly abstract wall of text, not "accidental IT guy" friendly, then of course you are right. But that can be remediated by writing better docs, providing better UX via better tools. (All the usual linux tools are horribly user hostile, and then they have an additional stinking pile of v6 tools, or the occasional -6 parameter.... but that's not exactly the IETF's fault.)
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.

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.
  - jeroenhd 4y ago
    > No you wouldn't. 0.0.0.0.1.0.0.0/40 and 1.0.0.0/8 are the same thing. I don't see why the CIDR would make a direct difference. Whether it's converting 1.0.0.0/8 to 0.0.0.0.1.0.0.0/40 or 2002:c000:0204::1.0.0.0/96 doesn't seem to matter to me. The only difference I can think of is local networks (10/8, 192.168/16, 172.16/12) but your suggestion would fail in the same way. Several compatibility systems for IPv6 exist. 6to4 is the most common one I've seen. It all works on a technical level until DNS gets involved. > Then they would discover they had IP4+ support and maybe start using it. If your business network is managed by "hey, this feature exists, let's see what happens if we turn it on" then your network admin needs to be more professional.
    - jedberg 4y ago
      > If your business network is managed by "hey, this feature exists, let's see what happens if we turn it on" then your network admin needs to be more professional. I think this is why you don't understand how IP4+ would be easier. 99% of companies make their "IT guy" manage the network. They aren't network professionals. They are mostly desktop professionals who also get forced to manage the network and firewall. Same with most schools -- they can't afford to hire network professionals. Sometimes they get lucky and someone is excited about learning networking, but that's not true in most cases. If they already have a bunch of IPv4 rules that some contractor wrote once, and they have a vague understand of how those rules work and why, they don't want to learn a new scheme or run 6to4 or anything else. They just want it to work by copying the old config and then maybe if they have time they can explore the new features of their new equipment.
rnhmjoj 4y ago
If you really wanted you to could keep you old addressing scheme in IPv6 (arbitrary IPv4 addresses can be embedded into IPv6), you can disregard all best IPv6 practices about subnetting and do everything like you did for IPv4, DHCP and all, heck even NAT. The problem is that as soon as you're turning it on you need to maintain two sets of routing and firewall configs, even if they were identical. Also you need proper support from all those lazy vendors (both hardware and software) that did the absolutely minimal amount of work to advertise their products as IPv6 ready when it fact the support ranges from subpar to practical unusable. As soon as you make a one bit incompatible change to the protocol routers aren't able to communicate anymore: it's the same situation again. It doesn't matter how similar the two protocols are, they're incompatible.
jcranmer 4y ago
The evidence at this point I think refutes your argument. It's been the case for a while now that basically all the hardware, all the networking stacks, all the major libraries and software supports IPv6. So the reason people haven't switched to IPv6 as quickly is because there's all sorts of hidden IPv4 assumptions that take significant effort and energy to get rid of--and there's relatively little resources being devoted to rooting those out. The kinds of things I'm talking about are places where an IP address is stored in a uint32_t in the middle of your core business app somewhere. Or maybe you've got some log sniffing that only looks for four dotted octets and can't pick an IPv6 address. Those are the sorts of things that if you move to any system that's not IPv4, it's just not going to work period. And you're often not going to discover that you have these issues until you try forcing things to use not-IPv4. A migration I've been working on--admittedly not in networking--has been LLVM's opaque pointer migration, and the vast majority of the time has been spent not figuring out how to get rid of every "pointer_type->getPointerElementType()" call, but in quashing all of the assumptions like "this input operand has to be a bitcast of a global variable" that is violated by the pointer migration. I have no reason to expect that the IPv4-to-IPv6 migration is not similar, in that most of the effort is going to be spent on code that you didn't think would assume it is using IPv4.
pas 4y ago
This comes up every few years. I remember there was even a link about it, but I can't remember what to search for :) Naive approaches all assume that there is some incremental step, and IETF was just too idealistic to go with a completely new second system. But as others mentioned, it's a coordination problem. Since IPv4 does not have any signaling mechanism for upgrade, or for somehow encapsulating variable/longer length addresses ... adding that is the minimal change size. Of course if your argument is that the RFCs and the whole v6 world is just a big unfriendly abstract wall of text, not "accidental IT guy" friendly, then of course you are right. But that can be remediated by writing better docs, providing better UX via better tools. (All the usual linux tools are horribly user hostile, and then they have an additional stinking pile of v6 tools, or the occasional -6 parameter.... but that's not exactly the IETF's fault.)

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.