18 ms·

IPv6 isn't hard, and as the article alludes to, it is different, but it's not even that different. What is hard, is dual stack networking. Dual stack networkin

IPv6 isn't hard, and as the article alludes to, it is different, but it's not even that different. What is hard, is dual stack networking. Dual stack networking absolutely sucks, it's twice the stuff you have to deal with, and the edge cases are exponentially more complex because if your setup isn't identical in both stacks, you're going to hit weird issues (like the article suggests) with one stack behaving one way and the other behaving another way. None of this is the fault of IPv6, it's a natural consequence of the strategy of having two internets during the transition period. A transition period which has now been going on longer than the internet existed when it started. Maybe 100 years from now we'll finally be able to shut off the last IPv4 system and the "dream" of IPv6 will become a reality, but until then, life is strictly more difficult on every network administrator because of dual stack. (Note: no, we could not have done it any other way. Any upgrade strategy to IPv4 that extended the address size would have necessitated having two internets. It just sucks that it's been this long and we're still not even at 50% IPv6 usage.)

ninkendo 2y ago
To add: The really sad thing about IPv6 is that it's a relic of a bygone era. The internet was envisioned as a thing where every device on every network could, in principle, initiate a connection to any other device on any other network. But then we started running out of addresses, ISP's wouldn't give you more than one for a household, so we started doing NAT, and that kind of sealed the internet's fate. Nowadays, we wouldn't want a world where everything was connectable, even if we had enough addresses. Everyone's network in essence has a firewall. If you run IPv4 and using NAT, you're going to be dropping unsolicited incoming packets no matter what (let alone that you wouldn't know where to route them even if you wanted to let them through) and with IPv6 you'd be insane to allow them. Devices have "grown up" in a world where we expect the router we're connecting to, to shield us from incoming unsolicited traffic. I certainly don't have the firewall enabled on my linux desktop. Windows I _think_ has it enabled by default, but I often turn it off because I want LAN connections to work. MacOS is probably similar. Suffice to say, if the IPv6 dream happened overnight and everyone's devices were instantly connectable, all hell would break loose. We need our routers to disallow traffic. (Edit: This wasn't all that clear, so let me restate: In both the IPv4 and IPv6 world, you'd be insane to disallow incoming unsolicited traffic, which is why basically everyone blocks it in IPv6 as well as IPv4. I'm not trying to say IPv6 can't do this... quite the contrary: IPv6 routers absolutely do, and should, block unsolicited incoming traffic. But my point is that this is what prevents the original vision of IPv6 from becoming a reality: We can't design software around the idea of direct peer-to-peer communication, without stuff like UPnP. Oh, and UPnP works with NAT and IPv4 anyway so, there's the rub.) So, even in a pure-IPv6 world, that instantly prevents any startup with an idea to allow true peer-to-peer communication using end-to-end routability. What are you going to do, train your users to log into their router and enable traffic? Approximately 0% of your customers know how to do that, even in a counterfactual universe where IPv6 happened and we all have routable IP's on our devices. Maybe in such a universe, people would be trained to use local firewalls on their device, and say "ok" to popups asking if you want to let software through. But I'd wager that a lot of people would prefer the simplicity of just having their gateway drop the traffic for them. No, the "all devices are routable" idea came from a naive world where there wasn't a financial incentive for malicious behavior at every turn. Where there aren't millions of hackers waiting for an open port to an exploitable service they can use to encrypt all your data and ransom it for bitcoin. The internet is a dark forest now. We don't _want_ end-to-end connectivity.
- boredatoms 2y ago
  In an IPv6 world, your home router still firewalls just like with IPv4 (the NAT is just an extra accidental firewall-ish thing), you can still skip the firewall on your laptop Having globally allocated address space doesn’t actually imply openness of connectability
  - tomas789 2y ago
    I wouldn’t want to relay on random caffee’s router to do this for me. I would still end up running firewall more carefully on my end devices. Which for my iPhone I’m not even sure if I can. So probably a personal VPN would be a must.
    - yjftsjthsd-h 2y ago
      Does a VPN prevent inbound traffic on other IPs? If I put my laptop on a VPN, I can still SSH to it on its RFC 1918 address.
      - throwaway173738 2y ago
        A VPN can’t prevent inbound traffic but if the VPN alters the routing table it can prevent the return leg from working. This probably isn’t enough to prevent compromise.
      - icedchai 2y ago
        It depends on the VPN and its policies. Some deny all local traffic when active, routing everything through the VPN, and only leave a IPv4 /32 route for the default gateway. Some are more permissive.
    - averageRoyalty 2y ago
      Sure... But wouldn't you want to treat this random network as hostile anyway? The router might already have port forwarding to the IP you grab from DHCP, not to mention other clients on the network. I'm also unsure how a VPN would help against inbound traffic regardless?
