6 ms·

These arguments always boil down to these two: "Please just try to fit more than 4 billion numbers into 4 bytes" -- this is mathematically impossible. "Just e

These arguments always boil down to these two: "Please just try to fit more than 4 billion numbers into 4 bytes" -- this is mathematically impossible. "Just extend the address size" -- this is an entirely new protocol by the definition of IPv4, which uses fixed-size addresses. The reason for the slow IPv6 adoption is that there was no financial or business pressure. While IPv4 is ubiquitous, nobody individually feels a need to migrate to IPv6. E.g.: How many customers would you gain by supporting IPv6? Generally zero. That doesn't sell well internally when the network team is asking for a budget. The IPv6 transition will be like a bankruptcy: very slowly, slowly, then all of a sudden. The sudden bit will happen when IPv4 address will cost $1K to $10K annually. At that point, customers will be reaching those IPv4 endpoints via three layers of proxies or NAT gateways, and IPv6 will be noticeably faster, more reliable, and free.

dannyw 3y ago
Fitting more than 4B numbers into 4 bytes is mathematically impossible, but building a backwards compatible and easier to integrate standard may not be. Take USB for example. The capabilities of USB 3.1, 3.0, 2.0 is impossible to achieve for USB 1.0. So is high-speed charging. However, the end-user experience is generally pleasant, nitpicks around some of USB-IF's specific choices aside.
- jiggawatts 3y ago
  The USB protocols over the wire are generally not compatible between versions, especially at the lowest levels (signalling). That's the definition of how more bandwidth can be squeezed into the same wires. The signalling layer changed between versions. The "end-user experience" IPv6 equivalent of the USB version transition is that a person browsing to "www.google.com" has no clue whatsoever that it actually went via IPv6 instead of IPv4. Just like with USB 1 to 4, IPv6 goes down the same cables and works the same at the application layer. Some changes occurred, but changes are mandatory for things to change. You're asking for USB 4 to be magically "the same" as USB 1.0 while sending tens of gigabits over the wires -- not for the end users -- but for the lazy electrical engineers that can't be bothered to update their designs!
- growse 3y ago
  How does a host that thinks there are only 4 billion addresses send a packet to a host with an address that falls outside of the 32 bit v4 space? This is a fundamental problem. Backwards compatibility (without introducing translation schemes and middleboxes) is literally impossible.
  - rini17 3y ago
    Extending address is fully possible, and if we drop requirement that the extended part be individually routable, even simple. But no, someone said we must redo whole stack and we need every piece of sand to have public routable address..so now we are stuck between rock (old fossilized IPv4) and hard place (completely incompatible IPv6).
    - growse 3y ago
      You're inventing a new addressing scheme, and proposing that we put a bunch of middleboxen in to mediate connecting the old world to hosts on this new addressing scheme. You're re-inventing IPv6.
      - rini17 3y ago
        No, I describe existing practice with NAT where you in fact have IP addresses extended by TCP/UDP port numbers. You could instead move this "port" directly into IP header in backward-compatible way and fall back to stateful NAT only if the counterparty does not support it.
        growse 3y ago
        A device that doesn't understand your newly invented addressing scheme would need to rely on some other intermediate device in order to get traffic to an endpoint that does support your new scheme. You're using different words, but you've got a separate addressing scheme, and dependence on proxies to enable everyone to talk to each other. This is exactly where we are with IPv6. > You could instead move this "port" directly into IP header in backward-compatible way If you're changing the meaning of the headers, it is by definition not backwards compatible.
- candiodari 3y ago
  IPv6 is backwards compatible. In multiple ways: Option 1: "6to4" https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4 Option 2: "nat64" https://en.wikipedia.org/wiki/NAT64 https://en.wikipedia.org/wiki/NAT64 + DNS64 Option 2b: "nat46" (which makes a few ipv6 hosts available over ipv4 if yo ulike) Option 3: "Teredo" (also known as "6in4" "tunnel broker" "6over4" "tunneling" ...) https://en.wikipedia.org/wiki/Teredo_tunneling https://en.wikipedia.org/wiki/Teredo_tunneling Option 4: 6rd https://en.wikipedia.org/wiki/IPv6_rapid_deployment https://en.wikipedia.org/wiki/IPv6_rapid_deployment Option 5: ffff/96 (yes I get it, only works if host has both ipv4 and ipv6, on the plus side: no need for the network to support it. Mostly for applications) Option 6: DS-lite https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_(DS-Lite) https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual... And then there's the weird ones: https://en.wikipedia.org/wiki/IPv6_transition_mechanism https://en.wikipedia.org/wiki/IPv6_transition_mechanism The issue is most of these require ISPs to deploy new hardware, or deploy new network services. The problem is that network hardware is single-purpose, because only single purpose hardware can sustain the speeds we demand of internet networks. This means a lot of hardware needs to be replaced in order to make the global IPv6 transition and, short of redesigning IPv4, which is 43 years old now, there's no other way to make the transition. All these solutions require either work by your ISP, or work by you yourself on all your hosts.
  - ta1243 3y ago
    The fact there are so many options shows the fundamental design problem.
    - deleted 3y ago
      [deleted]
    - supertrope 3y ago
      It's iterating over time to fix real problems. No protocol is perfect in the initial RFC.
      - p1mrx 3y ago
