6 ms·

I'm curious when we'll declare some sort of "idea bankruptcy" on IPv6, develop a new version (IPv7?) that has a "ease of migration from IPv4" as a stated goal,

I'm curious when we'll declare some sort of "idea bankruptcy" on IPv6, develop a new version (IPv7?) that has a "ease of migration from IPv4" as a stated goal, and deploy/implement that. Knowing the historical transition issues collected over the past 20 years, we could, as an industry and society, design a next generation and provide a reasonable rollout target of, say, 2030, and move towards that. Since 1998/99, there's been an explosion of networking, and large cultural shifts (billions of mobile devices, IoT, etc) which were not around when all this was specced out. No technology adopted IPv6 as a default during that time, and I dare say most things (services, devices, etc) aren't even tested against IPv6. After 20+ years of this, I see IPv6 as a failure, even if there is 30-50% adoption (or perhaps because of those figures).

jl6 5y ago
With ~30% adoption of IPv6 today, your great new alternative is going to need an “ease of migration from IPv6” feature too.
- zinekeller 5y ago
  Nope, you don't need to, because of a simple fact that there is a very minuscule amount of IPv6-reliant systems in the wild. Most of them also operate in IPv4 (because IPv4 is more prevalent). Name me an existing system where: a) requires IPv6; but b) not because of its long address. Good luck finding such a system.
  - kazen44 5y ago
    mobile telecom gateways? most modern telecom uses ipv6 for LTE communication, with nat64 to communicate with ipv4.
- formerly_proven 5y ago
  Not really, since IPv6 adoption is low, a service that doesn't also exist on IPv4 practically does not exist, so if you have a good migration path (unlike v6) from v4, you're taking approximately all services with you.
  - jl6 5y ago
    Mobile networks, for example, have huge deployments of IPv6. Whether or not they are used to access IPv6-only services doesn’t change the fact that IPv6 is an integral part of their network design and therefore an alternative to IPv6 would need a migration pathway from it.
  - ArchOversight 5y ago
    Comcast's entire core network is pure IPv6. Every cable box, cable modem, everything is connected and managed using IPv6 addressing. None of it is IPv4. T-Mobile's core network is entirely IPv6, IPv4 lives on the edge only. Facebook's entire internal network is IPv6, they have IPv4 edges that translate to IPv6 internally so that it is routed as if it were IPv6 and all services see IPv6 only. Sorry, but your "adoption is low" is very VERY wrong and IPv6 has already solved a lot of problems, for example the "we are out RFC1918 space, and adding more NAT is not the solution". That last part is literally why Comcast moved to an IPv6 core.
darren_ 5y ago
> and I dare say most things (services, devices, etc) aren't even tested against IPv6. literally every single iOS app is required to fully support ipv6 and will not pass apple review if it doesn't.
- whoknowswhat11 5y ago
  I think folks are trying to break apple's stranglehold / monopoly so that other app stores can be offered on iOS. This should help address these types of issues so more devs can get onto iOS more easily without having to meet Apple's level of requirements.
  - throw0101a 5y ago
    > This should help address these types of issues so more devs can get onto iOS more easily without having to meet Apple's level of requirements. Well if an app developer does not ensure that their code works on a device that only has an IPv6 address they will be in for a big surprise: lots of mobile telcos only give out IPv6 addresses. Connecting to the IPv4 world is done via CG-NAT with the first few hops being IPv6-only. Here's a guy from T-Mobile presenting on it: * https://www.youtube.com/watch?v=nNMNglk_CvE https://www.youtube.com/watch?v=nNMNglk_CvE
  - inetknght 5y ago
    Require IPv6 support (or fail upload to store) is a good thing.
- huibf 5y ago
  If your server is ipv4 only that's okay because it's still reachable via DNS64/NAT64. I know because I've uploaded apps like that recently.
throw0101a 5y ago
> I'm curious when we'll declare some sort of "idea bankruptcy" on IPv6, develop a new version (IPv7?) that has a "ease of migration from IPv4" as a stated goal, and deploy/implement that. We need more addresses. That's the primary problem of IPv4 right now. 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? AFAICT, code updates will needed to occur on every device that needs to talk to the new address scheme. So what's the difference between updating every device to handle IPv6 versus updating every device to handle this hypothetical IPv7?
- zinekeller 5y ago
  > 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. What's worse is that it was actually already proposed in 1992 (https://datatracker.ietf.org/doc/html/rfc1347 https://datatracker.ietf.org/doc/html/rfc1347). Did it work? Actually, yes! Why IPv6 then? Because it's shiny!
  - throw0101a 5y ago
    From the RFC (emphasis added): > The long term goal of the TUBA proposal involves transition to a worldwide Internet which operates much as the current Internet, but with CLNP replacing IP and with NSAP addresses replacing IP addresses. […] In §3 Migration: > Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged. Updated Internet hosts talk to other updated Internet hosts using (TCP or UDP over) CLNP. This implies that updated Internet hosts must be able to send either old-style packets (using IP), or new style packet (using CLNP). Which to send is determined via the normal name-to-address lookup. So you're replacing IPv4 with something that is not-IPv4 on every router and every host. During the transition period everyone will have IPv4 and not-IPv4 addresses. How is not-IPv4 being CLNP/NSAP any different that not-IPv4 being IPv6? What am I missing? In §6 on DNS: > TUBA requires that a new DNS resource record entry type ("long-address") be defined, to store longer Internet (i.e., NSAP) addresses. Which is basically describing AAAA records.
