20 ms·

The world in which IPv6 was a good design (2017)

179 points by jnord 3y ago

greyface- 3y ago
(2017), and it should be noted that the author has updated his views since then: https://apenwarr.ca/log/20200708 https://apenwarr.ca/log/20200708 ("IPv4, IPv6, and a sudden change in attitude", 2020).
- KirillPanov 3y ago
  And, lest anybody be misled by the title you quoted, > No, I'm not switching sides. IPv6 is just as far away from universal adoption, or being a "good design" for our world, as it was three years ago.
- captaincrowbar 3y ago
  "The awesome unstoppable terribleness that is Postel's Law." Eloquence for the ages.
deleted 3y ago
[deleted]
ggm 3y ago
35% worldwide by population of users in random samples at APNIC: https://stats.labs.apnic.net/ipv6/XA https://stats.labs.apnic.net/ipv6/XA US on 50%, India on 70% and China just shy of 40% -As China continues to grow (and it will) the likely outcome is > 50% IPv6 Capable. I doubt any new Mobile deployment will be single stack, the most likely is pure IPv6 with CGN for 4. So Africa which is still in growth, the most likely outcome is dualstack preferring 6 It may not be ideal, there may be significant issues with EH for instance, but at scale its alive and kicking. Now, if only we could get jumbogram more widely deployed. Thats older than V6 is and still struggling to break the 1500 byte MTU limit.
- throwaway892238 3y ago
  It doesn't matter if even 98% of "the internet" is "on" IPv6. If public websites don't advertise an IPv6 address, every user is still going to use IPv4 to connect to them. All the cloud providers still prioritize IPv4, and usually don't support IPv6 at all until a few years after a new service comes out.
  - TedDoesntTalk 3y ago
    Entire countries still do not have IPv6. Ukraine for example.
    - deleted 3y ago
      [deleted]
    - greyface- 3y ago
      There is some IPv6 adoption in Ukraine. https://stats.labs.apnic.net/ipv6/UA https://stats.labs.apnic.net/ipv6/UA
      - Sesse__ 3y ago
        Funny enough, when I measured IPv6 readiness/use in the world for the very first time (2008), Ukraine was on top. IIRC it moved to third as we got more data, but it still was a very surprising result. We found out much later that the reason was that Opera had broken RFC3484 handling and prioritized 6to4 way too high (which skewed the results), and Opera was popular in Ukraine at the time. :-)
  - Dagger2 3y ago
    NAT64 handles the "public v4-only website" use case very well. I run my desktop without v4 today and it works fine. A few websites without v6 aren't a blocker to either deploying v6 or undeploying v4.
- toast0 3y ago
  > Now, if only we could get jumbogram more widely deployed. Thats older than V6 is and still struggling to break the 1500 byte MTU limit. Really, we barely hit 1500. Look at mss for popular websites, most people drop from 1500, because 1500 has problems in enough places. Does http/3 even send 1500 byte packets ever? One major problem is most servers (Linux all versions, I think, FreeBSD before about 2000 and after something like 2019) always send the interface mss with a syn+ack. You get meaningfully better results by sending the lesser of the interface mss and the received mss; there are enough broken systems out there that don't communicate the real MTU to end systems[1], don't send enough ICMP needs frags, try to cover it up by manipulating mss in syns, but don't manipulate mss in syn+ack. Windows and iOS (and presumably mac) do a pretty good job of detecting pmtud blackholes, but it's often disabled on servers and I can't remember where Android is these days; I know it used to ship with the option compiled in but disabled and no way to enable. Of course, packet sizing is actually a hard problem. Larger packets are good for faster links but bad for slower links. [1] which is hard, because I don't know how you get windows to use MTU from dhcp; it doesn't request it, so it won't use it. This is a problem too.
  - klabb3 3y ago
    > Does http/3 even send 1500 byte packets ever? Iirc quic has a hard MTU cap at 1280 bytes.
    - cyberax 3y ago
      Nope. QUIC requires the _minimum_ MTU of 1280: https://datatracker.ietf.org/doc/html/rfc9000#name-datagram-size https://datatracker.ietf.org/doc/html/rfc9000#name-datagram-... The maximum permitted size is 65527 (max_udp_payload_size).
- cyberax 3y ago
  There will be no larger MTU, this battle is lost. 1500 will live forever. If it makes you feel better, think about it as if Ethernet packets are just oversized ATM cells. Solving PMTU problem would have required reifying the MTU to the IP layer. It could have been done like this: 1. Use a 16-bit field in the non-checksummed portion of the IP header. Initially this field is set to the MTU of the link that originates the packet. 2. Each router inspects this field, and sets it to the MTU of the next hop link, if it is lower than the MTU already in the packet. This will be cheap, as the field is not checksummed. 3. If the packet is bigger than the MTU of the next hop, just truncate it, and set a special bit somewhere in the packet header to indicate it. No need to recalculate the checksum either, the packet is going to be corrupt anyway. 4. The destination host gets the discovered MTU of the forward path, and sends it back to the originating host in the header of the next packet (in a checksummed part). That's it. Easy, continuous MTU discovery, with robust handling of failures, that doesn't require any smarts from the routers (a comparator to update the MTU can be done in a few logical gates!). Alas, nobody had the presence of mind to think about this back then.
  - ggm 3y ago
    It should be noted that pockets of jumbogram-in-the-wild exist. It's just normalised to clamp it to the point few people can exploit it. For example, the NBN in Australia uses a 2000+ layer-2 frame and nothing like 500 bytes is consumed to mark the upper carrier. They COULD have gone higher than 1500 and I would be surprised if there arent customers using 1300 or less because of the ADSL configuration they brought over when they uplifted from a real modem. A lot of people do 9000 in their filestore network. They know it works on the local segment. Reducing the forwarding burden in header-TCAM-routing by a factor of 5 is a significant win, if you have a lot of packets. People continue to discuss mechanistic approaches to finding your MTU in the IETF but I think you're right: its 1500 or less pretty much forever unless somebody makes a move here for product differentiation reasons. Given the embedding of content inside the ISP or at the IX, I suspect it COULD happen, if e.g. Netflix said it was a better overall experience? The ISPs would do it.
    - cyberax 3y ago
bragr 3y ago
>It's hard to imagine a network interface (except ppp0) without a 48-bit MAC address? Not super common but there's Infiniband. Latter versions supported encapsulating ethernet frames (Ethernet over InfiniBand) but not all hardware supports it. Otherwise it's straight IP over IB. There must be other niche networking technology that does IP without Ethernet.
- Bellyache5 3y ago
  Does networking over Thunderbolt work similarly?
photonbeam 3y ago
Does google downrank sites that are IPv4-only yet? That would shift some behaviors
- oneshtein 3y ago
  I switched to M$ search already, thank you.
- PlutoIsAPlanet 3y ago
  Google search results are already awful these days, please don't make them any worse.
themerone 3y ago
The myth that it would have been easier to switch to a protocol that is just ip4 with more bits needs to die. The companies too cheap or lazy to adopt ipv6 would still be clinging to classic ipv4 with NAT.
- DougMerritt 3y ago
  ipv4 with NAT is in fact still extremely common, but skipping that, which parts of ipv6 (beyond extra bits) do you regard as essential versus which parts are over-engineered?
  - lmm 3y ago
    What "parts of ipv6 (beyond extra bits)" are you concerned about? As far as I know there aren't any, unless you're talking about extensions or something?
    - DougMerritt 3y ago
      I haven't been fresh on this stuff for years, but there are some other differences. Included multicast, true QoS, included IPsec, a few other things. It's just that I sometimes see people advocating upgrading from ipv4+NAT to ipv6 for reasons beyond address bits, so I thought that's where you (edit, "they", oops) were coming from. I was just curious.
