[HN Gopher] IPv6 traffic crosses the 50% mark
___________________________________________________________________
IPv6 traffic crosses the 50% mark
Author : Aaronmacaron
Score : 765 points
Date : 2026-04-15 11:59 UTC (1 days ago)
(HTM) web link (www.google.com)
(TXT) w3m dump (www.google.com)
| miyuru wrote:
| crossed 50% on Mar 28, 2026, 3 weekends back.
|
| google published the latest data only yesterday, hence the delay.
| randompartytime wrote:
| we did it, boys!
|
| despite the smoothbrain naysayers:
|
| https://circleid.com/posts/20190529_digging_into_ipv6_traffi...
|
| finally, the end of the dark tunnel of NAT is in sight, and the
| internet will be free once more
| usui wrote:
| It has barely hit 50% and it's already plateauing. This adoption
| rate is ridiculous despite basically all network interfaces
| supporting it. I thought I would see IPv6 take over in my
| lifetime as the default for platforms to build on but I can see I
| was wrong. Enterprise and commercial companies are literally
| going to hold back internet progress around 60 to 75 years
| because it's in their best interest to ensure users can't host
| services without them. Maybe even 75 years might be too
| optimistic? They are literally going to do everything in their
| power to avoid the transition, either being dragged out kicking
| and screaming or throwing their hands up and saying they can't
| support IPv6 because it costs too much.
|
| Try going IPv6-only by disabling IPv4 on your computer as a test
| and notice that almost nothing works except Google. End users
| shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs
| doing that to prepare for the transition.
|
| Also, notice how Android and iOS don't support turning off IPv4.
| imoverclocked wrote:
| ISPs often fail to do this because there is always someone in
| the hierarchy who says, "nobody is demanding it."
| FridgeSeal wrote:
| I worked at a place where they refused to run it _anywhere_
| because a couple of people were insistent that it was
| "insecure".
| Galanwe wrote:
| ... and they were right.
|
| v6 adoption is often an all or nothing, because if you run
| both stacks, you have to ensure they are consistent. While
| you can reasonably do it on your home LAN, doing it across
| an entire infrastructure is the worst.
|
| Now you have to make sure all your subnets, routing, VLANs,
| firewall rules, etc work exactly the same in two protocols
| that have very little in common.
|
| It is the equivalent of shipping two programs in different
| languages and maintaining exact feature parity between both
| at all times.
| kstrauser wrote:
| I genuinely don't understand this. The concepts are
| nearly identical between the two.
| Galanwe wrote:
| Hum no, to me they are orthogonal.
|
| v4 was built around the idea of multiple free standing
| networks linked by gateways. v6 was built around the idea
| of a universal network.
|
| I dont care about what your LAN adress space look like
| when I'm in my LAN, because we are not in the same v4
| network. I am sovereign in my network.
|
| With v6, everyone is effectively in the same network. I
| have to ask my ISP for a prefix that he will rent me for
| money even for my LAN. If I want some freedom from said
| ISP prefix, I am mercifully granted the honor of managing
| ULA/NAT66 (granted I paid for a fancy router).
|
| Also if I want any kind of privacy, I will have to manage
| privacy extensions and the great invention of having to
| use automatically generated, dynamically routed,
| essentially multiple random IPs per interface. How lucky
| am I to use such a great new technology.
|
| Seriously v6 was created by nerds in a lab with no
| practical experience of what people wanted.
| kstrauser wrote:
| v4 and v6 were build around the exact same use cases.
|
| > With v6, everyone is effectively in the same network.
|
| Just like IPv4.
|
| > I have to ask my ISP for a prefix that he will rent me
| for money even for my LAN.
|
| Just like IPv4, if you need a static address.
|
| > If I want some freedom from said ISP prefix, I am
| mercifully granted the honor of managing ULA/NAT66
| (granted I paid for a fancy router).
|
| Compared with IPv4, where if you want some freedom from
| said ISP subnet, you are mercifully granted the honor of
| managing RFC-1918 addresses/NAT (granted you paid for a
| router that doesn't screw it up).
|
| > Also if I want any kind of privacy, I will have to
| manage privacy extensions
|
| ...which are enabled by default nearly universally
|
| > and the great invention of having to use automatically
| generated, dynamically routed, essentially multiple
| random IPs per interface.
|
| Make up your mind. Are rotating, privacy-preserving
| addresses good or bad? The way it works in real life, not
| in the strawman version, is that you (automatically!) use
| the random addresses for outgoing connections and the
| fixed addresses for incoming.
| ThatPlayer wrote:
| > v4 was built around the idea of multiple free standing
| networks linked by gateways.
|
| I don't think this is what v4 was built around, but
| rather what v4 turned into.
|
| CIDR wasn't introduced until 1993. NAT in 1994. Both to
| handle depleting IP addresses.
| sethops1 wrote:
| This is exactly why I decided not to enable IPv6 on my
| colo. When money is involved, the benefits of IPv6 simply
| do not outweigh the risk, in my estimation. If my side
| gig eventually pays enough to pay a contractor to handle
| networking then sure, that'll be one of the first tasks.
| But when it's just me managing the entire stack, my
| number one priority is security, and for now that means
| keeping things simple as possible.
| bluGill wrote:
| I with I knew how to get through that I want it. I'm supposed
| to be a tech guy - that means I need experience with the
| latest tech in my house
| moduspol wrote:
| I switched my home ISP from cable (which supported IPv6) to
| fiber (which doesn't) and I've had a nagging disappointment
| ever since. But I guess consumers aren't really demanding
| it enough.
| betaby wrote:
| Nobody is demanding IPv4 either. Or Ethernet. People buy "Wi-
| Fi", literally "Wi-Fi", not Internet access.
| vel0city wrote:
| It has been interesting to me to see how the usage of "my
| wifi bill" instead of "my internet bill" has shifted.
| kentm wrote:
| Exactly. To this point I went to a Comcast store to cancel
| my internet and the person asked me if I meant I wanted to
| cancel my "Wi-Fi". I was very confused for a couple
| seconds.
| throw0101d wrote:
| > _ISPs often fail to do this because there is always someone
| in the hierarchy who says, "nobody is demanding it."_
|
| I'm with an ISP whose landline/fibre division does not have
| IPv6, but whose mobile division gives IPv6 to handsets.
| themafia wrote:
| Comcast, one of the largest residential ISPs in the USA, has
| almost full IPv6 deployment by default. The majority Verizon
| Wireless is IPv6 by default. Residential customers in the USA
| have great access if they just enable the stack.
|
| There is nothing about IPv6 that prevents ISPs from filtering
| ports for all customers. They almost all actively filter at
| least port 25, 139 and 445 regardless of the actual transport.
| So I'm not sure "blocking service hosting" is the actual goal
| here.
|
| The problem seems to be that all of the large and wealthy
| nations of the world have made the necessary huge investments
| into IPv6 while many of their smaller neighbors and outlying
| countries and islands have struggled to get any appreciable
| deployment.
|
| It should be a UN and IMF priority to get IPv6 networks
| deployed in the rest of the world so we can finally start
| thinking about a global cutover.
| dtech wrote:
| In many developing countries IPv6 adoption is far and
| sometimes networks are IPv6-only, because IPv4 is expensive
| and they have relatively little addresses compared to
| users...
|
| You can see southeast Asia is pretty green on the map of the
| post.
| kortilla wrote:
| A UN priority!? They have real issues they should be dealing
| with like the life and death of millions of people
| themafia wrote:
| I think it's fine if they have more than one priority.
| realityking wrote:
| To be fair to the grand parent, the International
| Telecommunications Union is a specialized agency of the UN
| and actively promoting IPv6:
| https://www.itu.int/en/ITU-T/ipv6/Pages/default.aspx
| zokier wrote:
| > End users shouldn't need to set up 6to4 tunneling. It should
| be ISPs doing that to prepare for the transition.
|
| Which is what ISP are doing with 464XLAT deployments.
| IPv6-mostly networking and IPv4-as-a-service are things that
| are happening in real world right now.
| kalleboo wrote:
| Yeah in Japan my ISP even lets me choose which IPv4 provider
| I want to use, as the fiber network is IPv6-native and IPv4
| is "just another service" like IPTV.
| lxgr wrote:
| Wow, that's very cool! Do you know how that works? Do they
| just connect you to a NAT64 gateway of your choice?
| kalleboo wrote:
| IPv4 is provided using DS-Lite or MAP-E depending on the
| provider.
|
| I'm using OpenWRT and paid for a static IP so I had to
| manually configure all the details for the MAP-E tunnel
| in OpenWRT myself, I think typically the routers sold to
| consumers pick up the configuration automatically
| somehow.
| usui wrote:
| Which provider are you using? I'm curious about this
| since there are not many OpenWrt guides for getting
| connected in Japan. Is your config similar to this write-
| up? https://github.com/fakemanhk/openwrt-jp-ipoe
|
| I didn't need to do any configuration for DS-Lite or
| MAP-E, as DHCPv6 with a configured prefix got IPv6
| working, although DNS is still broken when turning off
| IPv4 entirely.
| lxgr wrote:
| Woah, MAP-E allows static v4 (and presumably inbound
| connections)? That seems neat and much better than DS-
| Lite!
| preisschild wrote:
| > It should be ISPs doing that to prepare for the transition.
|
| Yeah, I dont get why more ISPs don't offer carrier-grade NAT64
| instead of the typical CGNAT
| lmm wrote:
| In parts of the world with fewer IP addresses they already
| are. My ISP _only_ offers MAP-E access to the IPv4 internet
| for anyone not grandfathered into an older plan.
| ianburrell wrote:
| NAT64 doesn't make sense for consumers. There are too many
| apps that hardcoded IPv4 in their code. People are going to
| complain that their old Xbox games don't work.
|
| For most people, dual stack works fine. For mobile, the
| solution is 464XLAT that translates locally. There is MAP-E
| that does translation on gateway with IPv4 on local network.
|
| For businesses, NAT64 makes more sense cause they can control
| what software is running. Even there, usually have to make
| IPv4 subnet for the old printers.
| preisschild wrote:
| > There are too many apps that hardcoded IPv4 in their code
|
| That would work over CLAT, which most operating systems
| support. Steam has this issue, clat works around it while
| still using a ipv6-only net.
|
| https://github.com/ValveSoftware/steam-for-
| linux/issues/3372...
| keeperofdakeys wrote:
| Nearly all ISPs these days are deploying IPv6 for their mobile
| networks and core service networks, especially in less
| developed markets^1. The reason is simple, a cost
| justification. What doesn't exist is a cost justification for
| Enterprises to deploy IPv6, and for ISPs to deploy Residential
| / Corporate Internet IPv6.
|
| IMO with the right market conditions, IPv6 could spread really
| fast within 6-24 months. For example, most cloud providers are
| now charging for IPv4 addresses when IPv6 is free. Small
| changes like that push in the right direction.
|
| ^1 https://www.theregister.com/2025/08/04/asia_in_brief/
| reddalo wrote:
| Hetzner makes you pay 1 EUR per IPv4, while IPv6 is free. I'd
| gladly get rid of all IPv4's given that I have many servers.
| saltyoldman wrote:
| I don't even know why clouds offer public IP addresses. In
| my opinion all clouds should only have a gateway that
| routes via host header for millions of customers. IPv4
| should be a special priv for special situations at a higher
| price. Then these clouds could own maybe 20 IPs total
| instead of millions.
| seabrookmx wrote:
| > host header
|
| Not all workloads are HTTP.
|
| > gateway .. for millions of customers
|
| That's basically what an AWS ALB is. It's not
| provisioning bespoke infrastructure when you create it..
| it's just a routing rule in their shared infra.
|
| If Amazon wanted, they could easily have shared IP's but
| the cost of an IPv4 isn't so great that this approach has
| been warranted yet, clearly.
| saltyoldman wrote:
| Yeah I get all that, but the only two connection types
| that are useful are http/s/ and ssh. SSH can have work-
| arounds like the way google does.
|
| Let's let the people that want non http workloads pay
| more.
| kstrauser wrote:
| > In my opinion all clouds should only have a gateway
| that routes via host header for millions of customers.
|
| This is incompatible with TCP/IP networking. In TCP
| connections, (sender_address, sender_port,
| receiver_address, receiver_port) is a unique combination.
| Those numbers together uniquely identify the sender
| talking to the receiver. For a public webserver:
|
| * sender_address is the client machine's IP address
|
| * sender_port is a random number from 0..65535 (not
| quite, but let's pretend)
|
| * receiver_address is the webserver's IP address
|
| * receiver_port is 443
|
| That means it'd be impossible for one client IP to be
| connected to one server IP more than 65535 times. Sounds
| like a lot, right?
|
| * sender_address is the outbound NAT at an office with
| 10,000 employees
|
| Now each user can have at most 6.5 connections on average
| to the same webserver. That's _probably_ not an issue, as
| long as the site isn 't a major news org and nothing
| critical is happening. Now given your scheme:
|
| * receiver_address is the gateway shared by 10000
| websites
|
| Now each user can have at most 6.5 connections _to all of
| those 10000 websites combined, at once, total, period_.
| Or put another way, 100,000,000 client /website combos
| would have to fit into the same 65535 possible
| sender_ports. Hope you don't plan on checking your
| webmail and buying airline tickets at the same time.
| andix wrote:
| But their VLANs still only support ipv4, which makes it
| hard to route external ipv6 traffic through the VLANs. You
| need tunnels.
| Avamander wrote:
| OVH does the same, but only gives you a /128. Which is
| ridiculously shitty of them.
| dsl wrote:
| Imagine if one day someone came up with a "better" way to
| chew food, but you had to learn how to do a super complex jaw
| movement and it wouldn't work in restaurants. It has no
| obvious benefit to you. The only motivation is that a small
| group of obsessively passionate (but not in a good way)
| people say at some unknown point in the future food won't be
| edible anymore.
|
| IPv6 just tried to do too much so it failed at everything.
| Putting letters in IP addresses made it near impossible to
| remember what your network settings were supposed to be.
|
| It is nothing short of a miracle that devices can even get
| IPv6 addresses. SLAAC was supposed to replace DHCP, but it
| couldn't provide DNS server addresses. DHCPv6 was introduced
| to replace SLAAC, but this time they forgot to add a way to
| communicate a default route. This lead to Cisco, Microsoft,
| and Google all taking completely different approaches, and
| the IETF helpfully blocking any efforts at cross vendor
| standardization because of v6 zealots.
| stackghost wrote:
| Is there a reason why adoption has been so abysmally slow? Like
| surely all the big players have updated their networking
| equipment by now, and surely every piece of enterprise-grade
| kit sold in the last 20 years has supported v6.
|
| The only arguments I've ever heard against ipv6 that made any
| sense are that:
|
| 1: it's hard to remember addresses, which is mayyyyybe valid
| for homelab enthusiast types, but for medium scale and up you
| ought to have a service that hands out per-machine hostnames,
| so the v6 address becomes merely an implementation detail that
| you can more or less ignore unless you're grepping logs. I have
| this on my home network with a whopping 15 devices, and it's
| easy.
|
| and 2: with v6 you can't rely on NAT as an ersatz firewall
| because suddenly your printer that used to be fat dumb and
| happy listening on 192.168.1.42 is now accidentally globally-
| routable and North Korean haxors are printing black and white
| Kim Il Sung propaganda in your home office and using up all
| your toner. And while this example was clearly in jest there's
| a nugget of truth that if your IOT devices don't have globally-
| routable addresses they're a bit harder to attack, even though
| NAT isn't a substitute for a proper firewall.
|
| But both of these are really only valid for DIY homelab
| enthusiast types. I honestly have no idea why other people
| resist ipv6.
| nubinetwork wrote:
| > Like surely all the big players have updated their
| networking equipment by now
|
| My home isp can't even do symmetrical gigabit, let alone
| ipv6...
| esseph wrote:
| That's extremely common unless on "active" fiber (vs GPON,
| DOCSIS3, DSL, most fixed wireless, satellite, mobile, etc.)
|
| Your wifi isn't symmetrical either.
| Hikikomori wrote:
| Those are designed to have static asymmetrical bandwidth
| though, *dm split gives ISP side more of possible shared
| bandwidth. Wifi bandwidth is shared and dynamic so client
| can use all of it.
| esseph wrote:
| > Those are designed to have static asymmetrical
| bandwidth though
|
| Yes, that's why I said that?
|
| > *dm split
|
| No idea what you're trying to say here.
| direwolf20 wrote:
| Ignore all the excuses like longer addresses and incompatible
| hardware. The _actual_ reason is that everyone hates change.
| crote wrote:
| Sure, the _data plane_ supports it - but what about the
| management plane?
|
| I wouldn't be surprised if ISPs did all the management tasks
| through a 30-year-old homebrew pile of technical debt, with
| lots of things relying on basic assumptions like "every
| connection has exactly one ip address, which is 32 bits
| long".
|
| Porting all of that to support ipv6 can easily be a multi-
| year project.
| Sesse__ wrote:
| > Porting all of that to support ipv6 can easily be a
| multi-year project.
|
| FWIW, as someone who has done exactly this in a megacorp
| (sloshing through homebrew technical debt with 32-bit
| assumptions baked in), the initial wave to get the most
| important systems working was measured in person-months.
| The long tail was a slog, of course, but it's not an all-
| or-nothing proposition.
| Hikikomori wrote:
| This is true, I worked for an old ISP/mobile carrier that
| started in the 80s about 10-15 years ago. They had
| basically any system you could think of still running, from
| decently modern vmware with windows and linux to hp-ux,
| openvms, sunos, AIX, etc. Could walk around and see
| hardware 30 years old still going, I think one console
| router had an uptime of 14 years or so. One time I opened a
| cabinet and found a pentium 1 desktop pc on the floor still
| running and connected, served some webpage. The old SMSC
| from the 80s on DEC hardware was still in its racks though
| not operational, they didn't need the space as the room
| couldn't provide enough power or cooling for more than a
| few modern racks. The planning program for fiber,
| transmission, racks, etc, required such an old java that
| new security bugs didn't apply to it, and looked and worked
| like an old mainframe program.
|
| The core team supported ipv6 for a long time, but its
| rather easy to do that part. The hard part is the customer
| edge and CPE and the stack to manage it, it may have a
| lifetime of 2 decades.
| mjcl wrote:
| Comcast actually implemented IPv6 10-15 years ago so that
| they could unify the management of all of their cable
| modems. Prior to that they had many regional networks using
| with modems assigned management IPs in overlapping private
| IPv4 ranges.
| noirscape wrote:
| The big reason is that domestic ISPs don't want to switch
| (not just in the US, but everywhere really.)
|
| Data centers and most physical devices made the jump pretty
| early (I don't recall a time where the VPS providers I used
| didn't allow for IPv6 and every device I've used has allowed
| IPv6 in the last 2 decades besides some retro handhelds), but
| domestic ISPs have been lagging behind. Mobile networks are
| switching en masse because of them just running into internal
| limits of IPv4.
|
| Domestic ISPs don't have that pressure; unlike mobile
| networks (where 1 connection needing an IP = 1 device), they
| have an extra layer in place (1 connection needing an IP = 1
| router and intranet), which significantly reduces that
| pressure.
|
| The lifespan of domestic ISP provided hardware is also
| completely unbound by anything resembling a security patch
| cycle, cost amortization or value depreciation. If an ISP
| supplies a device, unless it fundamentally breaks to a point
| where it quite literally _doesn 't work anymore_ (basically
| hardware failure), it's going to be in place forever. It took
| _over 10 years_ to kill WEP in favor of WPA on consumer grade
| hardware. To support IPv6, domestic ISP providers need to do
| a mass product recall for all their ancient tech and they don
| 't want to do that, because there's no real pressure to do
| it.
|
| IPv6 exists concurrently with IPv4, so it's easier for ISPs
| to make anyone wanting to host things pay extra for an IPv4
| address (externalizing an ever increasing cost on sysadmins
| as the IP space runs out of addresses) rather than upgrade
| the underlying tech. The internet default for user facing
| stuff is still IPv4, not IPv6.
|
| If you want to force IPv6 adoption, major sites basically
| need to stop routing over IPv4. Let's say Google becomes
| inaccessible over IPv4 - I guarantee you that within a year,
| ISPs will suddenly see a much greater shift towards IPv6.
| ENGNR wrote:
| It's frustrating that even brand new Unifi devices that
| claim to support IPv6 are actually pretty broken when you
| try to use it. So 10 years from right now even, unless they
| can software patch it upwards.
| stackghost wrote:
| Interesting, what's broken for you? I have some unifi
| gear and it handles v6 no problem.
| zokier wrote:
| Except that is completely wrong. Consumer/residential
| networks have significantly higher ipv6 adoption rates that
| corporate/enterprise networks. That is why you see such
| clear patterns (weekend vs weekday) in the adoption graphs.
| bluGill wrote:
| There are still a lot that have not.
| cyberax wrote:
| IPv6 is a recursive WTF. It might _look_ like a conservative
| expansion of IPv4, but it's really not. A lot of operational
| experience and practices from IPv4 don't apply to IPv6.
|
| For example, in IPv4 each host has one local net address, and
| the gateway uses NAT to let it speak with the Internet.
| Simple and clean.
|
| In IPv6 each host has multiple global addresses. But if your
| global connection goes down, these addresses are supposed to
| be withdrawn. So your hosts can end up with _no_ addresses.
| ULA was invented to solve this, but the source selection
| rules are STILL being debated:
| https://www.ietf.org/archive/id/draft-ietf-6man-
| rfc6724-upda...
|
| Then there's DHCP. With IPv4 the almost-universal DHCP serves
| as an easy way to do network inspection. With IPv6 there's
| literally _nothing_ similar. Stateful DHCPv6 is not supported
| on Android (because its engineers are hell-bent on preventing
| IPv6). And even when it's supported, the protocol doesn't
| require clients to identify themselves with a human-readable
| hostname.
|
| Then there's IP fragmentation and PMTU that are a burning
| trash fire. Or the IPv6 extension headers. Or....
|
| In short, there are VERY good reasons why IPv6 has been
| floundering.
| yangm97 wrote:
| The reason: Skill issue.
| philipallstar wrote:
| How do the working IPv6 deployments cope with these issues?
| cyberax wrote:
| The simple answer is: they just don't deploy IPv6.
|
| These days you can use ULA and third-party monitoring
| tools instead of DHCP.
| dwattttt wrote:
| > For example, in IPv4 each host has one local net address,
| and the gateway uses NAT to let it speak with the Internet.
| Simple and clean.
|
| I assume you mean "interface", not "host". Because it's
| absolutely not true that a host can only have one "local
| net address".
|
| EDIT: a brief Google also confirms that a single interface
| isn't restricted to one address either: sudo ip address add
| <ip-address>/<prefix-length> dev <interface>
| teddyh wrote:
| > _For example, in IPv4 each host has one local net
| address, and the gateway uses NAT to let it speak with the
| Internet. Simple and clean._
|
| No, that's not the IPv4 design. That's an _incredibly ugly
| hack_ to cope with IPv4 address shortage. It was never
| meant to work this way. IPv6 _fixes_ this to again work
| like the original, _simpler_ design, without "local"
| addresses or NAT.
|
| > _In IPv6 each host has multiple global addresses._
|
| Not necessarily. You can quite easily give each host one,
| and only one, static IPv6 address, just like with old-style
| IPv4.
| cyberax wrote:
| Hyrum's law. That's how IPv4 is being used in practice.
|
| > You can quite easily give each host one, and only one,
| static IPv6 address, just like with old-style IPv4.
|
| You literally CAN NOT. On Android there's no way to put
| in a static IPv6 or even use stateful DHCPv6.
| Dylan16807 wrote:
| > Hyrum's law. That's how IPv4 is being used in practice.
|
| It's still very ugly to mess with the ports that way.
|
| The only clean NAT is 1:1 IP NAT.
| holowoodman wrote:
| > For example, in IPv4 each host has one local net address,
| and the gateway uses NAT to let it speak with the Internet.
| Simple and clean.
|
| That's only true for smalltime home networks. Try to merge
| 2 company IPv4 networks with overlapping RFC1918 ranges
| like 10.0.0.0/8. We'll talk again in 10 years when you are
| done sorting out that mess ;)
|
| > In IPv6 each host has multiple global addresses. But if
| your global connection goes down, these addresses are
| supposed to be withdrawn. So your hosts can end up with
| _no_ addresses.
|
| Only a problem for home users with frequently changing
| dialup networks from a stupid ISP. And even then: Your host
| can still have ULA and link-local addresses
| (fe80::<mangled-mac-address>).
|
| > ULA was invented to solve this, but the source selection
| rules are STILL being debated:
| https://www.ietf.org/archive/id/draft-ietf-6man-
| rfc6724-upda...
|
| RFC6724 is still valid, they are only debating a slight
| update that doesn't affect a lot.
|
| > Then there's DHCP.
|
| DHCPv6 is an abomination. But not for the reasons you are
| enumerating.
|
| > With IPv4 the almost-universal DHCP serves as an easy way
| to do network inspection.
|
| IPv4 DHCP isn't a sensible means to do network inspection.
| Any rougue client can steal any IP and MAC address
| combination by sniffing a little ARP broadcast traffic. Any
| rogue client can issue themselves any IPv4 address, and
| even well-behaved clients will sometimes use 169.254.0.0/16
| (APIPA) if they somehow didn't see a DHCP answer. If you
| want something sensible, you need 802.1x with some strong
| cryptographic identity for host authentication.
|
| > Stateful DHCPv6 is not supported on Android (because its
| engineers are hell-bent on preventing IPv6).
|
| Yes, that is grade-A-stupid stubborness. On the other hand,
| see below for the privacy hostname thingy in IPv4 and the
| randomized privacy mac addresses that mobile devices use
| nowadays. So even if Android implemented stateful IPv6, you
| will never be reliably able to track mobile devices on your
| network. Because all those identifiers in there will be
| randomized, and any "state" will only last for a short
| time. If you want reliable state, you need secure
| authentication like 802.1x on Ethernet or WPA-Enterprise on
| Wifi, and then bind that identity to the addresses
| assigned/observed on that port.
|
| > With IPv6 there's literally _nothing_ similar.
|
| Of course there is. DHCPv6 can do everything that IPv4 DHCP
| can do (by now, took some time until they e.g. included MAC
| addresses as an option field). But in case of clients like
| Android that don't do DHCPv6 properly, you still have
| better odds in IPv6: IPv6 nodes are required to implement
| multicast (unlike in IPv4 where multicast was optional). So
| you can just find all your nodes in some network scope by
| just issuing an all-nodes link-local multicast ping on an
| interface, like:
|
| > ping6 ff02::1%eth0
|
| There are also other scopes like site-local: > ping6
| ff05::1%eth0
| https://www.iana.org/assignments/ipv6-multicast-
| addresses/ip...
|
| (The interface ID (like eth0, eno1, "Wired Network", ...)
| is necessary here because your machine usually has multiple
| interfaces and all of those will support those multicast
| ranges, so the kernel cannot automatically choose for you.)
|
| > And even when it's supported, the protocol doesn't
| require clients to identify themselves with a human-
| readable hostname.
|
| DHCP option 12 ("hostname") is an option in IPv4. Clients
| can leave it out if they like. There is also such a thing
| as "privacy hostname" which is a thing mobile devices do to
| get around networks that really want option 12 to be set,
| but don't want to be trackable. So the hostname field will
| be something like "mobile-<daily_random>".
|
| What you skipped are the really stupid problems with DHCPv6
| which make it practically useless in many situations:
| DHCPv6 by default doesn't include the MAC address in
| requests. DHCPv6 forwarders may add that option, but in
| lots of equipment this is a very recent addition still
| (though the RFC is 10 years old by now). So if you unbox
| some new hardware, it will identify by some nonsensical
| hostname (useless), an interface identifier (IAID, useless,
| because it may be derived from the MAC address, but it may
| also be totally random for each request) and a host
| identifier (DUID, useless, because it may be derived from
| the mac address, but it may also be totally random for each
| request). Whats even more stupid, the interface identifier
| (IAID) can be derived from a MAC address that belongs to
| another interface than the one that the request is issued
| on. So in the big-company usecase of unboxing 282938 new
| laptops with a MAC address sticker, you've got no chance
| whatsoever to find out which is which, because neither IAID
| nor DUID are in any way predictable. You'll have to boot
| the installer, grab the laptop's serial number somewhere in
| DMI and correlate with that sticker, so tons of extra
| hassle and fragility because the DHCPv6 people thought that
| nobody should use MAC addresses anymore...
| cyberax wrote:
| > That's only true for smalltime home networks. Try to
| merge 2 company IPv4 networks with overlapping RFC1918
| ranges like 10.0.0.0/8. We'll talk again in 10 years when
| you are done sorting out that mess ;)
|
| Look, I've been doing IPv6 for 20 years, starting with a
| 6to4 tunnel and then moving to HE.net before getting
| native connectivity. I'm probably one of the first people
| who started using Asterisk for SIP on an actual
| IPv6-enabled segmented network.
|
| I _know_ all the pitfalls of IPv6 and IPv4. And at this
| point, I'm 100% convinced that NAT+IPv4 is not just an
| accidental artifact but a better solution for most
| practical purposes.
|
| > What you skipped are the really stupid problems with
| DHCPv6 which make it practically useless in many
| situations: DHCPv6 by default doesn't include the MAC
| address in requests.
|
| Yes. DUIDs were another stupid idea. As I said, IPv6 is a
| cascade of recursive WTFs at every step of the way.
|
| And let me re-iterate, I'm not interested in academic
| "but acshually" reasons. I know that you can run IPv4
| with DHCP giving out publically routable IPv4 addresses
| to every host in the internal network without NAT. Or
| that you can do NAT on IPv6 or laboriously type static
| IPv6 addresses in your config.
|
| What matters is the actual operational practice. Do you
| want a challenge? Try to do this:
|
| 1. An IPv6 network for a small office with printers, TVs,
| and perhaps a bunch of smart lightbulbs.
|
| 2. With two Internet uplinks. One of them a cellular
| modem and another one a fiber connection.
|
| 3. You want failover support, ideally in a way that does
| not interrupt Zoom meetings or at least not for more than
| a couple of seconds.
|
| 4. No NAT (because otherwise why bother with IPv6?).
|
| Go on, try that. This is something that I can do in 10
| minutes using an off-the-shelf consumer/prosumer router
| and IPv4. With zero configuration for the clients, apart
| from typing the WiFi password.
| holowoodman wrote:
| Well, I can do that with OpenWRT, no idea which prosumer
| devices already implement this, but it isn't rocket
| science: Announce the Prefix of the currently active
| connection, invalidate the other one. Will interrupt all
| your TCP connections, but they are toast anyways, most
| software should handle this just fine. It's quite the
| same as a Wifi-to-Cellular handover.
| cyberax wrote:
| > Announce the Prefix of the currently active connection,
| invalidate the other one
|
| And this doesn't actually work. Prefix deprecation is a
| best-effort feature that is not implemented correctly in
| tons of devices, including such rarely used niche
| operating systems as macOS. It even technically violates
| RFC4862 (section 5.5.3).
|
| As usual, IETF only recently woke up to that reality:
| https://datatracker.ietf.org/doc/html/rfc8978
|
| I highly recommend actually trying what I proposed. Not
| in a theoretical hand-wavy way, but actually setting it
| all up and verifying that it works. I did not pose this
| challenge in a "gotcha" way. I really was not able to
| make it work cleanly with either Mikrotik or OpenWRT
| routers.
| toast0 wrote:
| > Then there's IP fragmentation and PMTU that are a burning
| trash fire.
|
| It's not significantly worse on v6 compared to v4. Yes, in
| theory, you can send v4 packets without DF and helpful
| routers will fragment for you. In practice, nobody wants
| that: end points don't like reassembling and may drop
| fragments; routers have limited cpu budget off the fast
| path and segment too big is off the fast path, so too big
| may be dropped rather than be fragmented and with DF, an
| ICMP may not always be sent, and some routers are
| configured in ways where they can't ever send an ICMP.
|
| PMTUd blackholes suck just as much on v4 and v6. 6rd
| tunnels maybe make it a bit easier to hit if you advertise
| mtu 1500 and are really mtu 1480 because of a tunnel, but
| there's plenty of derpy networks out there for v4 as well.
| kalleboo wrote:
| > _but there 's plenty of derpy networks out there for v4
| as well._
|
| God yes, I've helped so many users on PPPoE by telling
| them to set their MTU to something lower...
| cassianoleal wrote:
| In my case, I set the MTU of the physical NIC to 1508 and
| kept the PPPoE interface at 1500. Best of both worlds.
| Needs the ISP to support it though.
| cyberax wrote:
| IPv4 allows fragmentation by the middleboxes, which in
| practice papers around a lot of PMTU issues.
|
| The IPv6 failing was not taking advantage of the new
| protocol to properly engineer fragmentation handling. But
| wait, there's more! IPv6 also has braindead extension
| headers that require routers to do expensive pointer
| chasing, so packets with them are just dropped in the
| public Net. So we are stuck with the current mess without
| any way to fix it.
|
| People are trying:
| https://datatracker.ietf.org/doc/rfc9268/ but it's
| futile. It's waaaay too late and too fundamental.
| toast0 wrote:
| > IPv4 allows fragmentation by the middleboxes, which in
| practice papers around a lot of PMTU issues.
|
| In theory yes; but actual packets are 99%+ flagged DF.
| Reassembly is costly, so many servers drop fragmented
| packets, or have tiny reassembly buffers. Back when I ran
| a 10G download server, I would see about 2 fragmented
| packets per minute, unless I was getting DDoSed with
| chargen reflection, so I would use a very small
| reassembly buffer and that avoided me burning excessive
| cpu on garbage, while still trying to handle people with
| terrible networks.
|
| Router fragmentation is also expensive and not fast path,
| so there's pretty limited capacity for in path
| fragmentation.
|
| I think I agree with you, that RFC you linked seems
| awfully hopeful... unlikely to actually happen. Better
| endpoint probing is probably where we're going to end up.
| Or things like QUIC where if you don't have the required
| minimum MTU, too bad so sad.
| throw0101d wrote:
| > _For example, in IPv4 each host has one local net
| address, and the gateway uses NAT to let it speak with the
| Internet. Simple and clean._
|
| If you think NAT is "simple and clean", you may wish to
| investigate STUN/TURN/ICE. An entire stack of protocols
| (and accompanying infrastructure) had to be invented to
| deal with NAT.
|
| Heaven help you if your ISP uses CG-NAT.
| cyberax wrote:
| I can type entire SIP handshakes from memory. And by now
| I'm convinced that STUN/TURN are a superior solution to
| IPv6, even with CGNAT.
|
| Others agree with me. Don't believe me? Try to find a SIP
| provider in the US that has IPv6 connectivity. Go on. Try
| it.
| stackghost wrote:
| >For example, in IPv4 each host has one local net address
|
| Most of my home devices have multiple v4 addresses, not
| counting 127.0.0.1, so this assumption is incorrect.
| jandrese wrote:
| > For example, in IPv4 each host has one local net address,
| and the gateway uses NAT to let it speak with the Internet.
| Simple and clean.
|
| This is a troll right? NAT is a lot of things, but "simple
| and clean" is definitely not one of them. It causes
| complications at every step of the process.
|
| Pure IPv6 is so much cleaner.
|
| I will say that DHCP6 is probably misnamed. It does not
| fill the same niche has IPv4 DHCP, and this causes a lot of
| confusion with people who are new to IPv6. It should
| probably be called DPDP (Dynamic Prefix Distribution
| Protocol) or something like that. It's for _routers_ not
| hosts.
|
| In theory you should be using anycast DNS to find local
| hostnames, but in practice the tooling around this is
| somewhat underbaked.
| cyberax wrote:
| > This is a troll right? NAT is a lot of things, but
| "simple and clean" is definitely not one of them. It
| causes complications at every step of the process.
|
| I invite you to try this challenge:
| https://news.ycombinator.com/item?id=47796992
|
| This is something that can be done with consumer-grade
| routers in _minutes_ with zero configuration from
| endpoints apart from the usual WiFi password.
|
| NAT is a _superior_ design in practice. It can be chained
| transparently, it moves all the stateful routing
| complexity to the border router, it enforces network
| isolation. And most importantly, IT ACTUALLY WORKS.
| Dagger2 wrote:
| _Has_ it been abysmally slow? What 's the par time for
| migrating millions of independent networks, managed by as
| many independent uncoordinated administrators, to a new layer
| 3 protocol?
|
| We've never done this before at this scale. Maybe this is
| just how long it takes?
| alibarber wrote:
| > 1: it's hard to remember addresses
|
| fd::1 is perfectly valid internal IPv6 address (along with
| fd::2 ... fd::n)
| holowoodman wrote:
| fd::1 is somewhere in the reserved ::/8 space where various
| stuff like old ipv4 mapped addresses and localhost reside.
| What you probably mean is something like fd00::1, but that
| is something you shouldn't use, because 'fd00::/8' is a
| probabilistically unique local address (ULA) block. You are
| supposed to create a /48 net by appending 40 random bits to
| fd00::/8. Of course, if your fair dice roll lands on all
| zeroes, and you are ok with probable collisions in case of
| a network merge, you are fine ;)
| ninkendo wrote:
| In home networks, the idea of merging with someone else's
| network is... most certainly not worth worrying about.
| Maybe you marry someone or become roommates with someone
| who also picked fd00::/8? And you still want two separate
| subnets? Other than that I don't see a scenario where it
| matters.
|
| Granted, if you're doing this in a corporate setting
| (where merging with someone else's address space is a lot
| more realistic), then yes definitely pick a random 40
| bits. But at home? Who cares. Same as using
| 192.168.1.0/24 instead of a random 10.0.0.0/24 subnet...
| it's not worth worrying about.
| holowoodman wrote:
| I'm having my own and my girlfriend's router (in
| different flats) connect to each other with a wireguard
| tunnel, so I can print on her printer. Non-colliding
| addresses make this a lot easier.
|
| But yes, renumbering also isn't a lot of work.
| nottorp wrote:
| > But both of these are really only valid for DIY homelab
| enthusiast types. I honestly have no idea why other people
| resist ipv6.
|
| Simple. The "homelab enthusiast types" are those that usually
| push new technologies.
|
| This is one they don't care about, so they don't push it.
| Other people don't care about any technology if it's not
| pushed on them.
| boredatoms wrote:
| Nothing stops you running a NAT for v6 too, its just people
| tend to choose not to when given the choice
| ok123456 wrote:
| I set up NAT66 recently with DHCPv6. The IPv4 and IPv6
| addresses are practically the same, except IPv6 has a
| prefix and a double colon as the last separator.
|
| This really should be how SOHO routers do IPv6 out of the
| box.
|
| Most people don't want 1:1 addressing for their entire home
| or office.
| lxgr wrote:
| > it's hard to remember addresses
|
| We desperately need a standardized protocol to look up
| addresses via names. Something hierarchical, maybe.
|
| > with v6 you can't rely on NAT as an ersatz firewall
|
| Why would you not just use a regular firewall? Any device
| that is able to act as a NAT could act as a firewall, with
| less complexity at that.
| stackghost wrote:
| >Why would you not just use a regular firewall?
|
| No idea, but people do it. Every time this comes up on HN
| there are dozens of comments about how they like hiding
| their devices behind a NAT, for security
| lxgr wrote:
| Just because people regularly bring up a non sequitur
| doesn't mean there actually is a problem.
|
| "I have a device acting as both a NAT and a stateful
| firewall, why are you making me switch to IPv6 and in the
| process drop both the NAT and the stateful firewall?" is
| a non sequitur.
| stackghost wrote:
| I think we're talking about two different things, or
| maybe I just don't understand your reply.
|
| What I'm saying is this: There exist people in the
| hobbyist space who believe that when their devices only
| have private IPv4 addresses such as 192.168.0.0/16 that
| this meaningfully increases their network security, and
| that if their raspberry pi has a globally-routable v6
| address that this weakens their network security, even
| though this is bogus because NAT is orthogonal to network
| security considerations, and that this belief contributes
| to IPv6 hesitancy.
| bananamogul wrote:
| "Is there a reason why adoption has been so abysmally slow?"
|
| Just the obvious one: the people who designed IPv6 didn't
| design for backwards compatibility.
| jampekka wrote:
| > Just the obvious one: the people who designed IPv6 didn't
| design for backwards compatibility.
|
| Nor for easy transition.
| Dagger2 wrote:
| How so? The same working group published e.g.
| https://www.rfc-editor.org/rfc/rfc1933, and it's hard to
| see how v6 could have been designed for backwards
| compatibility in ways that it wasn't already.
|
| I've asked lots of people to describe a more backwards-
| compatible design, and generally the best they can manage
| is to copy the way v6 does things, ending up with the same
| problems v6 has. This has happened so often that the only
| reasonable conclusion is that it can't really be done any
| better than it was.
| waynesonfire wrote:
| > It has barely hit 50% and it's already plateauing.
|
| That makes sense. The majority of IPv6 deployment is mobile.
|
| The next wave of adoption requires ISPs start offering
| residential IPv6. Once this happens, router manufacturers will
| innovate around the IPv6 offering as a differentiator, making
| it easy to deploy by end-users. IPv6 wifi APs will then become
| ubiqutious and so forth across other services. Has to start
| with ISPs.
| dtech wrote:
| ISPs in the US and Europe mostly have been offering IPv6 for
| a while now
| Hikikomori wrote:
| Other than France or Germany its far from mostly.
| jabl wrote:
| Unfortunately my ISP here in Europe is not one of those
| offering IPv6.
| yxhuvud wrote:
| Mine does and it works so well that I actually have to
| turn it off when working from home as a bunch of the
| third party servers at work doesn't have any support for
| it.
| lxgr wrote:
| That sounds more like broken support then. Not having any
| support at all (i.e. A records or v4 literals only)
| should just send you to whatever v4 transition technology
| your ISP offers, no?
| dtech wrote:
| Apple/iOS is probably one of the biggest individual drivers of
| IPv6 adoption. They've been requiring that iOS apps work on
| IPv6-only networks for close to 10 years now
| aniviacat wrote:
| If that's the case, how does the Github app work on iOS?
| dtech wrote:
| Nat64: https://developer.apple.com/support/ipv6/
| eptcyka wrote:
| Differential enforcement.
| fogllgldl wrote:
| Apple's App Store enforcement is very arbitrary. For
| example, if the app developer offends steve jobs, you're
| banned for life.
| nothrabannosir wrote:
| I'm guessing the app works but their prod servers don't? If
| they can point the app during review at a "self hosted"
| GitHub Enterprise server on a test domain with AAAA that
| would pass the requirement as stated by gp , without
| requiring GitHub.com actually support ipv6.
| Dagger2 wrote:
| The prod servers work. The app does a DNS lookup,
| receives something like 64:ff9b::140.82.112.5 and
| 140.82.112.5 from the ISP's DNS servers, and then
| connects to 64:ff9b::140.82.112.5. Some part of the ISP
| network translates the connection into a v4 connection to
| 140.82.112.5.
|
| The requirement is simply that the app does AAAA queries,
| and that it attempts to connect to them if they exist. It
| doesn't matter whether the server does v6 natively or if
| the ISP is covering for a v4-only server via backwards
| compatibility. (Native v6 will probably perform better,
| but any site that wants to give up that advantage is free
| to do so.)
| lxgr wrote:
| That's DNS64, which is pretty annoying in practice. (For
| one thing, you can't use your own DNS server anymore, but
| more importantly, anything using v4 literals will 100%
| break.)
|
| What's nicer is 464XLAT, or more generally NAT64 prefix
| announcements. Then your local OS can just synthesize
| NAT64 addresses from v4 literals, either at the socket
| library or kernel networking (via "bump in the stack"
| translation) layer.
| lxgr wrote:
| The requirement is to support IPv6 only networks with IPv4
| transition mechanisms. It does not preclude contacting
| v4-only servers.
| moduspol wrote:
| And the higher level libraries mostly do it for you, too,
| even if you directly specify IPv4 addresses in your code
| (due to NAT64 [1]). I think it only even requires special
| work from you as a developer if you're using low-level or
| non-standard libraries.
|
| [1] https://en.wikipedia.org/wiki/NAT64
| lxgr wrote:
| The problematic low-level libraries are standard, and
| effectively impossible to fully deprecate since they're
| decades old and part of the socket API.
|
| I think currently Apple still helps you with these via
| "bump in the stack" (i.e. they can translate internal v4
| structures and addresses into NAT64-prefixed v6 at the
| kernel level), but they probably don't want to commit to
| doing that forever.
| throw0101d wrote:
| > _They 've been requiring that iOS apps work on IPv6-only
| networks for close to 10 years now_
|
| This was at the behest of mobile network. E.g., T-Mobile US
| has 140M subscribers, and moved to IPv6-only many years ago:
|
| * https://www.youtube.com/watch?v=d6oBCYHzrTA
| panny wrote:
| I don't want IPv6. Why would I? It's like a permanent global
| cookie. You're uniquely tagged and identifiable on every
| website you visit.
|
| >it's in their best interest to ensure users can't host
| services without them.
|
| They'll just keep blocking port 25. IPv6 won't change anything
| with regards to self hosting.
| farfatched wrote:
| My OS gives me IPv6 privacy addresses out-the-box which
| rotate every few hours.
| kstrauser wrote:
| > You're uniquely tagged and identifiable on every website
| you visit.
|
| Almost every modern OS enables IPv6 privacy extensions, ie
| address randomization, by default.
| lmm wrote:
| I think we'll hit a tipping point soon, just like with Python3
| - for years and years it seemed almost stalled, then it became
| easier to start with python3 than python2 and suddenly everyone
| migrated.
| usui wrote:
| This seems like wishful thinking. Python3 vs. Python2 seems
| different than IPv6 vs. IPv4.
| tucnak wrote:
| "seems" is doing a lot of heavy-lifting in your message
| yangm97 wrote:
| "Gradually, then suddenly."
| drpixie wrote:
| >> It has barely hit 50% and it's already plateauing.
|
| Well, the curve has got to level-out at 100%.
| cowsandmilk wrote:
| No, it can level out below that and is (as the parent was
| saying).
| bluGill wrote:
| How far below is the question. It could level out at 60% -
| that is believable. However it can't level out at 99% -
| Somewhere around 95% major sites will decide IPv4 isn't
| worth supporting and they will just ignore that final 5% of
| customers, which will force them to upgrade - which in turn
| will give others confidence to remove their final 4% of
| customers - until IPv4 dies.
| lazide wrote:
| There are still ascii dialup bulletin boards out there.
| and operating model T's. IPv4 will be around for longer
| than you or I.
| lxgr wrote:
| There are also still Telex and X.25 networks around
| there, not to forget the whole public telephone network!
|
| But at some point, getting a native connection to all of
| these started becoming increasingly rare, and now these
| are largely emulated/tunneled on top of IP. The same can
| happen for IPv4.
| Dylan16807 wrote:
| > IPv4 will be around for longer than you or I.
|
| That's a matter for the legacy network on the other side
| of the internet to handle, as it converts my IPv6 packets
| to IPv4.
| umanwizard wrote:
| That's indeed what they're saying, but they're simply wrong
| which is obvious from looking at the graph and accounting
| for seasonal variation.
| vr46 wrote:
| My German ISP supports it now, which was the limiting factor
| for me, and a new VPS I just bought also does, so finally I was
| able to create my first personal AAAA record. I am hoping that
| we're seeing a tipping point. Again.
| fogllgldl wrote:
| Worst migration plan ever.
| MiscIdeaMaker99 wrote:
| Since when was there ever a plan to disable IPv4 on the
| Internet? Just because IPv6 is around doesn't mean that IPv4 is
| going to go away.
| bluGill wrote:
| That was always the plan for "the future". That is get
| everyone to IPv6 and then get rid of IPv4. IPv4's days are
| numbered - but the number looks really big.
| lxgr wrote:
| Why would we keep around a whole separate Internet? Dual
| stack was always only intended for the transition period.
| g8oz wrote:
| It's very hard to get rid of old standards.
|
| "The past is never dead. It's not even past"
| lxgr wrote:
| Of course there's an incredibly long tail here, but in
| the big picture, "nobody except some people maintaining a
| few legacy systems ever need to learn to work with this
| protocol anymore" is practically the same thing.
| ectospheno wrote:
| > Also, notice how Android and iOS don't support turning off
| IPv4.
|
| You can trivially connect an iOS device via IPv6 only.
| boredatoms wrote:
| Presumably thats with the network having a PLAT somewhere if
| you're relying on CLAT for any v4-only connections when you
| use safari
| usui wrote:
| Can you share details on how one trivially connects via IPv6
| only? I see no option in iOS Wi-Fi settings to do this, and I
| think it's reasonable to expect not to have to turn off IPv4
| on my access point to test IPv6-only networking.
| unethical_ban wrote:
| I think they're saying you can't force disable ipv4 entirely.
| RiverCrochet wrote:
| > It has barely hit 50% and it's already plateauing. This
| adoption rate is ridiculous despite basically all network
| interfaces supporting it
|
| It's fine. IPv4 and IPv6 can be used at the same time. There's
| no hurry. Network interfaces support anything as long as both
| sides agree (nothing stopping you from building your own IPX
| network over MPLS).
|
| People can move to IPv6 when the IPv4-as-real-estate
| speculators get out of control, and if IPv6 prevents IPv4
| rental prices from going haywire, then it's served a useful
| purpose.
|
| I saw a news article that said something about India
| considering moving to IPv6-only? That's going to be interesting
| if the rest of the world moves to IPv6 and the U.S. doesn't.
|
| > End users shouldn't need to set up NAT64/6to4 tunneling. It
| should be ISPs doing that to prepare for the transition.
|
| 100%
| bananamogul wrote:
| I've been hearing that those speculators were going to get
| out of control and the IPv4 price was going to skyrocket for
| 10+ years.
|
| Yet I can still rent a VPS with IPv4 for $12/year from a wide
| variety of providers.
| RiverCrochet wrote:
| For now, :) Hopefully it continues.
|
| > if IPv6 prevents IPv4 rental prices from going haywire,
| then it's served a useful purpose.
|
| Competition is good.
| Dylan16807 wrote:
| You can, but a significant portion of that money is going
| toward paying off that IP.
|
| "Skyrocket" is wrong but the market cap of IPv4 addresses
| is quite high.
| realityking wrote:
| The Czech government has announced it'll stop offering its
| services via IPv4 in June 2032.
|
| Source https://konecipv4.cz/en/
| crazygringo wrote:
| > _It has barely hit 50% and it 's already plateauing._
|
| Is it plateauing? From the chart it doesn't look that way at
| all to me.
|
| You could say it's flat between August 2025 and now, but it
| also was from Jun 2024-Feb 2025, or August 2023-March 2024.
| There's just a lot of noise to it -- lots of short plateaus or
| even dips followed by lots of sudden jumps. Indeed, it seems to
| have a bit of a yearly cycle to it, suggesting we're at the
| inflection point of another jump upwards.
|
| So it still seems to be growing _strongly_ to me. The rate of
| growth has slowed maybe the _tiniest_ bit 2024-2026 compared
| 2018-2023, but I don 't see it anywhere close to plateauing
| yet.
| UltraSane wrote:
| Every company I have ever worked for in the US didn't use IPv6
| and actually blocked it at the FW
| SuperMouse wrote:
| Our freaky network admins rolled it out in our global corpo.
|
| Was fun seeing IPv6 running for a few days without problems.
| lmm wrote:
| The US has something like 80% of the world's IPv4 addresses, so
| they feel a lot less pressure to migrate.
| zokier wrote:
| US is significantly above average in terms of adoption
| UltraSane wrote:
| I worked for a state government agency that had a public /16
| icedchai wrote:
| I've worked for a company that was barely using its /16. I
| know several individuals, including myself, with personal
| /24s.
| Dagger2 wrote:
| None of which are any help when connecting to someone who
| doesn't have those.
| icedchai wrote:
| I know, I'm just agreeing there's a ton of IP waste in
| the US. Early adopters were perhaps unjustly rewarded.
| InterNIC (before ARIN) would just about hand out IPs to
| anyone who could send an email.
| Bender wrote:
| During the dot-com crash I had to put a /16, some /17's
| and a /19 on one vlan and connected a 1U Linux box
| running Labrea Tarpit just so those ranges would respond
| to ping because InterNIC used to harass us for not
| utilizing all the space. They threatened a few times to
| take them back. AFAIK nobody nags like that any more.
| They probably should.
| UltraSane wrote:
| A /24 is currently worth between $5,000 and $9,000 USD. Did
| you get them a long time ago?
| icedchai wrote:
| Yes, over 32 years ago. It was before ARIN and is
| considered a legacy block.
| UltraSane wrote:
| With your own /24 you can get an AS number and
| potentially BGP multi-home it.
| icedchai wrote:
| Yes, I've already done that. I have the /24 tunneled to
| my home network.
| UltraSane wrote:
| That would be so cool to see your own AS in the global
| BGP table. I suppose I could still try this using IPv6
| icedchai wrote:
| You can get that going pretty cheap through various RIPE
| LIRs!
| ButlerianJihad wrote:
| I recently released a /24 that I registered in 1992 and I
| hadn't realized it was still mine.
|
| ARIN was gonna charge me $100 to authenticate and recover
| the account, but once I asserted and notarized my letter of
| relinquishment, the process went real quick!
| icedchai wrote:
| You could've recovered it and sold it for $7K, or rented
| it out for $500/month.
| Animats wrote:
| It's been amazingly linear since 2014.
|
| amazon.com needs to get with the program. Still IPv4 only.
| cubefox wrote:
| Nice. But note that the average is still significantly below 50%.
| It's also a bit concerning that the growth rate seems to be
| levelling off. It currently looks like a sigmoid curve with a
| maximum far below 100%.
| gspr wrote:
| I wouldn't be so worried about it. It's really hard for
| something as big as this to really hit 100%. If we hit 80% or
| thereabouts, we can at least plausibly argue to backwards ISPs
| that IPv6 is the default and the standard that everyone should
| reasonably be offering.
|
| Generally: I'm really surprised that Norway is just at 27%. I
| think I've been with 3 different residential ISPs the last 15
| years, and all of them have done IPv6 perfectly well (two nits:
| I think one required a trivial opt-in, and my current ISP is
| just giving me /60 which isn't perfect).
|
| Edit: Oops, sorry to my current ISP for shaming them. Some
| googling told me that one can get a /56 using DHCPv6-PD. I'll
| try that!
| imoverclocked wrote:
| The question is, "what will the graph look like in the next 10
| years?"
|
| I get the whole s-curve trend but if I squint at 2017, there is
| an inflection to slow the s-curve down.
|
| Annoyingly, when setting up service with a fiber company in the
| last couple months, I explicitly asked about IPv6 connectivity
| and they said, "yes." Turns out "yes, but not in my region."
| snvzz wrote:
| >I explicitly asked about IPv6 connectivity and they said,
| "yes."
|
| ABC, Always Be Closing.
| pheggs wrote:
| while it looks like its slowing down, I am pretty sure it will
| speed up once IPv4 get even more expensive, sites start to be
| hosted on IPv6 only and become inaccessible to some users that
| dont have IPv4. Thats surely going to put pressure on ISPs
| snvzz wrote:
| Maybe "think of the children."
|
| There might be a child behind the NAT, thus IPv6 requirement.
| jeroenhd wrote:
| With IPv6 privacy extensions it's impossible to tell which
| device you're talking to inside of a /64. You'd need to do
| something silly like DHCPv6 to get that kind of remote
| device-level tracking.
| usui wrote:
| Outside of hobbyist niche uses, sites won't start being hosted
| IPv6-only. The financialization of IPv4 addresses will simply
| get worse and be even more pay-to-play than it is now. Amazon
| raises the price of IPv4 and everyone goes along as a cost of
| doing business.
| zokier wrote:
| My prediction is that sites will be half-IPv6 only; backends
| will be IPv6 and IPv4 traffic will get proxied to IPv6 by
| CDNs / edge LBs. I think CloudFront for example supports that
| scenario, avoiding IPv4 costs (in theory).
| pheggs wrote:
| that may be true, but not being able to access hobbyist sites
| still feels like "being locked out" of something. My ISP
| provides /48 IPv6 addresses for free, and I already run a
| couple sites only on IPv6 - because an IPv4 would cost 20
| bucks a month - it's not important enough to me personally to
| pay that.
| elsjaako wrote:
| If you have a big site and want as broad an access as
| possible I agree.
|
| But I wouldn't be surpised if we start seeing self-hosted
| minecraft or factorio servers with ipv6 only.
| neojima wrote:
| Yeah, hobbyist niche sites like these:
|
| https://clintonwhitehouse1.archives.gov/
|
| https://clintonwhitehouse2.archives.gov/
| rtdq wrote:
| And still, in the year of our lord 2026, GitHub does not support
| IPv6.
|
| https://github.com/orgs/community/discussions/10539
| growse wrote:
| A non-trivial minority of the time, they don't support IPv4
| either!
| hsbauauvhabzb wrote:
| What? One nine isn't good enough for you?
| lambda wrote:
| Excuse me. Zero nines. Or two nines if you relax your
| definition of where they are in the number.
| https://infosec.exchange/@0xabad1dea/116334321751266751
| bdangubic wrote:
| we shut down our production every day from 2pm till 5pm
| for a siesta :)
| Zancarius wrote:
| You jest... (but probably not!)
|
| I remember when I was first using my alma mater's online
| sign up for classes in the very early 2000s, their class
| sign up site had office hours.
| AlienRobot wrote:
| Excuse me, but I see 4 nines. 95 incidents in last 90
| days, 89.91% uptime.
| fogllgldl wrote:
| You guys have nines?
| fkarg wrote:
| You must be from Anthropic
| whh wrote:
| the ghost of twitter's past
| wiredfool wrote:
| Personally I'd look for the coveted 5 eights uptime.
| MarsIronPI wrote:
| 66.6% uptime anyone?
| doubled112 wrote:
| Still better than five eighths.
| wildylion wrote:
| Only if it's Australia.
| Ekaros wrote:
| As long as it is after the decimal separator I can try for
| that...
| sidewndr46 wrote:
| should we try going back to IPX ?
| MikeNotThePope wrote:
| Only if we're bringing back Token Ring, too.
| synalx wrote:
| That might be challenging, I hear people are pretty short
| on tokens these days.
| MikeNotThePope wrote:
| There's only one token! It's just very popular.
| bluGill wrote:
| Arcnet for me.
| sidewndr46 wrote:
| While we're at what about older physical layers? Coaxial
| based stuff seems cool in 2026
| jonhohle wrote:
| Isn't that what MoCa is for?
| rayiner wrote:
| Isn't twinax just "I heard you like coax so I put coax in
| your coax."
| sidewndr46 wrote:
| twinax I think is used more like a balanced line with
| shielding. Twisted pair is preferred because it is
| cheaper, but for short stuff like SATA the cost
| difference is so low it might as well be used
| riddlemethat wrote:
| If it's not 10BaseT I can't see small spread adoption.
| MisterTea wrote:
| IPX/SPX is datagram only. _BUT_ it would be an opportunity
| to build a QUIC-like that runs over it :-)
| colechristensen wrote:
| I've used IPX exactly once in my life, playing Diablo over
| modems _calling_ my dorm neighbor to establish the
| connection (in 2005).
| TabTwo wrote:
| I remember removing the IPX route entries from our Cat65
| MSFC back in 2006 and from the ATM/Framerelay WAN
| Equipment. Wasn't very popular with the customers.
|
| I also remember the first IPv6 Workshop on W2k SP3 back in
| 2002. Not that long ago.
| reincarnate0x14 wrote:
| Comically IPv6 now has almost all the neat stuff IPX did.
| There probably is an argument for more datagram centric
| networking these days as the underlying services are
| generally much faster and more reliable and there is so
| much more session tracking going on at higher application
| layers anyway.
| CupricTea wrote:
| GitHub is at the point where it immediately rate limits me if
| I try to look at a project's commit history without being
| logged in, as in the first time I even open a single URL to
| the commit history, I get "Too Many Requests" from GitHub
| thrown at me. I don't know if my work's antivirus stack is
| causing GitHub to be suspicious of me, but it's definitely
| egregious.
| colechristensen wrote:
| Your work is probably all exiting through the same IP, you
| competing with others on the same IP is causing the rate
| limit.
| CupricTea wrote:
| I've considered this, but the company is small enough
| that the number of people who would be on GitHub at any
| moment (instead of our internal git forge) can be counted
| on one hand, and when I'm the first one there in the
| morning it still rate limits me.
| growse wrote:
| Maybe your company's ISP is CGNat'ting you?
| NewJazz wrote:
| Do you have any on-prem cicd jobs that access github?
| Our's kept failing, had to move over to the ECR release
| of some stuff.
| colechristensen wrote:
| Hm, I've also noticed sites being more aggressive about
| verifications after I started using LLMs locally. They
| think I'm a bot (which... fair), even on completely
| unrelated sites I seem to be getting prompted for human
| verification much more often.
| embedding-shape wrote:
| The very same thing happen on my residential connection,
| I can do one search query, then I'm rate limited for 15+
| minutes, same if I access any list of commits.
| tyingq wrote:
| May explain the ipv6 resistance. Hard to do effective
| per-ip rate-limiting with v6.
| nickserv wrote:
| I don't understand, wouldn't it make it easier?
| hkt wrote:
| No, IPv6 as it is supposed to be implemented gives (say)
| a single server a /64, which is for all intents and
| purposes an inexhaustible supply of IPs. You could in
| principle have an IP per site you visit and have plenty
| left to spare.
|
| Random Google result with a bit more:
|
| https://www.captaindns.com/en/blog/ipv6-subnet-
| sizes-48-vs-5...
|
| So if I wanted to annoy GitHub, I could connect to them
| without ever using the same IP twice. Their response
| would have to be banning my /64, or possibly /56.
| Hikikomori wrote:
| Its not harder to rate limit a /64 though.
| mmbleh wrote:
| It is because the IPv6 rollout has not been consistent.
| Some assign /64 per machine, some assign /64 per data
| center. Some even go the other way and do a /56 per
| machine. We've had to build up a list of overrides to do
| some ranges by /64 and others by /128 because of how they
| allocate addresses. This creates extra burden on server
| operators and it's not surprising that some just choose
| not to deal with it.
| wolrah wrote:
| > No, IPv6 as it is supposed to be implemented gives
| (say) a single server a /64, which is for all intents and
| purposes an inexhaustible supply of IPs. You could in
| principle have an IP per site you visit and have plenty
| left to spare.
|
| No, as it's supposed to be implemented a single internet-
| routable /64 is used per * _network*_ and then most
| devices are expected to assign themselves a single
| address within that network using SLAAC.
|
| ISPs are then expected to provide each connected *
| _site*_ with at least a /56 and in some cases a /48 so
| the site's admins can then split that apart in to /64s
| for whatever networks they may have running at the site.
| That said, I'm on AT&T fiber and I am allocated a /60
| instead, which IMO is still plenty for a home internet
| connection because even the most insane homelab setups
| are rarely going to need more than 16 subnets.
|
| > So if I wanted to annoy GitHub, I could connect to them
| without ever using the same IP twice. Their response
| would have to be banning my /64, or possibly /56.
|
| Well yeah, but it's not like it's exactly rocket science
| to implement any sorts of IP rate limiting or blocking at
| the subnet level instead of individual IP. For those
| purposes you can basically assume that a v6 /64 is
| equivalent to a v4 /32. A /56 is more or less comparable
| to /25 through /29 block assignments from a normal ISP,
| and a /48 is comparable to a /24 as the smallest network
| that can be advertised in the global routing tables.
| sholladay wrote:
| It's not you or your setup. I experience the same behavior.
| Tried with and without Private Relay, residential and
| commercial ISPs at different locations, and more to debug
| it. Same results.
|
| I think GitHub has just gotten so aggressive with their
| rate limit policies that it's straight up incompatible with
| their own product. The charitable interpretation is that
| they aren't keeping good track of how many requests each
| page actually performs in order to calibrate rate limiting.
| kdhaskjdhadjk wrote:
| On the other side of the coin, they also punish people
| who have slow connections. The acceptable speed for
| downloading from github on my connection is 90k/sec. No
| more, no less. Something prevents the rate from being
| higher (probably Github), and if the rate drops any lower
| for any length of time, the connection will suddenly
| abort right in the middle of the download. Since the
| dumpster fire that is git doesn't support resume, welcome
| to hell. If I didn't have a fast server elsewhere to git
| to then zip up and re-download, I'd be screwed.
| bmicraft wrote:
| If you didn't specifically test without it, I'd attribute
| that to cgnat
| vhcr wrote:
| My theory is that they rate limit that URL aggressively due
| to AI scrapers. At this point it's faster to just clone the
| repo and do your searching locally.
| nailer wrote:
| IPv1, IPv2, and IPv3 were very early experimental versions of
| the Internet Protocol developed in the 1970s during the
| ARPANET era (the precursor to the modern internet). Has
| anyone tried to find out if GitHub is reliable on those?
| sandeepkd wrote:
| Came here to exactly check on this to see if there are any
| changes on Github side too
| globular-toast wrote:
| Do we know any technical reason for this? Or are we left to
| think this is somehow a political thing?
| denkmoon wrote:
| Outdated beliefs probably. When I talk about v6 support in
| our b2b saas, PM laughs and says nobody uses that shit. Big
| tech are massive laggards on this funnily enough.
| ViscountPenguin wrote:
| It's because big tech is USA based mostly, where there's
| still a glut of ipv4 available.
| FuriouslyAdrift wrote:
| IPv4 was exhausted at ARIN in 2011. Last time I bought a
| /24 on the open market, it was around $6k. I assume it is
| much more, now.
| Dylan16807 wrote:
| It's close to that right now. Prices more than doubled as
| covid set in, then dropped back down to about where they
| were before.
| paulddraper wrote:
| Where can I get it, asking for a friend?
| 10000truths wrote:
| Definitely not for the biggest ones. Google and Meta have
| so many machines in their data centers that IPv6 addressing
| becomes a technical necessity due to the risk of exhausting
| the RFC 1918 address space. Naturally, they were early
| adopters of IPv6.
| throw0101d wrote:
| > _Outdated beliefs probably. When I talk about v6 support
| in our b2b saas, PM laughs and says nobody uses that shit._
|
| Nobody except the 140M subscribers on T-Mobile US's
| network:
|
| * https://www.youtube.com/watch?v=d6oBCYHzrTA
|
| But sure, be IPv4-only and add latency by forcing traffic
| through an extra translation box.
| paulddraper wrote:
| Well it's over 50%...
| direwolf20 wrote:
| It could be that they don't want to implement IP bans in
| IPv6.
| c0balt wrote:
| Or the most likely more expensive rate limiting
| (computational wise)
| michh wrote:
| I mean, given how the site performs on average I don't
| think they've optimized so much that the extra cpu cycles
| of ANDing with the fixed constant of 2^64-1 and then
| looking up or hashing a 16 byte integer - whatever they
| do - rather than a 4 byte one would increase the load
| significantly. Let's be pessimistic and say it's 20 extra
| cpu cycles, that's not gonna be much of a problem if
| their load balancers were made in the past 20 years.
| merpkz wrote:
| How does IP bans work in IPv6 case? One just blocks whole
| /64 or /56 address range?
| throw0101d wrote:
| I have not had a deal with this, but if I was going to, I
| would start at the /64 and move up by nibble (4-bit)
| boundaries: /64, /60, /56, /52, /48.
|
| /56 is often recommended as the minimum as for a
| (residential) customer. /48 is considered a "site"
| address prefix, and is the smallest allocation that can
| be advertised in BGP:
|
| * https://blog.apnic.net/2020/06/01/why-is-a-48-the-
| recommende...
|
| * https://www.infoblox.com/blog/ipv6-coe/a-48-for-every-
| site-a...
|
| You get 65k subnets with it, which is what you get with
| 10/8.
| roryirvine wrote:
| Yes, /64 is a reasonable starting point for blocking
| outright, but /48 is the right unit for scoring
| reputation.
| GoblinSlayer wrote:
| APNIC blog says /48 prefixes are for global routing, i.e.
| site=country there, not web server.
|
| >/48 is the minimum prefix size that will be routed
| globally in the BGP.
| alex_duf wrote:
| It's a possibly a managerial thing, which KPI are you
| improving when spending engineering time on adding IPv6
| support?
|
| That said, for their HTTP stack they use fastly (as far as I
| understand), which should make the shift moderately easier.
| AtNightWeCode wrote:
| You probably need a hefty security reimplementation if you
| want to add IPv6 to Github.
| michh wrote:
| Perhaps a little tin foil hatty and definitely not the only
| reason but Microsoft owns Github and also makes a boatload of
| money off of Azure. Incumbent cloud providers like Azure have
| a major advantage in terms of having plenty of IPv4
| addressing available whereas a new entrant to that market
| would have to buy or lease that space at a premium. Thus,
| these companies have an incentive to keep IPv4 a necessity.
| IshKebab wrote:
| IPv4 is going to be a necessity for many many decades no
| matter what Microsoft do. Even when IPv6 is at 99%, people
| aren't going to want 1 in every 100 people to not be able
| to access their site at all. It'll need to be like 99.9%
| before we start seeing serious IPv6-only services.
| jiggawatts wrote:
| Sure, but the implementation in the public clouds is
| totally backwards.
|
| What they should have done is have their core network
| default to IPv6 with IPv4 an optional add-on for things
| like public IP addresses, CDN endpoints, edge routers,
| VPNs, etc...
|
| Instead, their core networks are IPv4 _only_ for the most
| part with IPv6 a distant afterthought.
| fogllgldl wrote:
| IPv6 is the protocol of the future. And will be so.
| michh wrote:
| I don't know what the percentage would be, but we do have
| some historical precedent that could give us a clue.
|
| Best one I can think of is when bigger websites started
| actually dropping SSLv3 and TLSv1.0 (and later TLSv1.1)
| support, cutting off older browsers and operating
| systems. Google and Amazon still support TLSv1.0, but
| plenty of others (including Microsoft) have dropped 1.0
| _and_ 1.1. HN itself doesn 't accept 1.1 anymore either.
|
| Then there's browser support. Lots of websites - big and
| small - cut off support for Internet Explorer 6 when it
| was somewhere below 5% marketshare because the juice was
| no longer worth the squeeze. Of course, few of those
| actually fully cut off the ability to browse the (now
| broken) website fully but it's a datapoint suggesting
| trade-offs can and will be made for this sort of thing.
| Or to put it in the present: a significant amount of
| webapps don't support Firefox (3% market share) to the
| extent their product is completely unusable in it.
| 1317 wrote:
| a browser you at least have the ability to change though.
| if your ISP doesn't offer v6 you're SOL really
| Ericson2314 wrote:
| ISPs almost all offer IPv6. The reason the US number is
| not higher is lazy corporate networks.
| pbhjpbhj wrote:
| Meanwhile big gaming companies when Linux users are 5% of
| Steam users: 'eff off'.
| globular-toast wrote:
| I don't buy that. Do Netflix or YouTube care that people
| on 56k can't use their service?
| mmbleh wrote:
| IPv6 is very difficult to implement and enforce reliable rate
| limits on anonymous traffic. This is something we've
| struggled a lot with - there is no consistent implementation
| or standard when it comes to assigning of IPv6 addresses.
| sometimes a machine gets a full /64, other times a whole data
| center uses a full /64. So then we need to try and build
| knowledge of what level to block based on which IP range and
| for some it's just not worth the hassle.
| Tuna-Fish wrote:
| ... But that's no different from IPv4. Sometimes you have
| one per user, sometimes there are ~1000 users per IP.
|
| Most of the ipv4 world is now behind CGNAT, one user per ip
| is simply a wrong assumption.
| mmbleh wrote:
| Anonymous rate limits for us are skewed towards
| preventing abusive behavior. _Most_ users do not have a
| problem, even there is a CGNAT on IPv4.
|
| For IPv6, if we block on /128 and a single machine gets
| /64, a malicious user has near infinite IPs. In the case
| of Linode and others that do /64 for a whole data center,
| it's easy to rate limit the whole thing.
|
| Wrong assumption or not, it is an issue that is made
| worse by IPv6
| agwa wrote:
| I don't doubt your experience, but I wouldn't expect it
| to continue. I don't think Tuna-Fish is correct that
| "most" of the IPv4 world is behind CGNAT, but that does
| appear to be the trend. You can't even assume hosting
| providers give their subscribers their own IPv4 addresses
| anymore. On the other hand, there's a chance providers
| like Linode will eventually wise up and start giving
| subscribers their own /64 - there are certainly enough
| IPv6 addresses available for that, unlike with IPv4.
| mmbleh wrote:
| Yeah, absolutely no expectations for the future. My point
| was more that while there may be clear benefits for
| users, IPv6 presents real problems for service operators
| with no clear solutions in sight.
|
| Given that GitHub also offers free services for anonymous
| users, I can imagine they face similar problems. The
| easiest move is simply to just not bother, and I can't
| blame them for it.
| Tuna-Fish wrote:
| > I don't think Tuna-Fish is correct that "most" of the
| IPv4 world is behind CGNAT
|
| ~60%+ of internet traffic is mobile, which is ~100%
| behind CGNAT.
|
| On desktop, only ~20% of US and European web traffic uses
| CGNAT, but in China that number is ~80%, in India ~70%
| and varies among African countries but is typically well
| over 70%, with it being essentially universal in some
| countries.
|
| Overall, something a bit over 80% of all ipv4 traffic
| worldwide currently uses CGNAT. It's just distributed
| very unevenly, with US and European consumers enjoying
| high IP allocations for historical reasons, and the rest
| of the world making do with what they have.
| agwa wrote:
| Oh wow, thanks for those numbers!
|
| Since mmbleh mentioned Linode I'm guessing they're more
| concerned with traffic from servers, where CGNAT is
| uncommon. But even that may be changing -
| https://blog.exe.dev/ssh-host-header
| mmbleh wrote:
| Yeah, our traffic is more from automated systems/servers,
| nothing from mobile
| GoblinSlayer wrote:
| If a single machine gets /64 and you rate limit by /64,
| what doesn't work?
|
| >Linode and others that do /64 for a whole data center
|
| That's how it's supposed to work.
| Dylan16807 wrote:
| > That's how it's supposed to work.
|
| According to who?
|
| It could fit best practices if your datacenter has one
| tenant and they want to put the entire thing on a single
| subnet? In general I would expect a datacenter to get
| something like a /48 minimum. Even home connections are
| _supposed_ to get more than /64 allocated.
|
| And Linode's default setup only gives each server a
| single /128. That's not how it's supposed to work. But
| you can request /64 or /56.
| GoblinSlayer wrote:
| If the OS uses SLAAC by default, then it will just work,
| but SLAAC is for humans and makes less sense for web
| servers (yet can make sense for vpn servers). For web
| servers /128 is more meaningful.
| RiverCrochet wrote:
| Well, even if there was a standard, that's still not a
| guarantee that the other side of the /64 would be following
| it. It's correct for you to rate-limit the whole /64.
| skywhopper wrote:
| IPv6 rollout is a lot of operational work that ends with next
| to no immediate quantifiable benefit. So I'll never be
| prioritized in a cost-cutting environment.
| tialaramex wrote:
| I mean, all your numbering woes vanished, so, that's
| probably an immediate quantifiable benefit unless you're so
| tiny you never needed any renumbering effort, in which case
| your "operational work" to deploy IPv6 was probably zero.
| jeroenhd wrote:
| They supported IPv6 for a short time, but then stopped their
| experiment.
|
| An excellent reason to move away from Github, I find.
| literalAardvark wrote:
| I've been there. Management was fine with the testing but it
| added too much overhead for nearly no benefit to us.
|
| One more thing to troubleshoot at 3 am, one more thing to
| teach to a disinterested tier 1 support team, one more thing
| for Chrome to be weird about, hundreds more rules to manage
| in a hostile load balancer, logging tools that don't
| understand ipv6.
|
| Turned it off. End customer asked why the site got a little
| slower (CGN) and when we can turn ipv6 back on. As far as I
| know it's still on the backlog.
| throw0101a wrote:
| Facebook is (AIUI) 100% IPv6-only on their internal
| network, and has been for many years:
|
| * https://engineering.fb.com/2017/01/17/production-
| engineering...
|
| * https://www.internetsociety.org/blog/2014/09/facebook-
| launch...
|
| IPv4 is actually the "leftover" stuff they have to deal
| with at the front end.
|
| But they are an eye-balls heavy service, with a lot of
| mobile devices, which also tend to be IPv6-native.
| tialaramex wrote:
| It also just takes actual policy will. Somebody has to
| actually say "No" when the supplier who promised an IPv6
| product says afterwards actually they meant IPv6 "ready"
| and they should have put an asterisk because really only
| the next version will be "ready", and er, so the product
| they've delivered doesn't actually work with IPv6 but
| that's fine right?
|
| "No". Not every human is psychologically prepared to do
| that. They want to acquiesce, to go along to get along,
| you need somebody to be firm. "No".
| m-s-y wrote:
| I have found that it is incredibly satisfying to whip out
| the "no" card.
|
| I have also found that an uncomfortable number of people
| do _not_ consider it appropriate in any way shape or
| form. Even when it's ultimately your call and no one
| else's.
|
| Folks don't really like waves. They like looking at them
| from the shore, but freak out when it's their turn to
| hang 10
| lazide wrote:
| Just wait until someone starts remembering the other
| archaic terms like 'fraud', 'indictment', etc.
| toast0 wrote:
| From my time there, this is for the internal prod
| network. Corporate networking was dual stack (which was
| pretty useful because it was common for v4 or v6 to
| break, but usually not at the same time)
| jeroenhd wrote:
| One of the big challenges with IPv6 remains that many of
| the knows-just-enough-about-networking people, like support
| staff, often never received any IPv6 training (or, for that
| matter, even enough IPv4 training that they don't need to
| Google things that come up in real life). Another is that
| the weird, awful, everyone-hostile corporate "solutions"
| often break IPv6 in stupid ways (like load balancers and
| logging tools being unable to cope with minor changes and
| requiring a full configuration rework).
|
| Things have definitely gotten better over time, though. The
| massive 90s style corporate networks will probably never
| transition, but smaller and more modern companies don't
| have that issue.
|
| Apple mandating that apps are IPv6 compatible and various
| government legislation forcing companies to make their
| shitty middleware IPv6-compatible has improved things quite
| a bit so far. As uptake keeps rising, the need for
| technologies like STUN and TURN will slowly start
| decreasing, and as a result more and more people will end
| up in "untested" situations where not having IPv6 and
| falling back to legacy paths starts becoming a problem.
| GoblinSlayer wrote:
| A networking dude (he clutched his smartphone all the
| time) typed "spedtes" in my browser and was deeply
| confused when the server wasn't found. He tried several
| times more with slightly different spelling to the same
| effect, he literally couldn't even what went wrong.
| QuercusMax wrote:
| Here's an example of a potential security hole caused by
| lack of ipv6 knowledge:
|
| I've been setting up Snapcast (open-source multi-room
| audio), and needed to move the server to a different
| machine. While I was setting up the new system, I told it
| to only bind to localhost. Somehow this only affects the
| ipv4 networking stack, as some of my clients started
| automatically connecting to the new server even before I
| had finished all my testing.
|
| Turns out that it was advertising some kind of ipv6 link-
| local address that showed up in autodiscovery. In my case
| there wasn't any harm, but this type of thing could very
| easily result in a major security vulnerability.
| jcgl wrote:
| I don't see how this generalizes into a security hole
| caused be lack of IPv6 knowledge. It just sounds like a
| random bug in Snapcast (great program!). If a user
| configures a program to only bind to loopback, but the
| program binds to other interfaces as well, that's a bug
| in the program.
| QuercusMax wrote:
| There are sure to be dozens or hundreds of
| vulnerabilities like this, that's what I'm saying. I'm
| not even sure it's a bug in snapcast - very possible I
| configured it wrong without realizing.
| jcgl wrote:
| Without knowing exactly what happened here, it could be
| hundreds, dozens, or zero other such vulnerabilities.
|
| The usual convention for configuring listening interfaces
| usually involves listing IP addresses or interface names.
| There's very little room for misconfiguration here,
| although it's possible. More likely to be a bug in
| Snapcast (it's almost certainly not an issue in the Linux
| kernel).
|
| Moreover, this general problem (i.e. configuring
| listening interfaces) is not/should not be different
| between IPv4 and IPv6. So introducing IPv6 should not(tm)
| incur any additional risk at this level.
|
| But as said, it's hard to get more concrete without
| knowing exactly what happened in your case.
| jeroenhd wrote:
| Localhost doesn't appear on autodiscovery. Whatever you
| ran into had nothing to do with IPv6, but rather with
| your application not binding to the address you were
| telling it to bind to. On IPv6, localhost binds to ::1,
| not anything reachable by any other address. Furthermore,
| whatever you set up automatically seems to have added
| itself to your server's firewall, which is equally
| troubling.
| QuercusMax wrote:
| The address my clients were finding automatically was a
| link-local address (fe80...). Can't say exactly what
| happened but it was _very_ surprising since I didn 't
| even know these addresses existed.
|
| I'm sure it's totally my fault but that's the point:
| folks who know how ipv4 works may have huge blind spots
| for ipv6.
| nextaccountic wrote:
| That's why ipv6 migration should be government mandated.
| Then it becomes just the cost of doing business
| sschueller wrote:
| Just found this little site. https://isgithubipv6.web.app/
|
| Maybe we shouldn't even measure percentage adoption and instead
| just if github has finally adopted..
| Landing7610 wrote:
| Our university has bad problems with ipv4. Every few days
| you'll notice some websites being unreachable, including
| github. Although with their uptime recently, you never know
| who's to blame...
| missingdays wrote:
| Most websites still don't
| farfatched wrote:
| GitHub should absolutely support IPv6, but until then...
| transip.eu provide IPv6 addresses which transparently proxy to
| github.com: https://www.transip.eu/knowledgebase/5277-using-
| transip-gith...
|
| You'll need to update your DNS server to include those as AAAA
| records.
|
| Do providers like NextDNS or RethinkDNS allow these sorts of
| overrides?
| voltagex_ wrote:
| >The Github IPv6 Proxy can only be used for traffic to Github
| using a VPS from TransIP which uses IPv6.
| farfatched wrote:
| Good spot. Sorry to disappoint!
| ignoramous wrote:
| _rdns dev here_
|
| > _Do providers like NextDNS or RethinkDNS allow these sorts
| of overrides_
|
| Not on the resolver, but on the Android client (Rethink DNS +
| Firewall) we do (if enabled) manipulate DNS answers to
| implement an opportunistic _464xlat_ (over Kasper Dupont 's
| public relays [0]).
|
| [0] https://github.com/celzero/firestack/blob/c10c155464e0d4a
| 81a...
| jiggawatts wrote:
| The irony of this is that pretty much all they'd have to do to
| enable IPv6 support is to use Azure Front Door as their CDN.
| Or... use any other CDN, they pretty much all default to
| providing IPv6!
| aetimmes wrote:
| Last I checked, they're on Fastly who already support IPv6.
| throw0101a wrote:
| > _And still, in the year of our lord 2026, GitHub does not
| support IPv6._
|
| Especially given that it is now owned by Microsoft, which has
| been working on IPv6-only (at least on their corporate network)
| for almost a decade:
|
| * https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/
|
| * https://www.arin.net/blog/2019/04/03/microsoft-works-
| toward-...
| rekoil wrote:
| I mean Azure doesn't really support IPv6 well either for a
| lot of the big-ticket services.
| fogllgldl wrote:
| More importantly, it doesn't support uptime well.
| sidewndr46 wrote:
| we could meet in the middle: Azure support IPv6 with 0%
| uptime
| Twirrim wrote:
| That seems weird given NIST, and the US Government, set a
| requirement for IPv6 Only back several years ago, and it
| sort-of became part of the JWCC requirements (It wasn't in
| the requirements, IIRC, because it came after those were
| set, but the government wouldn't fully approve use for JWCC
| if you didn't meet it).
|
| You'd think they'd have sprinted for that feature as fast
| as they could go.
| bigfatkitten wrote:
| Microsoft gets special treatment.
|
| USG also set a whole bunch of security requirements under
| FedRAMP that Microsoft can never meet, but they received
| an ATO anyway because they are so heavily entrenched in
| government.
| jermaustin1 wrote:
| Same with Twilio. We have an internal server that does system
| alerts. We recently moved it to an IPv6 only host, and a few
| weeks went by and noticed there were no longer receiving
| alerts.
|
| Turns out we could not connect to Twilio's API which is IPv4
| only.
| tbrownaw wrote:
| So zero validation after that change?
| vlovich123 wrote:
| Zero observability and alerting too. Seems like they're
| planning to be a productive future member of that team.
| jermaustin1 wrote:
| Who? The infrastructure team that did the move didn't
| even tell anyone. They were decommissioning old servers,
| and moving the VMs to new hardware. I'm just a lowly
| developer that had to troubleshoot why SMSes stopped
| going out.
| vlovich123 wrote:
| Observability and alerting is pretty standard devops.
| Both the dev and infrastructure teams dropped the ball
| here. But at least as part of remediating this you added
| alerting to make sure you'd notice when your twillio
| connection fails in the future, right?
| jermaustin1 wrote:
| Even better, infrastructure enabled IPv6, and the issue
| was closed.
|
| In corporate software development, we work the tickets
| assigned, and keep our KPIs up so that we don't face the
| wrath of the bean counters.
| jermaustin1 wrote:
| Couldn't tell you. I'm not part of the infrastructure team.
| I wasn't even aware the alerting service was moving.
|
| QA found it a couple weeks later when they were testing
| alerting, and SMSes weren't coming through.
| strenholme wrote:
| Kinda sorta.
|
| github.com doesn't have an IPv6 address.
|
| github.io _does_ have an IPv6 address. Indeed, one workaround
| for getting rate limited when using a carrier NAT with
| github.com is to have a github.io page and pull data from
| github.io instead of github.com.
|
| Edit: About a decade ago, all of my hosting had full IPv6
| support, and I tried to move over to IPv6. However, there was
| an issue with Letsencrypt certs not validating over IPv6, so I
| made my web pages IPv4 only. Recently, I gave IPv6 a go again,
| and the cert issue has been fixed, so now my webpages finally
| have both IPv4 and IPv6 addresses.
| GoblinSlayer wrote:
| >github.io does have an IPv6 address
|
| Are you sure? I don't see it.
|
| Name: github.io
|
| Addresses: 185.199.111.153 185.199.110.153 185.199.108.153
| 185.199.109.153
| codethief wrote:
| At least HN supports IPv6 now, which I remember was not the
| case last time I checked.
| sschueller wrote:
| My next project, IPv6 in my homelab. It will be a challenge but
| it is time. My ISP gives me a static /48, I should use it.
| jeroenhd wrote:
| I recommend going through Hurricane Electric's multiple-choice
| tests. It's not exactly a how-to guide or course, but it'll
| mention all of the terms and technologies you need to look up
| to get things right. They'll even send you a free T-shirt if
| you make it through all of them.
|
| The most difficult parts for a homelab in my experience is
| getting Docker to play nicely. All of the other stuff sort of
| just works these days. Even things like using DHCPv6 prefix
| delegation to obtain a routable subnet is almost trivial with
| how well-supported the protocol is with modern networking
| software.
| sschueller wrote:
| Where do I find that? https://www.ipv6.he.net/ has an invalid
| certificate and is the first result on Google.
| elevendroids wrote:
| You need to omit the "www" subdomain: https://ipv6.he.net
| jeroenhd wrote:
| Their www sub-subdomain is broken it seems.
|
| https://ipv6.he.net/certification/ has instructions on how
| to get started.
| davidkuennen wrote:
| Setting up my own server (migrating off GCP LB) taught me so much
| about networking. I was especially surprised that providing IPv6
| is such a performance boost for low bandwidth phones since they
| mostly only operate on IPv6 by now and IPv4 needs some sort of
| special roundtrip.
| emj wrote:
| Cool! Could you give some concrete examples of apps or traffic
| patterns where you think IPv6 may noticeably improve
| performance on phones? Are you mainly referring to NAT
| traversal during connection setup, or to something that also
| affects traffic after the connection is established?
| Dagger2 wrote:
| Many mobile ISPs handle v4 via NAT64 or CGNAT. Routers
| capable of doing those are far more expensive than regular
| routers, so there tends to be fewer of them. v4 traffic has
| to travel out of its way to reach one of those routers,
| whereas v6 traffic can be handed off sooner with a more
| direct physical path.
|
| It affects anything where latency matters, e.g. from
| Facebook: "We've observed that accessing Facebook can be
| 10-15 percent faster over IPv6."
| (https://engineering.fb.com/2015/09/14/networking-
| traffic/ipv...).
| molf wrote:
| It's only a matter of time before laptops get 5G. Macbooks have
| been rumoured for a while to get cellular modems. [1]
|
| This will probably help adoption. On the one hand it will
| generate more IPv6 traffic. On the other hand it will expose more
| developers to IPv6; which will expose them to any lack of support
| for IPv6 within their own products.
|
| [1]: https://9to5mac.com/2025/08/14/apples-first-mac-
| with-5g-cell...
| panny wrote:
| I can't imagine a worse privacy nightmare. Always on backdoored
| baseband in 5G with a unique permanent IPv6 address assigned to
| the machine. Okay, maybe it could be worse if each user account
| is assigned its own unique IPv6 perma-cookie.
| merpkz wrote:
| As if people doesn't already carry always online machine in
| their pockets
| Dagger2 wrote:
| You're thinking of MAC addresses. Machines don't have
| permanently-assigned v6 addresses, rather the IP is assigned
| by whatever network they're currently attached to and will
| change based on that network's whims, just like it does in
| v4.
| nottorp wrote:
| > Okay, maybe it could be worse if each user account is
| assigned its own unique IPv6 perma-cookie.
|
| They will. One from facebook, one from google, one from
| tiktok, several from Palantir and its partners...
| Glemllksdf wrote:
| Thats quite surprising thing to me and weirdly obvious.
|
| If you are single, have a phone contract, you would need some
| extra contract for a landline internet and wifi router because
| thats what a lot of people just do and now they can just add an
| esim and pay a little bit more.
|
| Interesting that this sounds/feels a lot more right or useful
| than it did 5 years ago.
| venzaspa wrote:
| Dell, HP and Lenovo have had laptops with cellular modems for
| maybe 15 years at this point.
| theandrewbailey wrote:
| I can confirm this. I work at an e-waste recycling company,
| and the vast majority of my inventory is corporate IT
| decommissioned gear. About 1 out of 10 laptops I tear down
| has a cellular modem, going back to about Intel Core 5th gen.
| vel0city wrote:
| I've had laptops with cellular modems built in going back
| to Pentium IIIs. The Compaq N600c had a "multiport" bay on
| the lid, one of the options was a GSM modem.
| brcmthrowaway wrote:
| Jesus, what a waste
| gempir wrote:
| *A few select models got celluar modems.
|
| I have owned several Dell, HP and Lenovo Laptops in the past
| 15 years and I have never had a cellular modem.
|
| When Apple makes a change like that it impacts a lot of
| customers because they have way fewer skews.
| dlcarrier wrote:
| I've never had a modern laptop with a cellular modem, but
| every one I've owned has supported them internally. Even
| when they aren't provisioned with them, they're usually
| still supported as aftermarket options.
| dlcarrier wrote:
| Yeah, but any given technology hasn't been invented yet,
| until Apple releases it.
| nottorp wrote:
| > It's only a matter of time before laptops get 5G.
|
| So you want laptops to cost <whatever the laptop costs> plus a
| measly 19.99/month for internet connectivity?
|
| What's wrong with just tethering to my existing phone?
| Sweepi wrote:
| | Macbooks have been rumoured for a while to get cellular
| modems.
|
| Maybe they are finally coming, however the rumors are older
| then the iPhone. Example from 2008: https://pcr-
| online.biz/2008/11/03/3g-macbooks-on-the-way/
| traderj0e wrote:
| 5G services all give you an ipv4 too, so devs won't be exposed
| to lack of v6 support.
| zokier wrote:
| This google metric measures adoption in access networks, but at
| this point I feel more interesting metric is adoption in
| services.
|
| One such stat is here:
|
| > adoption ranging from 71% among the top 100 to 32% in the long
| tail
|
| https://commoncrawl.org/blog/ipv6-adoption-across-the-top-10...
|
| Getting full coverage on AWS (/GCP/Azure) and few other key
| services (GitHub...) would be significant here imho.
| tonymet wrote:
| great resource. Common crawl is a goldmine
| traderj0e wrote:
| Yeah, a large portion of those ipv6 Google searches are
| afterwards connecting to an ipv4 host.
| loevborg wrote:
| Sometimes TCP/IP is a leaky abstraction, and recently ipv6 peeked
| through in two separate instances:
|
| - In a cafe wifi, I had partial connectivity. For some reason my
| wifi interface had an ipv6 address but no ipv4 address. As a
| result, some sites worked just fine but github.com (which is,
| incredibly, ipv4-only) didn't
|
| - I created a ipv6-only hetzner server (because it's 2026) but
| ended up giving up and bought a ipv6 address because lack of ipv4
| access caused too many headaches. Docker didn't work with default
| settings (I had to switch to host networking) and package
| managers fail or just hang when there's no route to the host. All
| of which is hard to debug and gets in your way
| pastage wrote:
| You can solve this issue if you have one server with ipv6/ipv4
| you can run NAT with Jool and connect ipv6 only servers to
| that. Like Android does.
|
| I wish hosting providers would give you a local routed ipv4 on
| ipv6 servers with a default NAT server. It is not that
| expensive I move 10Gbps "easily" and they could charge for that
| traffic.
| zokier wrote:
| > I wish hosting providers would give you a local routed ipv4
| on ipv6 servers with a default NAT server.
|
| You mean like AWS NatGW
| https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-
| gat...
| crote wrote:
| Those are still per-customer and require you to dedicate an
| entire IP address to it. That's overkill for a server which
| mostly talks over ipv6 but needs to connect to an ipv4-only
| service like Github once in a blue moon.
| emj wrote:
| 30 USD/month and 0.045 USD/GB for ingress it is ok if you
| are big. It is a cheap service to build yourself. I do feel
| the pain of it being hard to get IPv4 minimal connectivity
| on ipv6 only hosts, i.e. for me a 1 USD/GB would be fine.
| loevborg wrote:
| Any services like this for Hetzner?
| umanwizard wrote:
| The cafe WiFi thing (getting IPv6 only, no ipv4, on a public
| network) used to happen quite often to me on macOS. I never
| figured out why, and I haven't noticed in a while.
| ymolodtsov wrote:
| But I still have to pay Hetzner separately to rent out an IPv4.
| ruuda wrote:
| Finally https://www.metaculus.com/questions/9558/50-of-users-
| access-... can resolve!
| anonymfus wrote:
| Current submission title:
|
| > IPv6 traffic crosses the 50% mark
|
| Graph description:
|
| > The graph shows the percentage of users that access Google over
| IPv6
|
| There are reasons to expect both much more and much less traffic
| per user on IPv6 compared to IPv4...
| purerandomness wrote:
| IPv6 will never make it. Maybe IPv8 [0], which IPv6 should have
| actually looked like:
|
| > 1.1.1.1.1.1.1.1
|
| [0] https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
| direwolf20 wrote:
| Why do people keep proposing alternatives to IPv6 that are no
| easier than IPv6 but still require the whole world to start the
| deployment over from 0%?
| c0l0 wrote:
| I'd say it's either because they're just having fun, or
| because they're dumb.
| josh3736 wrote:
| For observers, this draft was posted to HN earlier but quickly
| flagged and removed because the linked "IPv8" draft is absolute
| bunk.
|
| See the removed thread for details:
| https://news.ycombinator.com/item?id=47788857
| tialaramex wrote:
| Having read that thread, I guess one of the small upsides of
| the world I live in is that "FIFA Peace Prize" is now
| available as a joke award reference. FIFA really hit it out
| of the park there in a way that even their normal legendary
| levels of corruption couldn't imagine.
|
| Edited: In hindsight I notice that "hit it out of the park"
| is the wrong sport metaphor for FIFA, but I stand by it
| anyway.
| embedding-shape wrote:
| > Edited: In hindsight I notice that "hit it out of the
| park" is the wrong sport metaphor for FIFA, but I stand by
| it anyway.
|
| For future reference, you can use: "knocked it into the top
| corner", "put it in the back of the net" or "smashed it
| past the keeper". Not a native football-talker, but hang
| out too much with a few.
| tialaramex wrote:
| "Back of the net" doesn't feel the same to me even though
| (I learn after reading far too much about a sport I do
| not play) "Out of the park" is basically the same thing.
|
| In my mind "out of the park" had meant the ball leaves
| the actual stadium but in fact (I read) "the park" in
| this context is actually the field of play and so "out of
| the park" represents in fact the vast majority of home
| runs and not the over-achievement I had imagined.
|
| So TIL but thanks for the suggestions.
| embedding-shape wrote:
| True, "back of the net" is more "someone kicked the ball
| really hard and it hit the back of the net really hard"
| instead of "the ball came across the goal line" which can
| be very different, so in my mind that's as close to "out
| of the park" as you can get in soccer :)
| po1nt wrote:
| Nice idea. Always wondered why IPv6 went so ambitious with the
| addressing
| Ekaros wrote:
| Might as well go big. 24 extra bytes per packet is not that
| big deal. And having that much extra space means you can
| screw up design multiple times and still be able to reuse lot
| of infra. Also getting rid of idea that you are even trying
| to manually manage the address space eases many things.
| po1nt wrote:
| But it's not human readable anymore, nor backwards
| compatible. The expectation was that the industry is
| reasonable, but it proved to be as hard as it would be to
| push breaking email v2 implementation.
| Dagger2 wrote:
| If you think v6 isn't backwards compatible then literally
| anything bigger than 32 bits will never count as
| backwards compatible for you. The whole point of making
| the address space bigger is to make it bigger, so what do
| you expect to achieve by complaining that the result is
| incompatible?
|
| As a human, I've found that e.g. "fd00::53" is perfectly
| readable to me, and most of the time you're interacting
| with strings like "news.ycombinator.com" anyway which is
| identical to how it works in v4, so I'm not sure how far
| I'd agree with that part either.
| ButlerianJihad wrote:
| One of the craziest aspects of IPv6 implementation is the
| reverse DNS lookups.
|
| IPv6 uses ip6.arpa and segments each little nybble into a
| subdomain!
|
| https://en.wikipedia.org/wiki/Reverse_DNS_lookup#IPv6_revers.
| ..
|
| This means there are _always_ 32 octets to a reverse-IPv6
| address, and there are no shortcuts or macros to overcome
| this! That means if you wish to assign a singular name that
| maps from a legitimate /64 Network ID, you must populate 64
| bits worth of octets in a zone with this data. It is an
| absurd non-solution. This never should've been allowed to
| happen, but it will basically mean that ISPs abandon reverse
| DNS entirely when they migrate to IPv6 implementations.
| Dagger2 wrote:
| $ dig -x 2606:7100:1:67::26 | grep PTR ;6.2.0.0.0.0.0
| .0.0.0.0.0.0.0.0.0.7.6.0.0.1.0.0.0.0.0.1.7.6.0.6.2.ip6.arpa
| . IN PTR
|
| Run this, then copy/paste the output into your zone file.
| Remove the ; and add "example.com." or whatever to the end.
|
| I agree it's a pain to read, mostly because DNS addresses
| are written backwards, but an "absurd non-solution"? For a
| set of instructions that don't even depend on the format of
| the record (they work for v4 too), and which I could
| describe in one line in a HN comment?
|
| If this is the craziest part of v6 then it must be
| incredibly well designed overall.
| tialaramex wrote:
| It is a pretty nice design, partly as a result of the
| fact that we've got a working system to look at (IPv4)
| and we have a lot more eyeballs "these days" (when IPv6
| was designed, so, decades ago now) than when the Internet
| Protocol was a new idea.
|
| I think perhaps the person you're responding to imagines
| that somehow DNS mandates a very naive implementation and
| so this behaviour would be incredibly expensive. The sort
| of person who sees a flip clock and imagines it needs
| 1440 different faces not 84 (or in some cases 72) because
| they haven't realised 12:34 and 12:35 simply use the same
| hour face.
| ButlerianJihad wrote:
| "copy paste the output" is your solution? You think this
| somehow scales to manage entire networks like this with
| dynamic addressing? Do you perceive a network admin as a
| monkey who copy-pastes things all day?
|
| This is exactly the absurd non-solution I am referring
| to, and it seems like if someone dismisses this with "one
| line instruction is all u need lol" they cannot even
| comprehend the scale at which real life operates.
| Dagger2 wrote:
| Copying and pasting was just my attempt to demonstrate
| how simple a v6 rDNS record is to add. If you were
| interested in hiring me to write a solution for your ISP,
| that's fine, but you can't seriously expect random people
| to do it for you for free in a HN comment.
|
| It should be pretty obvious that a script can generate
| these records from the forward records or from any other
| source of IPs/hosts, with no per-address effort needed on
| the part of the network admins.
| ButlerianJihad wrote:
| Again, absolutely blind to the management of these things
| at scale. Yeah, I don't rightly care about "how easy it
| is" to generate them. You can't even comprehend or convey
| the massive number of records and zones that are involved
| in managing a network of devices that all require dynamic
| updates to reverse-DNS and add/update/remove device
| addresses on a regular basis.
|
| DNS is a distributed database system, and so the
| challenge is not cramming in data with a brainless
| script, but managing how that data is distributed and
| accessed by thousands or millions of peer servers,
| caches, and clients worldwide.
|
| IPv4 reverse-DNS was quite simple when it was broken on
| octet boundaries and there were only four of those
| boundaries in total. But even then, ISPs could often not
| be arsed to put the right data in there. Some left it
| blank and some waited until they were forced, by strict
| requirements that said reverse must match forward DNS in
| many cases.
|
| I have never found any user-accessible software, not on
| any Linux distribution or on any cloud service, that
| would permit an ordinary consumer to manage even a /24
| IPv4 network's reverse-DNS at scale, or programmatically,
| as opposed to by-hand "copy paste" as has been so
| condescendingly suggested here. There are plenty of
| hosted DNS providers, and there are plenty of monkey-
| brain Dashboard interfaces where you can pound out one A
| record at a time. But there was nothing to deal with
| dynamic addressing or DNS databases at scale. That's why
| IPv6's reverse DNS remains an absurd non-solution.
| Dagger2 wrote:
| So... how many records and zones? I'm pretty sure I could
| convey it if I could work out what you were talking
| about.
|
| You went from "you can't even comprehend or convey the
| massive number of records and zones that are involved" to
| one v4 /24, managed "at scale" but by an ordinary
| consumer, who you expect to be capable of programming.
| This is a bit all over the place.
|
| It's not any harder to deal with v6 reverse DNS than it
| is v4. In fact, making every reverse label 4 bits instead
| of 8, combined with v6 being much bigger than v4, makes
| rDNS much easier to deal with in v6 because you can
| generally delegate reverse zones on exactly the same
| boundaries that you delegate the corresponding IP blocks.
| In v4, you often need to delegate on boundaries that
| aren't /8, /16 and /24 and it suddenly gets more
| annoying.
|
| Scaling up for rDNS is no different to scaling up for
| forward DNS. It's a well-understood problem.
| neojima wrote:
| Anyone who's ever had to delegate DNS authority on anything
| other than an 8-bit boundary can understand the value of
| that feature.
|
| At face value, yeah, that's replacing "8" with "4," but
| from a practical perspective, delegating authority for a
| customer IPv4 /25 requires, at minimum, 128 records.
| (Granted, there's also no practical need to be stingy about
| IPv6 allocations -- that IPv4 /25 customer could simply
| receive an IPv6 /48.)
|
| I would firmly expect to see a lot more formulaic reverse
| (and presumably forward) DNS responses, where needed, since
| filling files with records you need to store on disk (and
| in memory) doesn't scale well. The tech has existed for
| years; I wrote my own implementation years ago, but these
| days I'd use something like PowerDNS with
| https://github.com/wttw/regexdns .
| ButlerianJihad wrote:
| At home, I use an Android 16 Pixel phone, and a Chromebook, and I
| would suspect (but cannot prove) that 100% of my LAN outages can
| be blamed on the dual-stacking nature of IPv6 plus IPv4.
|
| Chris Siebenmann has written extensively on IPv6:
| https://utcc.utoronto.ca/~cks/space/?search=ipv6
|
| Google has some weird way of asserting connectivity, and I
| suspect that when connectivity on one protocol is lost, it is
| impossible to maintain or establish connectivity through the
| other one (IPv6) even if it is available upstream.
|
| I am rather infuriated with the _status quo_ at this point,
| because it is impossible to disable IPv6 on my devices and it is
| also impossible for my ISP to disable IPv6 on my LAN or on the
| CPE router which they own and control.
|
| Due to chronic WiFi issues I was eventually forced to place my
| ISP router into Bridge mode permanently, and I use a 3rd party
| Netgear which I own, and does not have the same WiFi issues, and
| where IPv6 is optional (and often fails, because its
| implementation is buggy and glitchy for no reason.)
| direwolf20 wrote:
| I am rather infuriated that it's impossible to disable IPv4 on
| my devices, so does that make us even?
| ButlerianJihad wrote:
| Yes I believe so!
|
| I recently purchased a brand-new LaserJet printer, and since
| it needs nothing to do with the Internet or a WAN outside my
| home, I thought it'd be great to simply disable IPv4 and stop
| doing the DHCP dance.
|
| Well it immediately fell off the net completely. I couldn't
| figure out how to expose its IPv6 address or contact its
| management interface.
|
| Hypothetically, Bonjour and mDNS should make this a no-
| brainer. Hypothetically, disabling IPv4 shouldn't even
| prevent it from connecting to the Internet. But I was
| ultimately forced to factory-reset it.
|
| IPv6-only LAN makes a lot of sense for most people, and
| perhaps reduces attack surface a little. If you have the
| means, I highly recommend setting it up!
| jabl wrote:
| Are any ISP's or corp intranets doing IPv6-mostly style networks
| yet: https://www.ietf.org/archive/id/draft-
| link-v6ops-6mops-00.ht...
|
| That seems to be a promising approach.
| farfatched wrote:
| According to https://www.ipv6.org.uk/wp-
| content/uploads/2023/11/13_IPv6-M... , Google is.
|
| The author of the RFC is the author of the slides.
| ninkendo wrote:
| T-Mobile does:
| https://www.internetsociety.org/deploy360/2014/case-study-t-...
|
| They use 464XLAT, basically NAT64/DNS64 with some extra
| cooperation on the OS's part for backwards compatibility with
| apps that hard-code IPv4. You get only a v6 address, and your
| OS basically synthesizes an v4 network on your device in
| cooperation with their NAT64 router. But all the bytes going
| from your device through to their towers are ipv6. Talking to a
| v4-only website uses carrier-grade NAT64 when leaving the
| t-mobile network.
| neojima wrote:
| Additionally, their fixed-wireless product gives you a
| physical CPE that does the CLAT (NAT46) side of the 464XLAT.
|
| To the local network, it looks like there's native IPv4, but
| it's translated to IPv6 by the gateway, and sent to the
| "nearest" NAT64 PoP to be translated back and sent along its
| merry way.
| Mashimo wrote:
| I wonder why Germany has a relative high adoption rate with 77%?
| They are normally behind when it comes to new technology.
|
| Is it because they have more carrier NAT?
|
| In Denmark I can get cheap 1 / 1 Gbit/s fiber, but still no ipv6
| :(
| ahartmetz wrote:
| Carrier-grade NAT for home connections is pretty rare in
| Germany. I only know of Deutsche Glasfaser - a fairly new ISP
| that isn't doing too well.
| interloxia wrote:
| Vodafone cable's cgnat struggles. I went v6 for home so that
| at least the v6 sites and my own connections avoid the
| congestion.
| Dagger2 wrote:
| It's very common. German ISPs collectively went with DS-Lite,
| so most of that 77% with v6 have CGNATed v4.
| ahartmetz wrote:
| Somehow it's really hard to find numbers, but AFAIK at
| least Telekom and 1&1 don't use CGNAT for home connections,
| which already rules out that 77% have it.
| Dagger2 wrote:
| Questions like this suggest that 1&1 do:
| https://forum.openwrt.org/t/solved-dsl-over-ds-lite-with-
| isp...
|
| I'm less sure about Telekom. For obvious reasons, it's
| hard to find info in English.
| ahartmetz wrote:
| My anecdata is that I'm on 1&1 fiber and I have a public
| IPv4 address.
| FeelingGood wrote:
| We have enough IPv4 addresses (combined with CGNAT) in Denmark
| so the providers have no business incentive to spend money on
| supporting IPv6 :/
| BartjeD wrote:
| In before the dinosaurs arrive to complain about the challenges
| of moving to IPv6 and why NAT and IPv4 are better. ;)
| moralestapia wrote:
| Any idea why it oscillates?
| kalleboo wrote:
| Corporate IT networks have less IPv6 and residential/mobile
| networks have more IPv6, so on weekdays when people are using
| Internet at work = more IPv4, weekends when people are using
| Internet at home = more IPv6. Christmas also has a big bump for
| the same reason.
| moralestapia wrote:
| Awesome, thanks.
|
| No change in trend during COVID years, interesting.
| Dagger2 wrote:
| There is -- you can see the weekday/weekend difference is
| smaller when people are working from home en masse.
| ghoshbishakh wrote:
| Countries like India have higher adoption (>70%) because of 4G/5G
| abundance. Legacy broadband providers hold back IPv6 usage.
| Galanwe wrote:
| Every year I just wish someone will come up with IPv4-with-more-
| bytes and we can switch to it before IPv6 gets another percent
| usage share.
| AndrewDucker wrote:
| IPv4-with-more-bytes is not backwards compatible with IPv4. So
| you'd have to replace/upgrade every existing network stack,
| both hardware and software. To get, basically, the same effect
| as moving to IPv6.
| Galanwe wrote:
| > IPv4-with-more-bytes is not backwards compatible with IPv4
|
| Neither is IPv6
|
| > To get, basically, the same effect as moving to IPv6
|
| The only thing that IPv6 solves which is of interest to
| 99.99% of the users is having more adressable space. The rest
| of IPv6 features are either things that nobody asked for, or
| things which are genuinely worst compared to IPv4.
|
| I consider the mere fact of enabling IPv6 an unacceptable
| security risk, as I would now have to make sure my IPv4 and
| IPv6 firewall stack are perfectly mirroring each other. That
| would be trivial with IPv4-with-more-bytes, it's a nightmare
| with IPv6.
| mrsssnake wrote:
| Do NAT64 and just worry about IPv6 if not wanting dual
| stack.
|
| All of IPv6 features are just direct effects of having more
| space and not. Basically IPv6 "features" is just getting
| rid of IPv4 workarounds.
| vel0city wrote:
| > I would now have to make sure my IPv4 and IPv6 firewall
| stack are perfectly mirroring each other.
|
| You'd still have that in your IPv4-with-more-bytes, as
| you'll still probably end up running dual-stack to address
| those old-v4-only sites. Or you'd do the same with v6 and
| run a tunnel to translate those v4-only addresses to your
| v4-with-more-bytes. So you're in the same situation either
| way.
| mprovost wrote:
| There were backwards-compatible protocols proposed, such as
| EIP, but the committee chose a backwards-incompatible
| protocol for v6. Their assumption was that v4 would run out
| of space in a single-digit number of years and everyone would
| be forced to migrate. The past 30 years have shown that not
| to be the case.
|
| https://datatracker.ietf.org/doc/html/rfc1385
| Dagger2 wrote:
| They went with SIPP, which was one of the backwards-
| compatible options. It should be kind of obvious from the
| vast number of backwards compatibility methods available in
| v6 that v6 is actually backwards compatible... but for some
| reason a lot of people either refuse to believe this or
| have double standards around what counts as compatibility.
| blueflow wrote:
| IPv6 is IPv4 with 12 more bytes, right?
| pocksuppet wrote:
| That's what IPv6 is. People get so fixated on being annoyed at
| IPv6 they forget to actually think. Whatever you invent won't
| be any better than IPv6. Many people have tried.
|
| If you change the address format even the tiniest amount, if
| you add one single additional bit, your new protocol is already
| completely incompatible with all existing IPv4 software and
| equipment.
| p4bl0 wrote:
| It amuses me to see that according to the map, France is best in
| class or close to be, while just a few weeks ago, my ISP in
| France stopped providing me IPv6 connectivity...
|
| The story is that at the beginning I had IPv6, and a shared
| dynamic IPv4 behind a CGNAT, I asked for a rollback to a full
| duplex static IPv4 and for three years I had both a static
| personal IPv4 and an IPv6. A few weeks ago my router went down
| and since it went back up, I no longer have an IPv6 address. I
| called my ISP and they explained that I could either have IPv6 or
| a static IPv4, but not both, and that it's abnormal that I had
| both for so long... welp, it's sad to see IPv6 but getting it
| back is not worth abandoning my static IPv4 and going back to a
| dynamic shared IPv4.
| harg wrote:
| Are you with SFR? I also seem to only have a static IPv4 (I
| don't pay for it, but it's never changed in the lifetime of the
| connection). I asked for an IPv6 but they said it was not
| possible/difficult.
| p4bl0 wrote:
| Yep, with "RED by SFR" specifically.
| fossilwater wrote:
| Among all the major French providers, SFR lags far behind
| its competition unfortunately
| p4bl0 wrote:
| I know, but at the time I had to choose an ISP, they were
| the only ones with an offer with just internet (and a
| phone line), all others ISP forced a bundle with dozens
| of TV channels that I don't need along with their
| internet access subscription. They were also the most
| competitive price wise, and other than this problem
| (which is new for me, I had an IPv6 and a static IPv4
| until a few weeks ago), I'm satisfied with the service
| :).
| basilikum wrote:
| You might be interested in https://tunnelbroker.net/ and
| https://route64.org/ although the later looks a little shady
| and I haven't tried them.
|
| A cheap VPS or one with spare bandwidth with > /64 that is
| properly routed (some providers do NDP for some reason) and a
| Wireguard tunnel would also get you a simple DIY solution.
| everdrive wrote:
| I am waiting for the flood of evangelist to explain:
|
| - IPv6 proponents are the only ones who know that NAT is not a
| firewall, and
|
| - Everyone in the world would love IPv6 if they just didn't hate
| learning new things
| harg wrote:
| Interesting to see Spain having such low IPv6 adoption. Perhaps
| that's exacerbated the issues caused there by blocking IPs during
| football matches that we've seen mentioned in recent HN posts.
| zokier wrote:
| Spain has one of the highest FTTx rollouts in Europe though. My
| theory is that they just prioritized building fiber and there
| was no money left for ipv6 transition.
| jl6 wrote:
| Everyone's saying progress is slow, but maybe this is just how
| long it takes to do massive decentralized global migrations
| affecting billions of people. What are we comparing against?
| Maybe the ICE-to-EV transition?
| nlitened wrote:
| For example, compared to migration from 3G to 4G networks. As I
| understand, from the launch of 4G to complete shutdown of 3G it
| took around 12--14 years.
| zrail wrote:
| A reasonably fair comparison. The ISPs had a much stronger
| incentive to finish the migration, though, because the 3g
| spectrum could just get turned around and used for 4g after
| rollout. IPv6 doesn't really have that strong of an incentive
| structure now that CGNAT is a well-developed technology.
| vel0city wrote:
| One major difference in the 3G->4G and now 4G->5G conversion
| was that was largely a single-party change in the end to
| actually implement. The client and the server hosting an
| application doesn't care about whether that traffic is over
| 3G or 4G or IP over Avian Carriers as long as the packets get
| there in a reasonable time. Going from IPv4 to IPv6 requires
| lots of very different players to all work together to make
| the transition, meanwhile for a carrier to go from 3G to 4G
| its largely on them and their direct contractors.
| easterncalculus wrote:
| World IPv6 Day was in 2011, so 15 years since then. This is
| also requiring a consumer hardware and software upgrade on
| both the client and server (resource they're accessing).
| GitHub doesn't have to implement 4G support.
| tonymet wrote:
| Latin1 to UTF8
| umanwizard wrote:
| And I still, to this day, see mojibake from time to time.
| tonymet wrote:
| The exception that proves its success
| zeristor wrote:
| This is the global curve, it looks to be flattening I had thought
| it would be more asymptotic to 100%.
|
| My company is ipv4 still, and some customers are having issues
| with ipv6 only connections.
|
| Also we log the ip addresses, and that's only in ipv4.
| torcete wrote:
| They have released the draft for IPv8 two days ago:
| https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
|
| Does it mean we better put our chips on IPv8?
| badgersnake wrote:
| Guess you didn't read it.
| anilakar wrote:
| 15 years ago I would have dismissed this immediately as an
| elaborate troll but nowadays you cannot be sure anymore.
|
| I'm suggesting moving on to IPvNN which requires device and
| ISP forced guarantees that the originator is not under the
| effect nor the lack of any medication or other substance, not
| being coerced and not using non-human assistants in content
| creation.
| torcete wrote:
| That goes for me?
| anilakar wrote:
| Depends on the degrees of separation between you and the
| draft author.
|
| I guess we both agree that both humor and sarcasm are
| difficult to convey on the internet and LLMs do not make
| the job any easier :-)
| Dagger2 wrote:
| https://datatracker.ietf.org/doc/html/draft-wkumari-not-a-dr...
| zeristor wrote:
| My interest was piqued 20 years ago, then there was talk about
| Internet2 with all these amazing optimisations.
|
| Things have developed so much, a Internet2 is still going on I
| take it, however is more focussed on university research.
|
| As ever a killer strength is something that draws people to a new
| technology, I imagine there's various demographics that benefit
| from use of ipv6.
|
| Further I imagine that there are some levels of criticality which
| when reached are more self sustaining (dare I say it the network
| effect?).
|
| I've been posting this graph over the years, and it really has
| slowed down hugely close to this 50%. This is a global ipv6
| support, so some countries are racing ahead, others weirdly like
| Denmark have a stash of ipv4 addresses and seems content.
|
| France and Germany are at about 80%, but there's the rest of the
| world of course.
| gauravkundu wrote:
| Waiting for github to support
| ButlerianJihad wrote:
| One of the foremost obstacles to wide adoption is that IPv4 still
| works great and it's ubiquitous. There is no advantage or up-side
| to deprecating or abandoning IPv4 support at all. The only result
| of disabling IPv4 is a denial of service to a certain sector of
| customers or clients.
|
| The only way this will change is by increasing pressure on the
| resource of IPv4 networks. It was a few years ago that AWS broke
| the news to me that I'd be paying for IPv4 addresses but IPv6
| would remain free. If enough services are forced, financially, to
| abandon an IPv4 presence, then their clients would be likewise
| forced to adopt IPv6 in order to retain connectivity.
|
| But with the ubiquity of CGNAT and other technologies, it seems
| unrealistic that IPv4 will become so rare that it becomes
| prohibitively expensive, or must be widely abandoned. So that
| availability of the legacy protocol will inhibit widespread
| adoption and transitions to IPv6.
| ifwinterco wrote:
| In theory you can save quite a bit on AWS costs by having
| instances that can only use v6.
|
| But in reality at the moment there will probably always be at
| least one thing that only works with v4 a lot of the time.
|
| Incentives are misaligned as well - it saves you money as the
| EC2 instance user, but the owner of the website you're trying
| to access has to support v4 anyway so they don't have a big
| incentive to change anything
| netheril96 wrote:
| Maybe it's time to tax IPv4 usages or holders.
| kalleboo wrote:
| Yeah the reality is that the Internet is centralized now. There
| is no reason for two computers on the internet to connect to
| each other anymore, as long as you can reach
| Google/Microsoft/Amazon/CloudFlare, that's all anyone needs.
|
| Just log onto AOL and type in keyword "WALMART" and save! It's
| friendly and safe.
| menotyou wrote:
| Currently my IPS provides IPv6, but I set up my firewall in the
| access router of my home LAN to block all IPv6 in both
| directions.
|
| - I don't want to have a permanent global unchanged ipv6 as in id
| of my traffic.
|
| - IPv6 privacy extensions would change that but then I can not
| reach my two devices I do want to reach from outside anymore as
| my access router only supports DynDNS for its own address and no
| NAT in IPv6
| fleetfox wrote:
| And how exactly is your NATed ipv4 address better? This seems
| backwards.
| menotyou wrote:
| Router has a DynDNS function. I am using a reverse proxy for
| multiple services, but this only sets up router IP and IPv4
| NAT port forwarding to the reverse proxy.
|
| So what would be the correct setup with IPv6 when using
| privacy extensions?
|
| I don't see any benefit in allowing IPv6 traffic or using
| IPv6, but a couple of new problems coming up with it.
| Dagger2 wrote:
| Privacy extensions are additional addresses that are used
| by default for outbound connections. You still have the
| non-privacy address, which doesn't change; put that one
| into DNS.
|
| This approach prevents outbound connections from leaking
| the address needed to connect to your servers. On v4, it's
| likely that any outbound connection from your network gives
| the server the IP they need to do that.
| menotyou wrote:
| My ISP changes the prefix on a regular base (and on
| request)
| Dagger2 wrote:
| So you'll never have a permanent unchanging v6 address to
| ID your traffic with.
|
| Privacy extensions are orthogonal here; they only affect
| the suffix, not the prefix. As for dealing with a
| changing prefix... I'm afraid you'll just have to find
| some way to automate the DNS updates. You can do it with
| a program running on one of the servers -- I can't
| suggest a specific one offhand since I have a static
| prefix and haven't needed it, but they do exist.
| icedchai wrote:
| How often does your IPv4 address actually change?
| menotyou wrote:
| Never checked. But it does change once in a while. The
| router has a dyndns function which updates a DNS entry,
| but only for the router itself. But this is sufficient
| for the NAT port forwarding.
| icedchai wrote:
| Ok, so most of the time you are trackable by your public
| IPv4. The situation is not much better.
| menotyou wrote:
| Let's say when your ipv6 prefix changes it is almost the
| same situation. Only that ipv4 bundles all traffic of all
| devices on one ip which obfuscates a bit.
|
| But having the ipv6 prefix change you get a pile of
| problems (DNS, firewall), you don't have with ipv4.
| icedchai wrote:
| The IPv6 prefix changes are disruptive, I agree. My
| prefix has been stable for a couple years, but on another
| ISP it would change every few months and was certainly
| annoying.
| spl757 wrote:
| 90% spam/hack?
| spl757 wrote:
| Sounds like it's time to abandon it for something new and more
| stupid
| keybits wrote:
| Tailscale have a great FAQ about IPv4 vs IPv6:
| https://tailscale.com/docs/reference/faq/ipv6
|
| If you're not an expert in this area it's worth a read - I
| certainly learned a few things!
| rmunn wrote:
| That was excellent, thanks for recommending it. I particularly
| liked how it's a pretty factual FAQ, not particularly
| cheerleading for IPv6 nor saying "IPv6 is a failure, give up on
| it".
| menotyou wrote:
| "IPv6 is the next generation of the Internet Protocol (IP), the
| successor to IPv4."
|
| This is a misconception. It is not the successor to IPv4, it is
| an alternative. Maybe the alternative is so good it will
| eventually make the older extinct, but it does not look like
| that
| Galanwe wrote:
| I agree with you. While I can see some benefits to v6 on the
| internet, I find v4 to be miles easier and cleaner to work
| with in a LAN setup. Unfortunately though v6 oversteps on LAN
| features and makes bridging v4 and v6 way uglier than it
| should.
| cassianoleal wrote:
| > v6 oversteps on LAN features and makes bridging v4 and v6
| way uglier than it should
|
| How so?
| connicpu wrote:
| Regardless of whatever other things may be better or worse
| about ipv6, it's still a reality that as we continue
| connecting more and more devices to the internet eventually
| ipv4 addresses will become so scarce and valuable that a not-
| insignificant minority of residential customers will be
| behind such aggressive CGNAT that the internet will become
| nearly unusable unless a majority of the services they are
| using support ipv6.
| sedatk wrote:
| Here is my article that I wrote when I wanted to learn more
| about IPv6: https://ssg.dev/ipv6-for-the-remotely-interested-
| af214dd06aa...
|
| EDIT: After reading Tailscale's article, I noticed that I
| overlooked our neverending dependence to NAT despite that IPv6
| seems to eliminate it.
| tonymet wrote:
| a great assessment thanks I hadn't seen that
| eqvinox wrote:
| > _IPv6 doesn 't make it easy to allocate subnets to every
| device on a LAN; instead, subnets might be delegated to your
| local router, and then only individual addresses allocated to
| each device. If one of those devices then wants to route
| traffic on behalf of other devices (for example, to a sub-
| subnet behind a router, where the upstream router doesn't
| cooperate), it will need to use NAT. For example, this is how
| Tailscale exit nodes work, even with IPv6._
|
| This is quite wrong, there'd DHCPv6-PD (prefix delegation)
| specifically designed to do this. Even more interestingly, it
| has recently been made part of IETF CPE requirements (RFC 9818
| update to RFC 7084, July 2025).
| pjf wrote:
| NB: this is not "IPv6 traffic crosses the 50% mark" but
| "availability of IPv6 connectivity among Google users", which is
| a very important difference. This means roughly half of Google
| users have IPv6 _capability_ , which does not 1:1 correspond how
| much _traffic_ is actually transferred over IPv6, which is what
| this submission says in the title.
| kalleboo wrote:
| It also means you're excluding China, who has has it as a long-
| term priority to deploy IPv6 and have made huge strides.
| usui wrote:
| Yeah and this distinction explains the fact that because
| China's Great Firewall blocks Google, this website shows 4.66%
| adoption as a reflection of that. I think China's IPv6 support
| rate is actually much higher than that, maybe a little over 50%
| because of its central initiative to increase IPv6 adoption?
|
| EDIT: Apparently it's 77%
| https://pulse.internetsociety.org/en/news/2026/01/china-hits...
| umanwizard wrote:
| Wouldn't it be close? AFAIK modern network libraries on modern
| OSs default to IPv6 when available.
| easterncalculus wrote:
| Right, but in most situations clients will prefer IPv6 if its
| available, so if they have access, they almost always are using
| it, at the very least from their local network.
| ianburrell wrote:
| "The graph shows the percentage of users that access Google
| over IPv6."
|
| How would Google know what users have the potential for IPv6 if
| they are not using it?
| pzo wrote:
| I wish EU make it mandatory at least for all ISP to make
| mandatory support for IPv6 by end of this decade. I think that
| would push the needle even globally.
| ffaser5gxlsll wrote:
| Meanwhile: one of the major mobile network in my country
| announced cisco collab/ipv6 ~5 years ago, but still doesn't
| provide v6, just v4 CGNAT.
|
| Personal web server running dual stack since early 2010s
| currently sees 18-20% v6 traffic. When split by type, counting
| only mobile users it reaches 30% at peak.
|
| Bot/crawler traffic is ironically 100% v4.
|
| Meanwhile: enabled h3 in september last year for the fun of it,
| instantly at >40% traffic by request count, passing 50% since the
| beginning of the year, h2 accounting almost all the remaining
| traffic and plain ssl/http requests <1% being just bots.
| e-topy wrote:
| Maybe the best anti-scraper/LLM protection is going IPv6 only.
| I'd do that on my website, but I'm afraid some clients might
| not connect.
| colmmacc wrote:
| If GitHub flipped a switch and enabled IPv6 it would instantly
| break many of their customers who have configured IP based access
| controls [1]. If the customer's network supports IPv6, the
| traffic would switch, and if they haven't added their IPv6
| addresses to the policy ... boom everything breaks.
|
| This is a tricky problem; providers don't have an easy way to
| correlate addresses or update policies pro-actively. And
| customers hate it when things suddenly break no matter how well
| you go about it.
|
| [1] https://docs.github.com/en/enterprise-
| cloud@latest/organizat...
| alibarber wrote:
| Having been messing around personally with getting my own
| blocks of IP addresses and routing[1] - I've become terrified
| at the idea of implementing access control based on IP address.
|
| Unless your own organisation in the RR has the IP addresses
| assigned to you as Provider Independent resources, there just
| seems to be so many places where 'your' IP address could,
| albeit most likely accidentally, become not yours any more. And
| even then, just like domain names, stop renewing the
| registration and someone else will get them - I was that
| someone else recently...
|
| [1] AS202858
| yosamino wrote:
| Oh, cool! that's on my bucket list as well. I am still
| grappling with some concepts, though.
|
| Do you have a writeup of your setup somewhere or can you
| recommend some learning materials ?
| alibarber wrote:
| It's fun and has now become an addictive rabbit hole -
| trying to get packets from one location to the other in the
| fastest, most direct way (and at hobbyist budget level).
|
| Initial writeup based on IPv6: https://abarber.com/Setting-
| Up-ASN-IPv6-Routing-BIRD-Teltoni...
|
| Have been having fun recently with an IPv4 block and
| Asynchronous routing, working on writing that up right now
| :)
| progbits wrote:
| Anyone who relies on IP filtering for security deserves to have
| it broken. Change my mind.
| sebiw wrote:
| Defense in depth is a thing but I agree that relying on it is
| not a good idea.
| tucnak wrote:
| Defense in depth is not the point, zero trust networking
| is.
| omh wrote:
| I'll take that bait ;-)
|
| IP filtering is a valuable factor for security. I know which
| IPs belong to my organisation and these can be a useful
| factor in allowing access.
|
| I've written rules which say that access should only be
| allowed when the client has both password _and_ MFA _and_
| comes from a known IP address. Why shouldn 't I do that?
|
| And there are systems which only support single-factor
| (password) authentication so I've configured IP filtering as
| a second factor. I'd love them to have more options but
| pragmatically this works.
| friendzis wrote:
| Why are you (re-)implementing client security on provider
| end? If a client requires that only requests from a
| particular network are permitted... Peer in some way.
|
| I do understand the value of blocking unwanted
| networks/addresses, but that's a bit different problem
| space.
| apexalpha wrote:
| IP filtering + proper security is better than just having the
| security.
|
| There's value in restricting access and reducing ones attack
| surface, if only to reduce noice in monitoring.
| bluGill wrote:
| If you can't handle sites switching to ipv6 in 2015 (ten years
| ago) your security plan is garbage.
| TabTwo wrote:
| Thanks to the trend to SASE like Palo Alto GlobalProtect or
| ZScsler this practice is not a good idea anymore. Speaking of
| ZScaler, they are still IPv4 only, right?
| azernik wrote:
| > providers don't have an easy way to correlate addresses
|
| Yes, they do. It's called DNSSEC.
| rmunn wrote:
| Zoom in on that graph using the controls at the bottom, and
| you'll see a repeating pattern of crests and troughs, weekly.
| There's about a 5% difference between the crests and the troughs:
| the crests are hitting the 50% line or just below it, and the
| troughs are down around 45%.
|
| The real question is, why are the crests so predictable? They're
| always on Saturdays; Sunday dips down a little below the crest,
| then Monday-Friday is down in the 45% range before the next
| Saturday jumps up to 50% again. (Fridays usually have a small
| rise, up to the 46-47% area).
|
| My theory: mobile access rises on weekends. People are more often
| accessing Google services from their work computers Monday-
| Friday, but on Saturdays and Sundays most (not all) people are
| away from the office. Many of them will end up using smartphones
| rather than laptops for Internet access, for various reasons such
| as being outdoors. And since smartphones are nearly all using
| IPv6 these days, that means an uptick in IPv6 usage over the
| weekends.
| kalleboo wrote:
| It's not just mobile networking but residential ISPs in general
| have better IPv6 support. In the US, Comcast was one of the
| first big IPv6 deployments, in Europe CGNAT+IPv6 is common in
| many places.
|
| Meanwhile corporate IT for business and education networks have
| less incentive to upgrade and typically lag behind in adoption
| in general.
| crest wrote:
| I've been running full dual stack for >15 years now. It has
| become second nature by now and I'm slowly testing IPv6
| mostly, but so far it's just easier to deliver dual-stack to
| all users instead of dealing with workarounds to make the
| last few non-IPv6 capable services work without native IPv4.
| Xirdus wrote:
| Residential vs. business. If the graph was hourly and per
| country, you'd see the same rise every morning and drop every
| evening (likely by more than 5pp).
| ethan_smith wrote:
| This matches what I've seen too. Mobile carriers have been way
| ahead on IPv6 - T-Mobile in the US has been IPv6-only with
| NAT64 for years. The weekend pattern is pretty much a smoking
| gun for mobile being the driver. It also explains why the
| Google metric (which skews consumer) looks so much better than
| the Wikipedia numbers someone else posted (35% IPv6) or the
| server-side adoption stats from Common Crawl.
| jwilliams wrote:
| I'm surprised it's reporting is listed <5% - I thought it was
| pretty much ipv6 first?
| neitsab wrote:
| As a French national, I am surprised to discover we are topping
| the charts according to this analysis.
|
| Does anybody know why that might be the case? What's the story of
| IPv6 deployment in France?
| DANmode wrote:
| Technical literacy, hacker culture, and culture of well-
| considered infrastructure, have been French characteristics -
| at least, historically.
|
| Has something changed for the worse?
| ankit_mishra wrote:
| I'm wondering the same thing for India. Not the top but looks
| surprisingly surprisingly high. Perhaps I'm reading the data
| wrong.
| ggm wrote:
| Reliance Jio deployed cheap native v6 and tool massive market
| share. They single-handedly moved the market.
|
| It's been discussed on the apnic blog and at meetings heaps
| toast0 wrote:
| Adding on. Jio was a late entrant, so they could not get
| significant ipv4 address space without great expense. They
| deployed as mostly v6 with a tiny CGNAT. They also had an
| extensive 'pre-release' offering at zero cost to
| subscribers which got them a huge number of subscribers and
| clout to encourage internet services to offer ipv6.
| lazide wrote:
| India has about 1.5 billion people, and has only recently
| been getting most of them online. Less IPv4 legacy, and it
| has always been obvious that IPv4 was never going to be
| 'enough' to actually onboard everyone anyway.
|
| When I lived in India, everything had IPv6 out of the box.
| timpera wrote:
| The regulatory body, ARCEP, has been very proactive since 2002
| (!) on IPv6. The recent uptick is due to IPv6 obligations
| bundled in the 5G spectrum licences.
|
| https://www.arcep.fr/la-regulation/grands-dossiers-internet-...
| dwedge wrote:
| I worked with the internet society to mobitor ipv6 adoption for
| the top million sites ipv6matrix.org it's broken down by
| country so might answer some of your curiosity
| garganzol wrote:
| Maybe my guess only, but France has its bit of a technological
| centralization. I mean, a lot of people use internet from
| operators like "Orange" / "Free", and in contrast to other
| countries, routers provided by the operators in France do not
| suck. The routers are OEM, but overall quality you get from
| them is on-par with Ubiquity/Mikrotik.
|
| This gives operators a benefit of the vertical control for the
| whole ecosystem - from top to the bottom, including intricate
| parts of protocols and routing. And France, in contrast to
| other countries, does not suck here too - operators usually do
| a good job of meticulously maintaining their assets.
|
| My personal impression is that this is the result of several
| cultural factors:
|
| 1. Ingrained respect of privacy, private property, and a peace
| of heart as they call it. As a practical result of that, you do
| not get spammy messages and ads from operators, banks, etc. You
| may get some, like 3 or 4 discounts/offers in a year. Compare
| that to other countries where you can easily get 10s/100s
| messages like that in a single day. In other countries, instead
| of upgrading the infrastructure, people are busy with spamming
| each other.
|
| 2. The harsh oceanic environment with hurricanes and storms
| fosters an appreciation for reliability and functionality. It
| also encourages a certain frugality: every cent matters. As a
| result, people tend to develop a strong sensitivity to
| situations where form is prioritized over function, and such
| approaches are quickly dismissed as impractical. This gives a
| certain internal freedom of being able to see through things to
| determine what they are in the long run and not what they
| appear to be on the surface.
|
| 3. French people don't like to overwork outside of working
| hours. So choosing something like IPv6 over IPv4 seems like a
| natural forward-looking investment for the future where you can
| have less maintenance burden and thus you can devote more time
| to enjoying other things in life.
|
| Having all those things combined, it's not hard to see why
| France chose IPv6. It's a natural choice there and it's imposed
| by survival.
|
| P.S. I've spent some time in France, but was born in another
| country.
| creatonez wrote:
| This is _probably_ not the real reason, but I find it
| interesting that France had Minitel (^1) before and later had
| to switch to the Internet, and then later became the fastest
| country to complete the IPv6 transition. So perhaps they had an
| engineering culture that was prepared for the possibility they
| would have to upgrade the entire network on a nationwide scale.
|
| ^1: https://en.wikipedia.org/wiki/Minitel
| cubefox wrote:
| Spain: 9.9%
|
| What's going on in Spain?
| ggm wrote:
| Bizarrely, Telefonica doesn't see a need. But, their
| subsidiaries in LatAM do heaps! And, they do central
| purchasing.
| Schlagbohrer wrote:
| Can someone reconcile for me the constant chatter about how IPv6
| isn't getting impemented, versus this result that more than half
| of all traffic (as measured by google) is now IPv6?
|
| It sounds to me like its a tool which is available to be used
| when needed and when no better workarounds exist, and it is
| slowly but surely being adopted as needed.
| zokier wrote:
| Most of the chatter comes from the peanut gallery who have no
| real insight on what ISPs and other large networks are actually
| doing.
| neojima wrote:
| This. "Vibes," vs. data.
| toast0 wrote:
| As a sometimes chatterer, it's a mix of complaining about the
| annoying changes in v6 that weren't just lengthening the
| address fields, pointing out that the migration is taking
| forever, and implying a less disruptive design could have
| rolled out faster.
|
| For a long time, there really was next to no progress. Between
| the introduction in 1996 and about 2011, there was very little
| adoption. And since 2012 when pushing really started, we're at
| about 50% globally, with large variance by country and network
| type. 15 years between creation and real deployment seems like
| a lot, and 15 years of deployment getting to 50% also seems
| likes a lot.
|
| But wikipedia says touch tone dialing was first offered to
| consumers in the 1960s and didn't become majority until the
| 1980s, so maybe 30 years isn't _that_ slow.
| jcalvinowens wrote:
| I consistently get 100x as many captchas from google over V6 as
| over V4, on many different networks: it is obnoxious and
| obviously broken on their end.
| traderj0e wrote:
| IP reputation is a tough problem with a lot of establishment
| behind v4. Even if they were to build up v6 reputation, since
| v6 addresses are cheaper, wouldn't they have lower rep?
| hosh wrote:
| I am in the middle of building infrastructure in GCP. The
| workload is your typical stateless web + db workload.
|
| As of now, there is no way to have a 100% internal ipv6. Many of
| the services, including CloudSQL or the connection between
| external and internal load balancers do not support ipv6, even
| when the external load balancer support ipv6 forwarding rules at
| the front end.
|
| This means that careful internal ipv4 allocations still matter.
| kalleboo wrote:
| I had the same issue a few months ago on AWS. All I want is a
| server (that pulls a container), a database, and a load
| balancer. It's all going behind CloudFront so there should be
| no need to pay for an IPv4 address for any internal machine.
| Couldn't do it. Since then I saw that there was some movement
| on IPv6 for RDS but IIRC there was still some other blocker.
| vel0city wrote:
| > so there should be no need to pay for an IPv4 address for
| any internal machine
|
| At what level did you need to pay for IPv4 addresses in this
| stack? You should have been able to make this work with a
| private IPv4 space, have the ECS services be dual-stack and
| be on both the v6 network and the v4 network to talk to the
| database server, have the ALB be v6, and then have Cloudfront
| be v6. If you wanted, you could also just ignore v6 for the
| ECS services and have them just live in that same v4 subnet
| entirely.
|
| I could be wrong (and please tell me what I'm missing) but
| you shouldn't have had to pay for IPv4 in this case. I do
| just wish RDS (and so much else) would just support IPv6
| though, you shouldn't need to have a bunch of extra subnets
| just to talk to your database.
| dijit wrote:
| I think its incredibly ironic actually. The place where IPs are
| burned through rapidly (internal) is forced to use v4. (and,
| potentially even a subset of it, RFC1918; likely conflicting
| with some large company or service if they decide to plumb it
| together later- or you burn publicly accessible IPs in the
| limited address space)
|
| But the one interface that touches the internet can use v6: the
| one with a functionally infinite address space.
| hosh wrote:
| GCP encourages customers to use Class E (240.0.0.0/4) as
| internal IPs. That helps.
|
| What I am building won't exhaust that, but I hear some
| customers are blowing through even that.
|
| PSC has a builtin NAT. That also helps stitch things
| together.
|
| ... or we can have ipv6.
| Ekaros wrote:
| There really should have been proper government pressure and
| fines long ago.
|
| Say if you have 10% of market share or x million monthly users
| you must support IPv6 in say 5 years. If not you are fined say 2%
| revenue per year until you do...
| bluGill wrote:
| I'd make it required that ipv6 for all customers has a higher
| service guarentee than anyone ipv4. If you don't support ipv6
| you can't guarentee anything. give two years to to implement
| it.
| equinox6380 wrote:
| The failure wasn't in the technical design of v6, but in the
| economic assumption. When the cost of migration exceeds the cost
| of 'hacks' like NAT, people will stick to the hacks for as long
| as humanly possible.
| zsoltkacsandi wrote:
| Great, then another 20 years and we can retire IPv4.
| taf2 wrote:
| Just in time for ipv8 - https://www.ietf.org/archive/id/draft-
| thain-ipv8-00.html
| zrail wrote:
| This proposal is absolutely wild.
| spockz wrote:
| And in the mean time, Odido on the Netherlands still don't
| support ipv6 on their fiber network...
| shrubble wrote:
| I am aware of at least 2 telecoms, one publicly traded, that have
| very little to no IPv6 in their core networks and only use IPv6
| when they have to.
|
| Personally I think the design of IPv6 offers very little benefit;
| supposedly the Dept of Defense/Dept of War holds some 175 million
| IPv4 addresses, with other companies also holding large
| allocations - that should have been addressed 25-30 years ago as
| an administrative matter.
| mattstir wrote:
| To what end though? 4 billion addresses is not enough on its
| own, even if they were reallocated from hoarders. I think that
| NAT and especially CGNAT have been very detrimental to the
| shape of the internet, where it's nearly impossible to self-
| host a public service without a VPN of some kind. Needing to
| pay some company for the ability to host a server that isn't
| behind NAT is a barrier that doesn't need to exist when IPv6
| has a nearly limitless number of addresses.
| bananamogul wrote:
| You're not wrong, but practically speaking, hosting a VM is
| so cheap and comes with the advantage of serving from a
| datacenter that I would never want to host anything off my
| residential connection anyway.
|
| The $1 to $5 a month to have excellent, reliable connectivity
| (that no residential connection provides), DDoS protection,
| and isn't tied to my home IP outweighs any home hosting
| benefit in my experience.
| jcranmer wrote:
| There are 16 /8's in the class E address space that were never
| allocated, and 19 /8's (by my count) allocated to individual
| companies. If you waved a wand and returned all of that space
| to IANA for allocation, you would have staved off IPv4 address
| exhaustion by... about 3 years.
| neojima wrote:
| 2.7 - 4.0 years, by my math, so I would agree with your
| assessment.
|
| ...but that's based on pre-IANA-runout rates, though, and
| doesn't account for the pent-up backpressure of demand. So
| probably a lot less, in reality.
|
| Not even remotely worth the effort, even if there were a
| legal pretext for "reclaiming" IPv4 space (there isn't;
| there's already precedent denying it).
| benbristow wrote:
| And Virgin Media in the UK still doesn't support IPv6
| KronisLV wrote:
| Random test site for the consumer side: https://test-ipv6.com/
|
| 0/10 in Latvia with a local ISP, fun times.
| TekMol wrote:
| I still do not support IPv6 on my servers and I think I will skip
| it and wait for IPv8:
|
| https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
|
| Avoiding a dual-stack and making IPv4 a part of whatever
| superseeds it seems like the right choice to me.
|
| IPv6 always seemed to me like throwing away all existing
| telephone numbers, just to support longer numbers.
| Dagger2 wrote:
| ::203.0.113.42 (tunnels to 203.0.113.42 over v4)
| 64:ff9b::203.0.113.42 (translates to v4 at nearest NAT64 point)
| ::ffff:203.0.113.42 (opens a v4 connection via an AF_INET6
| socket)
|
| What are these then?
| abhinavk wrote:
| Maybe you didn't read the draft. It's either a delayed April's
| Fool joke or AI slop. Even if you take it seriously, it will
| require updating every v4 device in existence.
| pbw wrote:
| This is only 33 years after I took a networking class and learned
| all about IPv6 and the IPv4 address space crisis.
| neojima wrote:
| This is pretty remarkable, given that RFC 1883 is only 30 years
| old.
| schneems wrote:
| Puma 8.0+ webserver now defaults to IPv6
| tormeh wrote:
| As long as no significant websites are IPv6-only qnd no
| significant user base is IPv6-only, why would anyone join IPv6?
| What proponents could do is make their websites IPv6-only. The
| IETF website, for instance, should be IPv6-only.
| mgulick wrote:
| I get an IPv6 address from my ISP (a /56 I believe), but I wish
| there was some good information on how to update my OpenWRT VLAN
| configuration, routing, and firewall rules to be able to support
| native IPv6 on my devices. Would love to be able to have direct
| IPv6 connections to the internet from my devices, but I want to
| make sure I can do it safely.
| _bernd wrote:
| You only need to set nothing and it should setup ipv6 on all
| downstream vlan interfaces. For static prefix I'd you can set
| ip6hint per vlan interface. For each vlan interface you need a
| stanza in the DHCP config file. And regarding firewall, as with
| the default lan zone you might need to add new zones with the
| vlan interfaces and configure forwarding rules. That's it.
| nzeid wrote:
| This was surprisingly complicated for me on Altice/Optimum,
| which is why my home didn't have IPv6 for a while even after
| they started provisioning.
|
| We actually have a /128 address only, and had to tweak several
| settings including enabling IPv6 masquerading (NAT).
|
| I haven't the slightest clue why they didn't give us a block.
| dlcarrier wrote:
| Yeah, I'm in the same boat. I like the idea of being able to
| remotely connect to anything on my network, but I know just
| enough about networking to be dangerous, and don't trust my
| self to set it up securely, so I have IPv6 disabled on my
| router. With IPv4, it's physically impossible to mess up the
| firewall and NAT settings enough to make local devices public.
| pmarreck wrote:
| Good.
|
| I think most of us know that their design failure here was a lack
| of backwards compatibility. But at least it's getting adopted.
| neojima wrote:
| Backward compatibility was never really the problem; the
| problem is that forward compatibility with ANY successor
| protocol (without modifying IPv4) is a fundamental
| impossibility.
|
| But at least a reasonable facsimile eventually came out with
| NAT64.
|
| (You can also do NAT46, but it requires one IPv4 address for
| every IPv6 destination you want to be reachable from the IPv4
| Internet, so it doesn't scale very well.)
| johnhamlin wrote:
| I was wondering why someone proposed IPv8
| Leomuck wrote:
| What I have asked myself the last few months: I've read about
| IPv4 becoming sparce a few years ago. I haven't read much about
| it lately. And I've thought maybe the advance of cloud computing
| and load balancer kind of mitigated the issue of sparce IP4?
| neojima wrote:
| It officially started becoming scarce in 2011, when IANA, and
| then APNIC, depleted their IPv4 "free" pools, FWIW. Things have
| only gotten worse from there.
|
| Cloud computing doesn't mitigate IPv4 issues, it just moves it
| around. The big cloud providers buy up any IPv4 space they can,
| leaving less for everyone else. The difference is that they
| then get to collect rent, by the hour, on any IPs their
| customers use.
|
| Load balancers...yeah, actually that is a valid approach to
| reduce IPv4 use, assuming you mean the "reverse proxy" variety
| of load balancer. Cloudflare's proxy service is doing exactly
| this, on a pretty huge scale. (CLoudflare can then send the
| traffic on to an IPv6-only server, regardless of the client's
| protocol.) The downside is, like cloud, consolidating a lot of
| infrastructure into the hands of a small number of companies.
| Anonyneko wrote:
| And yet I still haven't ever connected to an internet provider
| that supports IPv6, across two countries I spend time in...
| 1970-01-01 wrote:
| A hidden benefit is it's no longer possible to have another "we
| typed the wrong IP address" raid story. IPv6 is larger than the
| total number of heartbeats of all heart-bearing life that has
| ever existed. You either nailed the abuse address or you're
| raiding something that doesn't even exist.
| whalesalad wrote:
| meanwhile I just disabled ipv6 on all my vm's last night due to
| ubuntu package servers being down and needing to get something
| critical out the door.
| bethekidyouwant wrote:
| The final 10% is gonna be a doozy..
| marginalx wrote:
| Is most of that due to mobile?
|
| The real migration challenges are in the server side/consumer
| home internet space which I'm not sure if there are clear stats
| around the adoption there.
|
| I think IPV6 is a great example of over engineering, trying to do
| too much in one iteration. In an ideal scenario this could work,
| but in the context of large scale change with no single
| responsible party, it usually doesn't work well.
| zokier wrote:
| CloudFlare Radar has stats for desktop (34%) vs mobile (46%)
| adoption:
| https://radar.cloudflare.com/explorer?dataSet=http&groupBy=i...
| jollyllama wrote:
| I was wondering how much is "last mile" between end-user
| devices and the next hop vs. within cloud networks, but the bit
| about mobile is a good point.
| azernik wrote:
| The problem has nothing to do with over engineering, or really
| anything to do with the actual contents of the IPv6 standard.
| It is just devilishly hard to make _any_ backwards-incompatible
| change to layer 3, and address expansion is always going to be
| backwards incompatible.
| mrjoe3332 wrote:
| There were some choices of v6 that made it extra hard, like
| declaring all v4 addresses no longer valid in v6, or making
| slaac default
| azernik wrote:
| IPv4 addresses are in fact a subspace of IPv6 (that's
| NAT64). They were not by fiat declared invalid. The actual
| thing I think you're complaining about - the necessity for
| NAT64 at all - is unavoidable, because you need a
| NAT/protocol-translation layer for packets to actually move
| between the new address space and the old one.
|
| SLAAC-by-default is not, in my experience implementing IT
| automation, an actual barrier for adopters. You have a
| router sending out RS instead of a DHCP server, to an admin
| this is not a meaningful change.
| mrjoe3332 wrote:
| It'd be annoying even in the scenario where it got quickly
| adopted. Complicated spec, user-unfriendly addresses, unclear
| defaults.
| grimmai143 wrote:
| It's amazing to see this finally hit 50%. Out of curiosity for
| the infrastructure folks here: are you actually running IPv6
| inside your internal VPCs and Kubernetes clusters now, or are you
| still mostly just terminating it at the edge/load balancer level?
| starkeeper wrote:
| It's all bots!!!
| ff317 wrote:
| Random related data point: for HTTP requests to Wikipedia (and
| related) for the past 7d, the IP protocol split is roughly 35%
| IPv6 / 65% IPv4. (this is counting by-request, so heavy usage
| from a small number of IPv4s can skew it).
| sedatk wrote:
| > heavy usage from a small number of IPv4s
|
| Basically, all crawlers.
| 10000truths wrote:
| If be curious to see what the IPv4/IPv6 breakdown looks like
| when looking at HTTP/2 and HTTP/3 connections only, which
| should exclude the vast majority of crawlers.
| himata4113 wrote:
| If anyone is confused on adoption is so slow when supporting it
| is easier than ever the reason is actually quite simple: it's
| expensive.
|
| Switches and routers have a little thing called TCAM memory, the
| premise behind it is that it allows you to single-cycle O(1)
| lookup any ips destination. Usually to replicate it you could
| have a 4gb*2 preallocated contiguous buffer, but that's not
| something that is wildly supported or used and this completely
| breaks down when you expand to the IPv6 range.
|
| The problem lies in that in a lot of cases TCAM can no longer
| hold the entire IPv4 routing table and now if you introduce IPv6
| you are expected to handle double the routes which degrades
| switching performance as more active routes have to be evicted
| and fall back to software routing.
|
| Routes are not the only thing that take up TCAM memory: the
| firewall rules, internal routing, vlans, everything becomes
| double and TCAM memory cannot be dynamically adjusted at runtime
| to allocate space so what happens is that you need to sacrifice
| IPv4 space in TCAM permenantly even if nobody is using IPv6.
|
| This is where it gets worse: if you have ever attempted to use
| IPv6 you will notice that is significantly slower than IPv4 and
| that is because most ISPs simply opted to use software routing
| for IPv6 which coupled with 4-10 hops is nearly double the
| latency in some cases (0.5ms to 1ms) while having throttled
| bandwidth to not overload the CPU.
|
| That's why network engineers will continue to refuse to
| (properly) support IPv6. If I had to guess the "properly"
| supported IPv6 percentage is less than 10%.
| crest wrote:
| What shitty ISP operates like that? I frequently see IPv6 have
| *lower* latency because of fewer middle boxes and fewer hops in
| general. Your routers in the default free zone shouldn't be
| close to their TCAM limits with a single IPv4 routing table.
| ck2 wrote:
| forgive dumb question but what happens when someone on IPv6
| without IPv4 tunnel visits a URL with only a IPv4 endpoint?
|
| like say
|
| * https://1.1.1.1/cdn-cgi/trace
|
| vs
|
| * https://one.one.one.one/cdn-cgi/trace
|
| When ipv6 threads like this come up, someone eventually mentions
| T-Mobile is completely IPv6 now but they must have IPv4 tunnels
| because I have IPv4 turned off on my modem/router and can still
| visit both those URLS
| nfriedly wrote:
| I just recently noticed that my ISP, Frontier, quietly turned on
| IPv6. I know it wasn't enabled back in December, so it has to
| have been sometime in the past few months.
| thescriptkiddie wrote:
| interestingly my ISP, at&t, quietly turned _off_ ipv6. not sure
| exactly when it happened, i should get around to complaining
| about it but i hate making phone calls
| blueybingo wrote:
| worth noting that the google stat measures ipv6 _availability_
| among users who access google, not general internet traffic -- so
| it 's a bit of a self-selecting sample skewed toward consumer
| isps that have deployed ipv6, which probaly overstates adoption
| for enterprise and datacenter traffic where the github situation
| is much more representative of reality.
| ryzvonusef wrote:
| Quick, someone tell slashdot!
| artooro wrote:
| Been waiting for this for years! Now I just wish my local ISP
| (rural Canada) supported it.
| JTbane wrote:
| It seems the biggest hurdle to IPv6 adoption is legacy software
| and hardware. Anything new that gets built can easily be v6 only.
| markhahn wrote:
| I guess most of this is mobile use in India.
___________________________________________________________________
(page generated 2026-04-16 23:01 UTC)