welterde 5y ago
This gets repeated over and over, but the issue is that it's an impossible task. A ipv4-only host cannot ever directly communicate with a IPv6/IPv7/.. host. The issue is simply that you cannot fit more than 32bit of information into 32bit. There are plenty of migration technologies that exist to integrate IPv4 and IPv6 (NAT64, tunneling ipv6 over ipv4, etc. etc.). And anything like IPv7/IPv6-light will end up with the same issues and solutions you are facing today with IPv6.
- zinekeller 5y ago
  > This gets repeated over and over, but the issue is that it's an impossible task. The counterpoint gets repeated and repeated all over, because it was already done in BGP. Unfortunately, most are purists who will never look at using TUBA (https://datatracker.ietf.org/doc/html/rfc1347 https://datatracker.ietf.org/doc/html/rfc1347) or something because they want "clean code" or something. Real world is messy, and code should adopt over it.
  - welterde 5y ago
    In case of BGP it was possible since it's not a end to end communication protocol. How exactly does TUBA solve the problem where ipv4-only host wants to communicate with a non-ipv4 host? This proposal solves none of the issues we are facing of IPv6. The RFC suggests some of the transitional technologies that are in issue with IPv6 today/the past: tunneling IPv6 over IPv4 (6in4, teredo, etc.), dualstack, NAT64 and other mapping, AAAA recrods in dns. But it doesn't get around the fact that you cannot fit more than 32bit of information into a 32bit address.
    - kazen44 5y ago
      also, in the case of BGP it is also possible because it is a protocol with a strict process around its use in the default free zone with a community of peers who all benefit from being interconnected and being able to exchange routes. it is far easier to convince a couple of thousand organizations to modify their highly specialized infrastructure compared to end users and manufacturers who just want to use or create widgets which will do what is required.
phicoh 5y ago
Realistically, such a new protocol will only make it worse. No doubt that new problem will lack some features that IPv6 has and that are in active use. So some group will refuse to move to the new protocol. Some group will not move at all. IPv4 is fine for them. And the rest of the world will get an endless amount of translation between IPv4 and the new protocol that is a nightmare to debug. There is also the big question whether there actually exists a better transition path. I have not seen any ideas that are likely to be accepted on a large scale by the networking community.
remram 5y ago
This is what Python 3 did. Python 3.0 removed a lot of Python 2 features which were then progressively re-added in 3.1, 3.2, and 3.3. No matter how good your design, you need people using something else to actually want to make the move.

jl6 5y ago

With ~30% adoption of IPv6 today, your great new alternative is going to need an “ease of migration from IPv6” feature too.

zinekeller 5y ago
Nope, you don't need to, because of a simple fact that there is a very minuscule amount of IPv6-reliant systems in the wild. Most of them also operate in IPv4 (because IPv4 is more prevalent). Name me an existing system where: a) requires IPv6; but b) not because of its long address. Good luck finding such a system.
- kazen44 5y ago
  mobile telecom gateways? most modern telecom uses ipv6 for LTE communication, with nat64 to communicate with ipv4.
formerly_proven 5y ago
Not really, since IPv6 adoption is low, a service that doesn't also exist on IPv4 practically does not exist, so if you have a good migration path (unlike v6) from v4, you're taking approximately all services with you.
- jl6 5y ago
  Mobile networks, for example, have huge deployments of IPv6. Whether or not they are used to access IPv6-only services doesn’t change the fact that IPv6 is an integral part of their network design and therefore an alternative to IPv6 would need a migration pathway from it.
- ArchOversight 5y ago
  Comcast's entire core network is pure IPv6. Every cable box, cable modem, everything is connected and managed using IPv6 addressing. None of it is IPv4. T-Mobile's core network is entirely IPv6, IPv4 lives on the edge only. Facebook's entire internal network is IPv6, they have IPv4 edges that translate to IPv6 internally so that it is routed as if it were IPv6 and all services see IPv6 only. Sorry, but your "adoption is low" is very VERY wrong and IPv6 has already solved a lot of problems, for example the "we are out RFC1918 space, and adding more NAT is not the solution". That last part is literally why Comcast moved to an IPv6 core.

darren_ 5y ago

> and I dare say most things (services, devices, etc) aren't even tested against IPv6. literally every single iOS app is required to fully support ipv6 and will not pass apple review if it doesn't.