- stephen_g 3y ago
  Yes, it's a common idea but relies on a misunderstanding - it would have required exactly the same difficulty as switching to IPv6, because there's no way to make an 'ipv4 with more bits' compatible with regular IPv4 software or hardware, without changing to a dual stack arrangement (which requires replacing all the packet processing hardware in big routers that relies on the layout of the IP header) - exactly the same problem we had with IPv6.
  - tuatoru 3y ago
    No. The difficulty is social. Everyone would have been fine with "IPV4.2", IPV4 with six octets, because it's just like something they already knew, fixing its one obvious defect, not enough addresses. The consitituency for replacing the hardware/firmware and software stacks would have been there. IPV6 was not just like IPV4 and so people naturally resisted the devaluation of their hard-won knowledge.
preommr 3y ago
Cloud providers don't even support ipv6 that well let alone expecting the general public to switch over.
- trustingtrust 3y ago
  The big ones do. Small ones are small for a reason.
- athrun 3y ago
  AWS will start charging for most IPV4 addresses next year [1]. And I'd expect other cloud providers to follow AWS' lead here. This could provide the needed push for the Industry to switch. [1] https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/ https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
- xvilka 3y ago
  GitHub is the most annoying one. It's funny, given how many parts of IPv6 stack are developed here.
  - crote 3y ago
    The interesting part is that GitHub has already assigned[0] IPv6 addresses to a lot of endpoints of its stack. They just haven't created any AAAA record yet. Perhaps they'll add support for it soon? [0]: https://api.github.com/meta https://api.github.com/meta
Animats 3y ago
The author would have liked Xerox Network Services. The Xerox plan was that devices had a 48-bit Ethernet address, and local area networks had a 32-bit network ID. Routing was by network ID until the packet hit the final LAN. No need for IP-level addressing. Early Stanford and PARC routers could route XNS packets, but this died out some time in the 1980s.
cyberax 3y ago
Ugh. This is one of my favorite "what ifs" in the computer engineering. Things I would change: 1. Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks. 2. Just use the IPv4 "local subnet" prefix logic for broadcast domains. No "on-link" nonsense. 3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary. 4. Remove SLAAC and stateless DHCPv6. Statefulness is helpful for network management. 5. Reify the MTU into the IP layer. No more ICMP nonsense for PMTU. 6. Rework extension headers to be actually useful. No more "next header" bullshit.
- amluto 3y ago
  > 3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary. I don’t even think it’s really ok. ARP was layered correctly: IPv4 runs on Ethernet+ARP. Or it can run on other things that aren’t Ethernet+ARP. IPv6 uses IPv6 messages to make itself work on Ethernet, thus baking knowledge of Ethernet into the IPv6 neighbor discovery logic. If multicast neighbor discovery is useful (which it may well be), then ARPv6 could have used multicast.
  - cyberax 3y ago
    I'm honestly not sure if ND along with interface addresses in V6 is a useless hack, or if it is a clever trick. I keep changing my mind all the time. I guess it's kinda both. On one hand, V6 addresses are big enough to represent hardware addresses directly. So you don't _need_ a low-level protocol like ARP to resolve V6 addresses to hardware addresses, you can represent it as special messages in IPv6 itself. It also allows some interesting tricks, like local network applications using interface addresses to communicate normally without setting up global connectivity. On the other hand, interface addresses in V6 cause no end of confusion ("what the heck fe80::88a:fd34:d1b:2de7%en0 means?!?"). And V6 also has no clear distinction between the local network and the Internet, and the easy ability to use broadcasts (just send a packet to the network address). And it's not like many applications actually use interface addresses anyway. So this is kinda a moot point.
- kccqzy 3y ago
mike_d 3y ago
IPv6 failed because they tried to boil the ocean. It was design by committee, where everyone got their pet feature thrown in to appease and gain consensus. Alternatively IPv4 is a mountain of small hacks, which is its biggest strength. We could have done a lot of good by adopting proposals to extend v4 like 0/8 and class D, but instead the decision was made to collectively drown the babies in the bathwater and insist on v6 at all costs.
- ianburrell 3y ago
  Freeing up more IPv4 space wouldn't have helped. IANA was assigning /8 per month at the end. The extra space would have gone in less than a year. IPv6 would have worked better if they had made minimal changes to the support protocols. But it was have had slow adoption because there was no incentive to switch until addresses ran out.
  - mike_d 3y ago
    > Freeing up more IPv4 space wouldn't have helped. IANA was assigning /8 per month at the end. You are confusing hoarding demand for legitimate need. The Amazon's and Cloudflare's of the world were playing games to get large allocations, speculators were spinning up hundreds of legal entities to get allocations, tons of backroom deals to look the other way. Pretty much every use case today for IPv6 is environments where CGN would have worked just as well.
  - schoen 3y ago
    We should probably have auctions for IPv4 space to encourage more efficient use. Not that we have some kind of authority to require this, but we've often suggested this in connection with our proposal to prepare to allocate 240/4. While one can say that there's no way that IPv4 demand can ever be "satisfied" (which seems right to me), one can also imagine a different quantity demanded at $0.50/address than at $0.00/address, and also different levels of effort to make sure that almost all addresses that are allocated get put into use on the Internet. (I know $0.00/address isn't exactly the right way to describe what RIR allocations cost, but economically they've been more similar to the "beauty contest" than the "auction" allocation method.) In the final direct initial allocation phase, people learned that something (with substantial economic value that can likely be sold in the future, no less!) was very scarce, and was being given out nearly at no cost for almost the last time. It's not surprising that they would have jumped at the opportunity to get as much of it as they could qualify for, somewhat independent of what use they expected to make of it in the short term. Maybe especially when they were hearing how other people were jumping at that opportunity.
unethical_ban 3y ago
I've only dabbled in IPv6, but the one thing that blew my mind was that you cannot set DNS automatically without DHCPv6. Other methods of "automatic addressing" are thus useless.
- fulafel 3y ago
  This would be relevant in v6-only networks, but in practice everyone also runs v4 which and v4 dhcp which gets you dns. (Also there's a DNS option in router advertisements now like subling comment said)
  - magicalhippo 3y ago
    Android ignores any IPv4 DNS address it gets if it gets an IPv6 address. Instead it falls back to Google's own DNS servers. So if you got Android devices in your house, you need to configure a IPv6 DNS server. AFAIK a IPv4 DHCP server can't hand out a IPv6 DNS address.
- greyface- 3y ago
  RFC8106 IPv6 Router Advertisement Options for DNS Configuration https://datatracker.ietf.org/doc/html/rfc8106 https://datatracker.ietf.org/doc/html/rfc8106
  - blacklion 3y ago
    Ans what software do support it? There are tons of these IPv6 RFCs which is not supported by "common" software - Linux and FreeBSD daemons, nsd, unbound, etc. How could I implement this in my home network, with off-the-shelf SOHO router or even something like OpenWRT / custom OSS-based "firmware"?
    - unethical_ban 3y ago
      I'm using opnsense and it seems to have worked for my network.
  - 3y ago
theptip 3y ago
The IP/Ethernet section is surprising to me. It sort of claims that there is no reason to have ARP and give your default router an IP when you could just give it a MAC address and skip the ARP. Maybe this is true now but it reads like it was a bad idea at the time. I wasn’t there (sounds like Apen was?) so I could be missing context, but I was under the impression that there were loads of layer 2 protocols at the time IP was designed (token ring, frame relay, etc) and so IP needed to be agnostic to the L2 protocol in order to be adopted.
deleted 3y ago
[deleted]
narrator 3y ago
I have said for the last decade or so whenever IPV6 comes up on HN that IPV6 was way too big of an address space for anything but having some sort of unique identifier in there to support an online digital ID. Like some space for a hash of a biometric or something in the lower 64 bits.
- greyface- 3y ago
  You may be interested in IPv6 CGAs. https://en.wikipedia.org/wiki/Cryptographically_Generated_Address https://en.wikipedia.org/wiki/Cryptographically_Generated_Ad... https://datatracker.ietf.org/doc/html/rfc3972 https://datatracker.ietf.org/doc/html/rfc3972
- jandrese 3y ago
  About a decade ago I worked on a project for secure networks where machines would encode identity information into the lower 64 bits of an IPv6 network and security devices could use that to enforce policy based on your identity, not your machine. The most interested customer, the government, had the problem of having way too much IPv4 space and little incentive to upgrade so it never went anywhere. Even after the government mandates to switch to IPv6, which mostly just ended up with loads of IPv4 only government websites behind Cloudflare gateways.
pm2222 3y ago
The core network stack is going to be dual stack any way during at least the transition phrase, OSes like linux should allow v4/v6 communication.
jeroenhd 3y ago
IPv6's biggest problem remains not that it's badly designed (at least not nowadays, there were problems but they were solved ten years ago) but that millions of network engineers never bothered to look deeper into IPv6 than "I don't get it, this feels off". You can't make a backwards compatible "IPv4 with more bits" like people dream of. L2 routers and middleboxes would still need to be replaced, software would still need to be rewritten, nothing would be different. IPv4 changed how private networks worked because its first attempt at private networks failed. People are stuck with the IPv4 mindset through a combination of lacking education (who even taught IPv6 when our current sysadmins were in college?) or assuming IPv4 is normal and well thought out. There are free guides, books, and playgrounds out there if you want to learn IPv6, so the education problem is one you can solve yourself. Realizing the flawed nature of IPv4 is harder. I've come from IPv4 networking, but learning IPv6 later made me realize how silly old networks really are. DHCP is a hack to solve a design failure in IPv4 and SLAAC is a much better solution. Companies have started relying on awful hacks originating from when companies decided to staple features to a side effects of a generic address distribution protocol. ARP feels more like a placeholder that should've been included a layer lower or higher in the network graph, put in its own little place to solve the theoretical "what if we don't run IP over our switch" problem that stopped being relevant decades ago. As annoying as it may be, we live in an age where the OSI model with seven layers of networking protocols don't exist. Token ring is dead, SCTP died in the womb, Ethernet II exist purely in theory. The world now runs on HTTPS on top of UDP or TCP on top of IPv6/4, on top of some kind of wire that carries ethernet. Ethernet now exists to support IP and vice versa in 99% of all use cases. TCP and UDP exist to serve HTTPS, or some legacy protocol that will be rewritten into HTTPS in the next ten years. WiFi and high-speed data networks came in as a whole new networking system and have turned out to be "what if ethernet, but wireless" with some control logic to make the wireless antennae talk. The OSI model and all the expansion and flexibility it provided simply died over a decade ago. Anything on top of the data link exists purely to support Ethernet + IP + HTTPS. The migration path to IPv6 is now blocked by excuses. People pretended to care about servers not supporting IPv6 as the reason not to use but, but three or four different ways of providing backwards compatibility to all IPv4 clients were thought up and nobody actually asked for any of them. People complained that their data center provider didn't support IPv6 but now that enabling IPv6 is just a single click in a web UI they don't enable it anyway. People cared about the IPv6 privacy risks but never let go of that concept even after rfc4941 fixed that oversight. Companies like Microsoft and Github, too incompetent to set up a network that their dollar store competitors have supported for years now, have become something to point at and go "see? we need those!" as if NAT64/DNS64/464XLAT/SIIT/whatever haven't been providing IPv4 compatibility for years now. "I don't know enough about it" and "I don't like it" are perfectly good excuses not to enable IPv6 in your home network, but they're not design flaws or protocol problems. If you're willing to accept the packet maiming we have nicknamed "NAT" or even "CG-NAT", you should feel refreshed at the sight of the plain and simple protocols IPv6 provides you with. The way people talk about IPv6 now reminds me of the way people talked about HTTPS back when Let's Encrypt started gaining popularity, and the way people dealt with systemd reinventing a better Linux management system. Grumpy people, clinging to what they know, delaying unavoidable change until the very last moment. You can be like the Dracut people running ipromiseiwillneverrunssl.com if you want, but it's a losing battle.
Helmut10001 3y ago
About a year ago I started the IPv6 migration for my home network (2 Remote sites, connected via IPSEC, with 10 VLANs (subnets) and about 70 devices, 10 people). - I started on one side of the IPSEC, where I have an OPNsense - there were like 5 updates of OPNsense in the last year where different IPv6 issues were fixed (and others have been introduced). - my ISP only hands out /64-Prefixes, and these are also dynamic, which makes configuration more difficult - a number of times I had to turn off IPv6 because different parts were suddenly not working anymore, mostly based on software issues in my stack All of that over 20 years after IPv6 was introduced makes me wonder if it is the correct technology, if it is so difficult to implement.
- Faaak 3y ago
  You're comparing two remote sites linked by IPv4 NAT to distributing IPv6 from a /64 (which was never meant to be subdivided) which is dynamic..
  - Helmut10001 3y ago
    Yes, I know - but as the article mentions, it is not possible to "deprecate" IPv4 yet. I need both. And during this "migration phase", both IPv4+IPv6 must work alongside each other, which frankly speaking, I haven't yet managed to accomplish.
    - Faaak 3y ago
      Well, tbh dual-stack is enabled in 70% of France's customers for example. If you start with a solid base (having a fixed IPv6 /56 delegation for example), or at least a dynamic allocation with IPv6-PD, then you'll see that it's way easier than IPv4 in the long end
      - Helmut10001 3y ago
        I already get a headache when thinking of configuring firewall rules with a dynamic prefix for all my hosts.
lproven 3y ago
I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear and needs more illustrations. (Which, as a technical writer myself, I generally regard as a crutch.) I think the core argument can be summarised as this: 1. IPv6 is flawed because it has 2 main layers, but it needed 3. 2. It understands physical addresses, and it has its own logical addresses. 3. But it really needed another layer in between them: a virtual translation/mapping layer. 4. Crucially, it lacks this. As such it is not better enough than IPv4 to ever totally replace IPv4. 5. But apenwarr proposes that it is, in essence, possible to fake this using QUIC. https://en.wikipedia.org/wiki/QUIC https://en.wikipedia.org/wiki/QUIC <- note the diagram in that article. 6. Using this, it's possible to fake what IPv6 should have had but didn't, and get some of the benefits at the cost of more work. 7. However IPv6 remains doomed to never totally replace IPv4. Boiling that down to 2 key points: Point A: IPv6 is broken because it didn't go far enough; its mapping model is fundamentally inadequate. Point B: It's OK, here's how we can work around that, but it doesn't fix the problem & never will. And generalising from that argument, my take is this: Butler Lampson said: "All problems in computer science can be solved by another level of indirection." David Wheeler pointed out: "… except for the problem of too many layers of indirection." The corollary of this is: it is imperative to closely track how many layers of indirection you have. Too many is bad, but arguably, not enough is worse. With too many, you get inefficiency, but you can nonetheless get the job done. But with too few, you might not usefully be able to do the job at all. IPv6 did not have enough, and so failed to achieve its primary goal.
- GordonS 3y ago
  > As such it is not better enough than IPv4 That's the crux of it. Sometimes I think we'd be better off forgetting about IPv6, and starting afresh with an IPv7 - something that provides a meaningful incentive to upgrade.
  - poizan42 3y ago
    IPv7 was used for the "TP/IX: The Next Internet" proposal from 1993: https://datatracker.ietf.org/doc/html/rfc1475 https://datatracker.ietf.org/doc/html/rfc1475 The next available version is IPv10
exabrial 3y ago
One thing I’ve realized lately is that scarcity is actually a benefit of ipv4, much in the way of the maximum amount of bitcoins theoretically increases their value. Ipv4 addresses are being ranked by their reputation. This is a good thing, at least right now, as it makes scammers/spammers/hackers/ddosers lives more expensive to acquire fresh addresses. This can only exist when a shortage exists.
- baq 3y ago
  in ipv6 you can (should) grade whole subnets as end customers typically get whole /64s.
  - alyandon 3y ago
    Not always though. Lower end VPS providers seem to be moving towards placing you on a shared /64. I run into issues on a particular Digital Ocean instance of mine where my IPv6 allocation is something like a /112 and it gets swept up in bans on the parent /64 because of other's bad behavior. Then you have other providers like Vultr that do weird things like not statically route your /64 prefix to your instance which kind of defeats the entire point of having a /64.
    - jandrese 3y ago
      Digital Ocean has been in the wrong with their IPv6 allocation since the day the implemented it. One of the rules of IPv6 is never allocate less than a /64. Unfortunately their network admins don't seem to care.
  - tsimionescu 3y ago
    There's still 2^64 /64 IPv6 subnets, and only 2^32 IPv4 addresses in total, of which huge swaths aren't even used.
- justsomehnguy 3y ago
  "People are DUI without a driver license, so let's make the driver license cost $$$$ for every Average Joe."
mnd999 3y ago
The "I don't like it, it's different" mob are out in force today. This isn't the Daily Mail.
denton-scratch 3y ago
> configuring DHCP really is a huge pain Not sure why the author is so sniffy about DHCP. To me it seems easy to understand and configure. Having said that, I appreciate the author's remarks about DHCP being a 'fake' IP protocol, and in reality being an ethernet protocol; I hadn't seen it that way before, but it's a reasonable way to look at it.
dang 3y ago
Related: The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=25568766 https://news.ycombinator.com/item?id=25568766 - Dec 2020 (131 comments) The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=20167686 https://news.ycombinator.com/item?id=20167686 - June 2019 (238 comments) The world in which IPv6 was a good design - https://news.ycombinator.com/item?id=14986324 https://news.ycombinator.com/item?id=14986324 - Aug 2017 (191 comments)
rjsw 3y ago
The author is unaware of, or has ignored, Mobile IP [1]. There are implementation of it available. [1] https://en.wikipedia.org/wiki/Mobile_IP https://en.wikipedia.org/wiki/Mobile_IP
rbanffy 3y ago
Connection roaming seems more like a TCP problem than an IP one. Wouldn’t it be wise to extend the TCP side? Or, rather, should we expect IPv6 to solve it?
systems_glitch 3y ago
Anyone else mostly fine with IPv6 like it is? Biggest complaint here is that I wish I had a way to correlate SLAAC addresses with hostnames somewhere other than the host. But I don't so when it matters I run a DDNS client on the host, which is probably the "more correct" answer anyway because the host always keeps DNS updated with its current address.
- kccqzy 3y ago
  I'm fine with IPv6. The more correct answer to your complaint is to dump the router's ND cache. I'm pretty sure this is part of SNMP.
  - systems_glitch 3y ago
    Interesting, thanks! I'll have to see if I can get OpenBSD to do that.
    - greyface- 3y ago
      On OpenBSD, you can dump the ND cache with `ndp -an`. You'd still have to map MAC addresses to hostnames somehow.
      - systems_glitch 3y ago
        Ah hah, thanks! I can probably just correlate them with DHCPv4 leases.
chasd00 3y ago
isn't the "mostly good enough" aspect of ipv4 the biggest problem for ipv6?
systemBuilder 3y ago
I was asked by my employer in 2003 when IPv6 would replace IPv4? After substantial research, my answer was, "never"!!! I almost got fired for that answer but I am correct so far. There are a large class of people out there who do not understand the end to end argument in system design and who never saw a piece of bloatware they didn't love. For them IPv6 will happen tomorrow. They are to internet like maga people are to democracy - caustic. In 2004 IPv6 was hyped as solving the impending IPv4 address shortage. NAT had already been invented and there was no shortage as IPv4 addresses were allocated as inefficiently as possible and there was no market to buy and sell IP addresses nor was there any rental cost for owning ipv4 addresses. So it was solving a non problem. My employer Qualcomm eventually proposed using IPv6 for cell phone handsets in an overlay network called openran. This was a convenience and not a necessity because there are more than 4 billion cell phones in the world. You just don't need these bloated addresses in IPv6. You need banks of addresses mainly for the server. The client never needs 65,000 incoming or outgoing connections. The number of client computers in the world that are running as servers and that need open datagram accessibility from anywhere in the internet is virtually zero. Want it? yes! Need it - meaning impossible to do without it - No! There are always bridging workarounds to avoid giving client machines dedicated IP addresses! IPv6 is not respectful of small system design and hardly provides usable improvements to IPv4. IPv6 was a marketing tool invented by Cisco to sell bigger more expensive routers, not to solve a problem with any economy ... It is especially detrimental to IOT.
jandrese 3y ago
One thing that isn't discussed very often but is IMHO one of the bigger roadblocks for IPv6 deployment is the Berkley Socket Interface. The API that loads of code is built upon to do internet communication. The problem is that the API is too low level, or more specifically there is no high level API for it. Ideally it would have a function that looks like: int sockfd = connect_to(hostname, port, SOCK_STREAM, options_bitfield); This would allow the stack to work out the details on its own and automatically use IPv6 if available. Or whatever future protocols can provide you a STREAM socket. The old interface could also be available for people who need to do low level stuff, but most of the time this would be sufficient.
gwbas1c 3y ago
I've always seen "The Internet" as a network of networks. I interpreted the article as inferring that "every device should only speak internet, and we shouldn't have non-internet hacks to allow devices to connect to the internet." But, if we interpret the internet as a network built on top of other networks, it negates the thesis (as I interpret it) of the article. It also locks us into networking, as understood in the late 1990s, and designed into IPv6. IMO: It seems like IPv6 suffers from second system syndrome. The authors lost sight of the purpose "network built on top of other networks" and tried to add lots of features for the "other networks" that really aren't needed. Maybe it's time for IPv7? Really, all we need is IPv4 + larger address space. I'd even argue that NAT is a good thing (security feature,) because allowing devices on a private network to automatically open ports on the public internet is insecure.
- hnarn 3y ago
  > I'd even argue that NAT is a good thing (security feature,) Any router that I’ve come across already blocks incoming IPv6 traffic by default, so I’d have to disagree. NAT was designed for a very specific purpose and keeping it in a new implementation makes no sense if it’s not necessary, which it’s not if the hardware requires you to open incoming ports. No NAT would make it a lot easier to understand what’s happening too, since the process would be “allow traffic from the internet to this device” rather than creating a translation for an internal address, possibly having to set up a MAC reservation to ensure the DHCP lease doesn’t expire etc.
mannyv 3y ago
"Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that." RARP is basically dhcp but only for your IP address. DHCP/bootp won because you sort of need a bit more than your ip. It was also easier to manage. RARP probably still works mostly.
brian_cunnie 3y ago
I must admit I'm at a loss about this IPv6 hate. I love IPv6. I love that (almost) every IPv6 subnet is a /64. Just this morning I assumed an IPv4 subnet was a /24, only to discover it was a /20, causing me to spend a couple of minutes re-working. I love that (almost) every IPv6 is a /64 because you'll never have to widen a subnet because you started of with a /24, but then after your office grew to 200 people you had to switch to a /20. And no matter how automated you are, there are always some important devices that have static IPs and that you have to reconfigure manually. I love that every IPv6 client gets a routable IP. This means NAT isn't necessary. NAT is a clever hack, but we've grown so accustomed to it that we've become blind to its failings. I've had to trace packets coming out of a corporate NAT, then into an AWS ELB (Elastic Load Balancer) back into a different NAT. With the IP address remappings, it's awful IPv4 NAT can also lead to IP address collisions. Your home subnet is 192.168.0.0/24? And so's your work? Good luck VPN'ing in. I like that IPv6 has an abundance of IPv6 addresses—I don't need to share the ports on my sole IPv4 address to 5 different machines.
maaarghk 3y ago
A bit off topic but the most interesting part of this was clicking through to the link about TCP BBR. It's available for the Linux kernel but not bundled / enabled by default, but if these related posts are telling the truth, maybe it should be: https://djangocas.dev/blog/huge-improve-network-performance-by-change-tcp-congestion-control-to-bbr/ https://djangocas.dev/blog/huge-improve-network-performance-... https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-control-84c9c11dc3a9 https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...

179 points by jnord 3y ago

(2017), and it should be noted that the author has updated his views since then: https://apenwarr.ca/log/20200708 https://apenwarr.ca/log/20200708 ("IPv4, IPv6, and a sudden change in attitude", 2020).

KirillPanov 3y ago
And, lest anybody be misled by the title you quoted, > No, I'm not switching sides. IPv6 is just as far away from universal adoption, or being a "good design" for our world, as it was three years ago.
captaincrowbar 3y ago
"The awesome unstoppable terribleness that is Postel's Law." Eloquence for the ages.

deleted 3y ago

[deleted]

ggm 3y ago

35% worldwide by population of users in random samples at APNIC: https://stats.labs.apnic.net/ipv6/XA https://stats.labs.apnic.net/ipv6/XA US on 50%, India on 70% and China just shy of 40% -As China continues to grow (and it will) the likely outcome is > 50% IPv6 Capable. I doubt any new Mobile deployment will be single stack, the most likely is pure IPv6 with CGN for 4. So Africa which is still in growth, the most likely outcome is dualstack preferring 6 It may not be ideal, there may be significant issues with EH for instance, but at scale its alive and kicking. Now, if only we could get jumbogram more widely deployed. Thats older than V6 is and still struggling to break the 1500 byte MTU limit.

throwaway892238 3y ago
It doesn't matter if even 98% of "the internet" is "on" IPv6. If public websites don't advertise an IPv6 address, every user is still going to use IPv4 to connect to them. All the cloud providers still prioritize IPv4, and usually don't support IPv6 at all until a few years after a new service comes out.
- TedDoesntTalk 3y ago
  Entire countries still do not have IPv6. Ukraine for example.
  - deleted 3y ago
    [deleted]
  - greyface- 3y ago
    There is some IPv6 adoption in Ukraine. https://stats.labs.apnic.net/ipv6/UA https://stats.labs.apnic.net/ipv6/UA
    - Sesse__ 3y ago
      Funny enough, when I measured IPv6 readiness/use in the world for the very first time (2008), Ukraine was on top. IIRC it moved to third as we got more data, but it still was a very surprising result. We found out much later that the reason was that Opera had broken RFC3484 handling and prioritized 6to4 way too high (which skewed the results), and Opera was popular in Ukraine at the time. :-)
