Using IPv6 by default with Teredo

[kasperd]

I have a Teredo server with some extra features. It works fine with Ubuntu clients, but is a bit problematic with Windows. So far none of my users have managed to get any browser under Windows to do AAAA lookups while using Teredo.

I have done a few searches on Google and pointed the users to pages mentioning an AddrConfigControl setting, that supposedly works. But nobody got it working yet. Did that setting only apply to some Windows versions, or is it supposed to still be working on the newest Windows versions?

Also, is there a way to get a browser under Windows to prefer IPv6 over IPv4 even when it is connected using Teredo? I am aware of the reliability implications of such a configuration, and I'll be sure to mention that to users wanting to test it.

[cholzhauer]

There's a command line setting to change the priority of different traffic types (native, teredo, 6in4) ect.  Is that what the AddConfigControl setting is?  I thought it was a netsh command, but it's been several years since I used it

[JRey]

Well, what DNS servers are they using? I've had to manually setup DNS for IPv6 with Teredo, last I remember.

Also for choosing preference for IPv6 vs. IPv4 its not simple but refer to RFC 6724 (obsoletes RFC3484).

[kasperd]

Well, what DNS servers are they using?

I don't know for sure. I guess at least some of them are using whatever their ISP provides them with through DHCP. So they'll be doing the DNS lookups over IPv4 (which you have to be able to in order to find a Teredo server in the first place). I know there exist DNS servers, which are not capable of looking up AAAA records. But those are a minority, and I don't think that can explain why none of the users can make it work.

I am considering setting up a DNS server as well, which will simply remove A records from replies. (I'll probably have to modify the bind source and compile it myself in order to achieve that.)

If the DNS server removes the A records, then I can force clients to use IPv6 as long as they are able to access IPv6 only hostnames in the first place. One user did manage to get Windows to look up AAAA records, when no A record was present. I am not sure exactly what he changed. Nobody managed to get it to use IPv6 when an A record was also present.

I had one friend test it, who couldn't get the Teredo client in Windows to connect to any Teredo server at all. He found some documentation claiming that Windows will refuse to start the Teredo client, if you do not have a software firewall filtering IPv6.

[JRey]

Actually I just recently found a Microsoft page that explains how that RFC relates to Windows better. So would be much better to just use those netsh commands to modify entries in the prefix policy tables, like cholzhauer was referring to. FYI, ::ffff:0:0/96 is the IPv6 way to specify IPv4 addresses.

I wouldn't worry about what browsers do until you get it working in Command Prompt. So if still issues after the above try some of these:

• Have someone type nslookup -type=AAAA google.com to see if they can get AAAA records back from a dual-stack site
• Utilize http://www.test-ipv6.com/ which gives very helpful details
• Verify both ICMP & IPv6 are not being blocked by Windows Firewall or others
• Google what to do if netsh interface teredo show state shows problems
• Reply back what you find for each of the above

Also why in the world would you force Teredo use over IPv4? Its going to cause things to be slower because of inherent packet overhead. Temporarily for testing to make sure its working is fine but for long-term multiple user use seems quite odd.

[kasperd]

Actually I just recently found a Microsoft page that explains how that RFC relates to Windows better.

Looks outdated. It is using both the deprecated site local prefix and the deprecated Teredo prefix. 2001::/32 is not mentioned at all.

So would be much better to just use those netsh commands to modify entries in the prefix policy tables, like cholzhauer was referring to.

First of all, Windows does not always look up the IPv6 address. If it does not know the IPv6 address, it cannot apply the policy. Also according to the policy in the document you linked to, Teredo would be preferred over IPv4, but in practice it is not.

FYI, ::ffff:0:0/96 is the IPv6 way to specify IPv4 addresses.

The document you linked to has ::/96 at higher precedence than ::ffff:0:0/96. But there is nothing between the two, so which of the two is used, doesn't make a difference.

Have someone type nslookup -type=AAAA google.com to see if they can get AAAA records back from a dual-stack site

This is just testing if the DNS server is functional. Just because you can lookup an IPv6 address this way, doesn't mean it will actually try that when an application resolves a domain name.

Utilize http://www.test-ipv6.com/ which gives very helpful details

I know. I also have my own test page, and the page users of my Teredo server access to configure more details will redirect to an IPv6 literal, if it is accessed over IPv4. So I have plenty of information to work with. And I have seen quite some variation in the achieved connectivity.

• Some do not get an IPv6 address at all, despite having configured the Teredo client
• Some get an IPv6 address, but cannot access IPv6 only hostnames. For an IPv6 only hostname, only the A lookup will be attempted. But acessing an IPv6 literal URL works.
• One has been able to access IPv6 only hostnames, but IPv4 would be preferred on dual stack hostnames.
• No-one has gotten IPv6 to be used by default.

Verify both ICMP & IPv6 are not being blocked by Windows Firewall or others

The Teredo protocol just needs to be able to send and receive UDP packets. I don't see how ICMP could anything to do with it. And I am pretty sure it is not packet filters on the network, which is causing the problems. The problem is Windows specific, so it has got to be something on Windows.

Google what to do if netsh interface teredo show state shows problems

Tried that already. But I don't have access to any Windows machines myself, so I'll have to rely on what users tell me.

Also why in the world would you force Teredo use over IPv4?

My Teredo server has some additional features. I'll of course explain to the users what the advantages and disadvantages are. I am perfectly aware of the drawbacks of Teredo.

[JRey]

Actually I just recently found a Microsoft page that explains how that RFC relates to Windows better.

Looks outdated. It is using both the deprecated site local prefix and the deprecated Teredo prefix. 2001::/32 is not mentioned at all.

Well yeah its from 2006. :) I mentioned it to relate the RFC to Windows' implementation of it & to specify the related netsh commands.

So would be much better to just use those netsh commands to modify entries in the prefix policy tables, like cholzhauer was referring to.

First of all, Windows does not always look up the IPv6 address. If it does not know the IPv6 address, it cannot apply the policy. Also according to the policy in the document you linked to, Teredo would be preferred over IPv4, but in practice it is not.

Okay since you don't have access to Windows yourself I'll share what this XP SP3 box has for its default prefix policy since its different from that document:

Precedence  Label  Prefix
----------  -----  --------------------------------
         5      5  2001::/32
        10      4  ::ffff:0:0/96
        20      3  ::/96
        30      2  2002::/16
        40      1  ::/0
        50      0  ::1/128

Have someone type nslookup -type=AAAA google.com to see if they can get AAAA records back from a dual-stack site

This is just testing if the DNS server is functional. Just because you can lookup an IPv6 address this way, doesn't mean it will actually try that when an application resolves a domain name.

That's true but I didn't realize you're as experienced as you are so just wanted to make sure that this wasn't skipped since if this doesn't work then not worth trying in a browser.

Utilize http://www.test-ipv6.com/ which gives very helpful details

I know. I also have my own test page, and the page users of my Teredo server access to configure more details will redirect to an IPv6 literal, if it is accessed over IPv4. So I have plenty of information to work with. And I have seen quite some variation in the achieved connectivity.

• Some do not get an IPv6 address at all, despite having configured the Teredo client
• Some get an IPv6 address, but cannot access IPv6 only hostnames. For an IPv6 only hostname, only the A lookup will be attempted. But acessing an IPv6 literal URL works.
• One has been able to access IPv6 only hostnames, but IPv4 would be preferred on dual stack hostnames.
• No-one has gotten IPv6 to be used by default.

Interesting. That test site is the first I've come across that checks each side-by-side on the same page. Other ones just tell you which type of IPv6 you're using. What's odd is I've found inconsistent results with non-Teredo connectivity there. When it only loads 18 out of 20 then it fails another test (?) which causes the Teredo test to be skipped and only show 3 instead of 4 server vs. client test results. For some reason both of those seemed to be related since happened at the same time.

Now its plainly obvious that something's majorly wrong here as evident by those symptoms.

Another thing is have you seen trends for different versions of Windows acting differently than others?

Google what to do if netsh interface teredo show state shows problems

Tried that already. But I don't have access to any Windows machines myself, so I'll have to rely on what users tell me.

Then that's your biggest problem. I'd try to talk one of them into letting you remotely control one of their computers or at least view access to try some things yourself (or talk them through it faster/easier). If their IT is picky about that or something PM me and I'll see about arranging something where you can on a 7 or XP box of mine.

Best tip on troubleshooting Windows IPv6 for now is to rely on netsh int ipv6 show help. I just haven't found better documentation all in one place yet. I now know you know enough on what to do once you can get there & see what you're trying to work with.

Also why in the world would you force Teredo use over IPv4?

My Teredo server has some additional features. I'll of course explain to the users what the advantages and disadvantages are. I am perfectly aware of the drawbacks of Teredo.

Yes, sorry I see you mentioned that in your first post.

[kasperd]

Interesting. That test site is the first I've come across that checks each side-by-side on the same page. Other ones just tell you which type of IPv6 you're using. What's odd is I've found inconsistent results with non-Teredo connectivity there. When it only loads 18 out of 20 then it fails another test (?) which causes the Teredo test to be skipped and only show 3 instead of 4 server vs. client test results. For some reason both of those seemed to be related since happened at the same time.