deleted 2y ago
[deleted]
spaceywilly 2y ago
Yes. In my day job I work mainly on containers running entirely in data centers we own, they are fully ipv6, it’s very nice to work with. Then there is this one customer, they are colocated in other ISP owned datacenters, and some of their server maybe have fully IPv6, some may have only IPv4, some may be a mixture of both. Supporting them is a never ending nightmare.
pclmulqdq 2y ago
It doesn't help that the use of an IPv4 is a status symbol that indicates that you are willing to spend money on your infrastructure (and are thus not a spammer). If you attempt to run an email server on IPv6, you will see what I mean.
- immibis 2y ago
  I found an open email relay on IPv6 once, because nobody scans IPv6 and therefore nobody ever sent spam through it. (Apparently this was caused by a reverse proxy misconfiguration causing the server to think IPv6 connections were from localhost)
  - sleepy_keita 2y ago
    Also the surface area of IPv6 is huge, it just takes so much time to scan everything. It's not security, but it's a deterrent.
    - crote 2y ago
      And yet scanning IPv6 is exactly what some people are doing. IPv6 nodes aren't individual random addresses in a 128-bit address space. They are going to be grouped in subnets, so it makes sense to explore /64 ranges where you know there's already at least 1 address active. There's a pretty decent chance at least some addresses are going to be sequential - either due to manual configuration or DHCPv6 - so you can make a decent start by scanning those. For non-client devices, SLAAC usually generates a fixed address determined by the NIC's MAC address, which in turn has a large fixed component identifying the NIC's vendor. This leaves you with a 24-bit space to scan in order to find other devices using NICs made by that vendor - not exactly an unfair assumption in larger deployments. Much faster scanning can of course be done if you can use something like DNS records as source for potential targets, and it's game over once an attacker has compromised the first device and can do link-local discovery. It's not going to be extremely fast or efficient, but IPv6 scanning isn't exactly impossible either. It's already happening in practice[0], and it's only going to get worse. [0]: https://www.akamai.com/blog/security-research/vulnerability-scanning-IPv6-why-should-we-care https://www.akamai.com/blog/security-research/vulnerability-...
ignoramous 2y ago
> and the "dream" of IPv6 will become a reality Depending on what that dream is, it may already be a reality in the upper layers (webrtc, websockets, quic/http3, etc). This is why not many really bother if IPv4 will go away?
johnea 2y ago
This is a little self contradictory. Saying that it's "not that different", then going on to mention "the strategy of having two internets". Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 protocol. Just to provide the architypical links: This was documented about 25 years ago by DJB: https://cr.yp.to/djbdns/ipv6mess.html https://cr.yp.to/djbdns/ipv6mess.html And has been repeatedly discussed on HN: https://news.ycombinator.com/item?id=10854570 https://news.ycombinator.com/item?id=10854570 As you mention, IPv6 has exsited for the majority of the commercial internet's history, now 25 years later, it's still not the default transport protocol. It _was_ possible to create an address space extension that was IPv4 backwards compatible, this option was just not chosen, and now we're still dealing with the dual stack mess.
- ninkendo 2y ago
  > Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6 That's not at all what I'm suggesting, I'm saying "two internets" because there are two internets: IPv4 and IPv6. You need two internet stacks on every host to deal with this, hence two internets. If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, there would still be two internets, because they are not mutually compatible. Saying "two internets" is not a judgement call on whether IPv6 changed too much or is too different. It's just the literal truth. There are two internets, because one can't communicate with the other.
  - Dagger2 2y ago
    Well, that's just not true: $ ip -4 addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever $ ping -6 ipv4.google.com PING ipv4.google.com(sof04s06-in-f14.1e100.net (64:ff9b::142.251.140.78)) 56 data bytes 64 bytes from 64:ff9b::8efb:8c4e: icmp_seq=1 ttl=55 time=27.9 ms This is a v6-only machine (no v4 address other than lo), talking to a v4-only hostname. If it was truly not possible to communicate, this wouldn't work. > If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, because they are not mutually compatible. This part is true though. v6 is backwards compatible in rather a lot of ways, but v4 isn't forwards compatible, and it's important to note that this comes entirely from the larger address size -- no amount of making v6 more identical to v4 than it already is would make v4 any more compatible with it, unless you undermined the entire point and made the addresses 32 bits.