- Dagger2 3y ago
  NAT64 handles the "public v4-only website" use case very well. I run my desktop without v4 today and it works fine. A few websites without v6 aren't a blocker to either deploying v6 or undeploying v4.
toast0 3y ago
> Now, if only we could get jumbogram more widely deployed. Thats older than V6 is and still struggling to break the 1500 byte MTU limit. Really, we barely hit 1500. Look at mss for popular websites, most people drop from 1500, because 1500 has problems in enough places. Does http/3 even send 1500 byte packets ever? One major problem is most servers (Linux all versions, I think, FreeBSD before about 2000 and after something like 2019) always send the interface mss with a syn+ack. You get meaningfully better results by sending the lesser of the interface mss and the received mss; there are enough broken systems out there that don't communicate the real MTU to end systems[1], don't send enough ICMP needs frags, try to cover it up by manipulating mss in syns, but don't manipulate mss in syn+ack. Windows and iOS (and presumably mac) do a pretty good job of detecting pmtud blackholes, but it's often disabled on servers and I can't remember where Android is these days; I know it used to ship with the option compiled in but disabled and no way to enable. Of course, packet sizing is actually a hard problem. Larger packets are good for faster links but bad for slower links. [1] which is hard, because I don't know how you get windows to use MTU from dhcp; it doesn't request it, so it won't use it. This is a problem too.
- klabb3 3y ago
  > Does http/3 even send 1500 byte packets ever? Iirc quic has a hard MTU cap at 1280 bytes.
  - cyberax 3y ago
    Nope. QUIC requires the _minimum_ MTU of 1280: https://datatracker.ietf.org/doc/html/rfc9000#name-datagram-size https://datatracker.ietf.org/doc/html/rfc9000#name-datagram-... The maximum permitted size is 65527 (max_udp_payload_size).
