15 ms·

Why IPv6 is so complicated

• leonidasrup 6mo ago
  "The IPv6 mess" by DJB https://cr.yp.to/djbdns/ipv6mess.html https://cr.yp.to/djbdns/ipv6mess.html
  • stingraycharles 6mo ago
    How I wish that djb time stamped his articles, as I feel like this article is over a decade old but I can’t tell with certainty.
    • IvyMike 6mo ago
      https://web.archive.org/web/20021203075817/https://cr.yp.to/djbdns/ipv6mess.html https://web.archive.org/web/20021203075817/https://cr.yp.to/...
      • stingraycharles 6mo ago
        Yeah, 24 years old. It’s crazy how little has changed in 24 years, other than most of the major sites now supporting IPv6 (with some notable exceptions, such as AWS and GitHub).
        • Dagger2 6mo ago
          That's because the problems he's describing come from v4 rather than v6, and v4 hasn't changed in a long time.
    • nottorp 6mo ago
      It's not like anything has changed, except the running out of IPv4 part. Edit: or maybe they added 12 more extra configuration protocols to manage, in the name of "ease of use".
    • deleted 6mo ago
      [deleted]
• junofan 6mo ago
  What I don’t understand is why coexistence was so important. TFA notes a lot of protocols were in use back then. Also what’s with all the problems? I’ve had RA packets leak across VLANs via firewall misconfigurations, some my fault and some not. I get that people designing internet protocols had a lot to think about, but why am I fighting stuff like this?
  • Etheryte 6mo ago
    The whole world can't migrate all of their hardware on a whim. There was a period of time when it was a very common quip to say that Amazon would have to buy every new IPv6 compatible router in the world for a year if they wanted to upgrade their infra. I don't know if the urban legend is true or not, but the fact that it sounded plausible is a good enough of an example.
    • Hikikomori 6mo ago
      And packet forwarding was done in hardware pipelines, can't software update them to handle new protocols.
  • eqvinox 6mo ago
    > What I don’t understand is why coexistence was so important. Military, corporate, tech... it isn't. (If your people like flag day migrations. It's… "a choice".) But if you have to explain to an end user why some things work and some don't, you're just f'd. And note "coexistence" here means that an end host can implement IPv4 and IPv6 at the same time, without them interacting at all. Imagine if you had to choose between IPv4 and IPv6 on your devices, maybe something like "you need a 2nd network card". Can you imagine anyone switching to the less popular protocol?
    • deleted 6mo ago
      [deleted]
    • wongarsu 6mo ago
      The article describes coexistence as both dual-stack and connectivity between single-stack IPv6 and single-stack IPv4 host. And that in the autor's opinion all the complexity is in the latter, not in the dual-stack You raise a good point that we also should't take dual- stack for granted. But I think the more precise question 'why not dual-stack as the only coexistence option' also seems like a good one, and one the article does not explore or even acknowledge
• themafia 6mo ago
  > The main reason for IPv6, and its only real reason for existence, was bigger addresses. Which also allowed for better route aggregation in the core BGP tables. Better node mobility support. Better multicast support. Genuine link local addresses. IPv4 had a lot of unfortunate edge cases. I think IPv6's greatest strength and also responsible for it's slow rollout was it's insistence on solving several of these problems at once, along with IPSec as the article notes, and hammering them into the hard requirements for the core stack.
  • foxrider 6mo ago
    And that's what you should do, since you're forcing the protocol update you should take the opportunity that might not come later
    • apple4ever 6mo ago
      In hindsight though, and really also in foresight, it didn't work out that way.
  • ggm 6mo ago
    Didn't happen. The swamp aside, Traffic engineering drives most disaggregation. Better in some senses, but not orders of magnitude better I think.
• ggm 6mo ago
  India on around 80% in the apnic labs active measurement of end users. https://stats.labs.apnic.net/ipv6/in https://stats.labs.apnic.net/ipv6/in They report nearly a billion users, predominantly in mobile. So, "only" 750 to 800 million users. Think about that: 3x the population of the USA using it most of the time, in one economy. Here's the rankings: https://stats.labs.apnic.net/ipv6/XA?o=cINw30x1r1 https://stats.labs.apnic.net/ipv6/XA?o=cINw30x1r1 This is a different measure to Google's. They measure different things,
  • nslsm 6mo ago
    Now compare average income to see how much this matters.
    • ZeWaka 6mo ago
      very transparent.
    • harvey9 6mo ago
      Depends what you are selling and to whom. Meanwhile, India wanted to get a lot of people online and this appears to suit their needs.
    • signa11 6mo ago
      what has _that_ got to do with ipv6 adoption/usage ? afaics, it probably has more to do with large indian-isp’s f.e. jio adopting ipv6.
    • kmacdough 6mo ago
      I'm confused. What's your point? Obviously economies that rely largely on second hand technology are going to have old technology. Much of Africa is in this bucket. But looking past the extremes, India is at nearly 80% right alongside Germany. They fall in very different average income brackets. So the correlation isn't tight. I can't see any value in pointing out vague correlation between income and proliferation of a new technology. It's the most obvious of observations.
    • imtringued 6mo ago
• muppetman 6mo ago
  This annoys me, especially the last “It takes at least 25 years” rhetoric. It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP. GPRS/HSDPA/3G/4G/5G They all rolled out just fine and were pretty backwards and forwards compatible with each other. The whole SLAAC/DHCPv6/RA thing is a total clusterfuck. I’m sure there’s many reasons that’s the case but my god. What does your ISP support? Good luck. We need IPv6 we really do. But it seems to this day the designers of it took everything good/easy/simple and workable about v4 and threw it out. And then are wondering why v6 uptake is so slow. If they’d designed something that was easy to understand, not too hard to implement quickly and easily, and solved a tangible problem it’d have taken off like a rocket ship. Instead they expected humans to parse hex, which no one does, and massive long numbers that aren’t easily memorable. Sure they threw that one clever :: hack in there but it hardly opened it up to easy accessibility. Of course hindsight is easy to moan but the “It’s great what’s the problem?” tone of this article annoys me.
  • SkiFire13 6mo ago
    > Instead they expected humans to parse hex, which no one does Of all aspects of IPv6 you took the only one that doesn't complicate implementations and can easily be swapped if you wanted.
    • rusk 6mo ago
      Wait til you’ve got to copy & paste em, or see em comingled with hw addresses
      • eqvinox 6mo ago
        Wait till you find an application that accepts 1.65793 as an IPv4 address. Or 134744072. $ ping -c 1 1.65793 PING 1.65793 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=54 time=1.56 ms --- 1.65793 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.560/1.560/1.560/0.000 ms (by the way, this was way less of a dumb peculiarity back when IPv6 was designed)
