Vista IPv6 Ping Question
To get the Terodo Tunnel interface to function, I had to enable the Windows Firewall. With the Firewall disabled, I could ping the other link-local addresses on the subnet without a problem, but with the Firewall enabled, I had to include the source interface ID along with the link-local address. Alternately, I could just use the computer name and it would function properly. For whatever reason, it always selected the IPv6 address when using a name, contrary to the descriptions I found for the ping command. Is this by design, and why is the interface ID only required using the ping command with the Firewall enabled. Is it required with all local connections, or just the ping? Systems are Windows Vista Business SP2. J.A. Coutts
April 24th, 2011 12:43pm

In answer to the question "Is it required with all local connections, or just the ping?", it does appear to be required on all local connections. Unfortunately, it is not returned by the "getaddrinfo" call. Is this by design, and is there any way to get rid of the Firewall requirement that imposes this restriction?
Free Windows Admin Tool Kit Click here and download it now
April 26th, 2011 5:58pm

In answer to the question "Is it required with all local connections, or just the ping?", it does appear to be required on all local connections. Unfortunately, it is not returned by the "getaddrinfo" call. Is this by design, and is there any way to get rid of the Firewall requirement that imposes this restriction?
April 26th, 2011 5:58pm

It turns out that disabling the Firewall also disables the Teredo Tunnel, leaving only one IPv6 interface to choose from. I ran into another problem on one of my machines after a reboot. It started returning the Teredo interface address instead of the link-local address. I did however find an answer in RFC 3484. sockaddr_in6 includes something called sin6_scope_id, which it turns out is the interface ID for IPv6 (this was glossed over in the IPv6 descriptions that I encountered). Windows maintains a precedence list for destination addresses, but it seems to have been left out for source addresses. Since the source address list is not sorted by precedence, the user application must do this using the scope_id and/or the other 7 rules. Does Microsoft intend to correct this or not. J.A. Coutts
Free Windows Admin Tool Kit Click here and download it now
April 27th, 2011 7:02pm

It turns out that disabling the Firewall also disables the Teredo Tunnel, leaving only one IPv6 interface to choose from. I ran into another problem on one of my machines after a reboot. It started returning the Teredo interface address instead of the link-local address. I did however find an answer in RFC 3484. sockaddr_in6 includes something called sin6_scope_id, which it turns out is the interface ID for IPv6 (this was glossed over in the IPv6 descriptions that I encountered). Windows maintains a precedence list for destination addresses, but it seems to have been left out for source addresses. Since the source address list is not sorted by precedence, the user application must do this using the scope_id and/or the other 7 rules. Does Microsoft intend to correct this or not. J.A. Coutts
April 27th, 2011 7:02pm

It turns out that disabling the Firewall also disables the Teredo Tunnel, leaving only one IPv6 interface to choose from. I ran into another problem on one of my machines after a reboot. It started returning the Teredo interface address instead of the link-local address. I did however find an answer in RFC 3484. sockaddr_in6 includes something called sin6_scope_id, which it turns out is the interface ID for IPv6 (this was glossed over in the IPv6 descriptions that I encountered). Windows maintains a precedence list for destination addresses, but it seems to have been left out for source addresses. Since the source address list is not sorted by precedence, the user application must do this using the scope_id and/or the other 7 rules. Does Microsoft intend to correct this or not. J.A. Coutts
Free Windows Admin Tool Kit Click here and download it now
April 27th, 2011 7:02pm

Hi, I will report this through our internal channel. Regards,Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
April 29th, 2011 6:30am

More info: When I first started working on this problem, I could not ping a second machine on the local network by machine name. It basically could not find the machine, which I presume was a failure of the LLMNR protocol. When I went to the second machine and attempted to ping the first machine, it would find the first machine OK, but the ping would fail because it was using the link-local address of the Teredo interface to ping the link-local address of the ethernet adapter. Both machines had the Teredo interface enabled and operational. In an attempt narrow down contributing factors, I disabled the unused ISATAP interface on both machines via the registry. I could then ping both machines by name using the link-local addresses. Since I had no idea how or why this corrected the problem, I re-enabled the ISATAP interface on the second machine. Much to my surprise, everything still worked. Every change was followed by a reboot, and after each change the Teredo interface had to be re-activated. J.A. Coutts
Free Windows Admin Tool Kit Click here and download it now
May 2nd, 2011 5:22pm

More info: When I first started working on this problem, I could not ping a second machine on the local network by machine name. It basically could not find the machine, which I presume was a failure of the LLMNR protocol. When I went to the second machine and attempted to ping the first machine, it would find the first machine OK, but the ping would fail because it was using the link-local address of the Teredo interface to ping the link-local address of the ethernet adapter. Both machines had the Teredo interface enabled and operational. In an attempt narrow down contributing factors, I disabled the unused ISATAP interface on both machines via the registry. I could then ping both machines by name using the link-local addresses. Since I had no idea how or why this corrected the problem, I re-enabled the ISATAP interface on the second machine. Much to my surprise, everything still worked. Every change was followed by a reboot, and after each change the Teredo interface had to be re-activated. J.A. Coutts
May 2nd, 2011 5:22pm

More info: When I first started working on this problem, I could not ping a second machine on the local network by machine name. It basically could not find the machine, which I presume was a failure of the LLMNR protocol. When I went to the second machine and attempted to ping the first machine, it would find the first machine OK, but the ping would fail because it was using the link-local address of the Teredo interface to ping the link-local address of the ethernet adapter. Both machines had the Teredo interface enabled and operational. In an attempt narrow down contributing factors, I disabled the unused ISATAP interface on both machines via the registry. I could then ping both machines by name using the link-local addresses. Since I had no idea how or why this corrected the problem, I re-enabled the ISATAP interface on the second machine. Much to my surprise, everything still worked. Every change was followed by a reboot, and after each change the Teredo interface had to be re-activated. J.A. Coutts
Free Windows Admin Tool Kit Click here and download it now
May 2nd, 2011 5:22pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics