Google play store and ipv6

[vobelic]

Running a few mikrotiks and tunnelbroker service to tserv23.zhr1.
I can't seem to make any app download (browsing the store works).
It's definitely a v6 connection issue as it works with v4 only.
Its been like this for quite some time, doubt its Google fault as many mobile providers offer v6 nowadays.

Anyone noticed this?

[gnarlymarley]

I have noticed parts of google seem to have issues with the MTU of the tunnels.  Does this timeout, or do you get an immediate rejection response?

[vobelic]

I've got v4 MTU of 1492 so I had to set my tunnel to 1472 on both endpoints (my gateway and HE tunnel config).
This seems to work fine, icmpv6 type 2 is properly sent from my gw to clients, hopefully the same happens upstream at HEnet tunnel endpoint.

Now google seems to use 2a00:1450:4016::/48 for data (e.g. 2a00:1450:4016:805::2001) and on my side i didn't see packets exceeding 1280B (1208 payload + 32 tcp + 40 ipv6) which is far below MTU of 1472.

What I'm seeing are dup acks and retransmits for packets from this address.
Symptoms are very specific, browsing the store and other google components works flawless.
It's just that app downloads get stuck, timeout actually.

[vobelic]

Actually the culprit seem to be CDN addresses from 2620:11a:a000::/48, google's CDN resolvable on *.sn-bvvbax-15be.gvt1.com.
I didn't have the time yet to see what happens, but it gets stuck after SSL negotiation with those machines.
SSL negotiation finishes, client tries to request the data (sub 1000B packet), and there's no TCP ACK from the server for that request.
Client tries to retransmit a few times, nothing happens and finally the server sends RST.
It's as if the packet either never reaches the server or the ACK gets lost somewhere...
Doesn't seem like MTU issue.

Also I've tried reducing both tunnel endpoints to minimal MTU of 1280. Didn't work.

I've now added a DNS RPZ entry

Code Select Expand

48.zz.a000.11a.2620.rpz-ip      IN CNAME        .
It effectively blocks clients from receiving AAAAs with that range.
Dirty, but works for now.