averageRoyalty 2y ago
For what it's worth I have many years of technical experience and a pretty decent knowledge of IPv4 networking, and I found it quite hard - at least when first learning. The addressing is intimidating, getting your head away from NAT, thinking about being globally routable, the lack of (or variances in) DHCP, ND, "static" addressing via suffixes, etc. None of this is technically "hard", but it's a significant barrier to entry because it's quite different to what most normal technical users are used to. Dual stack may create some new problems, but it fixes a lot of others. All of the major cloud providers have awful IPv6 only support, and many prominent web resources that usually invisibly "just work" have little to no IPv6 support.
- ninkendo 2y ago
  I think you thought it was hard precisely because you had a decent knowledge of IPv4. I suspect that if the situation were reversed and we always had IPv6, and someone proposed a new IP suite where you had to use NAT for everything, and all hosts needed to have their addresses hand-picked (or served via a DHCP server that used an ugly hack to communicate with hosts that don't have an IP yet), you'd find that to be the "hard" one.
  - globular-toast 2y ago
    Yeah, it makes me think of finding an automatic car difficult because you're used to manual. I have noticed people are often reluctant to give up on something they had to learn, though.
  - strken 2y ago
    The one objectively difficult thing about IPv6 is remembering an address. Four base-10 numbers between 0 and 255 fit in working memory, while eight groups of four hex digits don't. Even a shortened address can be difficult to recall.
    - crazygringo 2y ago
      Your working memory must be better than mine. I can remember two numbers from 0 to 255, but four? Not in a million years. Isn't there an idea that our working memory holds seven pieces of information? Which would be two of those numbers and change, if you consider each digit as a piece of information.
no_identd 2y ago
We don't live in the world in which IPv6 was a good design. Please avoid acting like IPv6 makes for a good design, because it doesn't. See apenwarr's by now nearly a decade old blog post "The world in which IPv6 was a good design": https://apenwarr.ca/log/20170810 https://apenwarr.ca/log/20170810, previous discussions of it here: https://hn.algolia.com/?query=The%20world%20in%20which%20IPv6%20was%20a%20good%20design&type=story&dateRange=all&sort=byDate&storyText=false&prefix&page=0 https://hn.algolia.com/?query=The%20world%20in%20which%20IPv..., as well as the follow up blog post here: https://apenwarr.ca/log/20200708 https://apenwarr.ca/log/20200708, previous discussions here: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=IPv4%2C%20IPv6%2C%20and%20a%20sudden%20change%20in%20attitude&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... And the issues with IP (and by extension, TCP, ignoring the fundamental results from the Delta-T research at Lawrence Livermore keeps biting us all in the ass) whether IPv4 or IPv6 go even deeper, far deeper, than what that blog post already tells us, so here, have this—flawed in some minor aspects, which makes CCIEs burry their head in the sand of denial about the deeper point of it—polemic for dessert: https://web.archive.org/web/20210415054027if_/http://rina.tssg.org/docs/How_in_the_Heck_do_you_lose_a_layer.pdf https://web.archive.org/web/20210415054027if_/http://rina.ts...
- ninkendo 2y ago
  > Please avoid acting like IPv6 makes for a good design, because it doesn't. Where did I give that impression? I tried my hardest in that post to not make a judgement call one way or the other as to whether it was a good design, only that dual stack fucking sucks. My followup post in fact, totally agrees with you? https://news.ycombinator.com/item?id=43070286 https://news.ycombinator.com/item?id=43070286
- convolvatron 2y ago
  that's not what this article says. I dug through it, and the main point seems to be 'It would have been beautiful. Except for one problem: it never happened.' there is nothing really wrong with the design of ipv6 relative to ipv4
- immibis 2y ago
  It's almost exactly just IPv4 with longer addresses. If IPv6 isn't a good design then IPv4 is even worse because of the address shortage.
daft_pink 2y ago
I’m gonna get downvoted for this, but IPv6 has lost and they have to come up with something else with enough benefit for the user to achieve widespread adoption to beat IPv4.
- ninkendo 2y ago
  IPv6 certainly hasn’t “won” in the sense that it’s nowhere near where it should have been by now, but I would definitely not say we need to make something else that also isn’t ipv4 and thus also isn’t forward compatible. IPv6 is still the only game in town as a successor technology to IPv4, and it makes no sense to invent some other new thing. The real question at hand, is do we keep trying to make IPv6 happen, or do we give up and just deal with IPv4 until the end of time. (It’s not an obvious answer. L7 load balancing and IP anycast makes it so you can basically run an entire tech company on a single IPv4 address. CGNAT is becoming more and more commonplace. The pressure on IPv4 availability is alleviating all the time. Maybe 4 billion addresses will ultimately be enough for humanity, who knows.) But I mean it when I say that if we continue as is and just sorta gradually, grudgingly add IPv6 on a best-effort basis, it’ll likely be 100 years or so before we can actually turn off IPv4.
Dylan16807 2y ago
You can run a pure IPv6 network that can connect out to both, though. You don't need to run dual stack.
pknomad 2y ago
When you say IPv6 isn't hard, do you mean implementing v6-only network stack isn't hard or understanding IPv6 isn't hard? Depending on which layer one lives on, I feel like the lack of networking effect makes supporting v6 difficult. Github is still isn't on v6 and some load balancers will prefer the v4 address over v6, etc...
- paulddraper 2y ago
  Understanding it isn’t hard. Obviously you can use (just) IPv6, e.g. GitHub.
o11c 2y ago
One major annoyance of IPv6 is that it lacks support for IPv4's whole 127.0.0.1/8 range.
- boredatoms 2y ago
  What are the use cases for it beyond the regular .1 address that you dont get from ::1?
  - o11c 2y ago
    It's very useful for cooperatively pretending that a single machine is actually a network of machines, without all the madness of network namespaces. Basically every server program ever supports the notion of "which IP address am I supposed to bind to?" Normally the answer is either "localhost" or "whatever my LAN or WAN address is, for a particular interface". And specifying this (both for servers and for clients) is much less effort than replacing all the standard-ish ports with ad-hoc ones.
    - Spivak 2y ago
      I love this feature so much when jumping back and forth between two projects that when devving expect exclusive control of postgres. All I have to do is set the bind address for one .1 and the other .2 and all is good.
    - akdev1l 2y ago
      You can literally do the same thing with IPv6. Just assign multiple IPv6 to your loopback interface and everything will work as expected. You can use either private IPv6 or even link-local IPv6 range. There’s no need to waste thousands of addresss on this use case.
      - paulddraper 2y ago
        > waste thousands Yeah would hate to run out
      - o11c 2y ago
otabdeveloper4 2y ago
> Note: no, we could not have done it any other way. Any upgrade strategy to IPv4 that extended the address size would have necessitated having two internets No, this isn't right. Instead of having IPv6 we ended up extending IPv4 by using port numbers as extra address bits and using NAT. This transition was painless (for the most part), and didn't require building a second internet. In a better and saner world we could have got roughly the same thing - except conceptually simpler and standard - instead of IPv6.
- ninkendo 2y ago
  I think I’d mostly agree with you if only one layer of NAT is in play, but in reality we have CGNAT and it makes it supremely difficult to host services without a very cooperative ISP (laughable.) And there are more internet subscribers in the world than there are IP’s for them, so CGNAT is required for at least some unfortunate part of the population. In reality we just really do need more IP’s. 32-bit addresses with 16 bits of ports isn’t enough.
  - otabdeveloper4 2y ago
    > makes it supremely difficult to host services without a very cooperative ISP Sadly, that's a feature, not a bug. Two layers of NAT sucks, but I guess it could have been avoided if a designed (instead of ad-hoc) solution to the problem was devised. > And there are more internet subscribers in the world than there are IP’s for them Is this really true, did somebody actually run the business math? "Internet subscriber" roughly corresponds to "household", not to "person".
dxld 2y ago
Good news: it's 20 years, not 100, at the most :-) https://labs.apnic.net/index.php/2024/10/19/the-ipv6-transition/ https://labs.apnic.net/index.php/2024/10/19/the-ipv6-transit...
- mort96 2y ago
  You can't just assume linear growth. Your link acknowledges this, and the "prediction" you refer to has the right caveat: "we can look at the time series shown in Figure 1 and ask the question: 'If the growth trend of IPv6 adoption continues at its current rate, how long will it take for every device to be IPv6 capable?'". It's using such a naïve model to illustrate that we're still nowhere close to completing the transition, not to say that we'll be done in 20 years at most as you suggest. Adoption will slow down and my guess is that we'll be stuck with a long tail forever, and only time will tell if that happens at 50% adoption or 90% adoption.
  - dxld 2y ago
    I would agree with you were it not for the fact that I'm personally investing my time into a FLOSS project to make sure the growth does not slow down by making “tomorrow NOT like today”, but gets a kick in the butt once we reach the 50% deployment inflection point instead. Stay tuned ;-)
    - mort96 2y ago
      Whatever you're cooking up, I wish you luck! My life would be significantly easier if I could just completely ignore one network protocol, be that v4 or v6. So far I have mostly just ignored v6 and everything I do uses v4, but I have no strong preference (except that v4 addresses fit in my brain while v6 addresses do not, which is honestly a not-insignificant reason why v6 is hard)
      - dxld 2y ago
        Here's to hoping, but I agree one way or another one stack needs to go :-) BTW: Contact info is in my profile if anyone wants the inside scoop. The project just isn't fully ready for public launch yet, but we're well into the cooking.
ademarre 2y ago
ISPs aren't helping either. Ziply Fiber only provides IPv6 with their 10 Gig and up plans, starting at $300/month.
himinlomax 2y ago
The dual stack strategy was criticized 20+ years ago on these grounds, it seemed pretty obvious to me, and as you point out critics were right.
El_RIDO 2y ago
> What is hard, is dual stack networking. Dual stack networking absolutely sucks, [...] Clearly you have gotten some unfortunate hands on experience with those edge cases. In my uses the dual-stacking of IPv4 & IPv6 has been a big benefit in that I have to worry a lot less about locking myself out of systems, as I can always reconnect and correct configuration mistakes on the second stack. Comparing the IPv4+IPv6 dual-stack story to the one from the 90s of IPv4 with IPX/SPX (Novell Netware) and/or NetBIOS (Microsoft Windows), the current state is a lot more smooth and robust. I've so far only run into 3 issues over the years (2013 till now). A local train operator running IPv6 on routers that didn't properly support non-default MTU sizes (fragmented packages getting dropped) and Microsoft where Github is still IPv4-only and Teams recently developed an IPv6-only failure on a single API endpoint. Should we ever turn off IPv4 during my working life-time, I hope we have at that point introduced a successor to IPv6, so I can keep using a dual- or triple-stack solution, using different network protocols for robustness.
redeeman 2y ago
there could have been allocated a prefix to ipv6 that would contain the entire ipv4 space, and then all ISPs could have simply translated between at the edge, which would have made it possible for all normal consumer/company devices to only carry an ipv6 stack
- Dagger2 2y ago
  "Simply" is doing a lot of heavy lifting there. There are multiple v6 prefixes already allocated for containing the v4 space. It would help if all ISPs ran NAT64 routers on the standard NAT64 prefix, but e.g. how would that function with software that only works with v4 addresses?
  - redeeman 2y ago
    it wouldnt, that software would update or get left behind, too bad.
    - Dagger2 2y ago
      Then you're back at having "two internets" again. (Well, I don't agree that it's two Internets, but you'd be stuck with the same situation we have already because people would continue to use v4 in order for that software to continue to work.)
  - ta1243 2y ago
    OS would translate the ipv4 address to ipv6 before it leaves the machine. Very rare that software writes its own packet to the network card. On an ipv6 only device if I type "ping 1.1.1.1", I would expect that to be translated by the OS (not the program) to 64:ff9b::1.1.1.1, rather than relying on DNS64 to do it. Then at some point upstream it would go via a nat64 gateway to reach that legacy IP. This should have been in OS stacks 20 years ago.
    - ninkendo 2y ago
      You’re describing 464XLAT, it’s how T-Mobile internet works. iOS, macOS and windows all support what you describe out of the box (although last I checked, Windows inexplicably only does this if the interface is a mobile/5G interface. They may have fixed this.) You can try this on a vanilla macOS install if the router advertisement hints at a NAT64 prefix (RFC8781) and you either don’t run DHCP4, or your DHCP4 server lists the IPv6-preferred option (RFC8925). I think they’ve also added a check to query a well-known ipv4-only hostname on DNS, and if it gets a AAAA back and the connection works, it knows it must be behind a working nat64 setup, which obviates the need for the router advertisement to have the PREF64 option. I tried this a year ago and it worked great, macOS skips DHCPv4 and gives itself a single 192.0.0.1/32 address so that legacy apps can “see” an IPv4 interface, and any packets sent from it are translated to IPv6 and sent to the nat64 prefix. So “ping 1.1.1.1” works fine. I stopped using this though, because I have a garage door opener (ratGDO) that only works with ipv4, and my nat64 prefix can’t “hair-pin” the packet back to the LAN address… it basically only works if everything on your LAN is IPv6, which my garage door is not. I think android supports this as well, but I’m not sure about vanilla Linux, I think you need to install a clat daemon to do the translation. It did take way too long for this to work though, as you point out.
meragrin_ 2y ago
> we're still not even at 50% IPv6 usage Partially due to companies like Metronet whose focus is on growing rather than doing what it should be doing.

ninkendo 2y ago

To add: The really sad thing about IPv6 is that it's a relic of a bygone era. The internet was envisioned as a thing where every device on every network could, in principle, initiate a connection to any other device on any other network. But then we started running out of addresses, ISP's wouldn't give you more than one for a household, so we started doing NAT, and that kind of sealed the internet's fate. Nowadays, we wouldn't want a world where everything was connectable, even if we had enough addresses. Everyone's network in essence has a firewall. If you run IPv4 and using NAT, you're going to be dropping unsolicited incoming packets no matter what (let alone that you wouldn't know where to route them even if you wanted to let them through) and with IPv6 you'd be insane to allow them. Devices have "grown up" in a world where we expect the router we're connecting to, to shield us from incoming unsolicited traffic. I certainly don't have the firewall enabled on my linux desktop. Windows I _think_ has it enabled by default, but I often turn it off because I want LAN connections to work. MacOS is probably similar. Suffice to say, if the IPv6 dream happened overnight and everyone's devices were instantly connectable, all hell would break loose. We need our routers to disallow traffic. (Edit: This wasn't all that clear, so let me restate: In both the IPv4 and IPv6 world, you'd be insane to disallow incoming unsolicited traffic, which is why basically everyone blocks it in IPv6 as well as IPv4. I'm not trying to say IPv6 can't do this... quite the contrary: IPv6 routers absolutely do, and should, block unsolicited incoming traffic. But my point is that this is what prevents the original vision of IPv6 from becoming a reality: We can't design software around the idea of direct peer-to-peer communication, without stuff like UPnP. Oh, and UPnP works with NAT and IPv4 anyway so, there's the rub.) So, even in a pure-IPv6 world, that instantly prevents any startup with an idea to allow true peer-to-peer communication using end-to-end routability. What are you going to do, train your users to log into their router and enable traffic? Approximately 0% of your customers know how to do that, even in a counterfactual universe where IPv6 happened and we all have routable IP's on our devices. Maybe in such a universe, people would be trained to use local firewalls on their device, and say "ok" to popups asking if you want to let software through. But I'd wager that a lot of people would prefer the simplicity of just having their gateway drop the traffic for them. No, the "all devices are routable" idea came from a naive world where there wasn't a financial incentive for malicious behavior at every turn. Where there aren't millions of hackers waiting for an open port to an exploitable service they can use to encrypt all your data and ransom it for bitcoin. The internet is a dark forest now. We don't _want_ end-to-end connectivity.