• kristopolous 6mo ago
  if it was easier to use and less of a PITA, it wouldn't be taking decades.
  • 9dev 6mo ago
    If anything, IPv6 is extremely easy to use, especially with SLAAC: On any kind of standard network, you turn on IPv6 on your machine, and, given physical connectivity, bam! You're on the internet. It only gets complex if you try to micro-manage it.
    • nslsm 6mo ago
      So, like ipv4, but you lose the protection and privacy afforded by the NAT?
      • 9dev 6mo ago
        IPv4 requires a DHCP server. It requires assigning a range of addresses that's usually fairly small, and requires manual configuration as soon as you need more than 254 devices on a network. The range must never conflict with any VPN you use. And there's more. Compare to IPv6: Nothing. All of these just go away. And concerning the NAT: That's just another word for firewall, which you still have in your router, which still needs to forward packages, and still can decide to block some of them.
        • deleted 6mo ago
          [deleted]
        • nslsm 6mo ago
          The dhcp server is in the router, just like you need a router for slaac.
        • nobody9999 6mo ago
          >IPv4 requires a DHCP server. Windows[0]: Static IP configuration is as simple as typing an IP address into the pretty dialog box. No DHCP required. Linux[1]: # ip addr <ip4 address> <subnet mask> <device> will set a static IP address >It requires assigning a range of addresses that's usually fairly small, and requires manual configuration as soon as you need more than 254 devices on a network. Is 65,536 (172.16.0.0/16) or 16 million addresses (10.0.0.0/8) "fairly small"? Are DHCP servers unable to parse networks that "big"? >Compare to IPv6: Nothing. All of these just go away. They most certainly do. But they're not "problems" with RFC1918 addressing and aren't "problems" at all with IPv4. There are many issues with IPv4 and the sooner it dies, the better. But the ones you mention aren't issues at all. If you're going to dunk on IPv4, then dunk on it for the actual reasons it needs to go, not made up "problems."
• rawoke083600 6mo ago
  Honestly... Its more machine vocab than human level vocab. Ipv4 is jsut about able still to hold in your head, have a convo or more importantly you can: "Shout an ipv4 across the open office floor from your desk to your tech colleague" If you shout an ipv6 address in public, you jsut seem broken
• smolder 6mo ago
  It's not. I learned how IPv6 worked SO LONG AGO that I really can't understand remaining confusion.
  • mort96 6mo ago
    It's not complicated because you understand it? Okay then
    • smolder 6mo ago
      Not much more complicated than IPv4. There are more bits. The addresses are longer. It's not hard to grasp if you understand the prerequisites to understanding networking in general.
      • orev 6mo ago
        The idea that it’s just “more bits” it’s wrong, so I’m not sure your assessment is valid. Maybe at the packet level it’s just “more bits”, but at the network level a lot of processes changed. IP assignment, router discovery, etc. are different.
        • smolder 6mo ago
          Yes, processes changed. Because you don't need NAT, mainly. Overall it's simpler, with more bits in the addresses.
    • 9dev 6mo ago
      That applies to pretty much any reasonably complex idea. A new system requires effort to understand it. When you've expended that effort, it's not complicated anymore. I don't understand this sentiment—as if learning IPv4 was enough work on your part, and now you're entitled to networking protocols never changing anymore.
      • apelapan 6mo ago
        Just as much as people are not entitled to lack of change, they are not obligated to enjoy, welcome or facilitate change. What I learned about IPv4 at the turn of the century allows me to comfortably plan and manage networks up to a few thousand nodes, maybe a few tens of thousands. I don't work in networking anymore. I really don't care about what those who are in that business. What you need to manage contemporary billion-node size networks and interchange between them is not my problem. You try to make it my problem, but I don't care. I'll continue organizing the very few and very small networks that are still my responsibility using pre-CIDR ideas. Maybe it becomes impossible some day. I'll deal with it then.
• bryden_cruz 6mo ago
  I recently had to set up basic IP-based country detection in Nginx for a project. Parsing and handling IPv4 is trivial. The second I had to account for IPv6 string formats and update the Geo databases to match, the complexity just spiked for no good reason. It feels like we traded address exhaustion for parsing nightmares.
  • threiw 6mo ago
    On one of my linux machines the "localhost:8080" did not work after new installation. It resolves to local ipv6 address, while server only listened on ipv4. After this I go out of my way to disable, remove and nuke ipv6, out of every setup and deployment I do. Ipv6 is already quite complicated, but supporting TWO competing network stacks, with complicated pseudo compatibility, just multiplies unnecessary complexity!
    • eqvinox 6mo ago
      Or, you could've fixed your server's configuration. Probably would've been faster than to "disable, remove and nuke ipv6". In general, the mistake is that it says "0.0.0.0" or "0.0.0.0:8080" somewhere where it should really say "::" or "[::]:8080". (IPv6 sockets by default accept IPv4 connections, unless you disable that either system-wide or on the specific socket.) By the way, I do agree the colon was a really poor choice for separating the blocks, when it is also used to separate the port number.
      • threiw 6mo ago
        I fixed the problem once for all. Now my program even refuses to start, if IPv6 is enabled. I am not going to spend time debugging problem, that can be easily prevented. Pretty valid solution on private networks and local only kubernetes deployments. If customer wants proper ipv6 support, we can sign a contract and talk about it. But do not expect me to support some technology for free, just because it is enabled by default.
        • eqvinox 6mo ago