cyberax 3y ago
There will be no larger MTU, this battle is lost. 1500 will live forever. If it makes you feel better, think about it as if Ethernet packets are just oversized ATM cells. Solving PMTU problem would have required reifying the MTU to the IP layer. It could have been done like this: 1. Use a 16-bit field in the non-checksummed portion of the IP header. Initially this field is set to the MTU of the link that originates the packet. 2. Each router inspects this field, and sets it to the MTU of the next hop link, if it is lower than the MTU already in the packet. This will be cheap, as the field is not checksummed. 3. If the packet is bigger than the MTU of the next hop, just truncate it, and set a special bit somewhere in the packet header to indicate it. No need to recalculate the checksum either, the packet is going to be corrupt anyway. 4. The destination host gets the discovered MTU of the forward path, and sends it back to the originating host in the header of the next packet (in a checksummed part). That's it. Easy, continuous MTU discovery, with robust handling of failures, that doesn't require any smarts from the routers (a comparator to update the MTU can be done in a few logical gates!). Alas, nobody had the presence of mind to think about this back then.
- ggm 3y ago
  It should be noted that pockets of jumbogram-in-the-wild exist. It's just normalised to clamp it to the point few people can exploit it. For example, the NBN in Australia uses a 2000+ layer-2 frame and nothing like 500 bytes is consumed to mark the upper carrier. They COULD have gone higher than 1500 and I would be surprised if there arent customers using 1300 or less because of the ADSL configuration they brought over when they uplifted from a real modem. A lot of people do 9000 in their filestore network. They know it works on the local segment. Reducing the forwarding burden in header-TCAM-routing by a factor of 5 is a significant win, if you have a lot of packets. People continue to discuss mechanistic approaches to finding your MTU in the IETF but I think you're right: its 1500 or less pretty much forever unless somebody makes a move here for product differentiation reasons. Given the embedding of content inside the ISP or at the IX, I suspect it COULD happen, if e.g. Netflix said it was a better overall experience? The ISPs would do it.
  - cyberax 3y ago

bragr 3y ago

>It's hard to imagine a network interface (except ppp0) without a 48-bit MAC address? Not super common but there's Infiniband. Latter versions supported encapsulating ethernet frames (Ethernet over InfiniBand) but not all hardware supports it. Otherwise it's straight IP over IB. There must be other niche networking technology that does IP without Ethernet.

Bellyache5 3y ago
Does networking over Thunderbolt work similarly?

photonbeam 3y ago

Does google downrank sites that are IPv4-only yet? That would shift some behaviors

oneshtein 3y ago
I switched to M$ search already, thank you.
PlutoIsAPlanet 3y ago
Google search results are already awful these days, please don't make them any worse.

themerone 3y ago

The myth that it would have been easier to switch to a protocol that is just ip4 with more bits needs to die. The companies too cheap or lazy to adopt ipv6 would still be clinging to classic ipv4 with NAT.

DougMerritt 3y ago
ipv4 with NAT is in fact still extremely common, but skipping that, which parts of ipv6 (beyond extra bits) do you regard as essential versus which parts are over-engineered?
- lmm 3y ago
  What "parts of ipv6 (beyond extra bits)" are you concerned about? As far as I know there aren't any, unless you're talking about extensions or something?
  - DougMerritt 3y ago
    I haven't been fresh on this stuff for years, but there are some other differences. Included multicast, true QoS, included IPsec, a few other things. It's just that I sometimes see people advocating upgrading from ipv4+NAT to ipv6 for reasons beyond address bits, so I thought that's where you (edit, "they", oops) were coming from. I was just curious.
