Have we been opted out of IPv6 AAAA resolution?

[Bernhard Schmidt]

On 06.06.2012 13:54, Bernhard Schmidt wrote:

Hi,

> we do have a similar problem on one of our resolvers. We do have AAAA
> for Facebook and Yahoo, but lost AAAA for Google/Youtube yesterday and
> never got Bing.
>
> I wrote Google and they told me that they saw IPv6 connectivity issues
> from clients using that resolver and are thus not delivering AAAA
> anymore. I'm still waiting for exact data, since we have been
> whitelisted since year 1 and I don't see any tickets around about
> connectivity issues. And, same as for you, almost all our services are
> IPv6-enabled, so people with broken IPv6 won't have much fun.

Fixed for Google and Bing, although I never did get an answer from the 
latter.

Found out we had indeed some issues. We run (additional to native 
connectivity to a lot of networks) ISATAP relays.

There is some unknown software among our userbase that sets the Ethernet 
MTU to 1300 Bytes on Windows. We are suspecting some 3G software pack 
but we haven't found the culprit yet.

If those users establish a VPN tunnel to us, they get a tunnel with MTU 
1206. Through this tunnel, they establish an ISATAP connection with 
MTU=1280. When the ISATAP relay (Linux) sends an IPv6-frame with 
1280+20=1300 Bytes, the VPN concentrator neither fragments (due to 
DF-bit being set unconditionally by the relay) nor sends ICMP-too-big, 
but silently drops the packet. This makes the connection fail badly.

I could not find a way in Linux to unset the DF bit on the tunneled 
packets, and I could not find an easy way to clear it either. We 
implemented a workaround in the VPN concentrators ignoring the DF-bit, 
and it looks a lot better now.

Pretty soon [tm] our native-ipv6-on-vpn trial will be expanded to all 
users, then the problem should be gone anyway.

Regards,
Bernhard