| ▲ | kyledrake 2 hours ago |
| I don't like to admit this, but at this point honestly I think ipv6 is largely a failure, and I say this as someone that wrote a blog post for APNIC on how to turn on ipv6. I'll get endless pushback for this, but the reality is that adoption isn't at 100%, it very closely needs to be, and there are still entire ISPs that only assign ipv4, to say nothing of routers people are buying and installing that don't have ipv6 enabled out of the box. A much better solution here would have been an incredibly conservative "written on a napkin" change to ipv4 to expand the number of available address space. It still would have been difficult to adopt, but it would have the benefit of being a simple change to a system everyone already understands and on top of a stack that largely already exists. I'm not proposing to abandon ipv6, but at this point I'm really not sure how we proceed here. The status quo is maintaining two separate competing protocols forever, which was not the ultimate intention. |
|
| ▲ | hypeatei 2 hours ago | parent | next [-] |
| > A much better solution here would have been an incredibly conservative change to ipv4 to expand the number of available address space "And what do you base this belief on? Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6)."[0] 0: https://news.ycombinator.com/item?id=37120422 |
| |
| ▲ | avidiax an hour ago | parent | next [-] | | > Fact is you'd run into exactly the same problems as with IPv6. If you treat IPv4 addresses as a routable prefix (same as today), then the internet core routers don't change at all. Only the edge equipment would need to be IPv4+ aware. And even that awareness could be quite gradual, since you would have NAT to fall back on when receiving an IPv4 classic packet at the network. It can even be customer deployed. Add an IPv4+ box on the network, assign it the DMZ address, and have it hand out public IPV4+ addresses and NAT them to the local IPv4 private subnet. IPv6 seems to be a standard that suffered from re-design by committee. Lots of good ideas were incorporated, but it resulted in a stack that had only complicated backwards compatibility. It has taken the scale of mobile carriers to finally make IPv6 more appealing in some cases than IPv4+NAT, but I think we are still a long way from any ISP being able to disable IPv4 support. | | |
| ▲ | throw0101a 8 minutes ago | parent | next [-] | | > Only the edge equipment would need to be IPv4+ aware. "Only"? That's still the networking stack of every desktop, laptop, phone, printer, room presentation device, IoT thing-y. Also every firewall device. Then recompile every application to use the new data structures with more bits for addresses. And let's not forget you have to update all the DNS code because A records are hardcoded to 32-bits, so you need a new record type, and a mechanism to deal with getting both long and short addresses in the reply (e.g., Happy Eyeballs). Then how do you deal with a service that only has a "IPv4+" address but application code that is only IPv4-plain? Basically all the code and infrastructure that needed to be updated and deployed for IPv6 would have to be done for IPv4+. | |
| ▲ | p_l 32 minutes ago | parent | prev | next [-] | | No, routers would have to be fixed anyway, because even if you put extra bits into extension header we have 30 years of experience that routers and ISPs will regularly fuck around with those extra bits - it's related to why we have TLS GREASE option. Application rework would be exactly the same as with v6, because the issue was not with v6 but with BSD Sockets API exposing low-level details to userland. | |
| ▲ | sgjohnson 43 minutes ago | parent | prev [-] | | > Only the edge equipment would need to be IPv4+ aware. And even that awareness could be quite gradual, since you would have NAT to fall back on when receiving an IPv4 classic packet at the network. It can even be customer deployed. Add an IPv4+ box on the network, assign it the DMZ address, and have it hand out public IPV4+ addresses and NAT them to the local IPv4 private subnet. Congratulations, you’ve re-invented CGNAT, with none of the benefits, and the additional hassle of it being an entirely new protocol! No. No “extra bits” on an IPv4 address would have ever worked. NAT itself is a bug. Suggesting that as an intentional design is disingenuous. | | |
| ▲ | avidiax 23 minutes ago | parent [-] | | I have not "reinvented CGNAT". It is hierarchal public addressing similar to IPv4 and IPv6. The edge router has an IPv4+ subnet (either a classic v4 address, or part of a v4+ address). It maintains an L2 routing table with ARP+, and routes IPv4+ packets to the endpoint without translation. Private subnetting and NAT is only needed to support legacy IPv4 clients. CGNAT pools IPv4 public addresses and has an expanded key for each connection, and translates either 4 to 6 or into a private IPv4 subnet. My proposal needs no pooling and only requires translation if the remote host is IPv4 classic and the edge router is not assigned a full IPv4+/24. | | |
| ▲ | sgjohnson a few seconds ago | parent [-] | | Not just the edge router. Every router between the ISP edge and the destination edge. And since the goal is “backwards-compatability”, you’d always need to poll, because a “legacy” IPv4 client would also be unable to send packets to the IPv4+ destination. Or receive packets with an IPv4+ source address. And it would be an absolute nightmare to maintain. CGNAT + a quasi backwards-compatible protocol where the backwards-compatability wouldn’t work in practice. |
|
|
| |
| ▲ | redox99 2 hours ago | parent | prev [-] | | Hardware would catch up. And IPv4 would never go away. If you connect to 1.1.1.1 it would still be good ole IPv4. You would only have in addition the option to connect to 1.1.1.1.1.1.1.2 if the entire chain supports it. And if not, it could still be worked around through software with proxies and NAT. | | |
| ▲ | hypeatei 2 hours ago | parent [-] | | So... just a less ambitious IPv6 that would still require dual-stack networking setups? The current adoption woes would've happened regardless, unless someone comes up with a genius idea that doesn't require any configuration/code changes. | | |
| ▲ | krupan an hour ago | parent | next [-] | | I disagree. The current adoption woes are exactly because IPv6 is so different from IPv4. Everyone who tries it out learns the hard way that most of what they know from IPv4 doesn't apply. A less ambitious IPv4 is exactly what we need in order to make any progress | | |
| ▲ | throw0101a 6 minutes ago | parent | next [-] | | > I disagree. The current adoption woes are exactly because IPv6 is so different from IPv4. How is IPv6 "so different" than IPv4 when looking at Layer 3 and above? (Certainly ARP vs ND is different.) | |
| ▲ | bc569a80a344f9c 36 minutes ago | parent | prev | next [-] | | It’s not _that_ different. Larger address space, more emphasis on multicast for some basic functions. If you understand those functions in IPv4, learning IPv6 is very straightforward. There’s some footguns once you get to enterprise scale deployments but that’s just as true of IPv4. | |
| ▲ | sgjohnson 38 minutes ago | parent | prev [-] | | But that is a bug in history. IPv6 was standardized BEFORE NAT. “most what they know from IPv6” is just NAT. > A less ambitious IPv4 is exactly what we need in order to make any progress but we’re already making very good progress with IPv6? Global traffic to Google is >50% IPv6 already. | | |
| ▲ | btilly 4 minutes ago | parent | next [-] | | Current statistics are that a bit over 70% of websites are IPv4 only. A bit under 30% allow IPv6. IPv6 only websites are a rounding error. Therefore if I'm on an IPv6 phone, odds are very good that my traffic winds up going over IPv4 internet at some point. We're 30 years into the transition. We are still decades away from it being viable for servers to run IPv6 first. You pretty much have to do IPv4 on a server. IPv6 is an afterthought. | |
| ▲ | Aloisius a few seconds ago | parent | prev [-] | | [delayed] |
|
| |
| ▲ | hackthemack an hour ago | parent | prev | next [-] | | Sort of. I think people would understand 201.20.188.24.6 And most of what they know about how it works clicks in their mind. It just has an extra octet. I also think hardware would have been upgraded faster. | |
| ▲ | redox99 39 minutes ago | parent | prev [-] | | The main thing is keeping current addresses, not having both an ipv4 and ipv6 address. Just like for an apartment you append something like 5B. And for a house you don't need that. |
|
|
|
|
| ▲ | culi an hour ago | parent | prev | next [-] |
| The only solution is a gov't mandate. China went from almost no adoption to leading the world in adoption (77% of all Chinese internet users) in a few years because they explicitly prioritized it in their last 5-year-plan. The ISPs aren't gonna do it on their own. |
| |
| ▲ | p_l 31 minutes ago | parent [-] | | US government has finally learnt from how vendors break the mandates and there's now IPv6 mandate if you want to sell to federal government, and waivers are only available for buyers not vendors, and individually every time. |
|
|
| ▲ | onionisafruit 2 hours ago | parent | prev | next [-] |
| Circa 1999 I was working for Cisco as a sysadmin. I got my CCNP through internal training and considered making a career of network administration, but ipv6 changed my mind. It seemed so much more difficult and unpleasant to deal with. I didn't want that to be my day to day work. I think the same thing happens on a different scale with ISPs. They don't want to deal with it until they have to for largely the same reason. |
| |
| ▲ | sgjohnson 33 minutes ago | parent [-] | | > It seemed so much more difficult and unpleasant to deal with. In my experience it’s much easier and much more pleasant do deal with. Every VLAN is a /64 exactly. Subnetting? Just increment on a nibble boundary. Every character can be split 16 ways. It’s trivial. You don’t even need to use a subnet calculator for v6, because you can literally do that in your head. Network of 2a06:a003:1234:5678::555a:bcd7/64? Easy - the first 4 octets. Network of 10.254.158.58/27? Your cheapest shotgun and one shell please. |
|
|
| ▲ | ajross 2 hours ago | parent | prev | next [-] |
| I wouldn't say "failure". There are many, many IPv6 client devices out there, mostly on mobile networks. And it works great and they do well and the tools all support it very well. But IPv4 will never, ever die. The rise of NAT as a pervasive security paradigm[1] basically neuters the one true advantage IPv6 brought to the table by hiding every client environment behind a single address, and the rise of "cloud everything" means that no one cares enough about reaching peer devices anyway. Just this morning my son asked me to share a playlist, so of course I just send him a link to a YouTube Music URL. Want to work on a spreadsheet for family finances with your spouse in the next room? It lives in a datacenter in The Dalles. [1] And yes, we absolutely rely as a collective society on all our local devices being hidden. Yes, I understand how it works, and how firewalls could do this with globally writable addresses too, yada yada. But in practice NAT is best. It just is. |
| |
| ▲ | JeremyNT 26 minutes ago | parent [-] | | > I wouldn't say "failure". There are many, many IPv6 client devices out there, mostly on mobile networks. Honestly it's a huge success due to this fact alone. IPv6 is failure only if you measure success by replacing IPv4 or if you called "time" on it before the big mobile providers rolled it out. The fact that all mobile phones support it and many mobile networks exclusively deploy it tells you what you really need to know. IPv6 is a backbone of the modern Internet for clients, even if your servers don't have to care about it due to nat64. |
|
|
| ▲ | bigfatkitten 2 hours ago | parent | prev | next [-] |
| IPv6's failure was mostly caused by the IETF's ivory tower dwellers, who seem to generally have no practical experience or understanding whatsoever of how networks are actually built and run today, especially at the small to mid scale. Small site multihoming, for example, is an absolute disaster. Good luck if you're trying to add a cellular backup to your residential DSL connection. IETF says you should either have multiple routers advertising multiple provider-assigned prefixes (a manageability nightmare), or that you should run BGP with provider independent address space; have fun getting your residential ISP or cellular carrier onboard with this idea. |
| |
| ▲ | pigggg an hour ago | parent | next [-] | | IETF has a history of being hostile to network operators. I mean actual network operators - not the people who show up at conferences or work the mailing list who just happen to get a paycheck from a company that runs a network (and have zero production access / not on call / not directly involved in running shit). It's gotten better in the last few years in certain areas (and credit to the people who have been willing to fight the good fight). But it's very much a painful experience where you see good ideas shot down and tons of people who want to put their fingerprint on drafts/proposals - it's still a very vendor heavy environment. | | |
| ▲ | bigfatkitten an hour ago | parent [-] | | Even the vendor representatives are mostly getting paid to post on mailing lists and show up at conferences. They're not building products, and they're not supporting, visiting or even talking to their customers. Design-by-committee is a full time job that people actually building things for a living tend to not have time for. |
| |
| ▲ | nine_k an hour ago | parent | prev [-] | | > a cellular backup to your residential DSL connection Hmm, what's the problem? I suppose your home devices should never be exposed to the public internet, and should only be accessible via a VPN like Wireguard. NAT64 is a thing if your home network is IPv4. BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses? | | |
| ▲ | bigfatkitten an hour ago | parent [-] | | > BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses? Because it breaks your network when that router goes away. Your switch ACLs, firewall rules, and DNS records all become invalid because they contain addresses that no longer exist, that your devices continue trying to reach anyway. | | |
| ▲ | nine_k an hour ago | parent | next [-] | | Ah, I understand what you likely mean saying "small site multihoming": not a Web site (where it would be trivial), but e.g. a small office. But with multi-homing you would need to actively test which of your uplinks has Internet access anyway, won't you? And you would have to react somehow when one of your uplinks goes down. It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6. I still assume that you don't want the internals of your office network directly accessible via the public Internet, even when you easily can; VPNs exist for a reason. | | |
| ▲ | bigfatkitten 32 minutes ago | parent [-] | | In the IPv4 world, it's easy. Just use NAT, and forward everything over your preferred bearer. Have your router ping 8.8.8.8 or something periodically from that WAN interface to verify reachability. If your preferred link goes down, make your backup link the primary route, clear your NAT translation table, and your local devices remain mostly oblivious that anything happened. > It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6. In the IPv6 world, this is pretty much what you have to do. A whole lot of extra complexity and expense that you didn't have previously. |
| |
| ▲ | patmorgan23 an hour ago | parent | prev [-] | | You should be using dynamic DNS and firewall rules should be on the subnet boundary in this scenario, any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes. | | |
| ▲ | bigfatkitten 18 minutes ago | parent | next [-] | | > You should be using dynamic DNS That doesn't solve the problem. DNS remains broken until each and every device, assuming VERY generously that it is capable of dynamic DNS at all, realises that one of its prefixes has disappeared and it updates its DNS records. With DNS TTL and common default timeouts for prefix lifetime and router lifetime, that can take anywhere from 30 minutes to 30 days. > and firewall rules should be on the subnet boundary in this scenario, any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes. This requires you to assign one VLAN per device, unless perhaps you've got lots of money, space, and power to buy high end switches that can do EVPN-VXLAN so that you can map MAC addresses to SGTs and filter on those instead. | |
| ▲ | hdgvhicv 44 minutes ago | parent | prev | next [-] | | I want to send my ssh via my low latency reliable connection, I want to route my streaming via another connection. That’s just a routing rule and srcnat in ipv4 That’s before you go on to using PBR. I want to route traffic with different dscp via different routes. Ultimately I want the rout g to be handled by the network, not by the client. IPv4 and nat makes that a breeze. | | |
| ▲ | sekh60 36 minutes ago | parent [-] | | How is it not a routing rule with ipv6? Firewalls and routers typically support dynamic prefixes (even Vyos, pfSense, openSense do). | | |
| ▲ | hdgvhicv 35 minutes ago | parent [-] | | How do I tell my phone that I want to send traffic to server A via isp1 and server B via isp2 | | |
|
| |
| ▲ | sekh60 38 minutes ago | parent | prev [-] | | The amount of ignorance in these ipv6 posts is astounding (seems to be one every two months). It isn't hard at all, I'm just a homelabber and I have a dual-stack setup for WAN access (HE Tunnel is set up on the router since Bell [my isp] still doesn't give ipv6 address/prefixes to non-mobile users), but my OpenStack and ceph clusters are all ipv6 only, it's easy peasy. Plus subnetting is a heck of a lot less annoying that with ipv4, not that that was difficult either. | | |
| ▲ | transcriptase 27 minutes ago | parent [-] | | “it’s easy peasy” says guy who demonstrably already knows and has time to learn a bunch of shit 99.9% of people don’t have the background or inclination to. People like you talking about IPv6 have the same vibe as someone bewildered by the fact that 99.9% of people can’t explain even the most basic equation of differential or integral calculus. That bewilderment is ignorance. |
|
|
|
|
|
|
| ▲ | umanwizard 2 hours ago | parent | prev | next [-] |
| ipv6 adoption is still steadily rising. Not as fast as anyone hoped, but at least steadily. There is no way it can be abandoned at this point even if we wanted to. |
| |
| ▲ | aurumque 2 hours ago | parent [-] | | I wonder if it could still be usurped by another standard that is somehow more popular. If adoption of that leapfrogs over IPV6 then maybe it will have just been a waypoint along the way. | | |
|
|
| ▲ | kmeisthax an hour ago | parent | prev [-] |
| Stripped of all the other baggage that came with it (e.g. SLAAC, IPsec, etc) IPv6 is an incredibly conservative addressing extension. The only thing even more conservative than v6 would have been to drop the lower 64 bits of the address and the associated EUI-64 local addressing scheme. Which... to be fair, that turned out to be a very bad idea, but the length of the field isn't what was holding up v6 adoption. I suspect by "incredibly conservative" you mean "backwards compatible", which... no. You can't make an addressing extension backwards compatible with hardware that doesn't read all of the address. Of course, we did that anyway with CGNAT, and predictably it causes huge problems with end-to-end connectivity, which is the whole point of IPv6. You're probably thinking more along the lines of an explicit "extension addressing header" for v4. Problem is, that'd mean a more awkward version of IPv6's /64 address split[0], combined with all sorts of annoying connectivity problems. The same corporate middleboxes that refuse to upgrade to IPv6 also choke on anything that isn't TCP traffic to ports 80 and 443. So you'd need Happy Eyeballs style racing between CGNAT IPv4 and "extended IPv4". Also, that would just be a worse version of 6in4. Because they also thought of just tunneling IPv6 traffic in IPv4 links. I don't think you understand how incredibly conservative IPv6 actually is. The problem with "incredibly conservative" IP extensions is that nothing beats the conservatism of doing literally nothing. IT infrastructure is never ripped out and replaced unless there is a business case for doing so. The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic", they've only said "let's get more dual-stack hosts online", which is a process that only asymptotes to 100% IPv6, and never reaches it. IPv4 was not the first version of the Internet protocol. That honor goes to Network Control Protocol (NCP). The reason why we don't have an asymptotic long tail of Internet hosts still demanding NCP connectivity is because this was back when "having a connection to the Internet" meant "having a connection to ARPANET". The US military could just refuse to process NCP packets and actively did this to force people onto IPv4. Now imagine if someone big like Google said "we're going to stop accepting IPv4 connections" - people would jump onto v6 immediately. [0] Let's say we add a 32-bit extension header onto IPv4 |
| |
| ▲ | WorldMaker an hour ago | parent | next [-] | | > The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic" Mobile carriers have done that between consumer devices and network towers. That forced a lot of innovation (including tools like better DNS64 and "happy eyeballs" protocols) and network stack hardening. The roll out of out CGNAT in some cases is "let's drop IPv4 traffic randomly" and "happy eyeballs" in consumer devices is transparently driving a lot of consumer traffic to IPv6. This is why mobile and consumer devices are leading the pack on IPv6 adoption. It's maybe not all of Google that next needs to say "we're going to stop accepting IPv4 traffic", it's maybe more specifically GCP (and AWS and Azure) that need to do that to drive the non-consumer IPv6 push we need. The next best thing would be for all the cloud providers to at least start raising IPv4 address prices until their clients start to feel them. | |
| ▲ | eqvinox 43 minutes ago | parent | prev | next [-] | | > The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic"… One of the giant CDNs translates all IPv4 traffic to IPv6 at the edge (stateless NAT46) and is IPv6-only in its core network (for one of its primary product networks; like everybody they have multiple networks.) | | |
| ▲ | p_l 27 minutes ago | parent [-] | | Multiple networks do the same - Both T-Mobile (at least in EU) and Orange no longer actually support v4 other than through funky 464 and by funky I mean really funky at times. |
| |
| ▲ | krupan an hour ago | parent | prev [-] | | "Stripped of all the other baggage that came with it..." But that baggage is a huge part of the problem. Almost nothing you know about IPv4 applies when you switch to IPv6, and most of us found that out the hard way when we tried to make the switch. Leaves a pretty bad taste in your mouth. | | |
| ▲ | patmorgan23 an hour ago | parent [-] | | I mean this is just wrong. Routing and switching behave exactly the same in V6 vs V4. Details on how you get an IP and what it looks like changed but there's TONS of knowledge shared between the two. | | |
| ▲ | krupan 9 minutes ago | parent | next [-] | | "Details on how you get an IP and what it looks like changed but..." This is exactly what I'm talking about. When you have problems with your IP network, that's the first thing you try and figure out, "what's my address? Why is that my address? Did it change? If so, why? Are other devices able to get packets? What are their addresses? Why can those addresses get packets but this address can't?" | |
| ▲ | sgjohnson 27 minutes ago | parent | prev [-] | | Yes, the only key difference is that NAT is gone. Also a nitpick: switching is irrelevant here, that’s L2. L2 doesn’t even know what’s an IP address :) There was some dude on YouTube that resurrected the first Ethernet bridge (which was built for thicknet) - I recall even that worked with IPv6. |
|
|
|