- bauruine 3y ago
  What's your problem with the IPv6 end-user experience? Hundreds of millions of end-users are using it without even knowing what an IP is.
- danhor 3y ago
  USB 3 the protocol isn't backwards compatible with USB 2, USB 3 ports just include both USB 2 and USB 3 pins (what one might call dual stack). You can easily connect two differnt devices one to the USB 2 pins and one to the USB 3 pins. If you only want to connect USB 3 devices, there is no need for USB 2 Pins, as done on the PS4. There is also no specified way to convert USB 3 to USB 2, but some have tried, with mixed results.
bradley13 3y ago
"Just extend the address size" was certainly one of the options. Sure, it's still a change, but the point is: After this change, both protocols could have worked side-by-side. Devices that only supported IPv4, no problem, they send 32-bits. Devices that supported IPv6-as-it-could-have been would simply have zero-padded those 32-bits to match the new protocol. Talking to old devices, the zero-padding gets dropped. That would have saved a lot of pain.
- lmm 3y ago
  No it wouldn't. Think about how that would work for a minute. It would've created nondeterministic routing loops that would be a nightmare to debug.
- josephg 3y ago
  Then any network address beyond ipv4’s 32 bit range would have been completely inaccessible to any legacy devices. That would have essentially been the same situation that we have now - where ipv6 only services are inaccessible to anyone on an ipv4 network. So service operators need to keep their ipv4 addresses and networks don’t update. How would that be an improvement over the existing situation?
cm2187 3y ago
At this stage it shouldn't require much money to integrate ipv6. Your network equipment needs to be really old to not support v6 natively. Though granted, there is support and support. I use hyperoptic in the UK as an ISP. I replaced the native router and I still can't figure out a way to get an IPv6 address.
ta1243 3y ago
The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you). One major problem is dual stack. It doubles the workload for very limited benefit. You have all the downsides of making ipv4 work in the first place. You've then got all sorts of messes like NAT66 (ipv6 was supposed to get rid of NAT), a lack of clarity on which patch to use (NPTv6 and NAT66 are two different options for the same problem, a problem which was built into ipv6 in the first place), messy hacks like DNS64 Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster. You'd be able to communicate with ipv6 by using stateful NAT at the edge of your ipv6 network (as you do now at the edge of your RFC1918 network), you could expose services on your ipv6 only devices with natting (as you do now). You'd still have A and AAAA records, your client having an ipv6 stack could prefer AAAA instead of A, but if it needed to use an A record (or someone just tried to connect to 12.34.56.78) the stack would have gone "ok I'm ipv6 only, I'll connect to :ffff:12.34.56.78" and rely on the network to make it happen. Throw in things like NPTv6 and 464XLAT from the start (rather than 16+ years in) -- the addons which were created to address the fundamental architectural flaws in ipv6 -- and you'd have had a far smoother transition.
- tsimionescu 3y ago
  Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work. There was no way to make the transition to IPv6 without dual stack. The problem was much more that the precise dual-stack approach was not well thought out, when it should have been a fundamental part of the IPv6 RFC itself. Any ISP who wishes to move to IPv6 still to this day has to consider how it will handle clients that don't speak IPv6, servers that don't speak IPv6, routers they own that don't speak IPv6, and peers who don't speak IPv6. There is no way to make all of this work without having devices that translate between the two (losing most of the benefits of IPv6 when going through this translation, of course). When you've spent 10 million dollars or more on a router that doesn't speak IPv6, you don't change it one year later just because a new protocol has come up. That thing is there to stay for 5-10 years, and you just work around it as best you can.
cornholio 3y ago
There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upgrade just the endpoints in the first phase. So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN. This doesn't solve the "backwards compatibility" problem itself, because you still have two logical different IP networks running on top of each other, requiring separate name resolution, etc. But what it does solve is the "incentive problem": endpoints are incentivized to upgrade because it gives them an immediate benefit, end-to-end connectivity to other upgraded users with non-routable addresses sitting behind a dumb, non-upgraded IPv4 routers. For example, VoIP or P2P software would immediately benefit and it would drive adoption for an immediate use-case. In the later stage, when the entire infrastructure can understand the extended packet format, you would start to publish extended routes that don't fall into the hierarchical range, similar to IPv6 today. IPv6 lacks any such incentive, because me upgrading and enabling it has zero benefits until all hops separating me from the internet also enable it and correctly configure it. On the contrary, by requiring a completely new, complex configuration with no "default, just works" mode, IPv6 introduces a disincentive, because by enabling it not only do I not gain anything, but I risk breaking my internet due to misconfigured upstream. So the conservative setting for IpV6 has, for the last 3 decades, remained "off". This only recently began to change.
- gabereiser 3y ago
  >”So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure.” So… NAT.
  - cornholio 3y ago
    No. There would be no NAT box holding IP-port mappings in its internal memory, with the related timeouts, flakiness, port clobbering etc. and no packet re-writing. All routing decisions would be static, based on information in the IP header: the legacy outside routers would just examine the legacy part of the IP address and packet, while the internal IPv4.1 would use the extended bits. So just like any packet routing and without translation. Critically, this solves the cold start and connectability problem of NAT: if you get a packet addressed to your outside IP, to a port that has no memorized mapping, to what internal IP do you send it to? Lacking a static or UPnP port assignment, it can only be dropped. The extended packet format would provide this information for every packet, the upgraded outside host would tell you what upgraded internal host it wants to talk to.