whoknowswhat11 5y ago
I think folks are trying to break apple's stranglehold / monopoly so that other app stores can be offered on iOS. This should help address these types of issues so more devs can get onto iOS more easily without having to meet Apple's level of requirements.
- throw0101a 5y ago
  > This should help address these types of issues so more devs can get onto iOS more easily without having to meet Apple's level of requirements. Well if an app developer does not ensure that their code works on a device that only has an IPv6 address they will be in for a big surprise: lots of mobile telcos only give out IPv6 addresses. Connecting to the IPv4 world is done via CG-NAT with the first few hops being IPv6-only. Here's a guy from T-Mobile presenting on it: * https://www.youtube.com/watch?v=nNMNglk_CvE https://www.youtube.com/watch?v=nNMNglk_CvE
- inetknght 5y ago
  Require IPv6 support (or fail upload to store) is a good thing.
huibf 5y ago
If your server is ipv4 only that's okay because it's still reachable via DNS64/NAT64. I know because I've uploaded apps like that recently.

throw0101a 5y ago

> I'm curious when we'll declare some sort of "idea bankruptcy" on IPv6, develop a new version (IPv7?) that has a "ease of migration from IPv4" as a stated goal, and deploy/implement that. We need more addresses. That's the primary problem of IPv4 right now. 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? AFAICT, code updates will needed to occur on every device that needs to talk to the new address scheme. So what's the difference between updating every device to handle IPv6 versus updating every device to handle this hypothetical IPv7?

zinekeller 5y ago
> 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. What's worse is that it was actually already proposed in 1992 (https://datatracker.ietf.org/doc/html/rfc1347 https://datatracker.ietf.org/doc/html/rfc1347). Did it work? Actually, yes! Why IPv6 then? Because it's shiny!
- throw0101a 5y ago
  From the RFC (emphasis added): > The long term goal of the TUBA proposal involves transition to a worldwide Internet which operates much as the current Internet, but with CLNP replacing IP and with NSAP addresses replacing IP addresses. […] In §3 Migration: > Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged. Updated Internet hosts talk to other updated Internet hosts using (TCP or UDP over) CLNP. This implies that updated Internet hosts must be able to send either old-style packets (using IP), or new style packet (using CLNP). Which to send is determined via the normal name-to-address lookup. So you're replacing IPv4 with something that is not-IPv4 on every router and every host. During the transition period everyone will have IPv4 and not-IPv4 addresses. How is not-IPv4 being CLNP/NSAP any different that not-IPv4 being IPv6? What am I missing? In §6 on DNS: > TUBA requires that a new DNS resource record entry type ("long-address") be defined, to store longer Internet (i.e., NSAP) addresses. Which is basically describing AAAA records.

welterde 5y ago

This gets repeated over and over, but the issue is that it's an impossible task. A ipv4-only host cannot ever directly communicate with a IPv6/IPv7/.. host. The issue is simply that you cannot fit more than 32bit of information into 32bit. There are plenty of migration technologies that exist to integrate IPv4 and IPv6 (NAT64, tunneling ipv6 over ipv4, etc. etc.). And anything like IPv7/IPv6-light will end up with the same issues and solutions you are facing today with IPv6.

zinekeller 5y ago
> This gets repeated over and over, but the issue is that it's an impossible task. The counterpoint gets repeated and repeated all over, because it was already done in BGP. Unfortunately, most are purists who will never look at using TUBA (https://datatracker.ietf.org/doc/html/rfc1347 https://datatracker.ietf.org/doc/html/rfc1347) or something because they want "clean code" or something. Real world is messy, and code should adopt over it.
- welterde 5y ago
  In case of BGP it was possible since it's not a end to end communication protocol. How exactly does TUBA solve the problem where ipv4-only host wants to communicate with a non-ipv4 host? This proposal solves none of the issues we are facing of IPv6. The RFC suggests some of the transitional technologies that are in issue with IPv6 today/the past: tunneling IPv6 over IPv4 (6in4, teredo, etc.), dualstack, NAT64 and other mapping, AAAA recrods in dns. But it doesn't get around the fact that you cannot fit more than 32bit of information into a 32bit address.
  - kazen44 5y ago
    also, in the case of BGP it is also possible because it is a protocol with a strict process around its use in the default free zone with a community of peers who all benefit from being interconnected and being able to exchange routes. it is far easier to convince a couple of thousand organizations to modify their highly specialized infrastructure compared to end users and manufacturers who just want to use or create widgets which will do what is required.

phicoh 5y ago

Realistically, such a new protocol will only make it worse. No doubt that new problem will lack some features that IPv6 has and that are in active use. So some group will refuse to move to the new protocol. Some group will not move at all. IPv4 is fine for them. And the rest of the world will get an endless amount of translation between IPv4 and the new protocol that is a nightmare to debug. There is also the big question whether there actually exists a better transition path. I have not seen any ideas that are likely to be accepted on a large scale by the networking community.

remram 5y ago

This is what Python 3 did. Python 3.0 removed a lot of Python 2 features which were then progressively re-added in 3.1, 3.2, and 3.3. No matter how good your design, you need people using something else to actually want to make the move.