• eviks 6mo ago
  This is not very substantive, but rather procedural, like this example of an answer doesn't tell you much, but tells you the official paper IDs: > Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in {{RFC3513}} but deprecated by {{RFC4291}} because it turned out to be of no practical use for coexistence or transition. Why/how did it turn out?
  • eqvinox 6mo ago
    > Why/how did it turn out? It is extremely hard (for Brian, but even more so for anyone else, I certainly can't) to give a good answer to that, since you're talking about the absence of utility. People had applications in mind but dismissed them because they either found better ways or it wasn't practical. But that very frequently doesn't result in a "paper trail". (It's a bit like LLMs having problems with negatives/absences.)
  • Dagger2 6mo ago
    Try it and see! 192.168.1.1$ ip link set sit0 up 192.168.1.2$ ip link set sit0 up 192.168.1.2$ ping ::192.168.1.1 64 bytes from ::192.168.1.1: icmp_seq=1 ttl=64 time=0.812 ms (It works over the Internet too, though make sure your firewall doesn't block protocol 41 and that the packet doesn't get NATed.) Notice how this doesn't really help you at all. You still need a functional v4 network, you still need v6 support in the kernel on both sides and your programs still need to support AF_INET6 sockets -- at which point, why not just use ::ffff:192.168.1.1 which sends packets without the tunnelling and doesn't need OS support on the far side, or 192.168.1.1 which works with AF_INET sockets and doesn't need tunnelling or any OS support on either side? This is strictly worse than the former option and less compatible than the second.
• ExoticPearTree 6mo ago
  My first IPv6 implementation was in 2010-2011 (memory a but fuzzy). Carriers supporting BGP over IPv6 were few, websites over IPv6 were also scarce. Fast forward 15 years snd the situation has improved quite dramatically. IPv6 has some quirks that make it harder to digest. - link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space - privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer - multicast instead of broadcast - way too many ways for autoconfiguration (SLAAC, DHCPv6) - no real tentative mapping to what people were used to. Every IPv6 presentation I did had to start with “forget everything you know about IPv4” In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”. Those people love their NAT.
  • hnlmorg 6mo ago
    The nice thing about NAT is it makes the security model easier to reason about. By this, I don’t mean it’s more secure, because I know it isn’t. But it is a lot easier to see and to explain what has access to what. And the problem with enterprise is that 80% of the work is explaining to other people, usually non-technical or pseudo-technical decision makers, why your design is safe. I really do think IPv6 missed a trick by not offering that.
    • gucci-on-fleek 6mo ago
      > The nice thing about NAT [...] I really do think IPv6 missed a trick by not offering that IPv6 supports NAT [0], and nearly all routers make it easy to enable. The primary differences compared to IPv4 is that no-NAT is the default, and that it's more heavily discouraged, but it still works just as well as it does with IPv4. [0]: In the same way that IPv4 "supports" NAT, meaning that the protocol doesn't officially support it, but it's still possible to implement.
      • wongarsu 6mo ago
        But would we have said the same in 1996 or 2000? Part of the adoption curve seems to be that it took years to abandon some of the bad ideas around IPv6 and readopt some of the better ones from IPv4. And a good chunk of the complexity of IPv6 is that some of the early ideas are very persistent, both in some deployed systems and in people's minds
• izacus 6mo ago
  It is like it is because: * It was designed by people who didn't have the full picture and were missing representatives from hardware vendors, small businesses, home network admins and a bunch of other people that will be affected by design. * It was designed by people who didn't consider the cost of migration and the amount of work that would require (see previous point). * It was designed by people who lived in an ivory tower of "noone will run dual stack for a long time", "everyone will love to run two completely separate network designs". * It was designed on a premise that end-to-end, fully accessbile devices are something we actually want and won't cause privacy issues. I think it should be a study material on how standards and designs by commitee can go wrong if they're not headed by people with extensive experience across the industry with enough authority to push for good solutions. IPv6 tried to do too much (just like many software "let's refactor this legact code") and was done by people who didn't consider all perspectives and costs (again, like many less experienced architects trying to rewrite legacy software).
• Paracompact 6mo ago
  > Incidentally, "IPv8" proponents often ask why IPv6 didn't simply stick some extra bits on the front of IPv4 addresses, instead of inventing a whole new format. Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in {{RFC3513}} but deprecated by {{RFC4291}} because it turned out to be of no practical use for coexistence or transition. Any tl;dr on why/how the simplest solution imaginable would have been "of no practical use for coexistence or transition"? Granted, I understand the other points make a strong enough case by themselves.
  • duskwuff 6mo ago
    TL;DR: because it doesn't actually solve anything. Being able to jam an IPv4 address into an IPv6 packet header doesn't mean you can send that packet to an IPv4-only host and have it be understood. You still need an IPv6 stack on both endpoints, and on all the routers in the middle - and at that point, why not just use IPv6 addresses?
    • direwolf20 6mo ago
      Also, it already exists. The IPv4 range is included in the IPv6 range. 0000:0000:0000:0000:0000:ffff:0a00:0001 is the official IPv6 representation of 10.0.0.1. As you can see, it doesn't actually solve anything. It makes some APIs more convenient! You can pass this address to Linux for an IPv6 socket and it will secretly open an IPv4 connection to 10.0.0.1, so your code only has to support IPv6 sockets to support IPv6 and IPv4 connections. It seems I've been rate limited to post every 12 hours, instead of five times per three hours. It must be either because I said interpreters don't emit native instructions, or because I said America had to buy TikTok to maintain American propaganda, or because I said you can make money gambling if your bets are the same as insiders. Or maybe I'm being punished for voting. I don't think dang will ever confirm what the reason was. Hacker News is so intransparent.
• roenxi 6mo ago
  > There was also unnecessary confusion caused by a rather political decision to make IPv6 require support for IP Security (IPsec), which was an immature technology at the time. This was a definite brake on IPv6 deployment until it was dropped after some years. I don't know anything about the IPv6 situation, but the way this paragraph just slots in so innocently foreshadows some long wordy Wayland retrospective document on why adoption was so slow where someone from deep in the community slips in 1 short "sure we tried to block screenshots and that might have caused some issues with adoption for some users" paragraph in the middle-end. The innocence of the admission is so mild and context-free that it somehow manages to make itself look guilty.
• gucci-on-fleek 6mo ago
  In my experience, the IPv6 protocol is much simpler than the IPv4 protocol. However, the IPv6 tooling and documentation is still worse than it is with IPv4, and dual-stack is inherently going to be more complicated than implementing any single protocol, so I do have some sympathy towards "IPv6 is hard". For example, the IPv6 packet structure [0] is much simpler than the IPv4 packet structure [1]; SLAAC [2] is much simpler than DHCPv4 [3]; IPv6 multicast [4] is much simpler than IGMP [5]; IPv6's lack of NAT simplifies peer-to-peer networking compared to IPv4; ULAs [6] prevent the annoying address conflicts you get with IPv4 [7]; etc. [0]: https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header [1]: https://en.wikipedia.org/wiki/IPv4#Packet_structure https://en.wikipedia.org/wiki/IPv4#Packet_structure [2]: https://en.wikipedia.org/wiki/IPv6_address#Stateless_address_autoconfiguration_(SLAAC) https://en.wikipedia.org/wiki/IPv6_address#Stateless_address... [3]: https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Pro... [4]: https://en.wikipedia.org/wiki/IPv6#Multicasting https://en.wikipedia.org/wiki/IPv6#Multicasting [5]: https://en.wikipedia.org/wiki/Internet_Group_Management_Protocol https://en.wikipedia.org/wiki/Internet_Group_Management_Prot... [6]: https://en.wikipedia.org/wiki/Unique_local_address https://en.wikipedia.org/wiki/Unique_local_address [7]: https://stackoverflow.com/a/52374482/30512871 https://stackoverflow.com/a/52374482/30512871
  • j16sdiz 6mo ago
    ULA give more trouble than what it solves. Almost all computer have multiple interface (virtual or not). Application now need to know which interface the destination is on, and there is no easy data structure to store the interface
    • eqvinox 6mo ago
      You're confusing ULAs (Unique Local Addresses) with LLAs (Link-Local Addresses). (ULAs don't need the interface specified.) ULA: fc..:… and fd..:… LLA: fe80:… [ed.: By the way, sin6_scope_id is where the interface identifier is stored in struct sockaddr_in6. So, basically every single IPv6 address object you're handling has the field for it.]
    • 6mo ago
• peanut-walrus 6mo ago
  I've always found the most complicated part of IPv6 to be address scopes and source address selection. The fact that one interface can have any number of addresses in different scopes and prefixes complicates things a lot. Another thing that will always trip up new IPv6 network engineers is solicited-node multicast. You know the theory, computers talk to ff02::1 for neighbor discovery and then you hop onto a real network and see none of that actually happening. And probably the most complicated thing for network engineers - how to set up firewall rules if machines are constantly changing their addresses. For developers and security people - just parsing and validating v6 addresses is a whole bunch more work, but at least for this, the tools are available to help you now.
  • bewo001 6mo ago
    An interface can have many ipv4 addresses as well. It's just not that common, so many people believe they'd need vlans to achieve that.
    • peanut-walrus 6mo ago
      Yes. But it's quite an uncommon setup. For IPv6 multiple addresses is the default.
• wongarsu 6mo ago
  A lot of it seems to boil down to "IPv6 was too early". Had IPv6 been developed a couple years later DHCP would have been mature, and SLAAC would have never been invented (since DHCPv6 is fairly obvious when you have good experiences with DHCP). Also it would have given all the alternative protocols (especially OSI) time to try (and likely fail) to gain traction, freeing IPv6 from the obligation to cram in all of their features. IPv6 could have picked a much smaller set of features that were proven useful by other protocols, then swoop in as the much simpler upgrade from IPv4 than any of the competitors
  • grandinj 6mo ago
    A couple of years later ipv6 became unnecessary. A big driver for ipv6 at the time was routers not being able to manage the increasing size of the core routingtable. Then 2 years later betterhardware and routing table compression became available and ipv6 became unnecessary.
    • Dagger2 6mo ago
      Uh, no it didn't? Routing table size is still something of a problem, especially as v4 continues to fragment more and more, but also the main driver was insufficient IP addresses in v4 and that problem hasn't even slightly gone away.
      • grandinj 6mo ago
        I was there, reading the ipv6 mailing list eagerly. Address space exhaustion was a smaller problem because NAT was pretty primitive, so called carrier grade NAT was not even a thing yet. But cisco had the largest routers and their biggest was not big enough for the core router fabrics projected growth. And there was not enough demand (yet) for very large routers fir cisco to want to design and build the nevessary chips. The IPv6 people thought they held all the cards and could mandate whatever they wanted. But of course, it was s very long time ago and my memory may be inexact.
        • Dagger2 6mo ago
• wongabu 6mo ago
  There is no working solution to ipv6 dual WAN failover, 30 years later... A critical design flaw that was simply ignored by the designers despite being used in almost any SME network. inb4 no you can't have all lan devices have multiple ipv6 addresses and choose for themselves, typically 1 WAN is cheap and the second WAN is expensive/slow and should be used only for WAN1 failover Inb4 no you can't just advertise new RA, devices on lan can takes minutes to update. On ipv4, NAT+changing route on router just works, 1-2 seconds failover.
  • mrsssnake 6mo ago
    IPv4 has exact same problem, the NAT is working here because devices does not actually have proper Internet connection, all connections are terminated on NAT and reassembled after. Actual solution could be extending TCP and UDP or make a new transport layer procotol that handles changing addresses, similar to what QUIC do. But we cannot do it exactly because things like NATs existing, thus QUIC build was build on ossificated UDP. Imagine if instead of IP+port a connection use unique per-connection hash to persist IP addreses changing. No more trying fighting to keep the IP the same.
    • wongabu 6mo ago
      Ipv4 does NOT have this problem. The typical setup is always NAT for ipv4 lan, so external address can be changed with minimal disruption. All ipv4 apps that require hole punching assume they will need to "discover" the external address anyways, for every new p2p connection. In contrast to the vast majority of ipv6 apps which assume their ipv6 address is identical to external ipv6 address, as this is(was) the main marketing point of ipv6 - directly addressable end points.
      • icedchai 6mo ago
        "Directly addressable endpoints" is how the Internet is supposed to work. It's how it did work for anyone who grew up with the 90's Internet. NAT is a hack that let us get 30+ more years out of IPv4, nothing more. Sadly, we now have a generation of engineers who thinks NAT is normal.
• montag 6mo ago
  My problem with IPv6 is that I can't double click 2001:db8::1428:57ab to select the entire address. It's a silly complaint but representative of real ergonomic issues.
  • p1mrx 6mo ago
    It would be pretty straightforward to change the text selection rule, so that double-clicking anything matching the syntax of an IPv6 address selects the whole address. The hard part is to find all the places to repeat that change, and convince the code owners to accept it. Probably start with a standard analogous to RFC 5952?
    • zbentley 6mo ago
      This is a great idea. To slightly sidetrack things: I think updating computer UI text selection behavior to not break click/snap-to-next selectable words on colons without padding spaces in general would be a good thing. "A: B" would still click-select either "A:" or "B", but "1:2" (a ratio) would select the whole thing, as would "small:med:large" or an ipv6 address. In other words, I think that, in practice, English writing has assigned semantic significance to space-less colons in enough cases that text selection systems should reflect that. Though I'm not sure RFCs are going to drive general GUI behavior--they won't "MUST" it, because that's overstepping, and I'm not sure GUI/OS-text-selection-functionality maintainers will be persuaded otherwise.
  • tsoukase 6mo ago
    This is the most pro-IPv6 comment I could ever imagine. I am more persuaded now than by the IPv6-is-easy guys all these years.
  • petee 6mo ago
    Fwiw opera mobile on Android selects the whole address there when i long-press
• rao-v 6mo ago
  At a high level one of the sad things about IPv6 is that it surrenders a wierd, valuable and emergent property of IPv4 for the average home user in $random_country: IPv4 addresses in logs are not super helpful in tracking a specific person and household’s behavior long term (NAT, reuse etc.) Almost every end user oriented IPv6 deployment makes it significantly easier to use IPv6 addresses to persistently track individual machines (ie individual people) and map them to a household (yes I’m aware of RFCs 7217 and 8981, I’m mostly talking about long term stable prefixes). How much of a real concern this is is debatable but it’s perhaps a little bit unfortunate.
  • doubled112 6mo ago
    At home, my external IPv4 address was the same for extended periods of time even though I never paid for a static IP. You could have figured the traffic was coming from the same location. The one external IP to many internal devices relationship does help with privacy. But once you enable those IPv6 privacy extensions, I have so many devices bouncing between IPs I’m not sure how you’d even know how many devices I have, let alone which device is which.
    • rao-v 6mo ago
      My experience is that this is largely true only of the biggest ISPs in the US and Europe that were around in the 90s and have IPv4 in plenty. In other countries or even with other ISPs I see fairly frequent turnover. Agree it’s not the biggest deal but it is a pity and something the protocol stack around IPv6 should support (daily/weekly randomizing of prefix unless someone needs the stability). The vast majority of modern devices and usecases get no additional value from being stably addressable from the internet.
• RiverCrochet 6mo ago
  Most of the bitching about IPv6 is from those who really, really want IP addresses to identify machines or users. IP addresses (including IPv4) were never intended to do that and it was never a good idea to put them in that position. There was a time when most devices had 1 network interface and didn't move. But that was never a guarantee. People thought it was a guarantee when your $400-in-1988-dollars Madge ISA full-height full-width token-ring NICs with dangling AUI dongles next to your tank of an ST225 hard drive were a thing, but we're past that. Today most things that aren't servers have at least 2 - wired/Wi-Fi for laptops, Wi-Fi/cellular for phones. You can talk about NAT and security and mapping all you want, but if I can bypass your corporate internal network security simply by turning off my phone's Wi-Fi, yet still get to your resources - then NAT is a legacy chore that IPv6 makes unnecessary.
  • menotyou 6mo ago
    My IPS changes my prefix once in while. I consider this a privacy feature, not a bug. Now I find myself in a situation that my devices are not reachable anymore as when the IPv6 address changes and both DNS entries and firewall need to be updated each time when the prefix changed (In between connections break, but this might be a lesser problem) As far as I understand the only solution which does not include some complex scripting of ip change detection and automatically updating the firewall rules is to use NAT66 and ULA. But even then I have a protocol whose most advertised feature is not to rely on NAT and puts mit fast in a situation in need to use NAT. And the privacy extension of every device or the devices using SLAC and not DHCPv6 are problematic. IPv6 is just not able to steup efficiently for where IP addresses are changing. Not with moving mobile devices, not in wifi environments with multiple access points, not with changing prefixes, not in failover scenarios. Bottom Line: I disabled IPv6 again here without any intentions to look for complex workarounds. All outbound traffic is now IPv4 again. IPv6 is providing no benefit but causes additional problems over IPv4 due to issues with the design. I am waiting for IPv7 (or whatever will be the next successor of IPv4) will arrive.
    • Dagger2 6mo ago
      Are you talking about reaching the devices from inside the network, or outside? If inside then you don't need NAT66 and ULA, you just need ULA. Use both ULA and the ISP GUAs on the network, and do your internal connections over ULA. If outside, then NAT66+ULA doesn't help because connections from outside will still fail until you update DNS for the new prefix. NAT66 doesn't help in either situation, so why do you think you need to use it here? > automatically updating the firewall rules You can probably structure your firewall rules to not rely on the prefix, e.g. by doing "connections from WAN to LAN where the address matches ::42/-64" -- you might to write it with a mask instead (::42/::ffff:ffff:ffff:ffff), which looks awful but works fine. There's no point in putting a specific prefix into the rule if you're just going to change it to match the network anyway.
• ksec 6mo ago
  >Getting IPv6 to about 50% deployment has taken more than 25 years. Any alternative or new proposal would be the same. That is oversimplified a few things. The 50% deployment is largely Mobile Phone + Cloudflare and India. ( Not sure about China ). Outside of that things aren't that different from a high level overview. You could have 50% deployment in less than 10 years if 6G Mobile Phone mandate the use of let say IPv8.
• jordiburgos 6mo ago
  I would be easier to accept if it was just an extension of IPv4. Make the addresses longer but keep the types A,B,C,D. Keep the network address x.x.x.x/y. That way everybody will be familiar with it and change will be done smoothly.
  • tiberious726 6mo ago
    It basically did, just in hex...
• vaylian 6mo ago
  The headline is not confirmed in the text: > First of all, IPv6 really is a conservative design - it doesn't change the basic IP model of connectionless packet switching with topological addresses.
• api 6mo ago
  It’s not. It’s IPv4 with more bits and some changes to Ethernet level lookup. The SLAAC vs DHCPv6 mess is not really a problem with the core V6 spec.
  • ninkendo 6mo ago
    The changes to Ethernet lookup mandate that you have a link-local address in addition to your “real” address, and this starts the ball rolling on the idea that machines have multiple IP addresses in general. Which makes privacy addresses commonplace, ULA+GUA addresses on the same machine, etc. I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily predict what address will be used when connecting somewhere. IP-based access control becomes impossible (not that it was ever a great idea in the first place), reverse DNS lookups become irrelevant, seeing IP’s in logs no longer tells you “what machine connected here”, it’s overall a big change in mental model. But then you get over it, stop making assumptions that you can rely on IP addresses for knowing things about a host, and the rest of it is fine.
    • doctorpangloss 6mo ago
      > I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, a little over half the bytes of a typical IPv6 visitor's address is comparable in identification to what all four bytes of an IPv4 address tells you
      • ninkendo 6mo ago
        I'm not necessarily talking about fingerprinting or tracking here, it can be something a lot more mundane. Like if I have a homelab setup and I want to see what hosts connected to something, and I look at the logs and see privacy addresses, I know I'll never know what host it was. Or if I want to set up netgroups for access control to shares or something (just a hypothetical.) In the classic sysadmin world, the idea that an IP you see could belong to any host and you have practically zero way of knowing, is rather different from what we expect in the IPv4 world. You just have to embrace it, basically.
• evilmonkey19 6mo ago
  Personally, i feel it is complicated because ISPs are highly afraid of trying it. I understand that such novel technology would be risky to use. But after 20+ years there are still many countries, like Spain, which are barely using it. After that much time has passed, it is already well battle-tested. At this point, you don't want to make the move either because you are too afraid of anything or you have commercial reasons. I believe Telefonica has reasons to not use IPv6... Although in the long run is turning to be a bad decision. Look at digi :p
  • api 6mo ago
    IT and telecom tend to have an ultra conservative if it’s not broke don’t fix it attitude. It won’t get deployed until enough customers ask for it or it’s required for something important.
    • izacus 6mo ago
      That's because they actually get paid for providing a reliable service, not for ipv6.
      • tardedmeme 6mo ago
        Access to only half the internet isn't exactly a reliable service. None of china, none of africa, only half of europe, none of south america....
        • zadikian 6mo ago
          Those are regions that have a lot of v6 support alongside v4, not v6-only.
          • tardedmeme 6mo ago
            Most v4 support is through a gateway. You can't tell the user's IP address from the wrong side of the gateway, for example - only the gateway's address. The user isn't on v4, the gateway is.
• djha-skin 6mo ago
  Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is. For this reason, at every shop I've ever worked at, the intranet is ipv4, often with ipv6 disabled, with dual stack on the load balancer for ingress traffic. Note, I do not set it up that way: it comes like that when I've arrived.
  • josephcsible 6mo ago
    You can do NAT on IPv6. I've personally done so with both ip6tables and pf.
  • Galanwe 6mo ago
    Its not just NAT, it's also DHCP. Somehow the nerds creating IPv6 decided to not only add bytes (which is what people wanted), but also "fix" DHCP and NAT, which nobody asked for.
    • simoncion 6mo ago
      > Its not just NAT, it's also DHCP. I'm not sure what you mean by "fix" DHCP and NAT, but FYI: RFC 3315 was published in 2003. As far as NAT goes, it looks like iptables added IPv6 support to the MASQUERADE, SNAT, and DNAT targets in kernel version 3.7, released in 2012. IDK when other OSs added such support.
      • Galanwe 6mo ago
        > I'm not sure what you mean by "fix" DHCP SLAAC was part of IPv6 since the original RFC, its a horribly over engineered stateless replacement of DHCP. Nobody asked for that.
        • simoncion 6mo ago
• seanalltogether 6mo ago
  personally I just hate this -> http://[0123::4567]:5000/whatever
  • zhdc1 6mo ago
    This. It’s ugly. All of talk about the technical merits or demerits misses the point. I can spout of a dozen or more memorized IPv4 addresses. IPv6? Good luck.
    • simoncion 6mo ago
      There's nothing stopping you from using memorable ULA prefixes on your LAN [0] and requiring the use of DHCPv6 for addressing so that each host gets a host part that is easy to remember. Hand-selecting your ULA prefix abandons the collision-resistance that you get from using The Technique to generate one, but if that's something you don't care about, then it's something you don't care about. Plus, manual address assignment is just as viable in an IPv6 world as it is in IPv4. [0] fd00::/64 is quite easy to remember, as are fd00::1 and similar.
      • bombela 6mo ago
        Another option for simplicity in dual stack is to assign visually similar addresses: - ipv4: 192.168.0.42 - ipv6: prefix:192:168:0:42 I only do this for static/server machines, configuring Linux with a fixed ipv4, and append the fixed ipv6 host to the Router Advertisement prefix.
        • simoncion 6mo ago
          If I hadn't put my long-running machines' -er- ULA-derived [0] SLAAC addresses into my local DNS ages ago, I'd either do exactly that, or slice off the "redundant" parts of the IPv4 address off, so that I could choose to assign sixteen additional bits of addresses to each host. That is: - ipv6: prefix:192:168:0:42 would become - ipv6: prefix::0:42:[0-ffff] [0] I'm really not sure how to succinctly say "The autonomously-configured addresses on my LAN's ULA prefix".
• hackthemack 6mo ago
  I think this is the kind of the topic that can be endlessly debated because you can not easily go back in time and test out alternate hypothesis. I will say that I do not like ipv6 because it tried to fix multiple accumulated problems. I know! How contrarian! How can you be against trying to fix things. But all of those issues made ipv6 a dual stack solution that replaced ipv4. Address exhaustion, Routing table scalability, restore end to end routability, autoconfiguration, header simplification, mulitcast + anycast, security standardization. Whereas, I think a lot of those things could have been solved in other ways, or more slowly. I would have preferred a ipv4.2 64 style because it would have prioritized Address exhaustion, keeping backward operational compatibility, fewer changes to institutional knowledge, and still had incremental rollout (that I think would have occurred much more quickly than ipv6).
  • Plasmoid 6mo ago
    > keeping backward operational compatibility It is not possible to be backwards compatibility with a larger address space
    • sethops1 6mo ago
      And yet 50% of the internet is using CGNAT just fine. The extra bits are just in a different place.
      • johncolanduoni 6mo ago
        Yes, but CGNAT is an inherently stateful system and as a result will always be more expensive to operate per packet than a stateless router. The reason we are seeing steady (if slow) growth in native IPv6 is because the workarounds for IPv4 exhaustion cost money, and eventually upgrading equipment and putting pressure on website operators to support IPv6 becomes cheaper than growing CGNAT capacity.
    • hackthemack 6mo ago
      You are right that a 32 bit ipv4 stack can not understand a 64 bit packet format. The thing I am trying to get at is not native compatibility, it is operational compatibility via translation. I know, I know, you will probably say that is what ipv6 bridges do. But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow translation at network boundaries and let old systems continue to operate unchanged. Then the routers and systems would be upgraded incrementally. I think that is why it would have been upgraded more quickly.
• bell-cot 6mo ago
  Short answer: Too many cooks in the kitchen, and too many of 'em motivated to make it more complicated. A computer standard that is still widely avoided almost 30 years after it became official is a computer standard that should have been tossed in the bin before the ink was dry.
  • tardedmeme 6mo ago
    no it's just wrong. V6 isn't complicated. It's V4 with longer addresses and a slightly different field layout.
• amelius 6mo ago
  > Just adding bits to the address isn't as simple as it seems. They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine.
  • Dylan16807 6mo ago
    You can add bits to your own systems fine. When you want your packets to work on other people's routers, it stops being fine.
    • amelius 6mo ago
      If that means those other people cannot reach the internet, then I'm sure those people will fix that faster than anything ever fixed before.
      • Dylan16807 6mo ago
        No, it means you can't reach the Internet. Or it means a ton of people can't connect to you because of your netcode preferences, and that makes your boss very upset. It'll get fixed extremely fast, and fixed means turning IPv4 back on.
      • tardedmeme 6mo ago
        that's literally the exact situation with ipv6
        • amelius 6mo ago
          Except those people just use ipv4 instead.
          • tardedmeme 6mo ago
            so your solution is "let's do exactly the same as ipv6 but change the number and also force people to use it"?
  • 6mo ago
• zadikian 6mo ago
  I disagree that it would've been just as hard anyway. The people who say "I just wanted v4 with more bits" have a point that most of these arguments completely ignore, but this one touches on it: Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition. The practical use would've been going all-in on those, making it as easy as possible for users to switch. But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT, and 6to4 was bolted on in a way that never worked very well. The thing is, their objective wasn't just to add more bits, it was to defrag the old v4 routes. If you did it the "just add more bits" way, once everyone is on v6 but with the old v4 /32s, the new address space for sale is underneath those. Maybe there'd be a way to defrag afterwards in a separate effort.
  • Dylan16807 6mo ago
    Going all-in in what way? The only thing I can think of is making it easier to run your local network v6-only. But if you're translating at the router like that, you don't need any particular mappings.
    • zadikian 6mo ago
      I've clarified under another comment what I meant by that
  • johncolanduoni 6mo ago
    How would this have worked in practice, in a way that the NAT464/NAT64 schemes that most mobile operators use haven’t? Would IANA have dedicated some blocks of IPv4 to be used for IPv4-compatible IPv6 addresses on the public internet?
    • zadikian 6mo ago
      Copy-paste the v4 blocks into v6 space under a common prefix, let's say 4::. Routers and software add ipv6 support (as they already have), but you only use 4::. Now once a user wants to switch, it looks the same. I'm still on NAT and DHCP. If I'm hitting Google.com on ipv6, I still use DNS4 and get 142.251.214.110, it actually sends to 4::142.251.214.110 takes the exact same route. Time has to pass for all users to switch to v6. DNS6 and DHCP6 are in-place upgrades to the existing ones, not alternatives, so now they support longer fields. Once that's done, Google.com can say hey actually we're 142.251.214.110.1 now, and probably my ISP also gives me x.x.x.x.1.1 and leases x.x.x.x.2.2 to someone else. You can also do all the above without the 4:: prefix. The point of that was to keep the possibility of offering all-new routes under the other v6 /8s, but that has its own friction.
• speedgoose 6mo ago
  I installed a new bare metal server from a european cloud provider this week. Both my clean Debian and the rescue system couldn’t reach internet through IPv6 despite getting an address through DHCP. I immediately permanently disabled IPV6. I usually do that pretty late in my installation scripts anyway. I understand the perfect solution didn’t exist and still doesn’t exist, but it’s frustrating. I wish IPv6 could work reliably, not only on major CDNs, and that is appreciated. Then IPv4 would be a vanishing memory.
  • MaKey 6mo ago
    You could have spent a bit of time on debugging the issue. This would have been a great learning opportunity.
    • Hackbraten 6mo ago
      It's supposed to Just Work on clean and rescue systems. Otherwise, it's a regression with respect to v4. The fact that it doesn't work is evidence that someone has been doing something wrong. The user at the receiving end of this clusterfuck is not that someone.
    • speedgoose 6mo ago
      I agree, but debugging IPv6 issues is pretty far down on the list of things I want to learn.
      • MaKey 6mo ago
        Which european cloud provider is it?
        • speedgoose 6mo ago
          The latest dedibox from Scaleway.
          • miyuru 6mo ago
• ajb 6mo ago
  The problems of IPv6 deployment are ones of incentives, not design. Increasingly, the vast majority of services are accessed via the service cone of various CDNs and IAAS providers directly at edge servers local to them, and at some point it may be that the industry decides that it's not worth providing ordinary internet users the ability to talk to each other directly at all. At which point, we might just as well have stuck with IPv4. I don't particularly like that outcome, but it's possible.
  • t43562 6mo ago
    I think they worked that out long ago - that segmenting users has no downside for them and IPv6 has minor upside. It's only mobile devices that help us but I'm sure there will be kinks in the chain that don't get fixed.
• tonymet 6mo ago
  > Any address length greater than 32 would create all the coexistence and transition problems we have experienced since 1994 This is the author’s assumption and not a conclusion. Why did the other designers even bother if this was the case?
  • tardedmeme 6mo ago
    Because they didn't realize how that was the fundamental problem. There are some designers who knew their system would be incompatible but thought it was interesting enough to design anyway, like RINA. There are other designers who just didn't realize why this was a problem, like ipv8. The ipv8 designer is currently berating the NANOG (north america network operators group) mailing list for not already supporting ipv8 on all networks. If it's compatible then why do they need to do anything to add support, eh? People get emotionally attached to the name "IPv6" being bad, and don't realize how putting the same stuff in a different protocol makes that one just as bad, but without the 30 year head start. If a new proposal is about the same as IPv6 but isn't already supported by most equipment, then wouldn't it be better to use IPv6 instead?
    • tonymet 6mo ago
      some of the alternatives were simpler and deliberate attempts to reduce the scope of the migration problem. You can’t say “all approaches would have suffered the same migration effort” as if it’s a given. That’s like saying UTF8 and UTF16 had the same migration effort because they both tried to migrate from 1-byte code points. UTF8 was way easier.
      • zadikian 6mo ago
        Yeah and UTF-8 shouldn't be taken for granted. I always wondered why there's still UTF-16 in so many places, even Swift strings (apparently changed in v5)... It's cause that was the natural replacement for UCS-2, which for certain reasons was beating UTF-8 early-on.
• dreamcompiler 6mo ago
  I almost wish NAT had never been invented. It's a kludge that effectively added 16 bits to the IPv4 address space and delayed IPv6 as a result.
  • thayne 6mo ago
    And it added those 16 bits in a way that causes a lot of problems
  • PaulKeeble 6mo ago
    CGNat even more so because its added ~16 more bits and taken away full functioning connections form the ISP customers to do it.
  • zadikian 6mo ago
    If/when everyone is forced to leave ipv4 due to address+port exhaustion, it's possible that ipv6 isn't the replacement.
• t43562 6mo ago
  I think we've been shunted into an alternate universe by NAT - one which reinforces the power of large companies because we essentially cannot communicate computer to computer without going through some service. As for security.........are we really that secure running code in our browsers that we downloaded from who knows where? Is nat really saving us? And now here we are with IPv6 and the real age of the network could begin.
  • tardedmeme 6mo ago
    Odd that all these pro ipv6 top level comments are greyed out.
    • t43562 6mo ago
      Well, there's some food for paranoia :-D.
• sylware 6mo ago
  Core IPv6 is not.
• Fabricio20 6mo ago
  Personal experience that I see noone talk about with IPv6 is how much more expensive hardware that handles it correctly is for datacenters. On IPv4 your usual unit of allocation is a /32 for customers - that means a simple hashmap `1.1.1.1=destination mac` works wonderfully and is cheap (single memory lookup), but for ipv6 your usual unit is a /64 so its longest prefix match instead, which requires parsing the address to group it back into the /64 and alot of switches and routers that are already expensive still have very low limits on LPM memory banks. Expensive switch at work we have can only do 3000 route entries for example on ipv6. If we did /128s it's basically infinite though, because it goes from a LPM to exact match, which has much much more memory available. Doesn't help as well that for example, to be able to do SLAAC or even DHCPv6 (which barely works reliably in my experience) you need to do a /64 at minimum, those mechanisms dont even work otherwise, so for ISPs who can easily have more than 3000 downstream customers doing routed ipv6 is such an increase in hardware cost vs just doing NAT which they were already doing anyway.
  • kstrauser 6mo ago
    Why on earth would you ever want to route something smaller than a /64? At the ISP level, you'd only be concerned about your customers' /48 or maybe /56 networks.
    • simfree 6mo ago
      OP seems to want to route /64 or larger to each customer, but can only have 3000 total entries larger than /128 in the expensive routers his firm owns. Essentially the hardware doesn't support scaling a /64 or /56 to each customer, leaving OP in a terrible position when it comes to proper IPv6 deployment. When you look at Ziply Fiber, they seem to be ripping out these types of Enterprise grade routers left and right in favor of a simple Linux box doing routing. I think a large portion of why they're doing this is due to limitations like what OP is experiencing
    • Fabricio20 6mo ago
      Both of which are LPM and cause the issue I just mentioned! It's not about "routing lower than a /64" its about LPM vs Exact Match memory bank usage (and for some reason, how much more expensive good hardware that handles LPM is).
• torginus 6mo ago
  My personal opinion of having worked with all layers of networking for my job without developing a comprehensive understanding, is this: We as consumers see and use the highest level, which is often https or friends, and due to the layered nature of the OSI stack, as often happens in software, if a layer is lacking in something, it gets fixed 1 or 2 layers up. If then said thing is then implemented on the layer its supposed to, its often unwelcome and just causes issues. TCP/IP has already acknowledged this (haha) by offering UDP, on top of which you can build the network protocol of your dreams. And people have. It's called QUIC or HTTP3. It does everything one could ask of a network protocol, with QoS, NAT punchthrough, packet based low latency/overhead comms, etc. etc. And QUIC doesn't assume any sort of advanced mechanisms beneath, it works happily with IPv4. And once you have everything figured out for you on the level you like to work, there's not really a need for the lower layers to pick up the slack, as long as they work reliably.
  • torginus 6mo ago
    I wish people actually put some thought into responding as opposed to just hitting the downvote button
    • yencabulator 6mo ago
      You are being downvoted because nothing you said seems to have anything to do with IPv6. It seems you think as long as it's not your problem, it's solved?
      • torginus 6mo ago
        I feel like it's an entirely reasonable stance. The two valid approaches to solving a technical problem is either you try to solve all of it so that no one is concerned by it any more, or you solve as little of it as possible, but solve that part well, so there's a clear line on what's your job and what is not. IP as a concept of 'digital PO box' falls short even if we upgrade to IPv6 - imagine talking to someone via voicechat on your phone, and moving from home Wifi to mobile data. They are two separate HW interfaces with their own identities and networking stacks, so moving your connection has to bypass the IP layer even on IPv6. On the other hand if your job description is to shuttle packets between 'A' and 'B', where neither is guaranteed to be the actual sender or receiver, IP address becomes an implementation detail, and doing you job on IPv4 is much simpler, with the rube-goldberg stuff of actually figuring out how to connect the actual sender and recipient falling to higher level protocols. So while I don't have strong feelings on the topic, this movement feels like a management reorg, where some business units get shuffled around, priorities change, but ultimately there's very little consistent motive or goal to the whole thing.
• arjie 6mo ago
  I have a /56 at the datacenter and Google Fiber gives me something like a /64 or something so I have full IPv6 connectivity everywhere. For the most part this is fine, but I've noticed the Internet is 'less reliable' on IPv6 and so in my head I still feel like it's a little iffy. There are times where a AAAA record points to an IP that doesn't respond, but the A record responds and so on. I just think it's the same as my blog's Gemini protocol server. I don't use it and offer it for fun but it's a best-effort basis. If it went down for months I wouldn't notice.
  • hackeraccount 6mo ago
    Man a /56 is not as big as you think. I'm an IPv6 neophyte but I'm starting to think about /64's the way I think I think about IPv4 /24's but 802.11 /24's y'know? So Google Fiber giving a you a /64 is the same as saying - would you run your home network on a single /24. I mean ... you could but it feel like saying could you have one pair of shoes. XFinitity gives me a /60 and honestly I feel unhappy about it. At my modestly sized job site we're easily using a couple 100 /24's - and I'm not in network operations so that number is probably wrong.
  • hackeraccount 6mo ago
    Just for fun and bitterness I checked on Google Fiber. "Google Fiber generally hands out a /56 IPv6 prefix delegation to residential customers, which allows for 256 subnets of \64's) each." Totally confused as to why XFinity only gives me a /60. I think it's a benefit for people who get the business class - that is a /56.
  • miyuru 6mo ago
    > There are times where a AAAA record points to an IP that doesn't respond, but the A record responds and so on > If it went down for months I wouldn't notice. you are not alone. I am building a service to monitor such events. usual up-time monitors mostly checks the v4 address. https://v6monitor.com/tools/ipv6-check https://v6monitor.com/tools/ipv6-check
• imoverclocked 6mo ago
  Despite the article title, IPv6 is not the complication. The problem is that IPv4 is incumbent and IPv6 has to live along side of it. It doesn’t matter how it’s done, the dual stack nature of expanding the addressing system will always exist.
  • tardedmeme 6mo ago
    this is why people keep inventing nonsense like ipv8 which is worse than ipv6 in every possible way but they think because ipv6 has problems and ipv8 isn't ipv6, ipv8 doesn't have exactly the same problems.
  • hackeraccount 6mo ago
    Dual stack isn't a terrible experience it's just usually bad. I wonder if more effort should have been put into making dual stack good instead of making IPv6 good? Would that have been possible? No clue but my instinct is that most design decisions are trade offs and if you can imagine a trade there's someone out there clever enough to make it happen.
    • imoverclocked 6mo ago
      IMHO, the worst thing about dual-stack is that you have to do it at all. There are translation mechanisms but that doesn’t help when you have local devices (maybe IoT?) that don’t support IPv6.
      • jcgl 6mo ago
        I think that's why this new IPv6-Mostly stuff is so exciting. You can dual stack a network segment if some of those v4-only devices exist there, but IPv6-Mostly will make sure that the other devices stay on v6 (translated or native).
• everdrive 6mo ago
  This is the only topic that tempts me to create a throwaway account. (I have not given in) None of the IPv6 proponents are willing to acknowledge that IPv6 is a pain. All of them seem to have gone to some secret seminar somewhere where they receive their talking points: - Everyone who dislikes IPv6 doesn't know how NAT works and thinks it's the same as a firewall. - There's absolutely no downside whatsoever to being publicly addressable. (also this is a good time to reiterate that NO ONE understands that NAT is not a firewall) - 128 bit addresses are exactly as convenient and memorable as as 32-bit addresses. - The entire internet would be hosting home servers if not for the evils of NAT.
  • PunchyHamster 6mo ago
    You forgot important thing: There will always be some security guy yelling that leaking your internal IP structure is bad. There will also be another clown that does IP whitelisting as security measure and refuses to just whitelist single /64|/24 network "because it is too wide" (I literally had this conversation last week with one of the clients) > - The entire internet would be hosting home servers if not for the evils of NAT. ISPs will find a way to fuck up
    • adrithmetiqa 6mo ago
      It would have been a success if they just called it ipv5.
  • ahoka 6mo ago
    IPv6 is classic second system effect.
    • tardedmeme 6mo ago
      [flagged]
      • Ekaros 6mo ago
        I think if they just double the address length the people would still cry about how 111.211.234.231.189.243.253.100 too hard to write and remember... There is no helping with people.
• bborud 6mo ago
  Why are we, in 2026, still talking about ipv6? It is time to give it up and start over. Yes, it is unlikely we can agree on an ipv4 successor. But at this point we should be able to agree ipv6 is not going to be it.
  • msla 6mo ago
    For the same reason we, in 2026, are still talking about Java.
    • zadikian 6mo ago
      Java bent a lot to accommodate. There are lambdas and records which violate the old OOP rules, and now virtual threads which were sorely missing for things like web backends.
  • tardedmeme 6mo ago
    What do you think should be done instead? If ipv4 but with longer addresses (which is called ipv6) is not to your satisfaction, what would be? You want to completely overhaul the internet like in ipv8 and you think ipv8 doesn't have the exact same problems and thousands more just because it's never been deployed and nobody's encountered them yet?
    • bborud 6mo ago
      You appear to not understand my argument. IPv6 is over 30 years old. The world has not embraced it. It isn’t going to. It is time to call it and try to figure out something that will work. You do understand that one need not have a better idea to make that observation? The observation is self-evident and can exist in the world regardless of what we think about IPv6 or the feasibility of figuring out something people will want to use. Getting defensive and playing “then you come up with something better”-games is not getting us anywhere. It is just part of the problem. It is unproductive. 30 years. Let’s not waste more time.
      • tardedmeme 6mo ago
• gred 6mo ago
  They should have had the UTF-8 guys tackle IPv6. Talk about elegant.
  • deleted 6mo ago
    [deleted]
  • mixmastamyk 6mo ago
    Great idea, somewhat similar to what I mentioned at: https://news.ycombinator.com/item?id=47991652 https://news.ycombinator.com/item?id=47991652
• t43562 6mo ago
  IPv6 is awesome and I'm so happy that my local network is IPv6 and my provider offers IPv6 by default too. I think it offers hope that we can serve up data in a much more peer-to-peer way without going via "bigcorp" servers. To break the network as a security measure seems the absolute wrong fix to me and it's hard to understand the logic of it.