paulsutter 3y ago
In practice IPv6 is for mass market ISPs and IPv4 is for servers. Wasn’t the intention, but that’s how it is to a first order approximation There are billions of phones so sure, they should be on ipv6. ipv6 is a kind of super NAT that few people bother to learn Sorry about that ipv6 committee
- sambazi 3y ago
  > ipv6 is a kind of super NAT that few people bother to learn true, for now. sometime it will reverse and i am exited about what will happen in/with the "legacy internet"
commandersaki 3y ago
Everyone is always quick to complain that we're going through N number of NAT gateways or N number of proxies, but this is virtually never a problem for most of the Internet. Even despite this rats maze of proxies and NAT gateways we're still supporting virtually all the applications that consumers use and love such as VoIP, WebRTC, HTTP(S), DNS, Gaming, Streaming Video, Mobile Apps, etc. NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience, but there has to be some sacrifice to keep the Internet running for the billions of users. NAT and by extension CGNAT are the unsung heroes of the Internet.
- deleted 3y ago
  [deleted]
- superluserdo 3y ago
  >Even despite this rats maze of proxies and NAT gateways we're still supporting virtually all the applications that consumers use That's a tautology: "Despite the limitations of IPv4, we're still supporting all the applications that can work within the limitations of IPv4". Lots of potential P2P applications (that might solve a lot of problems with have with the current centralised model of the internet) either don't make it past the drawing board because of NAT, or have to be encumbered with complex, expensive-to-develop, best-effort NAT-punching behaviour that burdens everyone involved (and can stop an application from being truly P2P by having to run things like STUN servers). >NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience I think there would be many more that wanted this if it were trivially easy to do >but there has to be some sacrifice to keep the Internet running for the billions of users. What's the sacrifice in using IPv6?
  - commandersaki 3y ago
    > I think there would be many more that wanted this if it were trivially easy to do I've seen figures from proponents of Future Internet Architectures such as Named Data Networking claim that consumption is about 80% of Internet traffic. The truth is not everyone needs a Internet addressable host, mobile phones for example don't. And well, we're living in this situation today with CGNAT and you don't hear complaints from customers about not having Internet addressable IPs. > What's the sacrifice in using IPv6? Support. Enabling IPv6 on broadband consumer networks, small medium businesses, etc. means that you have to support the various devices v6 stacks and applications and ensure they continue to work just as well as they did with IPv4. IPv6 can still cause damage and the ability to support and fix these issues throw out virtually all incumbent knowledge. If it were really just a "flip of a switch", everyone would've done it by now.
rewmie 3y ago
> The IPv6 transition will be like a bankruptcy: very slowly, slowly, then all of a sudden. I don't think that's true. Some services on the internet are already made available through IPv6. Doesn't that mean their migration to IPv6 is done? There are however some ISPs that seem to be dragging their feet. I recall I tried to deprecate IPv4 access to a personal project of mine and it was no longer reachable when I tried to access it from my home. Lookups from other points of the world could resolve the IP but not my little home network. I felt forced to continue paying the 2€ I paid for a IPv4 address just because of that. Edit: to make it abundantly clear, I'm looking at you, Vodafone. You suck.
- simiones 3y ago
  No, the migration is only done when you're exclusively running IPv6. Very very little of the internet is accessible only over IPv6.
  - rewmie 3y ago
    > No, the migration is only done when you're exclusively running IPv6. I don't think that's an informed, thought-out take. The internet works just fine for all intents and purposes if you have some services reachable through IPv4. There is no obligation to shut down IPv4 in order to work with IPv6. If you're able to go through your daily work seamlessly hitting services with IPv6, that's a successful migration. It matters nothing if an unrelated service hasn't went through their migration yet.
    - simiones 3y ago
      What I meant was, almost all server operators on the internet have to support either IPv4-only or dual stack. It is still economic suicide to run an IPv6-only server, at least in most areas of the world. As long as you have to run IPv4 software as well and lease an IPv4 address, I would say you are not fully migrated to IPv6.