stephen_g 3y ago
Yes, it's a common idea but relies on a misunderstanding - it would have required exactly the same difficulty as switching to IPv6, because there's no way to make an 'ipv4 with more bits' compatible with regular IPv4 software or hardware, without changing to a dual stack arrangement (which requires replacing all the packet processing hardware in big routers that relies on the layout of the IP header) - exactly the same problem we had with IPv6.
- tuatoru 3y ago
  No. The difficulty is social. Everyone would have been fine with "IPV4.2", IPV4 with six octets, because it's just like something they already knew, fixing its one obvious defect, not enough addresses. The consitituency for replacing the hardware/firmware and software stacks would have been there. IPV6 was not just like IPV4 and so people naturally resisted the devaluation of their hard-won knowledge.

preommr 3y ago

Cloud providers don't even support ipv6 that well let alone expecting the general public to switch over.

trustingtrust 3y ago
The big ones do. Small ones are small for a reason.
athrun 3y ago
AWS will start charging for most IPV4 addresses next year [1]. And I'd expect other cloud providers to follow AWS' lead here. This could provide the needed push for the Industry to switch. [1] https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/ https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
xvilka 3y ago
GitHub is the most annoying one. It's funny, given how many parts of IPv6 stack are developed here.
- crote 3y ago
  The interesting part is that GitHub has already assigned[0] IPv6 addresses to a lot of endpoints of its stack. They just haven't created any AAAA record yet. Perhaps they'll add support for it soon? [0]: https://api.github.com/meta https://api.github.com/meta

Animats 3y ago

The author would have liked Xerox Network Services. The Xerox plan was that devices had a 48-bit Ethernet address, and local area networks had a 32-bit network ID. Routing was by network ID until the packet hit the final LAN. No need for IP-level addressing. Early Stanford and PARC routers could route XNS packets, but this died out some time in the 1980s.

cyberax 3y ago

Ugh. This is one of my favorite "what ifs" in the computer engineering. Things I would change: 1. Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks. 2. Just use the IPv4 "local subnet" prefix logic for broadcast domains. No "on-link" nonsense. 3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary. 4. Remove SLAAC and stateless DHCPv6. Statefulness is helpful for network management. 5. Reify the MTU into the IP layer. No more ICMP nonsense for PMTU. 6. Rework extension headers to be actually useful. No more "next header" bullshit.

amluto 3y ago
> 3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary. I don’t even think it’s really ok. ARP was layered correctly: IPv4 runs on Ethernet+ARP. Or it can run on other things that aren’t Ethernet+ARP. IPv6 uses IPv6 messages to make itself work on Ethernet, thus baking knowledge of Ethernet into the IPv6 neighbor discovery logic. If multicast neighbor discovery is useful (which it may well be), then ARPv6 could have used multicast.
- cyberax 3y ago
  I'm honestly not sure if ND along with interface addresses in V6 is a useless hack, or if it is a clever trick. I keep changing my mind all the time. I guess it's kinda both. On one hand, V6 addresses are big enough to represent hardware addresses directly. So you don't _need_ a low-level protocol like ARP to resolve V6 addresses to hardware addresses, you can represent it as special messages in IPv6 itself. It also allows some interesting tricks, like local network applications using interface addresses to communicate normally without setting up global connectivity. On the other hand, interface addresses in V6 cause no end of confusion ("what the heck fe80::88a:fd34:d1b:2de7%en0 means?!?"). And V6 also has no clear distinction between the local network and the Internet, and the easy ability to use broadcasts (just send a packet to the network address). And it's not like many applications actually use interface addresses anyway. So this is kinda a moot point.
kccqzy 3y ago

mike_d 3y ago

IPv6 failed because they tried to boil the ocean. It was design by committee, where everyone got their pet feature thrown in to appease and gain consensus. Alternatively IPv4 is a mountain of small hacks, which is its biggest strength. We could have done a lot of good by adopting proposals to extend v4 like 0/8 and class D, but instead the decision was made to collectively drown the babies in the bathwater and insist on v6 at all costs.

ianburrell 3y ago
Freeing up more IPv4 space wouldn't have helped. IANA was assigning /8 per month at the end. The extra space would have gone in less than a year. IPv6 would have worked better if they had made minimal changes to the support protocols. But it was have had slow adoption because there was no incentive to switch until addresses ran out.
- mike_d 3y ago
  > Freeing up more IPv4 space wouldn't have helped. IANA was assigning /8 per month at the end. You are confusing hoarding demand for legitimate need. The Amazon's and Cloudflare's of the world were playing games to get large allocations, speculators were spinning up hundreds of legal entities to get allocations, tons of backroom deals to look the other way. Pretty much every use case today for IPv6 is environments where CGN would have worked just as well.
- schoen 3y ago
  We should probably have auctions for IPv4 space to encourage more efficient use. Not that we have some kind of authority to require this, but we've often suggested this in connection with our proposal to prepare to allocate 240/4. While one can say that there's no way that IPv4 demand can ever be "satisfied" (which seems right to me), one can also imagine a different quantity demanded at $0.50/address than at $0.00/address, and also different levels of effort to make sure that almost all addresses that are allocated get put into use on the Internet. (I know $0.00/address isn't exactly the right way to describe what RIR allocations cost, but economically they've been more similar to the "beauty contest" than the "auction" allocation method.) In the final direct initial allocation phase, people learned that something (with substantial economic value that can likely be sold in the future, no less!) was very scarce, and was being given out nearly at no cost for almost the last time. It's not surprising that they would have jumped at the opportunity to get as much of it as they could qualify for, somewhat independent of what use they expected to make of it in the short term. Maybe especially when they were hearing how other people were jumping at that opportunity.

unethical_ban 3y ago

I've only dabbled in IPv6, but the one thing that blew my mind was that you cannot set DNS automatically without DHCPv6. Other methods of "automatic addressing" are thus useless.