boredatoms 2y ago
In an IPv6 world, your home router still firewalls just like with IPv4 (the NAT is just an extra accidental firewall-ish thing), you can still skip the firewall on your laptop Having globally allocated address space doesn’t actually imply openness of connectability
- tomas789 2y ago
  I wouldn’t want to relay on random caffee’s router to do this for me. I would still end up running firewall more carefully on my end devices. Which for my iPhone I’m not even sure if I can. So probably a personal VPN would be a must.
  - yjftsjthsd-h 2y ago
    Does a VPN prevent inbound traffic on other IPs? If I put my laptop on a VPN, I can still SSH to it on its RFC 1918 address.
    - throwaway173738 2y ago
      A VPN can’t prevent inbound traffic but if the VPN alters the routing table it can prevent the return leg from working. This probably isn’t enough to prevent compromise.
    - icedchai 2y ago
      It depends on the VPN and its policies. Some deny all local traffic when active, routing everything through the VPN, and only leave a IPv4 /32 route for the default gateway. Some are more permissive.
  - averageRoyalty 2y ago
    Sure... But wouldn't you want to treat this random network as hostile anyway? The router might already have port forwarding to the IP you grab from DHCP, not to mention other clients on the network. I'm also unsure how a VPN would help against inbound traffic regardless?

deleted 2y ago

[deleted]

spaceywilly 2y ago

Yes. In my day job I work mainly on containers running entirely in data centers we own, they are fully ipv6, it’s very nice to work with. Then there is this one customer, they are colocated in other ISP owned datacenters, and some of their server maybe have fully IPv6, some may have only IPv4, some may be a mixture of both. Supporting them is a never ending nightmare.

pclmulqdq 2y ago

It doesn't help that the use of an IPv4 is a status symbol that indicates that you are willing to spend money on your infrastructure (and are thus not a spammer). If you attempt to run an email server on IPv6, you will see what I mean.

