0

I'm experimenting with moving my home network to IPv6 only.

My first try was turning off the IPv4 WAN interface of my OpenWRT box. When I did that, Google continued to work and by that I concluded that my ISP was ready for IPv6 since it gave me an IPv6 address and could correctly resolve names for Google and Apple. But then I tried some other addresses in my country (Brazil) and found that the sites were completely inaccessible, including my own ISP.

I tracked the problem to what I think is a fault at resolving an IPv6 address for those sites. If I ping those sites under IPv6 (or with ping6), they won't resolve to an IPv6 address, and I think that is the problem. For example:

$ ping6 www.google.com
PING6(56=40+8+8 bytes) 2804:14d:5c33:1ac6:c971:6205:4a7a:a49 --> 2800:3f0:4004:802::1011

$ ping6 www.serverfault.com
ping6: getaddrinfo -- nodename nor servname provided, or not known

I tried setting the IPv6 address of Google DNS on the IPv6 interface of OpenWRT, but it didn't solve the issue. Now, I turned back on the IPv4 interface on the router and repeated the same tests disabling IPv4 on my MacBook, to the same results.

Other sites, like www.microsoft.com, will resolve an IPv6 address, but won't load correctly. I guess they might have a problem with their CDN in Brazil not handling IPv6 properly, so I don't get the images and CSS.

I was guessing that there would be some "transparent gateway" between the IPv4 and IPv6 world to make everything work at least on the Internet side, since IPv6 launch day was 3 years ago, but it seems I guessed wrong.

Can anyone reproduce my results? What would be necessary to make these address work under an IPv6-only configuration, since the company I work for is one of the affected by the name resolution issue?

8
  • 1
    First, serverfault.com didn't have IPv6 address (just lookup while typing this). Second, ISP provides IPv6 address didn't implies they MUST provide 6to4 translation. Check with your ISP.
    – Ken Cheung
    Commented Oct 7, 2015 at 9:53
  • 1
    Serverfault.com doesn't have IPv6 and your ISP doesn't seem to offer NAT64/DNS64 (or you are not using the right DNS server) so you can reach IPv4 sites using IPv6. Commented Oct 7, 2015 at 9:55
  • @KenCheung: 6to4 is a different protocol where you get automatic IPv6-in-IPv4 tunnels if have a public IPv4 address. It doesn't do translation. What you probably meant is NAT64. 6to4 is unreliable and shouldn't be used unless you are aware of its issues. Commented Oct 7, 2015 at 9:58
  • 1
    @Sander Steffann: Thanks I've always mix up the names. I really meant NAT64.
    – Ken Cheung
    Commented Oct 7, 2015 at 10:01
  • 1
    @kasperd: I fully agree. Transition is a mess. The end result is nice :) Commented Oct 14, 2015 at 12:44

2 Answers 2

1

Websites that have an IPv4 address won't necessarily work on an IPv6 network (and vice-versa) unless those websites support both IPv4 and IPv6.

The other way these websites would work, as some of the comments have already pointed out, is if your ISP automatically "maps" IPv6 requests to their proper IPv4 destination and vice-versa.

As an aside, if a hostname has an IPv6 DNS record (AAAA) but the server itself doesn't support IPv6, then the website still won't work. (Why someone would setup an AAAA record for a hostname that doesn't respond to IPv6 queries is beyond me, but I'm throwing that out there as a theoretical example).

So if your home network only operates over IPv6, and your ISP doesn't automatically translate IPv6 addresses into their correct IPv4 address, then you won't be able to access websites that operate only on IPv4.

ServerFault.com does not support IPv6. At the time of this writing, here's a webpage that will check other websites for IPv6 support: http://ipv6-test.com/validate.php.

1
  • I can confirm that the scenario with a domain having an AAAA record but the server not responding to IPv6 traffic does happen. I came across an ISP who did that with their homepage. It didn't produce a timeout though, it send a TCP RST in response to any SYN arriving over IPv6. When I pointed this out to them, they told me that this was a deliberate decision. My response to that was that it was a very strange decision. They didn't provide any coherent reason for this setup, but they did change it by stopping the BGP announcement of their entire IPv6 prefix.
    – kasperd
    Commented Oct 14, 2015 at 12:33
0

What is needed to make your scenario work is DNS64 and NAT64.

Since your ISP is providing you IPv4 access through other means, it is perfectly sensible for them to not be providing DNS64 by default.

DNS64 does not make a lot of sense for a service like Google DNS either. First of all DNS64 goes against Google's goal of providing a DNS service that doesn't mangle DNS responses in any way.

And including DNS64 in the service would mean that Google would have to also operate a NAT64 service which their DNS64 could point to, which means a lot of additional bandwidth usage. Most users probably don't want their traffic to all IPv4-only sites going through Google's network. It would likely incur a slowdown for the majority of such sites.

There are public NAT64 gateways with public DNS64 servers pointing to them. You could make use of one of them. But I don't know any in South America. And using a NAT64 in another continent would slow traffic a lot.

You would be better off finding out if your ISP has DNS64 servers and NAT64 gateways you could make use if. Even if they don't send you there by default, they might still have it. You just need to get the static IPv6 addresses of their DNS64 servers and configure your router to use those.

Alternatively if your router supports it, your router could act as NAT64 and/or DNS64. If you want your router to act as NAT64 it needs to run dual stack on the WAN and IPv6-only on the LAN. Such a configuration makes most sense if your router has a public IPv4 address on the WAN interface.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .