4 ms·

- No transition or migration design. It seems like IPv6 was designed as if it was being built instead of building IPv4, and didn't consider how the move would h

- No transition or migration design. It seems like IPv6 was designed as if it was being built instead of building IPv4, and didn't consider how the move would happen beyond something like "everyone run dual-stack IPv4/IPv6, and once that's at 100% we'll turn off IPv4." This results in a stale-mate of sorts: As a server operator, as long as you have IPv4-only clients, you need an IPv4 address. There are no [1] IPv6-only clients, so implementing IPv6 at all is a lot of work with no tangible benefits for the next x years [2]. As a client, you can't go IPv6-only without losing access to the IPv4-only services. There are no[1] IPv6-only servers, so implementing IPv6 at all is a bunch of work with no real benefits for the next x years[2] [1] no meaning a tiny fraction that rounds to 0% [2] x being the number of years before there's a significant number of IPv6-only servers or users.

mikekchar 8y ago
This is literally my problem with upgrading to IPv6 currently. And at the cost of potentially embarrassing myself, I haven't really looked into what the potential problems are going to be (and I'm embarrassed to ask :-) ). My ISP will happily switch me from IPv4 to IPv6 but I've got absolutely no idea what the potential problems are. This has put the task into a near perpetual, "I'll look at that when I'm not so busy". I'm sure I'm not alone in this...
- pas 8y ago
  demand dual stack. nothing else really works. sure, we can simply stay on v4 and encapsulate everything into UDP and use vhost or other names and simply treat v4 address + ports as the solution. economically both are costs of growing the internet. (any solution requires a lot of application changes anyhow, v6 is simpler, but requires ISP buy in, so what app devs can do?)
phicoh 8y ago
To some extent this is unavoidable. Anything that is 'IPv4-like with larger addresses' is very much incompatible with any IPv4 equipment or setup at the edge. You could design something where the IPv4 could be left unchanged in the core of the Internet. But the core of the Internet has supported IPv6 for a long time, it is the edges where the problems are. Just something as simple as writing an address to a log file would fail if addresses suddenly became bigger.
- yholio 8y ago
  > Anything that is 'IPv4-like with larger addresses' is very much incompatible with any IPv4 equipment or setup at the edge. I disagree somewhat. You could imagine a hierarchical routing structure where IPv4 NAT servers double as IPv4ext routers and gateways. All current servers maintain an IPv4 address which, if the server is unaware of IPv4ext, will not be able to decode things like full client IP address for loging, giving an incentive for server operators to upgrade. Meanwhile, unaware client end-points connect to IPv4ext servers just as before, via NAT, but of course don't have end to end connectivity to other IPv4ext clients, giving them a (weak) incentive to upgrade. This would go on for a decade or two just like it did with IPv6, until the moment where virtually all firmware and software is upgraded. At this point carrier grade NATs would stop mangling, the IPv4 only packets are dropped from the core and full non-hierarchical routing can commence on the full IPv4ext address field, finally solving the IPv4 exhaustion problem, in addition to the already solved e2e problem. I agree this backwards compatible deployment scenario is much more convoluted than a clean slate redesign, and it's hard to imagine it could have seen preferable in the 90s, before wide-spread carrier NAT was a thing.
  - phicoh 8y ago
    There problem here is two fold: 1) As far as I know, nobody ever wrote down a protocol description, and preferably made an implementation. The devil is in the details. It is very hard to estimate if such a design would actually work. 2) At the moment, the core of the internet and just about all host operating system support IPv6. The hard part is getting the edge networks to upgrade. My guess is that your proposal would run into similar issues.
    - yholio 8y ago
      There are a number of proposals that build on these ideas, for example EnhancedIP. Typically, they would encode the extended addressing info in an options field. They were to late the party and missed the circa 2000-2005 window where it became clear Ipv6 will be an uphill struggle. Back in the day, only naive proposals like ipv7 existed, "ipv4 with larger address" but that solves little. The fundamental difference compared to dual stack is that there is no technical cost to deploy it outside software updates and very little risk - aside from the dubious security benefits of NAT. Not only the core, but virtually all hardware and software on the Internet today support ipv6, but there is an enormous cost to configure it to work. This flexibility and drop in upgradability of things like EnhancedIP comes with the significant cost of breaking the internet into 2^32 independent routing domains that prevent you for getting the full benefits of the larger address format. This is an acceptable trade off only in retrospect, after the v6 "failure".

mikekchar 8y ago

This is literally my problem with upgrading to IPv6 currently. And at the cost of potentially embarrassing myself, I haven't really looked into what the potential problems are going to be (and I'm embarrassed to ask :-) ). My ISP will happily switch me from IPv4 to IPv6 but I've got absolutely no idea what the potential problems are. This has put the task into a near perpetual, "I'll look at that when I'm not so busy". I'm sure I'm not alone in this...

pas 8y ago
demand dual stack. nothing else really works. sure, we can simply stay on v4 and encapsulate everything into UDP and use vhost or other names and simply treat v4 address + ports as the solution. economically both are costs of growing the internet. (any solution requires a lot of application changes anyhow, v6 is simpler, but requires ISP buy in, so what app devs can do?)

phicoh 8y ago

To some extent this is unavoidable. Anything that is 'IPv4-like with larger addresses' is very much incompatible with any IPv4 equipment or setup at the edge. You could design something where the IPv4 could be left unchanged in the core of the Internet. But the core of the Internet has supported IPv6 for a long time, it is the edges where the problems are. Just something as simple as writing an address to a log file would fail if addresses suddenly became bigger.

yholio 8y ago
> Anything that is 'IPv4-like with larger addresses' is very much incompatible with any IPv4 equipment or setup at the edge. I disagree somewhat. You could imagine a hierarchical routing structure where IPv4 NAT servers double as IPv4ext routers and gateways. All current servers maintain an IPv4 address which, if the server is unaware of IPv4ext, will not be able to decode things like full client IP address for loging, giving an incentive for server operators to upgrade. Meanwhile, unaware client end-points connect to IPv4ext servers just as before, via NAT, but of course don't have end to end connectivity to other IPv4ext clients, giving them a (weak) incentive to upgrade. This would go on for a decade or two just like it did with IPv6, until the moment where virtually all firmware and software is upgraded. At this point carrier grade NATs would stop mangling, the IPv4 only packets are dropped from the core and full non-hierarchical routing can commence on the full IPv4ext address field, finally solving the IPv4 exhaustion problem, in addition to the already solved e2e problem. I agree this backwards compatible deployment scenario is much more convoluted than a clean slate redesign, and it's hard to imagine it could have seen preferable in the 90s, before wide-spread carrier NAT was a thing.
- phicoh 8y ago
  There problem here is two fold: 1) As far as I know, nobody ever wrote down a protocol description, and preferably made an implementation. The devil is in the details. It is very hard to estimate if such a design would actually work. 2) At the moment, the core of the internet and just about all host operating system support IPv6. The hard part is getting the edge networks to upgrade. My guess is that your proposal would run into similar issues.
  - yholio 8y ago
    There are a number of proposals that build on these ideas, for example EnhancedIP. Typically, they would encode the extended addressing info in an options field. They were to late the party and missed the circa 2000-2005 window where it became clear Ipv6 will be an uphill struggle. Back in the day, only naive proposals like ipv7 existed, "ipv4 with larger address" but that solves little. The fundamental difference compared to dual stack is that there is no technical cost to deploy it outside software updates and very little risk - aside from the dubious security benefits of NAT. Not only the core, but virtually all hardware and software on the Internet today support ipv6, but there is an enormous cost to configure it to work. This flexibility and drop in upgradability of things like EnhancedIP comes with the significant cost of breaking the internet into 2^32 independent routing domains that prevent you for getting the full benefits of the larger address format. This is an acceptable trade off only in retrospect, after the v6 "failure".