Re: [nznog] A vs AAAA

Response inline and below. On 12/05/2014 3:17 p.m., Nathan Ward wrote:

On 12/05/2014, at 2:33 pm, Jeremy Visser wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 12/05/14 11:47, Mark Foster wrote:

...

In both cases a ping against a v6 IP address is tried (and failed, as the host has no v6 connectivity - and in at least one case, v6 is actually disabled in the network interface settings).

So why is the client trying to ping a v6 address when it has no v6 connectivity? As Brian alluded to, I commonly see this problem on a host if it has a public IPv4 address, which causes it to automatically establish a 6to4 tunnel, but subsequently the protocol 43 packets (IPv6-in-IPv4) get eaten by your external firewall.

Sidenote; no firewall 'per se' though in the workstation instance, it's all behind typical DSL NAT.

...

I've also seen some cases where PCs always try to establish Teredo connections. I don't believe this to be the default behaviour in Windows, but can be influenced by some third-party software — e.g. uTorrent has a button to do this.

On current versions of windows (ie. not XP) it is default behaviour to establish a Teredo tunnel. uTorrent has a button to turn it on when it has been disabled, or when it is Windows XP.

All it does is run “netsh interface ipv6 enable” (going from memory, I hope I got that right).

The behaviour of the Windows DNS resolver is: - Ask for A records if it has an IPv4 address - Ask for AAAA records if it has an IPv6 address natively, and/or over 6to4. Having only Teredo connectivity does not trigger an AAAA lookup.

Very useful; this was part of my puzzle - not knowing the resolver behavior.

The host that has IPv6 disabled probably has a public IPv4 address, and has 6to4 up. Disabling IPv6 in a single interface doesn’t disable the protocol for the whole box, it just disables native IPv6 on that interface.

Makes sense.

...

Normally I'd recommend running "route print" but if this is an automatic tunnelling issue, that may not give you the whole picture. I recommend you instead try disabling IPv6 tunnelling — the easiest method is via this page:

http://go.microsoft.com/?linkid=9728872

...from "Microsoft Fix it 50412" via this article:

https://support.microsoft.com/kb/929852

There’s a tradeoff in doing that that isn’t immediately obvious.

Disabling automatic tunnelling on a server (relevant if this machine is a server of course) means that you need to go through a relay to hit clients that are on Teredo or 6to4 addresses. If you have tunnelling enabled, you can return traffic to them directly over tunnelled packets.

Perhaps another solution is to configure the host so that IPv4 sorts above IPv6 in the address selection process. See RFC6724 for the mechanics of this. Section 10.3.1 addresses this specific case.

Depending on your current table, an example command might be "netsh interface ipv6 set prefix ::ffff:0:0/96 60 4”. This sets IPv4 addresses with a precedence of 60 (the default Windows 8.1 table’s highest is 50) and a label of 4.

However, I’m not sure this would solve your problem. IPv4 to IPv4 already sorts above 6to4 to 6to4 and Teredo to Teredo. Given this, even having a 6to4 address would cause the host to ask for AAAA but it should not use it even if it gets a 6to4 address in the DNS response - it should still use IPv4. IPv6 would only be preferred if the host as a “global” IPv6 address

Mark - can you share the output of “netsh interface ipv6 show prefix” from both machines, the output of “ipconfig /all" and the exact ping command you are using?

I can't directly simulate either case persistently... the workstation case was several days ago for me at home, and I can't for the life of me remember what the hostname was that I was having trouble with. FWIW I was on my RFC1918 IPv4 address, so it wasn't a 'public' ipv4 address on the box. Out of interest though I looked at both the ipconfig and the netsh syntax you suggested, here it is: Tunnel adapter Local Area Connection* 12: Connection-specific DNS Suffix . : IPv6 Address. . . . . . . . . . . : 2001:0:9d38:6ab8:28d2:7f6:3f57:fdae Link-local IPv6 Address . . . . . : fe80::28d2:7f6:3f57:fdae%18 Default Gateway . . . . . . . . . : :: C:\Users\markf>netsh interface ipv6 show prefix Querying active state... Precedence Label Prefix ---------- ----- -------------------------------- 50 0 ::1/128 40 1 ::/0 30 2 2002::/16 20 3 ::/96 10 4 ::ffff:0:0/96 5 5 2001::/32 Additional factoid for the workstation instance; i'm with Snap (native v6) but my workstation has v6 disabled on both wired and wifi NIC's. To be honest I had no idea that there was a tunnel interface coming up by default, despite the physical NIC's having v6 disabled. I'm going to look into the above tomorrow including the RFC referenced, and I will also see about the Windows Server instance and its precise circumstances as they relate. Thanks very much to those who've responded to this thread, i've learned a bit already. Mark.