> Apple also requires IPv6 support for backend services for approval of iOS apps in the App Store

It really doesn't. It requires that the iOS apps work on IPv6 networks with DNS64/NAT64/whatever it's called. It meerly suggests that you might want to have server side IPv6, since your iOS apps need to support it anyway.

> DNS64/NAT64/whatever it's called

I run an ipv6-only local network for fun, so I can tell you the name you're looking for is 464XLAT. In this style of setup, IPv4 packets are translated into IPv6, routed over the IPv6-only network, and translated back to IPv4.

NAT64 and DNS64 are not the same thing as 464XLAT.

It's been a number of years since I had to work on this at a previous company, but my recollection is that Android relies 464XLAT to make sure that all android apps will work properly on ipv6-only mobile networks that use carrier grade NAT.

Apple on the other hand demands that your app actually natively works with ipv6. I didn't have access to an ipv6 network when I was working on solving this issue in our networking libraries, so I used this https://www.jool.mx/en/ to set up NAT64 and I used bind9 to do DNS64 in order to create an ipv6 network for testing ipv6 functionality.

> NAT64 and DNS64 are not the same thing as 464XLAT.

Correct, that's my point. What my parent poster is describing is 464XLAT, not DNS64 and/or NAT64.

No, the iOS requirement is for DNS64/NAT64. The server can be IPv4, the app has to work with an IPv6 address provided by DNS64. If 464XLAT were the deployed, the app could continue to speak IPv4, but it can't. Nothing to poster you replied to said contradicted that, so I'm not sure where you got it from that they speak about 464XLAT?

Maybe I misinterpreted the original poster's comment, my understanding was they were referring to IPv6-only carrier networks.

In the US (unsure about other countries but they may work the same), the IPv6-only carrier networks mostly (all?) use 464XLAT and not DNS64.

My comments are intentionally devoid of talking about what Apple's requirements are because I don't know then and as far as I know the other posters are correct there.

That does sound like a fun project. Any reasoning behind it or benefits?

This means the requirement is only that the app doesn’t use hardcoded ip addresses.

I've also found this Geekflare tool to be useful to test the IPv6 compatibility of any domain/URL. https://gf.dev/ipv6-test

Geekflare (https://gf.dev/) has several other useful tools, worth checking out.

This page is useful to test the IPv6 compatibility of your current network/browser: https://test-ipv6.com/

I was surprised to see github.com in the list. I would generally expect them to be earlier adopters of new technology.

You got the wrong conclusion from your argument. IPv6 is older than some of HN's audience.

Indeed, IPv6 has existed for 26 years yet here we are in 2022 still having issues using it. Sites/apps are still deployed IPv4 only, consumer equipment is not ready for IPv6, and very few ISPs are even providing customers with native IPv6 addresses.

Mine is, luckily, so I've been able to set my network up, but I'm struggling to see how the world is gonna make this transition in the near future tbh. My guess is we'll be stuck with carrier grade NAT for a long time.

My ISP is dual stack (cox), as is AT&T fiber -- but that is only for residential. Almost all consumer gear is IPv6 compatible, much of Cisco Meraki's still isn't or is limited.

It is not all consumer.

>...consumer equipment is not ready for IPv6

Is that true? I had assumed that all network equipment could do IPv6, but the functionality was not exposed by default.

Just because the equipment can do it, doesn't mean it's ready. I was trying to get my home network setup for IPv6, but the DSL modem would reboot if a fragmented packet was sent, so that's not really ready. The replacement modem didn't reboot, but had severe induced latency, so I went in a different direction and still don't have IPv6.

> https://whynoipv6.com/country/us

What a strange layout - the sidebar, which cannot be manually collapsed, covers up page content at moderate widths, until the page is quite wide. When the window gets narrow enough, some of what's in the sidebar can't be accessed at all.

That site says reddit.com is IPv6 but I'm not able to resolve any AAAA records for it.

Reddit ipv6 was enabled before Christmas but got disabled because of issues with the Android app and square’s okhttp lib I think. Namely that it didn’t support happy eyeballs.

I'm sorry but "happy eyeballs"?

Yeah, the name is straight from marketing (implying happy people seeing a fast website). It simply means that clients detect which is the better connection (whether IPv4 or IPv6) rather than naive IPv6-first or IPv4-first. RFC Standards about this: https://datatracker.ietf.org/doc/html/rfc6555 and https://datatracker.ietf.org/doc/html/rfc8305

Unfortunately OkHttp is naively priotising IPv6 regardless if the IPv6 connection is good or not.

The latest release now has a Happy Eyeballs implementation.

Frankly, given the peering issues and lack of support from major peers it's not going to happen soon...

And the mess that is v6 when things go wrong...

I'm going to say it again. Private v6 and a powerful v6<->v4 NAT if you insist on using v6 only on devices, we're nowhere near the point where people can't afford a single v4 address and if the phone companies can do it at huge scale so can others...

Edit: "Adding support via cloudflare" ??? doesn't that mitigate pretty much 90% of all of the advantages of v6 in the first place? that's just implementing it for tech-point scoring...

It's not about tech point scoring, it's about quickly solving a problem. Specifically how can my customers on IPv6-only networks reach my service hosted on Heroku (which does not support IPv6)? Cloudflare is a practical and relatively easy solution to that problem.

and again... WHO IS ISSUING IPv6 ONLY WITHOUT A 6<->4 NAT AT THE EDGE???