cameronh90 3y ago
We could presumably have done something like: use the IPv4 packet format, treat the 32 bit src/dst address in the header as the first 32 bits of the address and put the remaining 96 bits (+ checksums/etc.) as the first few bytes of the payload. Then create TCPv6, UDPv6, IGMPv6 etc. protocol identifiers for the protocol field to distinguish traffic that's encoding an IPv6 address in the first few bytes of the payload. Then, if you own an IPv4 address, you effectively own an IPv6 subset. Then we reserve a whole bunch of IPv4 addresses for IPv6-only allocations. I obviously haven't thought it through in detail, but wouldn't something like that effectively transparently work via IPv4 core infrastructure provided the networks at either end support IPv6 if they're using it? We'd still need NAT for IPv6-only endpoints that need to talk to IPv4-only endpoints. It also wouldn't be anywhere near as clean as IPv6 and would lack a few of the nice features, but... an awesome protocol I can't actually use isn't much use to me.
- welterde 3y ago
  You more or less just reinvented a more complicated variant of 6to4/6rd, which is one of the IPv6 transition technologies.
- ilyt 3y ago
  > We could presumably have done something like: use the IPv4 packet format, treat the 32 bit src/dst address in the header as the first 32 bits of the address and put the remaining 96 bits (+ checksums/etc.) as the first few bytes of the payload. Then create TCPv6, UDPv6, IGMPv6 etc. protocol identifiers for the protocol field to distinguish traffic that's encoding an IPv6 address in the first few bytes of the payload. So no router can route it sensibly and no existing client works ? How would that help ?