fulafel 3y ago
This would be relevant in v6-only networks, but in practice everyone also runs v4 which and v4 dhcp which gets you dns. (Also there's a DNS option in router advertisements now like subling comment said)
- magicalhippo 3y ago
  Android ignores any IPv4 DNS address it gets if it gets an IPv6 address. Instead it falls back to Google's own DNS servers. So if you got Android devices in your house, you need to configure a IPv6 DNS server. AFAIK a IPv4 DHCP server can't hand out a IPv6 DNS address.
greyface- 3y ago
RFC8106 IPv6 Router Advertisement Options for DNS Configuration https://datatracker.ietf.org/doc/html/rfc8106 https://datatracker.ietf.org/doc/html/rfc8106
- blacklion 3y ago
  Ans what software do support it? There are tons of these IPv6 RFCs which is not supported by "common" software - Linux and FreeBSD daemons, nsd, unbound, etc. How could I implement this in my home network, with off-the-shelf SOHO router or even something like OpenWRT / custom OSS-based "firmware"?
  - unethical_ban 3y ago
    I'm using opnsense and it seems to have worked for my network.
- 3y ago

theptip 3y ago

The IP/Ethernet section is surprising to me. It sort of claims that there is no reason to have ARP and give your default router an IP when you could just give it a MAC address and skip the ARP. Maybe this is true now but it reads like it was a bad idea at the time. I wasn’t there (sounds like Apen was?) so I could be missing context, but I was under the impression that there were loads of layer 2 protocols at the time IP was designed (token ring, frame relay, etc) and so IP needed to be agnostic to the L2 protocol in order to be adopted.

deleted 3y ago

[deleted]

narrator 3y ago

I have said for the last decade or so whenever IPV6 comes up on HN that IPV6 was way too big of an address space for anything but having some sort of unique identifier in there to support an online digital ID. Like some space for a hash of a biometric or something in the lower 64 bits.

greyface- 3y ago
You may be interested in IPv6 CGAs. https://en.wikipedia.org/wiki/Cryptographically_Generated_Address https://en.wikipedia.org/wiki/Cryptographically_Generated_Ad... https://datatracker.ietf.org/doc/html/rfc3972 https://datatracker.ietf.org/doc/html/rfc3972
jandrese 3y ago
About a decade ago I worked on a project for secure networks where machines would encode identity information into the lower 64 bits of an IPv6 network and security devices could use that to enforce policy based on your identity, not your machine. The most interested customer, the government, had the problem of having way too much IPv4 space and little incentive to upgrade so it never went anywhere. Even after the government mandates to switch to IPv6, which mostly just ended up with loads of IPv4 only government websites behind Cloudflare gateways.

pm2222 3y ago

The core network stack is going to be dual stack any way during at least the transition phrase, OSes like linux should allow v4/v6 communication.

jeroenhd 3y ago

IPv6's biggest problem remains not that it's badly designed (at least not nowadays, there were problems but they were solved ten years ago) but that millions of network engineers never bothered to look deeper into IPv6 than "I don't get it, this feels off". You can't make a backwards compatible "IPv4 with more bits" like people dream of. L2 routers and middleboxes would still need to be replaced, software would still need to be rewritten, nothing would be different. IPv4 changed how private networks worked because its first attempt at private networks failed. People are stuck with the IPv4 mindset through a combination of lacking education (who even taught IPv6 when our current sysadmins were in college?) or assuming IPv4 is normal and well thought out. There are free guides, books, and playgrounds out there if you want to learn IPv6, so the education problem is one you can solve yourself. Realizing the flawed nature of IPv4 is harder. I've come from IPv4 networking, but learning IPv6 later made me realize how silly old networks really are. DHCP is a hack to solve a design failure in IPv4 and SLAAC is a much better solution. Companies have started relying on awful hacks originating from when companies decided to staple features to a side effects of a generic address distribution protocol. ARP feels more like a placeholder that should've been included a layer lower or higher in the network graph, put in its own little place to solve the theoretical "what if we don't run IP over our switch" problem that stopped being relevant decades ago. As annoying as it may be, we live in an age where the OSI model with seven layers of networking protocols don't exist. Token ring is dead, SCTP died in the womb, Ethernet II exist purely in theory. The world now runs on HTTPS on top of UDP or TCP on top of IPv6/4, on top of some kind of wire that carries ethernet. Ethernet now exists to support IP and vice versa in 99% of all use cases. TCP and UDP exist to serve HTTPS, or some legacy protocol that will be rewritten into HTTPS in the next ten years. WiFi and high-speed data networks came in as a whole new networking system and have turned out to be "what if ethernet, but wireless" with some control logic to make the wireless antennae talk. The OSI model and all the expansion and flexibility it provided simply died over a decade ago. Anything on top of the data link exists purely to support Ethernet + IP + HTTPS. The migration path to IPv6 is now blocked by excuses. People pretended to care about servers not supporting IPv6 as the reason not to use but, but three or four different ways of providing backwards compatibility to all IPv4 clients were thought up and nobody actually asked for any of them. People complained that their data center provider didn't support IPv6 but now that enabling IPv6 is just a single click in a web UI they don't enable it anyway. People cared about the IPv6 privacy risks but never let go of that concept even after rfc4941 fixed that oversight. Companies like Microsoft and Github, too incompetent to set up a network that their dollar store competitors have supported for years now, have become something to point at and go "see? we need those!" as if NAT64/DNS64/464XLAT/SIIT/whatever haven't been providing IPv4 compatibility for years now. "I don't know enough about it" and "I don't like it" are perfectly good excuses not to enable IPv6 in your home network, but they're not design flaws or protocol problems. If you're willing to accept the packet maiming we have nicknamed "NAT" or even "CG-NAT", you should feel refreshed at the sight of the plain and simple protocols IPv6 provides you with. The way people talk about IPv6 now reminds me of the way people talked about HTTPS back when Let's Encrypt started gaining popularity, and the way people dealt with systemd reinventing a better Linux management system. Grumpy people, clinging to what they know, delaying unavoidable change until the very last moment. You can be like the Dracut people running ipromiseiwillneverrunssl.com if you want, but it's a losing battle.

Helmut10001 3y ago

About a year ago I started the IPv6 migration for my home network (2 Remote sites, connected via IPSEC, with 10 VLANs (subnets) and about 70 devices, 10 people). - I started on one side of the IPSEC, where I have an OPNsense - there were like 5 updates of OPNsense in the last year where different IPv6 issues were fixed (and others have been introduced). - my ISP only hands out /64-Prefixes, and these are also dynamic, which makes configuration more difficult - a number of times I had to turn off IPv6 because different parts were suddenly not working anymore, mostly based on software issues in my stack All of that over 20 years after IPv6 was introduced makes me wonder if it is the correct technology, if it is so difficult to implement.

Faaak 3y ago
You're comparing two remote sites linked by IPv4 NAT to distributing IPv6 from a /64 (which was never meant to be subdivided) which is dynamic..
- Helmut10001 3y ago
  Yes, I know - but as the article mentions, it is not possible to "deprecate" IPv4 yet. I need both. And during this "migration phase", both IPv4+IPv6 must work alongside each other, which frankly speaking, I haven't yet managed to accomplish.
  - Faaak 3y ago
    Well, tbh dual-stack is enabled in 70% of France's customers for example. If you start with a solid base (having a fixed IPv6 /56 delegation for example), or at least a dynamic allocation with IPv6-PD, then you'll see that it's way easier than IPv4 in the long end
    - Helmut10001 3y ago
      I already get a headache when thinking of configuring firewall rules with a dynamic prefix for all my hosts.

lproven 3y ago

I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear and needs more illustrations. (Which, as a technical writer myself, I generally regard as a crutch.) I think the core argument can be summarised as this: 1. IPv6 is flawed because it has 2 main layers, but it needed 3. 2. It understands physical addresses, and it has its own logical addresses. 3. But it really needed another layer in between them: a virtual translation/mapping layer. 4. Crucially, it lacks this. As such it is not better enough than IPv4 to ever totally replace IPv4. 5. But apenwarr proposes that it is, in essence, possible to fake this using QUIC. https://en.wikipedia.org/wiki/QUIC https://en.wikipedia.org/wiki/QUIC <- note the diagram in that article. 6. Using this, it's possible to fake what IPv6 should have had but didn't, and get some of the benefits at the cost of more work. 7. However IPv6 remains doomed to never totally replace IPv4. Boiling that down to 2 key points: Point A: IPv6 is broken because it didn't go far enough; its mapping model is fundamentally inadequate. Point B: It's OK, here's how we can work around that, but it doesn't fix the problem & never will. And generalising from that argument, my take is this: Butler Lampson said: "All problems in computer science can be solved by another level of indirection." David Wheeler pointed out: "… except for the problem of too many layers of indirection." The corollary of this is: it is imperative to closely track how many layers of indirection you have. Too many is bad, but arguably, not enough is worse. With too many, you get inefficiency, but you can nonetheless get the job done. But with too few, you might not usefully be able to do the job at all. IPv6 did not have enough, and so failed to achieve its primary goal.

GordonS 3y ago
> As such it is not better enough than IPv4 That's the crux of it. Sometimes I think we'd be better off forgetting about IPv6, and starting afresh with an IPv7 - something that provides a meaningful incentive to upgrade.
- poizan42 3y ago
  IPv7 was used for the "TP/IX: The Next Internet" proposal from 1993: https://datatracker.ietf.org/doc/html/rfc1475 https://datatracker.ietf.org/doc/html/rfc1475 The next available version is IPv10

exabrial 3y ago

One thing I’ve realized lately is that scarcity is actually a benefit of ipv4, much in the way of the maximum amount of bitcoins theoretically increases their value. Ipv4 addresses are being ranked by their reputation. This is a good thing, at least right now, as it makes scammers/spammers/hackers/ddosers lives more expensive to acquire fresh addresses. This can only exist when a shortage exists.

baq 3y ago
in ipv6 you can (should) grade whole subnets as end customers typically get whole /64s.
- alyandon 3y ago
  Not always though. Lower end VPS providers seem to be moving towards placing you on a shared /64. I run into issues on a particular Digital Ocean instance of mine where my IPv6 allocation is something like a /112 and it gets swept up in bans on the parent /64 because of other's bad behavior. Then you have other providers like Vultr that do weird things like not statically route your /64 prefix to your instance which kind of defeats the entire point of having a /64.
  - jandrese 3y ago
    Digital Ocean has been in the wrong with their IPv6 allocation since the day the implemented it. One of the rules of IPv6 is never allocate less than a /64. Unfortunately their network admins don't seem to care.
- tsimionescu 3y ago
  There's still 2^64 /64 IPv6 subnets, and only 2^32 IPv4 addresses in total, of which huge swaths aren't even used.
justsomehnguy 3y ago
"People are DUI without a driver license, so let's make the driver license cost $$$$ for every Average Joe."

mnd999 3y ago

The "I don't like it, it's different" mob are out in force today. This isn't the Daily Mail.

denton-scratch 3y ago

> configuring DHCP really is a huge pain Not sure why the author is so sniffy about DHCP. To me it seems easy to understand and configure. Having said that, I appreciate the author's remarks about DHCP being a 'fake' IP protocol, and in reality being an ethernet protocol; I hadn't seen it that way before, but it's a reasonable way to look at it.

dang 3y ago

Related: The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=25568766 https://news.ycombinator.com/item?id=25568766 - Dec 2020 (131 comments) The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=20167686 https://news.ycombinator.com/item?id=20167686 - June 2019 (238 comments) The world in which IPv6 was a good design - https://news.ycombinator.com/item?id=14986324 https://news.ycombinator.com/item?id=14986324 - Aug 2017 (191 comments)

rjsw 3y ago

The author is unaware of, or has ignored, Mobile IP [1]. There are implementation of it available. [1] https://en.wikipedia.org/wiki/Mobile_IP https://en.wikipedia.org/wiki/Mobile_IP

rbanffy 3y ago

Connection roaming seems more like a TCP problem than an IP one. Wouldn’t it be wise to extend the TCP side? Or, rather, should we expect IPv6 to solve it?

systems_glitch 3y ago

Anyone else mostly fine with IPv6 like it is? Biggest complaint here is that I wish I had a way to correlate SLAAC addresses with hostnames somewhere other than the host. But I don't so when it matters I run a DDNS client on the host, which is probably the "more correct" answer anyway because the host always keeps DNS updated with its current address.

kccqzy 3y ago
I'm fine with IPv6. The more correct answer to your complaint is to dump the router's ND cache. I'm pretty sure this is part of SNMP.
- systems_glitch 3y ago
  Interesting, thanks! I'll have to see if I can get OpenBSD to do that.
  - greyface- 3y ago
    On OpenBSD, you can dump the ND cache with `ndp -an`. You'd still have to map MAC addresses to hostnames somehow.
    - systems_glitch 3y ago
      Ah hah, thanks! I can probably just correlate them with DHCPv4 leases.

chasd00 3y ago

isn't the "mostly good enough" aspect of ipv4 the biggest problem for ipv6?

systemBuilder 3y ago

I was asked by my employer in 2003 when IPv6 would replace IPv4? After substantial research, my answer was, "never"!!! I almost got fired for that answer but I am correct so far. There are a large class of people out there who do not understand the end to end argument in system design and who never saw a piece of bloatware they didn't love. For them IPv6 will happen tomorrow. They are to internet like maga people are to democracy - caustic. In 2004 IPv6 was hyped as solving the impending IPv4 address shortage. NAT had already been invented and there was no shortage as IPv4 addresses were allocated as inefficiently as possible and there was no market to buy and sell IP addresses nor was there any rental cost for owning ipv4 addresses. So it was solving a non problem. My employer Qualcomm eventually proposed using IPv6 for cell phone handsets in an overlay network called openran. This was a convenience and not a necessity because there are more than 4 billion cell phones in the world. You just don't need these bloated addresses in IPv6. You need banks of addresses mainly for the server. The client never needs 65,000 incoming or outgoing connections. The number of client computers in the world that are running as servers and that need open datagram accessibility from anywhere in the internet is virtually zero. Want it? yes! Need it - meaning impossible to do without it - No! There are always bridging workarounds to avoid giving client machines dedicated IP addresses! IPv6 is not respectful of small system design and hardly provides usable improvements to IPv4. IPv6 was a marketing tool invented by Cisco to sell bigger more expensive routers, not to solve a problem with any economy ... It is especially detrimental to IOT.

jandrese 3y ago

One thing that isn't discussed very often but is IMHO one of the bigger roadblocks for IPv6 deployment is the Berkley Socket Interface. The API that loads of code is built upon to do internet communication. The problem is that the API is too low level, or more specifically there is no high level API for it. Ideally it would have a function that looks like: int sockfd = connect_to(hostname, port, SOCK_STREAM, options_bitfield); This would allow the stack to work out the details on its own and automatically use IPv6 if available. Or whatever future protocols can provide you a STREAM socket. The old interface could also be available for people who need to do low level stuff, but most of the time this would be sufficient.

gwbas1c 3y ago

I've always seen "The Internet" as a network of networks. I interpreted the article as inferring that "every device should only speak internet, and we shouldn't have non-internet hacks to allow devices to connect to the internet." But, if we interpret the internet as a network built on top of other networks, it negates the thesis (as I interpret it) of the article. It also locks us into networking, as understood in the late 1990s, and designed into IPv6. IMO: It seems like IPv6 suffers from second system syndrome. The authors lost sight of the purpose "network built on top of other networks" and tried to add lots of features for the "other networks" that really aren't needed. Maybe it's time for IPv7? Really, all we need is IPv4 + larger address space. I'd even argue that NAT is a good thing (security feature,) because allowing devices on a private network to automatically open ports on the public internet is insecure.

hnarn 3y ago
> I'd even argue that NAT is a good thing (security feature,) Any router that I’ve come across already blocks incoming IPv6 traffic by default, so I’d have to disagree. NAT was designed for a very specific purpose and keeping it in a new implementation makes no sense if it’s not necessary, which it’s not if the hardware requires you to open incoming ports. No NAT would make it a lot easier to understand what’s happening too, since the process would be “allow traffic from the internet to this device” rather than creating a translation for an internal address, possibly having to set up a MAC reservation to ensure the DHCP lease doesn’t expire etc.

mannyv 3y ago

"Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that." RARP is basically dhcp but only for your IP address. DHCP/bootp won because you sort of need a bit more than your ip. It was also easier to manage. RARP probably still works mostly.

brian_cunnie 3y ago

I must admit I'm at a loss about this IPv6 hate. I love IPv6. I love that (almost) every IPv6 subnet is a /64. Just this morning I assumed an IPv4 subnet was a /24, only to discover it was a /20, causing me to spend a couple of minutes re-working. I love that (almost) every IPv6 is a /64 because you'll never have to widen a subnet because you started of with a /24, but then after your office grew to 200 people you had to switch to a /20. And no matter how automated you are, there are always some important devices that have static IPs and that you have to reconfigure manually. I love that every IPv6 client gets a routable IP. This means NAT isn't necessary. NAT is a clever hack, but we've grown so accustomed to it that we've become blind to its failings. I've had to trace packets coming out of a corporate NAT, then into an AWS ELB (Elastic Load Balancer) back into a different NAT. With the IP address remappings, it's awful IPv4 NAT can also lead to IP address collisions. Your home subnet is 192.168.0.0/24? And so's your work? Good luck VPN'ing in. I like that IPv6 has an abundance of IPv6 addresses—I don't need to share the ports on my sole IPv4 address to 5 different machines.

maaarghk 3y ago

A bit off topic but the most interesting part of this was clicking through to the link about TCP BBR. It's available for the Linux kernel but not bundled / enabled by default, but if these related posts are telling the truth, maybe it should be: https://djangocas.dev/blog/huge-improve-network-performance-by-change-tcp-congestion-control-to-bbr/ https://djangocas.dev/blog/huge-improve-network-performance-... https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-control-84c9c11dc3a9 https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...