1 edit | Windows Ipv6 Issues I am in the process of converting some of my programs to support IPv6, and this is proving not to be a small task.
The first problem is associated the Windows Firewall in Vista Business SP2. In order to use the Toredo Tunnel, the Fierwall has to be enabled. With the Firewall disabled, Windows has no problem in finding the link-local address on the local network because there is only one link-local address.
------------------------------------
C:\>ping fe80::8d22:1710:b68c:37d9
Pinging fe80::8d22:1710:b68c:37d9 from fe80::a5bb:d4f:e017:e25c%9 with 32 bytes of data:
Reply from fe80::8d22:1710:b68c:37d9: timeping fe80::8d22:1710:b68c:37d9
Pinging fe80::8d22:1710:b68c:37d9 from fe80::3c72:d731:30f9:a279%8 with 32 bytes of data:
Request timed out. (Note that source is now the Teredo Interface address)
C:\>ping fe80::8d22:1710:b68c:37d9%9
Pinging fe80::8d22:1710:b68c:37d9%9 from fe80::a5bb:d4f:e017:e25c%9 with 32 bytes of data:
Reply from fe80::8d22:1710:b68c:37d9%9: time=1ms
--------------------------------------
At first I thought this just had to do with the ping program, but it actually extends to all link-local traffic. Unfortunately the "getaddrinfo" routine does not appear to return this information. Does anyone have any idea why this occurs and how to get around it?
The second problem occurs when I attempt to put a port into the listening mode. I have four different IPv6 addresses, three of which are active (1 loopback, 1 link-local, and 1 Teredo). Windows seems to handle the precedence order for the destination just fine, and I could find the link-local address by using the first address returned by the "getaddrinfo" call using the machine network name. That worked fine until the machine was rebooted, and then it suddenly started returning the Terodo Tunnel link-local address instead. Since both IPv4 and IPv6 are active, I have to tell the system which one to listen on, but is there some way to set the precedence order for the local addresses? These 2 problems appear to be related. |
|
 timcuthBraves FanPremium
join:2000-09-18
Pelham, AL | I have IPv6 working on a Win 7 client, successfully. Part of my instructions when configuring it were to run netsh to disable Teredo.
Tim |
|
| said by timcuth:I have IPv6 working on a Win 7 client, successfully. Part of my instructions when configuring it were to run netsh to disable Teredo.
Tim
But I need the Teredo interface, and I could potentially have other interfaces. |
|
timcuthBraves FanPremium
join:2000-09-18
Pelham, AL Reviews:
 ·AT&T Southeast
| Well, I think the idea is you can use Teredo if you don't have IPv6 access, or you can use IPv6 access if you have it. I am unsure whether both can be used simultaneously, but my IPv6 instructions implied to me that you cannot.
Why would you need Teredo if you have real IPv6 access?
Tim
--
"Life is like this long line, except at the end there ain't no merry-go-round." - Arthur on The King of Queens
~ Project Hope ~ |
|
|
|
1 edit | That's the point; I don't have direct IPv6 access and I don't want to run a 6to4 server, so I have to use a tunnel to get to IPv6 sites. Anyway, I think I have found the answer, and I had to go RFC 3484 to find it.
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. I don't know if Microsoft intends to correct this or not.
J.A. Coutts |
|
| reply to couttsj
2cent advice - forget link local exists and get yourself a real IPv6 address for testing or at least manually configure one. Addressing a link local address without explicitly defining which 'link' is by definition ambiguous and should never be done.
If you don't specify an interface identifier there is no way for the system to know what interface you intent to address so the only thing it can do is try from each one. Without interface identifier your request is ambiguous and could easily apply to one or all interfaces. Link local addresses must not be viewed as globally unique. They are unique on link only.
When you listen use IN6ADDR_ANY_INIT as bind address and the system will listen on all interfaces so you don't need to worry about selecting the right one.
Also on the client its usually a good idea to iterate thru each address returned by getaddrinfo attempting a connection until you either succeed or run out of addresses.
You could also bind the client to a source interface before connecting to explicitly restrict access to source interface so that there is no longer an ambiguity WRT use of interface identifier. |
|
| reply to couttsj
There are some fairly major limitations using Teredo, not least of which is that if there's a choice of using ipv4 or ipv6 to connect, it will always prefer ipv4. You can read more about getting Teredo up and running at »yorickdowne.wordpress.com/2008/0···-teredo/
You'd really be better off getting a free tunnel with a broker, at least until you have native ipv6. |
|
| reply to dslcreature
said by dslcreature:When you listen use IN6ADDR_ANY_INIT as bind address and the system will listen on all interfaces so you don't need to worry about selecting the right one.
I didn't try that, but I will. I simply chose the first address returned, assuming they were in order of precedence. Worked on my development machine, but not on the next one I tried. Life was sure a lot simpler with IPv4. One interface, one address. I understand that IPv6 simplifies the routing issues, but it sure moves a lot more complexity onto the the end units themselves.
J.A. Coutts |
|
| reply to Dapper
said by Dapper:There are some fairly major limitations using Teredo, not least of which is that if there's a choice of using ipv4 or ipv6 to connect, it will always prefer ipv4. You can read more about getting Teredo up and running at »yorickdowne.wordpress.com/2008/0···-teredo/
You'd really be better off getting a free tunnel with a broker, at least until you have native ipv6.
I chose the Teredo Tunnel because it is essentially a free tunnel broker that works behind a NAT router, and that it what I am stuck with. Also, it is available on every modern Windows operating system. To get it working was as simple as adding another IPv6 address (eg. 2002:c0a8:102::) and a persistent default route. I can live with the IPv4 preference, but that can be corrected by modifying the prefixpolicies list. There does not appear to be a policy list for source addresses, and that is what is causing me all the grief.
J.A. Coutts |
|
| reply to couttsj
said by couttsj:I didn't try that, but I will. I simply chose the first address returned, assuming they were in order of precedence. Worked on my development machine, but not on the next one I tried. Life was sure a lot simpler with IPv4. One interface, one address. I understand that IPv6 simplifies the routing issues, but it sure moves a lot more complexity onto the the end units themselves.
Not really...
Link local addresses are completely worthless for most applications. They are just there to bootstrap local routing/ND not serve as explicit endpoints for communication.
Forget they exist and IPv6 is no different than IPv4. You just need a global IPv6 address. |
|
| said by dslcreature:Link local addresses are completely worthless for most applications. They are just there to bootstrap local routing/ND not serve as explicit endpoints for communication.
Forget they exist and IPv6 is no different than IPv4. You just need a global IPv6 address.
But if link-local addresses are worthless, why does the ping command utilize them when pinging the host name on the local network:
Pinging couttsj-PC [fe80::a5bb:d4f:e017:e25c%9] from fe80::a5bb:d4f:e017:e25c%9 with 32 bytes of data:
Reply from fe80::a5bb:d4f:e017:e25c%9: time1ms
available addresses:
fe80::a5bb:d4f:e017:e25c%9
fe80::c8f:3128:3f57:fefd%8
2002:c0a8:102::
2001:0:4137:9e76:c8f:3128:3f57:fefd |
|
| reply to couttsj
The Microsoft ping program is having exactly the same problem as my program. On my development machine it uses the Ethernet interface as source by default. On the other machine, it uses the Teredo interface as source by default. The only difference I can find between the 2 machines is that on the development machine "ipconfig /all" lists the Teredo interface second as "Tunnel adapter Local Area Connection* 6:". The other machine lists the Teredo interface third as "Tunnel adapter Local Area Connection* 7:". If I could change the order on the second machine, I could at least temporarily solve the problem. Anyone have any idea how I could do this?
J.A. Coutts |
|
| reply to couttsj
If you post a concrete example of what you are trying to do I'll show you how to do it without worrying about link local addresses or ordering assumptions.
In terms of pinging your computer from itself set the address you want it have in your hosts file.
windows\system32\drivers\etc\hosts |
|
| reply to couttsj
OK, so I disabled the other tunnel interface (ISATAP) via the registry, and that seems to have resolved the pinging problem (don't ask me why). I can now ping each machine by host name. Unfortunately, it has not corrected my own program, so it looks like I will need a little more code work.
J.A. Coutts |
|
| reply to dslcreature
said by dslcreature:If you post a concrete example of what you are trying to do I'll show you how to do it without worrying about link local addresses or ordering assumptions.
I have used the Microsoft Winsock Control quite successfully for years, but it does not support IPv6 and there is no indication that it ever will. Consequently, I have had to resort to direct Winsock calls. How the Winsock Control actually works internally is not well documented, but I found a couple of Class Modules that supposedly duplicate the Winsock functionality. Each Control/Class is theoretically capable of controlling a single socket. When binding to an internal socket the first time the routine binds, it has no record of the internal address. So it uses the machine name to recover the internal IP addresses, and that is where I am running into trouble. The first address returned on the one machine is the link-local address, but on the other machine it is the Teredo link-local address. |
|
| reply to couttsj
OK, I solved the multiple IP address problem by dumping them to a dropdown list and letting the user choose the one to listen on. I also added the Interface Identifier (also known as scope_id) to the IP address if it was non zero. This can only be considered a kludge, but at least it got me going again. If someone has a better solution, I am all ears. Binding to all addresses is not a viable solution at this point in time.
J.A. Coutts |
|
| reply to couttsj
I didn't care for the kludge, so I changed the program to bind to the internal “INADDR_ANY” or “INADDR_ANY6” addresses. That left the inexperienced user with only 2 choices (IPv4 or IPv6), but it was better than having them try to make sense of those long hex strings. I believe I now have a functional replacement for the Winsock Control that works with IPv4 and IPv6.
J.A. Coutts |
|