immibis 2y ago
I found an open email relay on IPv6 once, because nobody scans IPv6 and therefore nobody ever sent spam through it. (Apparently this was caused by a reverse proxy misconfiguration causing the server to think IPv6 connections were from localhost)
- sleepy_keita 2y ago
  Also the surface area of IPv6 is huge, it just takes so much time to scan everything. It's not security, but it's a deterrent.
  - crote 2y ago
    And yet scanning IPv6 is exactly what some people are doing. IPv6 nodes aren't individual random addresses in a 128-bit address space. They are going to be grouped in subnets, so it makes sense to explore /64 ranges where you know there's already at least 1 address active. There's a pretty decent chance at least some addresses are going to be sequential - either due to manual configuration or DHCPv6 - so you can make a decent start by scanning those. For non-client devices, SLAAC usually generates a fixed address determined by the NIC's MAC address, which in turn has a large fixed component identifying the NIC's vendor. This leaves you with a 24-bit space to scan in order to find other devices using NICs made by that vendor - not exactly an unfair assumption in larger deployments. Much faster scanning can of course be done if you can use something like DNS records as source for potential targets, and it's game over once an attacker has compromised the first device and can do link-local discovery. It's not going to be extremely fast or efficient, but IPv6 scanning isn't exactly impossible either. It's already happening in practice[0], and it's only going to get worse. [0]: https://www.akamai.com/blog/security-research/vulnerability-scanning-IPv6-why-should-we-care https://www.akamai.com/blog/security-research/vulnerability-...

ignoramous 2y ago

> and the "dream" of IPv6 will become a reality Depending on what that dream is, it may already be a reality in the upper layers (webrtc, websockets, quic/http3, etc). This is why not many really bother if IPv4 will go away?

johnea 2y ago

This is a little self contradictory. Saying that it's "not that different", then going on to mention "the strategy of having two internets". Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 protocol. Just to provide the architypical links: This was documented about 25 years ago by DJB: https://cr.yp.to/djbdns/ipv6mess.html https://cr.yp.to/djbdns/ipv6mess.html And has been repeatedly discussed on HN: https://news.ycombinator.com/item?id=10854570 https://news.ycombinator.com/item?id=10854570 As you mention, IPv6 has exsited for the majority of the commercial internet's history, now 25 years later, it's still not the default transport protocol. It _was_ possible to create an address space extension that was IPv4 backwards compatible, this option was just not chosen, and now we're still dealing with the dual stack mess.

ninkendo 2y ago
> Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6 That's not at all what I'm suggesting, I'm saying "two internets" because there are two internets: IPv4 and IPv6. You need two internet stacks on every host to deal with this, hence two internets. If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, there would still be two internets, because they are not mutually compatible. Saying "two internets" is not a judgement call on whether IPv6 changed too much or is too different. It's just the literal truth. There are two internets, because one can't communicate with the other.
- Dagger2 2y ago
  Well, that's just not true: $ ip -4 addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever $ ping -6 ipv4.google.com PING ipv4.google.com(sof04s06-in-f14.1e100.net (64:ff9b::142.251.140.78)) 56 data bytes 64 bytes from 64:ff9b::8efb:8c4e: icmp_seq=1 ttl=55 time=27.9 ms This is a v6-only machine (no v4 address other than lo), talking to a v4-only hostname. If it was truly not possible to communicate, this wouldn't work. > If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, because they are not mutually compatible. This part is true though. v6 is backwards compatible in rather a lot of ways, but v4 isn't forwards compatible, and it's important to note that this comes entirely from the larger address size -- no amount of making v6 more identical to v4 than it already is would make v4 any more compatible with it, unless you undermined the entire point and made the addresses 32 bits.

averageRoyalty 2y ago

For what it's worth I have many years of technical experience and a pretty decent knowledge of IPv4 networking, and I found it quite hard - at least when first learning. The addressing is intimidating, getting your head away from NAT, thinking about being globally routable, the lack of (or variances in) DHCP, ND, "static" addressing via suffixes, etc. None of this is technically "hard", but it's a significant barrier to entry because it's quite different to what most normal technical users are used to. Dual stack may create some new problems, but it fixes a lot of others. All of the major cloud providers have awful IPv6 only support, and many prominent web resources that usually invisibly "just work" have little to no IPv6 support.