Now its plainly obvious that something's majorly wrong here as evident by those symptoms.

It's not surprising at all. This happens when you are using an unreliable Teredo relay. I see it frequently myself, but only from my laptop.

The Teredo relays that the HE tunnel servers use are not very reliable. I have seen far worse, the upstream from the ISP I use at home is one example, on their network packets that should go to a Teredo relay will instead go into a routing loop.

An unreliable Teredo relay is only something to worry about, if you need to communicate with a Teredo client. My test is hosting a webserver on a Teredo client. I am only doing that for testing purposes. No serious server should be on a Teredo client. If you see an AAAA record with a Teredo address, which is not there for testing purposes, then tell the administrator to delete it. Because you are almost certainly better off without that AAAA record.

The reason my test has a Teredo address in an AAAA record is that this is the only way I can tell users, what Teredo relay they are using. And if you do need a reliable Teredo relay, it is convenient to be able to find out, which one you are using. Then you know who to contact about problems.

But it has proven to be more effective to setup my own Teredo relays than to get the HE ones to work reliably. It is easy to setup your own Teredo relay, you just need a public IPv4 address. And after I setup my own Teredo relay at home, I experienced an order of magnitude better performance than using the HE Teredo relay.

Considering that you don't really need to communicate with servers on Teredo clients, then the reliability of your Teredo relay only matters if you are running some servers, which you need to communicate with Teredo clients.

For example, when I am somewhere with my laptop, I'd like to be able to reach my computers at home. Those don't have public IPv4 addresses, so I need to reach them over IPv6. Often my laptop is connected to networks through NAT, and sometimes 6in4 cannot work through that NAT. In those cases running a Teredo client on my laptop is the only method left for me to access servers at home. This was very unreliable until I setup a Teredo relay at home.

If you are in a similar situation, where you have a latptop with a Teredo client, which you want to connect to machines at home with IPv6, then you should care about the reliability of the Teredo relay, which your network at home is using. In that case using my test page can tell you something useful.

Another situation where you should care about your Teredo relay is if you are running a server with IPv6 which lots of different clients need to connect to. The server of course should not be on Teredo itself, but it should have a reliable Teredo relay for those clients, that do use Teredo.

After I setup my own Teredo relay at home, my laptop have a very reliable connectivity to my home network through a Teredo client on the laptop. I cannot run a Teredo relay on the laptop though, since the laptop does not always have a public IPv4 address. That is why I see the same problem, when I access the test page from my laptop. But in that case I know, why those two tiles don't load, and I know that it doesn't matter.

I know how to setup a Teredo relay on Ubuntu, and it is very easy.

• Install miredo with: apt-get install miredo
• Edit the configuration file: vi /etc/miredo.conf
• Change the type from client (which is the default) to relay: RelayType relay
• Comment out any ServerAddress lines.
• Optionally add a BindPort to make debugging slightly easier, for example: BindPort 64646
• Start it with: service miredo restart

But if you know that you don't need to communicate with Teredo clients, then don't worry about it.

Another thing is have you seen trends for different versions of Windows acting differently than others?

I have seen Windows machines behave differently. But I don't have enough data to say whether it is related to specific versions of Windows. There are other factors, which can affect behaviour. And some of those factors, I cannot see directly.

for example it may make a difference if the Windows machine has a public IPv4 address or whether it is behind NAT. It may also make a difference if it is acting as tunnel endpoint itself or if it is talking native IPv6 with a router, which is then acting as tunnel endpoint.

I have noticed that Windows machines tend to use their own Teredo client when the server is on a Teredo address, even if they have a native IPv6 address and using that would have been more reliable. I have also noticed that some Windows users have a 6to4 address, in which the IPv4 address is repeated like 2002:c000:22a::c0000:22a, and apparently this is done automatically without the user having taken any steps to enable it on their own.

But I don't have access to any Windows machines myself, so I'll have to rely on what users tell me.

Then that's your biggest problem.

I'll try to get my hands on a Windows machine at some point. But I think I should have that modified DNS server ready before I go through the trouble of getting my hands on a Windows machine.

[plugwash]

I have noticed that Windows machines tend to use their own Teredo client when the server is on a Teredo address, even if they have a native IPv6 address and using that would have been more reliable. I have also noticed that some Windows users have a 6to4 address, in which the IPv4 address is repeated like 2002:c000:22a::c0000:22a, and apparently this is done automatically without the user having taken any steps to enable it on their own.

I'm pretty sure windows uses 6to4 (with that addressing scheme) by default if you give it a public IPv4 address and no native IPv6 connectivity.

The reason it's pretty rare is that most people don't put public IPv4 addresses on their windows boxes.