IPv6 nslookup works but not much else

[jezuk1]

Hi all,

nslookup confirms IPv6 names are being resolved:

Code Select Expand

C:\>nslookup ipv6.google.com
Server:  UnKnown
Address:  2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

Non-authoritative answer:
Name:    ipv6.l.google.com
Address:  2a00:1450:4007:801::1012
Aliases:  ipv6.google.com

traceroute can't resolve the name:

Code Select Expand

C:\>tracert ipv6.google.com
Unable to resolve target system name ipv6.google.com.

traceroute works to the address:

Code Select Expand

C:\>tracert 2a00:1450:4007:801::1012

Tracing route to par08s09-in-x12.1e100.net [2a00:1450:4007:801::1012]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
  2    15 ms    15 ms    15 ms  2a02:390:ffff:ffff:ffff:ffff:ffff:fffd
  3    15 ms    15 ms    15 ms  2a02:390:0:ff00:21b:21ff:fe70:869c
  4    16 ms    15 ms    16 ms  2001:7f8:17::3b41:1
  5    16 ms    16 ms    16 ms  2001:4860::1:0:15f
  6    16 ms    16 ms    16 ms  2001:4860::8:0:2dde
  7    25 ms    24 ms    24 ms  2001:4860::8:0:3df4
  8    26 ms    25 ms    24 ms  2001:4860::1:0:23
  9    24 ms    24 ms    26 ms  2001:4860:0:1::cf
10    24 ms    24 ms    24 ms  par08s09-in-x12.1e100.net [2a00:1450:4007:801::1012]

Nothing seems to be able to resolve the names apart from nslookup. Any ideas how to fix this one?

Cheers!

[Steve]

Whether tracert is supposed to work for IPv6 addresses    Try tracert6 on Windows -on OSX I get -

Code Select Expand

traceroute6 ipv6.google.com
traceroute6 to ipv6.l.google.com (2a00:1450:4001:c01::69) from 2a02:390:6c87::18fa:e4ed:1e2f:f3f3, 64 hops max, 12 byte packets
1  2a02:390:6c87::204:edff:fedb:1fe9  1.043 ms  1.024 ms  1.010 ms
2  2a02:390:ffff:ffff:ffff:ffff:ffff:fffe  25.395 ms  31.181 ms  44.300 ms
3  2a02:390::ff01:204:4eff:feb3:7419  25.462 ms  25.707 ms  25.054 ms
4  2a02:390::ff00:21b:21ff:fe70:869c  26.159 ms  25.875 ms  25.188 ms
5  2001:7f8:17::3b41:1  26.084 ms  33.035 ms  26.139 ms
6  2001:4860::1:0:15f  101.100 ms  26.595 ms  25.839 ms
7  2001:4860::8:0:2ddf  26.507 ms
    2001:4860::8:0:2dde  27.067 ms
    2001:4860::8:0:2ddf  25.596 ms
8  2001:4860::8:0:2daf  31.783 ms
    2001:4860::8:0:2db0  31.309 ms  31.932 ms
9  2001:4860::8:0:3016  41.000 ms  37.675 ms  39.368 ms
10  2001:4860::1:0:11  38.473 ms  41.119 ms  113.693 ms
11  2001:4860:0:1::21d  51.897 ms
    2001:4860:0:1::21f  60.919 ms  51.448 ms
12  fra07s07-in-x69.1e100.net  38.748 ms  38.755 ms  39.833 ms

[Glenn]

tracert -d -6HostName

http://technet.microsoft.com/en-us/library/cc758231(v=ws.10)

[Steve]

Can't get that link Glenn? - no content


Tracert6


http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_pro_diag_tracert.mspx?mfr=true

[Glenn]

I can't now either 

This is what it said;

Trace an IPv6 path by using the tracert command

0 out of 1 rated this helpful - Rate this topic
Updated: January 21, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

To trace a path by using the tracert command

Open Command Prompt, and type the following:

tracert -d -6HostName

Or, type tracertIPv6Address%ZoneID

where:

HostName is the host name of the remote computer.

IPv6Address is the IPv6 address of the remote computer.

ZoneID is the zone identifier (ID) for the destination address. The zone ID for link-local destination addresses is typically the interface index of the interface from which you want to send tracert packets. You can obtain the interface index from the display of the netsh interface ipv6 show interface command. The zone ID for site-local destination addresses is the Zone ID for Site from the display of the netsh interface ipv6 show interface level=verbose command. If you are not using site identifiers or have only a single site, the %ZoneID portion of the command for site-local addresses is not required. The %ZoneID portion of the command is not required for global destination addresses.

Notes

To open a command prompt, click Start, point to All programs, point to Accessories, and then click Command prompt.

For IPv6, the tracert command traces the path taken by IPv6 packets from this computer to another remote computer. The tracert command uses ICMPv6 Echo Request messages (similar to the ping command) to produce command-line report information about each router that is crossed and the roundtrip time for each hop.

If tracert is unsuccessful, you can use the command-line report information to determine at which intermediate router forwarding either failed or was slowed.

[Lance]

The link works without the extra bit on the end... http://technet.microsoft.com/en-us/library/cc758231

[jezuk1]

I tried that and yes it works:

Code Select Expand

C:\>tracert -d -6 ipv6.google.com

Tracing route to ipv6.l.google.com [2a00:1450:4007:801::1012]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  2a02:xxxx
  2    15 ms    15 ms    15 ms  2a02:390:ffff:ffff:ffff:ffff:ffff:fffd
  3    15 ms    15 ms    15 ms  2a02:390:0:ff00:21b:21ff:fe70:869c
  4    16 ms    16 ms    15 ms  2001:7f8:17::3b41:1
  5    16 ms    16 ms    16 ms  2001:4860::1:0:15f
  ......

However - no other applications seem to be able to resolve IP6 names either. For example, Firefox can't. There's something wrong but I don't know what. Both nameservers provided by my router (the IPv4 and IPv6) will resolve IPv6 names and there doesn't appear to be anything obviously wrong.

[jezuk1]

[Steve]

Is the last attachment a cure or a suggestion that didn't work? I've no knowledge of IPv6 on Windows so I'm not sure what next to try.

[jezuk1]

This was just what the test IPv6 website suggested was the problem. I followed those instructions but there wasn't anything configured incorrectly or no other useful suggestions there.

What it suggested appears to be correct:

"For some reason, your browser or your OS is not doing IPv6 DNS 'AAAA' lookups"

Problem is I have no idea why not 

[Glenn]

What happens if you try through a different DNS, say Google or OpenDNS?

[Steve]

I tried today using my IDNet DNS and OpenDNS and it didn't make any difference for me

OpenDNS IPv6 Sandbox IP's

2620:0:ccc::2
2620:0:ccd::2

[jezuk1]

Same situation Glenn.

Code Select Expand

C:\>nslookup ipv6.google.com
Server:  google-public-dns-a.google.com
Address:  2001:4860:4860::8888

Non-authoritative answer:
Name:    ipv6.l.google.com
Address:  2a00:1450:4009:808::1011
Aliases:  ipv6.google.com

C:\>ping ipv6.google.com
Ping request could not find host ipv6.google.com. Please check the name and try
again.

C:\>ping -6 ipv6.google.com

Pinging ipv6.l.google.com [2a00:1450:4009:808::1011] with 32 bytes of data:
Reply from 2a00:1450:4009:808::1011: time=15ms
Reply from 2a00:1450:4009:808::1011: time=16ms
Reply from 2a00:1450:4009:808::1011: time=16ms
Reply from 2a00:1450:4009:808::1011: time=16ms

Ping statistics for 2a00:1450:4009:808::1011:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 16ms, Average = 15ms


Firefox / IE cannot resolve "ipv6.google.com" or any others.

I never used to have to force ping with the "-6" option, it used to automatically detect and just work.

[jezuk1]

I'm seeing the same problems on my laptop so this is possibly a problem with my router (although no config changes I'm aware of). I could try restarting the router.

It's not an urgent problem 

[Steve]

Have you added IPv6 DNS to the network card configuration or are you relying on the router ?

[jezuk1]

The router supplies IPv4 and IPv6 addresses for the name servers however I manually configured both IPv4 and IPv6 to the google public dev DNS servers and it made no difference. I don't understand what the cause of the problem is but I'm not too worried at the moment 

[Steve]

I do wonder how many years we are away from it being a real issue.

[jezuk1]

In my case it's "virtually working", i can at least ping public IPv6 addresses.. There just appears to be some kind of problem with resolving AAAA records, no applications seem capable of doing it (e.g. Firefox, Chrome), although these names can be resolved using nslookup on the command line, or by issuing the "-6" option to the ping command.

I'm struggling to understand the nature of this problem in my specific environment, it's beyond my level of understanding. I've searched around Google quite a lot. There are people reporting similar problems but under a different environment - i.e. when using a Teredo tunnel under Vista (Technet details some issues with this and that seems to be the root cause of their problems) but it's not related to my configuration which is a pure/clean dual stack Windows 7 setup.

I'll keep investigating and perhaps I'll turn up some solutions. It's certainly an interesting issue!

Thanks again for the input here, really appreciated.

[jezuk1]

Purely for the record - I restarted my router this evening (in combination with the latest Billion 7800N firmware update) and everything is now working. Problem solved.