ninkendo 2y ago
I think you thought it was hard precisely because you had a decent knowledge of IPv4. I suspect that if the situation were reversed and we always had IPv6, and someone proposed a new IP suite where you had to use NAT for everything, and all hosts needed to have their addresses hand-picked (or served via a DHCP server that used an ugly hack to communicate with hosts that don't have an IP yet), you'd find that to be the "hard" one.
- globular-toast 2y ago
  Yeah, it makes me think of finding an automatic car difficult because you're used to manual. I have noticed people are often reluctant to give up on something they had to learn, though.
- strken 2y ago
  The one objectively difficult thing about IPv6 is remembering an address. Four base-10 numbers between 0 and 255 fit in working memory, while eight groups of four hex digits don't. Even a shortened address can be difficult to recall.
  - crazygringo 2y ago
    Your working memory must be better than mine. I can remember two numbers from 0 to 255, but four? Not in a million years. Isn't there an idea that our working memory holds seven pieces of information? Which would be two of those numbers and change, if you consider each digit as a piece of information.

no_identd 2y ago

We don't live in the world in which IPv6 was a good design. Please avoid acting like IPv6 makes for a good design, because it doesn't. See apenwarr's by now nearly a decade old blog post "The world in which IPv6 was a good design": https://apenwarr.ca/log/20170810 https://apenwarr.ca/log/20170810, previous discussions of it here: https://hn.algolia.com/?query=The%20world%20in%20which%20IPv6%20was%20a%20good%20design&type=story&dateRange=all&sort=byDate&storyText=false&prefix&page=0 https://hn.algolia.com/?query=The%20world%20in%20which%20IPv..., as well as the follow up blog post here: https://apenwarr.ca/log/20200708 https://apenwarr.ca/log/20200708, previous discussions here: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=IPv4%2C%20IPv6%2C%20and%20a%20sudden%20change%20in%20attitude&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... And the issues with IP (and by extension, TCP, ignoring the fundamental results from the Delta-T research at Lawrence Livermore keeps biting us all in the ass) whether IPv4 or IPv6 go even deeper, far deeper, than what that blog post already tells us, so here, have this—flawed in some minor aspects, which makes CCIEs burry their head in the sand of denial about the deeper point of it—polemic for dessert: https://web.archive.org/web/20210415054027if_/http://rina.tssg.org/docs/How_in_the_Heck_do_you_lose_a_layer.pdf https://web.archive.org/web/20210415054027if_/http://rina.ts...

ninkendo 2y ago
> Please avoid acting like IPv6 makes for a good design, because it doesn't. Where did I give that impression? I tried my hardest in that post to not make a judgement call one way or the other as to whether it was a good design, only that dual stack fucking sucks. My followup post in fact, totally agrees with you? https://news.ycombinator.com/item?id=43070286 https://news.ycombinator.com/item?id=43070286
convolvatron 2y ago
that's not what this article says. I dug through it, and the main point seems to be 'It would have been beautiful. Except for one problem: it never happened.' there is nothing really wrong with the design of ipv6 relative to ipv4
immibis 2y ago
It's almost exactly just IPv4 with longer addresses. If IPv6 isn't a good design then IPv4 is even worse because of the address shortage.

daft_pink 2y ago

I’m gonna get downvoted for this, but IPv6 has lost and they have to come up with something else with enough benefit for the user to achieve widespread adoption to beat IPv4.

ninkendo 2y ago
IPv6 certainly hasn’t “won” in the sense that it’s nowhere near where it should have been by now, but I would definitely not say we need to make something else that also isn’t ipv4 and thus also isn’t forward compatible. IPv6 is still the only game in town as a successor technology to IPv4, and it makes no sense to invent some other new thing. The real question at hand, is do we keep trying to make IPv6 happen, or do we give up and just deal with IPv4 until the end of time. (It’s not an obvious answer. L7 load balancing and IP anycast makes it so you can basically run an entire tech company on a single IPv4 address. CGNAT is becoming more and more commonplace. The pressure on IPv4 availability is alleviating all the time. Maybe 4 billion addresses will ultimately be enough for humanity, who knows.) But I mean it when I say that if we continue as is and just sorta gradually, grudgingly add IPv6 on a best-effort basis, it’ll likely be 100 years or so before we can actually turn off IPv4.

Dylan16807 2y ago

You can run a pure IPv6 network that can connect out to both, though. You don't need to run dual stack.

pknomad 2y ago

When you say IPv6 isn't hard, do you mean implementing v6-only network stack isn't hard or understanding IPv6 isn't hard? Depending on which layer one lives on, I feel like the lack of networking effect makes supporting v6 difficult. Github is still isn't on v6 and some load balancers will prefer the v4 address over v6, etc...

paulddraper 2y ago
Understanding it isn’t hard. Obviously you can use (just) IPv6, e.g. GitHub.

o11c 2y ago

One major annoyance of IPv6 is that it lacks support for IPv4's whole 127.0.0.1/8 range.

boredatoms 2y ago
What are the use cases for it beyond the regular .1 address that you dont get from ::1?
- o11c 2y ago
  It's very useful for cooperatively pretending that a single machine is actually a network of machines, without all the madness of network namespaces. Basically every server program ever supports the notion of "which IP address am I supposed to bind to?" Normally the answer is either "localhost" or "whatever my LAN or WAN address is, for a particular interface". And specifying this (both for servers and for clients) is much less effort than replacing all the standard-ish ports with ad-hoc ones.
  - Spivak 2y ago
    I love this feature so much when jumping back and forth between two projects that when devving expect exclusive control of postgres. All I have to do is set the bind address for one .1 and the other .2 and all is good.
  - akdev1l 2y ago
    You can literally do the same thing with IPv6. Just assign multiple IPv6 to your loopback interface and everything will work as expected. You can use either private IPv6 or even link-local IPv6 range. There’s no need to waste thousands of addresss on this use case.
    - paulddraper 2y ago
      > waste thousands Yeah would hate to run out
    - o11c 2y ago

otabdeveloper4 2y ago

> Note: no, we could not have done it any other way. Any upgrade strategy to IPv4 that extended the address size would have necessitated having two internets No, this isn't right. Instead of having IPv6 we ended up extending IPv4 by using port numbers as extra address bits and using NAT. This transition was painless (for the most part), and didn't require building a second internet. In a better and saner world we could have got roughly the same thing - except conceptually simpler and standard - instead of IPv6.

ninkendo 2y ago
I think I’d mostly agree with you if only one layer of NAT is in play, but in reality we have CGNAT and it makes it supremely difficult to host services without a very cooperative ISP (laughable.) And there are more internet subscribers in the world than there are IP’s for them, so CGNAT is required for at least some unfortunate part of the population. In reality we just really do need more IP’s. 32-bit addresses with 16 bits of ports isn’t enough.
- otabdeveloper4 2y ago
  > makes it supremely difficult to host services without a very cooperative ISP Sadly, that's a feature, not a bug. Two layers of NAT sucks, but I guess it could have been avoided if a designed (instead of ad-hoc) solution to the problem was devised. > And there are more internet subscribers in the world than there are IP’s for them Is this really true, did somebody actually run the business math? "Internet subscriber" roughly corresponds to "household", not to "person".

dxld 2y ago

Good news: it's 20 years, not 100, at the most :-) https://labs.apnic.net/index.php/2024/10/19/the-ipv6-transition/ https://labs.apnic.net/index.php/2024/10/19/the-ipv6-transit...

mort96 2y ago
You can't just assume linear growth. Your link acknowledges this, and the "prediction" you refer to has the right caveat: "we can look at the time series shown in Figure 1 and ask the question: 'If the growth trend of IPv6 adoption continues at its current rate, how long will it take for every device to be IPv6 capable?'". It's using such a naïve model to illustrate that we're still nowhere close to completing the transition, not to say that we'll be done in 20 years at most as you suggest. Adoption will slow down and my guess is that we'll be stuck with a long tail forever, and only time will tell if that happens at 50% adoption or 90% adoption.
- dxld 2y ago
  I would agree with you were it not for the fact that I'm personally investing my time into a FLOSS project to make sure the growth does not slow down by making “tomorrow NOT like today”, but gets a kick in the butt once we reach the 50% deployment inflection point instead. Stay tuned ;-)
  - mort96 2y ago
    Whatever you're cooking up, I wish you luck! My life would be significantly easier if I could just completely ignore one network protocol, be that v4 or v6. So far I have mostly just ignored v6 and everything I do uses v4, but I have no strong preference (except that v4 addresses fit in my brain while v6 addresses do not, which is honestly a not-insignificant reason why v6 is hard)
    - dxld 2y ago
      Here's to hoping, but I agree one way or another one stack needs to go :-) BTW: Contact info is in my profile if anyone wants the inside scoop. The project just isn't fully ready for public launch yet, but we're well into the cooking.

ademarre 2y ago

ISPs aren't helping either. Ziply Fiber only provides IPv6 with their 10 Gig and up plans, starting at $300/month.

himinlomax 2y ago

The dual stack strategy was criticized 20+ years ago on these grounds, it seemed pretty obvious to me, and as you point out critics were right.

El_RIDO 2y ago

> What is hard, is dual stack networking. Dual stack networking absolutely sucks, [...] Clearly you have gotten some unfortunate hands on experience with those edge cases. In my uses the dual-stacking of IPv4 & IPv6 has been a big benefit in that I have to worry a lot less about locking myself out of systems, as I can always reconnect and correct configuration mistakes on the second stack. Comparing the IPv4+IPv6 dual-stack story to the one from the 90s of IPv4 with IPX/SPX (Novell Netware) and/or NetBIOS (Microsoft Windows), the current state is a lot more smooth and robust. I've so far only run into 3 issues over the years (2013 till now). A local train operator running IPv6 on routers that didn't properly support non-default MTU sizes (fragmented packages getting dropped) and Microsoft where Github is still IPv4-only and Teams recently developed an IPv6-only failure on a single API endpoint. Should we ever turn off IPv4 during my working life-time, I hope we have at that point introduced a successor to IPv6, so I can keep using a dual- or triple-stack solution, using different network protocols for robustness.

redeeman 2y ago

there could have been allocated a prefix to ipv6 that would contain the entire ipv4 space, and then all ISPs could have simply translated between at the edge, which would have made it possible for all normal consumer/company devices to only carry an ipv6 stack

Dagger2 2y ago
"Simply" is doing a lot of heavy lifting there. There are multiple v6 prefixes already allocated for containing the v4 space. It would help if all ISPs ran NAT64 routers on the standard NAT64 prefix, but e.g. how would that function with software that only works with v4 addresses?
- redeeman 2y ago
  it wouldnt, that software would update or get left behind, too bad.
  - Dagger2 2y ago
    Then you're back at having "two internets" again. (Well, I don't agree that it's two Internets, but you'd be stuck with the same situation we have already because people would continue to use v4 in order for that software to continue to work.)
- ta1243 2y ago
  OS would translate the ipv4 address to ipv6 before it leaves the machine. Very rare that software writes its own packet to the network card. On an ipv6 only device if I type "ping 1.1.1.1", I would expect that to be translated by the OS (not the program) to 64:ff9b::1.1.1.1, rather than relying on DNS64 to do it. Then at some point upstream it would go via a nat64 gateway to reach that legacy IP. This should have been in OS stacks 20 years ago.
  - ninkendo 2y ago
    You’re describing 464XLAT, it’s how T-Mobile internet works. iOS, macOS and windows all support what you describe out of the box (although last I checked, Windows inexplicably only does this if the interface is a mobile/5G interface. They may have fixed this.) You can try this on a vanilla macOS install if the router advertisement hints at a NAT64 prefix (RFC8781) and you either don’t run DHCP4, or your DHCP4 server lists the IPv6-preferred option (RFC8925). I think they’ve also added a check to query a well-known ipv4-only hostname on DNS, and if it gets a AAAA back and the connection works, it knows it must be behind a working nat64 setup, which obviates the need for the router advertisement to have the PREF64 option. I tried this a year ago and it worked great, macOS skips DHCPv4 and gives itself a single 192.0.0.1/32 address so that legacy apps can “see” an IPv4 interface, and any packets sent from it are translated to IPv6 and sent to the nat64 prefix. So “ping 1.1.1.1” works fine. I stopped using this though, because I have a garage door opener (ratGDO) that only works with ipv4, and my nat64 prefix can’t “hair-pin” the packet back to the LAN address… it basically only works if everything on your LAN is IPv6, which my garage door is not. I think android supports this as well, but I’m not sure about vanilla Linux, I think you need to install a clat daemon to do the translation. It did take way too long for this to work though, as you point out.

meragrin_ 2y ago

> we're still not even at 50% IPv6 usage Partially due to companies like Metronet whose focus is on growing rather than doing what it should be doing.