theamk 3y ago
the reason for slow IP adoption is that they decided to break all backwards compatibility. You need new protocol, sure. But do you _have_ to switch from "1 almost fixed address per interface" to "tons of addresses per interface and dynamically changing"? Did you have to present it as a separate protocol to apps? Did you have to use : in representation, breaking most ad-hoc text processing code? etc.. if they goal was "herr is a new verion of IPv4 with same semantics" then we'd just need to wait for new kernels and libraries to come out, and it would be all done years ago.
AtlasBarfed 3y ago
Really, IPV6 has failed because of human reasons. I know because almost everyone demonstrably hates it, as evidenced by their behavior. The big issue is that the router vendors hated it, the OS vendors hated it, the programming language people hated it, and the software writers hated it. How do I know? NOBODY WANTS TO ADOPT IT except by force, even now. Worryingly, pro-IPV6 people are consistently arrogant and dismissive. Essentially their argument always boiled down to "ha, you'll be forced to use it eventually and then I'll be RIGHT!!!" which is why IPV6 people hate NATs with a vehement irrational passion, because it floated IPV4 for, what, two decades at least? I'm guessing it is because IPV6 was a tossed-over-the-wall protocol that didn't get reference implementations from the biggest router vendors first. Here's a very very very very very very troubling link: https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/network_systems/docs/cisco_it_case_study_ipv6.pdf https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/networ... That is Cisco bragging about it's IPV6 website on a pdf from 2011! 2011! Fifteen years after the birth of the protocol. If Cisco did not have an IPv6 site up until FIFTEEN YEARS after protocol definition ... oh god. Comcast routers weren't IPV6 functional back in 2015, at least they weren't on my cable modem. If an ISP that makes bank on renting and turning over its consumer routing hardware can't roadmap ipv6 adoption within 22 years... ugh. And my biggest complaint about ipv6 is that they didn't increase the number of ports. Really. We have to keep shoehorning apps into 64k ports rather than a sensible 4 billion, but maybe there's some OS mapping concern with that, doesn't matter, the ship sailed. https://en.wikipedia.org/wiki/Internet_Protocol_version_4 https://en.wikipedia.org/wiki/Internet_Protocol_version_4 Somewhere in IPV4 is an options header (up to 40 bytes). Why that didn't provide the necessary space for some degree of backwards compatibility somehow is beyond me. What should have happened is that the big router vendors got together and agreed on a standard protocol. Then the major OS vendors and language standards bodies got together and made reference implementations for basic networking. Once that was working / adopted by next gen hardware and software releases, then things might have gotten rolling. I mean, how much work was that relative to the mind boggling amount of work done to implement NAT and firewall traversal/busting code in, say, Skype? Ever seen those whitepapers? Wow are they doozies. Holy crap are people willing to write code. This is all screaming at the darkness.
- viraptor 3y ago
GoblinSlayer 3y ago
Technically address space can be expanded with a reverse proxy like SOCKS5: connect to NAT over ip4 and pass target address or even domain name.
plumeria 3y ago
> The IPv6 transition will be like a bankruptcy: very slowly, slowly, then all of a sudden. That's a fresh alternative to the boiling frog metaphor.
_8j50 3y ago
"this is an entirely new protocol by the definition " NO!!! this is what the parent comment meant about ipv6 design. Add an octet and that's it. Same protocol with same rules just a bigger address. It may be a different version of IP but the protocol and supporting protocols like ARP and DHCP just need to support the new IP. The reason IPv6 failed is the same reason why when new devs join a team, they find how everything is wrong and try to fix it all and leave a bigger mess than what they started with. You solve problems one step at a time. Overhauls are only justified when your objective is specifically to improve the whole system. "The reason for the slow IPv6 adoption is that there was no financial or business pressure." That is only part of the reason. The other part is it is a pain to use, there is no way to use it without also supporting v4 and on top of that you have to learn and adapt other new protocols, addressing schemes, gotcha's and much more. Just add a freaking octet!
fuy 3y ago
it's probably been mentioned before, but there are customers that require IPv6 (like some US gov agencies and others), so for a lot of B2B/enterprise software companies it actually makes sense to support ipv6. And it's technically interesting, so why not! (I've been there, and it was fun)

dannyw 3y ago

Fitting more than 4B numbers into 4 bytes is mathematically impossible, but building a backwards compatible and easier to integrate standard may not be. Take USB for example. The capabilities of USB 3.1, 3.0, 2.0 is impossible to achieve for USB 1.0. So is high-speed charging. However, the end-user experience is generally pleasant, nitpicks around some of USB-IF's specific choices aside.

jiggawatts 3y ago
The USB protocols over the wire are generally not compatible between versions, especially at the lowest levels (signalling). That's the definition of how more bandwidth can be squeezed into the same wires. The signalling layer changed between versions. The "end-user experience" IPv6 equivalent of the USB version transition is that a person browsing to "www.google.com" has no clue whatsoever that it actually went via IPv6 instead of IPv4. Just like with USB 1 to 4, IPv6 goes down the same cables and works the same at the application layer. Some changes occurred, but changes are mandatory for things to change. You're asking for USB 4 to be magically "the same" as USB 1.0 while sending tens of gigabits over the wires -- not for the end users -- but for the lazy electrical engineers that can't be bothered to update their designs!
growse 3y ago
How does a host that thinks there are only 4 billion addresses send a packet to a host with an address that falls outside of the 32 bit v4 space? This is a fundamental problem. Backwards compatibility (without introducing translation schemes and middleboxes) is literally impossible.
- rini17 3y ago
  Extending address is fully possible, and if we drop requirement that the extended part be individually routable, even simple. But no, someone said we must redo whole stack and we need every piece of sand to have public routable address..so now we are stuck between rock (old fossilized IPv4) and hard place (completely incompatible IPv6).
  - growse 3y ago
    You're inventing a new addressing scheme, and proposing that we put a bunch of middleboxen in to mediate connecting the old world to hosts on this new addressing scheme. You're re-inventing IPv6.
    - rini17 3y ago
      No, I describe existing practice with NAT where you in fact have IP addresses extended by TCP/UDP port numbers. You could instead move this "port" directly into IP header in backward-compatible way and fall back to stateful NAT only if the counterparty does not support it.
      - growse 3y ago
        A device that doesn't understand your newly invented addressing scheme would need to rely on some other intermediate device in order to get traffic to an endpoint that does support your new scheme. You're using different words, but you've got a separate addressing scheme, and dependence on proxies to enable everyone to talk to each other. This is exactly where we are with IPv6. > You could instead move this "port" directly into IP header in backward-compatible way If you're changing the meaning of the headers, it is by definition not backwards compatible.
candiodari 3y ago
IPv6 is backwards compatible. In multiple ways: Option 1: "6to4" https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4 Option 2: "nat64" https://en.wikipedia.org/wiki/NAT64 https://en.wikipedia.org/wiki/NAT64 + DNS64 Option 2b: "nat46" (which makes a few ipv6 hosts available over ipv4 if yo ulike) Option 3: "Teredo" (also known as "6in4" "tunnel broker" "6over4" "tunneling" ...) https://en.wikipedia.org/wiki/Teredo_tunneling https://en.wikipedia.org/wiki/Teredo_tunneling Option 4: 6rd https://en.wikipedia.org/wiki/IPv6_rapid_deployment https://en.wikipedia.org/wiki/IPv6_rapid_deployment Option 5: ffff/96 (yes I get it, only works if host has both ipv4 and ipv6, on the plus side: no need for the network to support it. Mostly for applications) Option 6: DS-lite https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_(DS-Lite) https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual... And then there's the weird ones: https://en.wikipedia.org/wiki/IPv6_transition_mechanism https://en.wikipedia.org/wiki/IPv6_transition_mechanism The issue is most of these require ISPs to deploy new hardware, or deploy new network services. The problem is that network hardware is single-purpose, because only single purpose hardware can sustain the speeds we demand of internet networks. This means a lot of hardware needs to be replaced in order to make the global IPv6 transition and, short of redesigning IPv4, which is 43 years old now, there's no other way to make the transition. All these solutions require either work by your ISP, or work by you yourself on all your hosts.
- ta1243 3y ago
  The fact there are so many options shows the fundamental design problem.
  - deleted 3y ago
    [deleted]
  - supertrope 3y ago
    It's iterating over time to fix real problems. No protocol is perfect in the initial RFC.
    - p1mrx 3y ago
bauruine 3y ago
What's your problem with the IPv6 end-user experience? Hundreds of millions of end-users are using it without even knowing what an IP is.
danhor 3y ago
USB 3 the protocol isn't backwards compatible with USB 2, USB 3 ports just include both USB 2 and USB 3 pins (what one might call dual stack). You can easily connect two differnt devices one to the USB 2 pins and one to the USB 3 pins. If you only want to connect USB 3 devices, there is no need for USB 2 Pins, as done on the PS4. There is also no specified way to convert USB 3 to USB 2, but some have tried, with mixed results.

bradley13 3y ago

"Just extend the address size" was certainly one of the options. Sure, it's still a change, but the point is: After this change, both protocols could have worked side-by-side. Devices that only supported IPv4, no problem, they send 32-bits. Devices that supported IPv6-as-it-could-have been would simply have zero-padded those 32-bits to match the new protocol. Talking to old devices, the zero-padding gets dropped. That would have saved a lot of pain.

lmm 3y ago
No it wouldn't. Think about how that would work for a minute. It would've created nondeterministic routing loops that would be a nightmare to debug.
josephg 3y ago
Then any network address beyond ipv4’s 32 bit range would have been completely inaccessible to any legacy devices. That would have essentially been the same situation that we have now - where ipv6 only services are inaccessible to anyone on an ipv4 network. So service operators need to keep their ipv4 addresses and networks don’t update. How would that be an improvement over the existing situation?

cm2187 3y ago

At this stage it shouldn't require much money to integrate ipv6. Your network equipment needs to be really old to not support v6 natively. Though granted, there is support and support. I use hyperoptic in the UK as an ISP. I replaced the native router and I still can't figure out a way to get an IPv6 address.

ta1243 3y ago

The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you). One major problem is dual stack. It doubles the workload for very limited benefit. You have all the downsides of making ipv4 work in the first place. You've then got all sorts of messes like NAT66 (ipv6 was supposed to get rid of NAT), a lack of clarity on which patch to use (NPTv6 and NAT66 are two different options for the same problem, a problem which was built into ipv6 in the first place), messy hacks like DNS64 Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster. You'd be able to communicate with ipv6 by using stateful NAT at the edge of your ipv6 network (as you do now at the edge of your RFC1918 network), you could expose services on your ipv6 only devices with natting (as you do now). You'd still have A and AAAA records, your client having an ipv6 stack could prefer AAAA instead of A, but if it needed to use an A record (or someone just tried to connect to 12.34.56.78) the stack would have gone "ok I'm ipv6 only, I'll connect to :ffff:12.34.56.78" and rely on the network to make it happen. Throw in things like NPTv6 and 464XLAT from the start (rather than 16+ years in) -- the addons which were created to address the fundamental architectural flaws in ipv6 -- and you'd have had a far smoother transition.

tsimionescu 3y ago
Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work. There was no way to make the transition to IPv6 without dual stack. The problem was much more that the precise dual-stack approach was not well thought out, when it should have been a fundamental part of the IPv6 RFC itself. Any ISP who wishes to move to IPv6 still to this day has to consider how it will handle clients that don't speak IPv6, servers that don't speak IPv6, routers they own that don't speak IPv6, and peers who don't speak IPv6. There is no way to make all of this work without having devices that translate between the two (losing most of the benefits of IPv6 when going through this translation, of course). When you've spent 10 million dollars or more on a router that doesn't speak IPv6, you don't change it one year later just because a new protocol has come up. That thing is there to stay for 5-10 years, and you just work around it as best you can.

cornholio 3y ago

There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upgrade just the endpoints in the first phase. So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN. This doesn't solve the "backwards compatibility" problem itself, because you still have two logical different IP networks running on top of each other, requiring separate name resolution, etc. But what it does solve is the "incentive problem": endpoints are incentivized to upgrade because it gives them an immediate benefit, end-to-end connectivity to other upgraded users with non-routable addresses sitting behind a dumb, non-upgraded IPv4 routers. For example, VoIP or P2P software would immediately benefit and it would drive adoption for an immediate use-case. In the later stage, when the entire infrastructure can understand the extended packet format, you would start to publish extended routes that don't fall into the hierarchical range, similar to IPv6 today. IPv6 lacks any such incentive, because me upgrading and enabling it has zero benefits until all hops separating me from the internet also enable it and correctly configure it. On the contrary, by requiring a completely new, complex configuration with no "default, just works" mode, IPv6 introduces a disincentive, because by enabling it not only do I not gain anything, but I risk breaking my internet due to misconfigured upstream. So the conservative setting for IpV6 has, for the last 3 decades, remained "off". This only recently began to change.

gabereiser 3y ago
>”So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure.” So… NAT.
- cornholio 3y ago
  No. There would be no NAT box holding IP-port mappings in its internal memory, with the related timeouts, flakiness, port clobbering etc. and no packet re-writing. All routing decisions would be static, based on information in the IP header: the legacy outside routers would just examine the legacy part of the IP address and packet, while the internal IPv4.1 would use the extended bits. So just like any packet routing and without translation. Critically, this solves the cold start and connectability problem of NAT: if you get a packet addressed to your outside IP, to a port that has no memorized mapping, to what internal IP do you send it to? Lacking a static or UPnP port assignment, it can only be dropped. The extended packet format would provide this information for every packet, the upgraded outside host would tell you what upgraded internal host it wants to talk to.

paulsutter 3y ago

In practice IPv6 is for mass market ISPs and IPv4 is for servers. Wasn’t the intention, but that’s how it is to a first order approximation There are billions of phones so sure, they should be on ipv6. ipv6 is a kind of super NAT that few people bother to learn Sorry about that ipv6 committee

sambazi 3y ago
> ipv6 is a kind of super NAT that few people bother to learn true, for now. sometime it will reverse and i am exited about what will happen in/with the "legacy internet"

commandersaki 3y ago

Everyone is always quick to complain that we're going through N number of NAT gateways or N number of proxies, but this is virtually never a problem for most of the Internet. Even despite this rats maze of proxies and NAT gateways we're still supporting virtually all the applications that consumers use and love such as VoIP, WebRTC, HTTP(S), DNS, Gaming, Streaming Video, Mobile Apps, etc. NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience, but there has to be some sacrifice to keep the Internet running for the billions of users. NAT and by extension CGNAT are the unsung heroes of the Internet.

deleted 3y ago
[deleted]
superluserdo 3y ago
>Even despite this rats maze of proxies and NAT gateways we're still supporting virtually all the applications that consumers use That's a tautology: "Despite the limitations of IPv4, we're still supporting all the applications that can work within the limitations of IPv4". Lots of potential P2P applications (that might solve a lot of problems with have with the current centralised model of the internet) either don't make it past the drawing board because of NAT, or have to be encumbered with complex, expensive-to-develop, best-effort NAT-punching behaviour that burdens everyone involved (and can stop an application from being truly P2P by having to run things like STUN servers). >NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience I think there would be many more that wanted this if it were trivially easy to do >but there has to be some sacrifice to keep the Internet running for the billions of users. What's the sacrifice in using IPv6?
- commandersaki 3y ago
  > I think there would be many more that wanted this if it were trivially easy to do I've seen figures from proponents of Future Internet Architectures such as Named Data Networking claim that consumption is about 80% of Internet traffic. The truth is not everyone needs a Internet addressable host, mobile phones for example don't. And well, we're living in this situation today with CGNAT and you don't hear complaints from customers about not having Internet addressable IPs. > What's the sacrifice in using IPv6? Support. Enabling IPv6 on broadband consumer networks, small medium businesses, etc. means that you have to support the various devices v6 stacks and applications and ensure they continue to work just as well as they did with IPv4. IPv6 can still cause damage and the ability to support and fix these issues throw out virtually all incumbent knowledge. If it were really just a "flip of a switch", everyone would've done it by now.

rewmie 3y ago

> The IPv6 transition will be like a bankruptcy: very slowly, slowly, then all of a sudden. I don't think that's true. Some services on the internet are already made available through IPv6. Doesn't that mean their migration to IPv6 is done? There are however some ISPs that seem to be dragging their feet. I recall I tried to deprecate IPv4 access to a personal project of mine and it was no longer reachable when I tried to access it from my home. Lookups from other points of the world could resolve the IP but not my little home network. I felt forced to continue paying the 2€ I paid for a IPv4 address just because of that. Edit: to make it abundantly clear, I'm looking at you, Vodafone. You suck.

simiones 3y ago
No, the migration is only done when you're exclusively running IPv6. Very very little of the internet is accessible only over IPv6.
- rewmie 3y ago
  > No, the migration is only done when you're exclusively running IPv6. I don't think that's an informed, thought-out take. The internet works just fine for all intents and purposes if you have some services reachable through IPv4. There is no obligation to shut down IPv4 in order to work with IPv6. If you're able to go through your daily work seamlessly hitting services with IPv6, that's a successful migration. It matters nothing if an unrelated service hasn't went through their migration yet.
  - simiones 3y ago
    What I meant was, almost all server operators on the internet have to support either IPv4-only or dual stack. It is still economic suicide to run an IPv6-only server, at least in most areas of the world. As long as you have to run IPv4 software as well and lease an IPv4 address, I would say you are not fully migrated to IPv6.

cameronh90 3y ago

We could presumably have done something like: use the IPv4 packet format, treat the 32 bit src/dst address in the header as the first 32 bits of the address and put the remaining 96 bits (+ checksums/etc.) as the first few bytes of the payload. Then create TCPv6, UDPv6, IGMPv6 etc. protocol identifiers for the protocol field to distinguish traffic that's encoding an IPv6 address in the first few bytes of the payload. Then, if you own an IPv4 address, you effectively own an IPv6 subset. Then we reserve a whole bunch of IPv4 addresses for IPv6-only allocations. I obviously haven't thought it through in detail, but wouldn't something like that effectively transparently work via IPv4 core infrastructure provided the networks at either end support IPv6 if they're using it? We'd still need NAT for IPv6-only endpoints that need to talk to IPv4-only endpoints. It also wouldn't be anywhere near as clean as IPv6 and would lack a few of the nice features, but... an awesome protocol I can't actually use isn't much use to me.

welterde 3y ago
You more or less just reinvented a more complicated variant of 6to4/6rd, which is one of the IPv6 transition technologies.
ilyt 3y ago
> We could presumably have done something like: use the IPv4 packet format, treat the 32 bit src/dst address in the header as the first 32 bits of the address and put the remaining 96 bits (+ checksums/etc.) as the first few bytes of the payload. Then create TCPv6, UDPv6, IGMPv6 etc. protocol identifiers for the protocol field to distinguish traffic that's encoding an IPv6 address in the first few bytes of the payload. So no router can route it sensibly and no existing client works ? How would that help ?

theamk 3y ago

the reason for slow IP adoption is that they decided to break all backwards compatibility. You need new protocol, sure. But do you _have_ to switch from "1 almost fixed address per interface" to "tons of addresses per interface and dynamically changing"? Did you have to present it as a separate protocol to apps? Did you have to use : in representation, breaking most ad-hoc text processing code? etc.. if they goal was "herr is a new verion of IPv4 with same semantics" then we'd just need to wait for new kernels and libraries to come out, and it would be all done years ago.

AtlasBarfed 3y ago

Really, IPV6 has failed because of human reasons. I know because almost everyone demonstrably hates it, as evidenced by their behavior. The big issue is that the router vendors hated it, the OS vendors hated it, the programming language people hated it, and the software writers hated it. How do I know? NOBODY WANTS TO ADOPT IT except by force, even now. Worryingly, pro-IPV6 people are consistently arrogant and dismissive. Essentially their argument always boiled down to "ha, you'll be forced to use it eventually and then I'll be RIGHT!!!" which is why IPV6 people hate NATs with a vehement irrational passion, because it floated IPV4 for, what, two decades at least? I'm guessing it is because IPV6 was a tossed-over-the-wall protocol that didn't get reference implementations from the biggest router vendors first. Here's a very very very very very very troubling link: https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/network_systems/docs/cisco_it_case_study_ipv6.pdf https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/networ... That is Cisco bragging about it's IPV6 website on a pdf from 2011! 2011! Fifteen years after the birth of the protocol. If Cisco did not have an IPv6 site up until FIFTEEN YEARS after protocol definition ... oh god. Comcast routers weren't IPV6 functional back in 2015, at least they weren't on my cable modem. If an ISP that makes bank on renting and turning over its consumer routing hardware can't roadmap ipv6 adoption within 22 years... ugh. And my biggest complaint about ipv6 is that they didn't increase the number of ports. Really. We have to keep shoehorning apps into 64k ports rather than a sensible 4 billion, but maybe there's some OS mapping concern with that, doesn't matter, the ship sailed. https://en.wikipedia.org/wiki/Internet_Protocol_version_4 https://en.wikipedia.org/wiki/Internet_Protocol_version_4 Somewhere in IPV4 is an options header (up to 40 bytes). Why that didn't provide the necessary space for some degree of backwards compatibility somehow is beyond me. What should have happened is that the big router vendors got together and agreed on a standard protocol. Then the major OS vendors and language standards bodies got together and made reference implementations for basic networking. Once that was working / adopted by next gen hardware and software releases, then things might have gotten rolling. I mean, how much work was that relative to the mind boggling amount of work done to implement NAT and firewall traversal/busting code in, say, Skype? Ever seen those whitepapers? Wow are they doozies. Holy crap are people willing to write code. This is all screaming at the darkness.

viraptor 3y ago

GoblinSlayer 3y ago

Technically address space can be expanded with a reverse proxy like SOCKS5: connect to NAT over ip4 and pass target address or even domain name.

plumeria 3y ago

> The IPv6 transition will be like a bankruptcy: very slowly, slowly, then all of a sudden. That's a fresh alternative to the boiling frog metaphor.

_8j50 3y ago

"this is an entirely new protocol by the definition " NO!!! this is what the parent comment meant about ipv6 design. Add an octet and that's it. Same protocol with same rules just a bigger address. It may be a different version of IP but the protocol and supporting protocols like ARP and DHCP just need to support the new IP. The reason IPv6 failed is the same reason why when new devs join a team, they find how everything is wrong and try to fix it all and leave a bigger mess than what they started with. You solve problems one step at a time. Overhauls are only justified when your objective is specifically to improve the whole system. "The reason for the slow IPv6 adoption is that there was no financial or business pressure." That is only part of the reason. The other part is it is a pain to use, there is no way to use it without also supporting v4 and on top of that you have to learn and adapt other new protocols, addressing schemes, gotcha's and much more. Just add a freaking octet!

fuy 3y ago

it's probably been mentioned before, but there are customers that require IPv6 (like some US gov agencies and others), so for a lot of B2B/enterprise software companies it actually makes sense to support ipv6. And it's technically interesting, so why not! (I've been there, and it was fun)