It seems there's a serious problem. After updating to Spring Creators Update, my tunnel is not working anymore. I cannot setup the tunnel device (adding v6v4tunnel fails). I fear this will not be resolved in the final build of the newly named April 2018 update. For now, I strongly advise against updating.
You must be on the insiders fast ring? What build number?
Not really. I am not even registered for the insiders program. I was just quick to download ISO file before Microsoft found some problem and decided to withdraw the final status again, and to delay the update until further adjustments have been made. I am currently on build 17133.1. Well, of course it could be possible that "some problems" also include the v6v4tunnel, but I have doubts about that.
I set a test machine to Windows Insider on the Release Preview ring. Build 17134.1. Problem still existing. I'll now try Slow Ring, and if that fails Fast Ring. From what I've found out, this issue exists at least since insider preview build 17046.
Seems like this problem slipped by unnoticed. Just "skipped ahead to the next Windows release" Insider 1803 build 17655.1000, and it's still broken.
I strongly advise anyone not to upgrade past Windows 1709 at the moment, if you need to start the tunnel from Windows. Maybe this bug will cause more noise once the April 2018 update goes live, and hopefully will result in a quicker fix then.
I am getting these errors when attempting to install the IPv6 Tunnel following the Win10 Pro x64 Spring Creators Update, v1803 (OS Build 17134.1):
C:\WINDOWS\system32>netsh interface teredo set state disabled
Ok.
C:\WINDOWS\system32>netsh interface ipv6 add v6v4tunnel interface=IPv6Tunnel localaddress=192.168.0.x remoteaddress=184.105.xxx.xx
There is no driver selected for the device information set or element.
C:\WINDOWS\system32>netsh interface ipv6 add address interface=IPv6Tunnel address=2001:470:1f10:111f::2
The filename, directory name, or volume label syntax is incorrect.
C:\WINDOWS\system32>netsh interface ipv6 add route prefix=::/0 interface=IPv6Tunnel nexthop=2001:470:1f10:111f::1
The filename, directory name, or volume label syntax is incorrect.
Those commands worked in the previous build but will not work now. What is concerning is the line "There is no driver selected for the device information set or element."
Is it possible that the Spring Creators Update changed the netsh commands without telling us?
Quote from: RDWells on April 30, 2018, 04:59:55 PM
Those commands worked in the previous build but will not work now. What is concerning is the line "There is no driver selected for the device information set or element."
For some reason, the v6v4tunnel-driver/binding/whatever-its-called is not correctly installed anymore. It's actually part of netip6.inf, which is for IPv6 in general, but it doesn't seem to work anymore. No idea if this can be manually fixed. I don't know the commands. Tried reinstalling the inf-file with no success.
netcfg -v -m (optionally use "netcfg -v -m | clip" which will copy to clipboard so you can paste output to notepad)
This shows at least one line "Binding entry ignored since it is Type:5 Name:ms_tcpip6_tunnel". So, Windows somehow is aware that this tunnel exists in theory. Maybe they even disabled it intentionally, since MS says they don't want to actively support IPv6-transition mechanisms anymore and instead push people towards using native IPv6. See for yourself:
https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803-removed-features
"6to4 has been disabled by default since Windows 10, version 1607 (the Anniversary Update), ISATAP has been disabled by default since Windows 10, version 1703 (the Creators Update), and Direct Tunnels has always been disabled by default. Please use native IPv6 support instead."
However, this doesn't mention "6in4". Or is that what "Direct Tunnels" are? In that case, it should be possible to enable it somehow.
Edit: if you need v6v4tunnel to work, DON'T update to 1803!!! Just stay on 1709.
Well, harrumph, they don't exactly say how to implement native IPv6, do they? My ISP (RCN) doesn't support it yet.
Guess we're stuck for now, huh?
Let's clarify some things here.
*You* can't implement native IPv6; you have to wait for your ISP to do that.
And as far as the "Direct Tunnels", I suspect they're talking about Teredo.
Quote from: cholzhauer on May 02, 2018, 10:12:27 AM
Let's clarify some things here.
*You* can't implement native IPv6; you have to wait for your ISP to do that.
Right, got that, and as far as I could discern, they aren't exactly hopping to it yet.
And as far as the "Direct Tunnels", I suspect they're talking about Teredo.
Nah, very few seem to be. Until you have IPv6-only content, it'll be hard to convince the small ISP's to make the infrastructure investment.
Is there maybe a 3rd party client software for 6in4 tunnels? I couldn't find anything. All the results are just saying about v6v4tunnel and how to do it from Windows.
I am really pissed. The one time that I directly deleted the previous Windows version after upgrading seeing it booted fine. And now this shit. And I don't have the time to reinstall Windows 10 at the moment.
Do you not have a device upstream of the Windows machine to configure the tunnel on? I mean, you could probably even run a linux VM on the Windows machine if it needs to be running on it.
No, cause I need this machine to be directly connected to the network.
I thought about the VM stuff, but I'd need a VM that forwards proto 41 from host to guest. And VirtualBox doesn't seem to be doing that.
I also posted in Windows forums, they seem to be aware of this issue now, and are also considering it an issue, and not a "feature for removal". But at least in insider build 17661 it's not fixed. To be honest, I don't know exactly how it works with the build numbers and possible intermediate patches. So, I am still just gonna sit it out.
Update: no news!
Still broken in final 1803 build 17134.48
Also still broken in
-RS5 insider build 17661.1001
-RS5 insider build 17666.1000
-RS5 insider build 17672
-RS5 insider build 17677.1000
I just spent a LOT of time with four, count 'em, four "techs" through MS' Virtual Assistant thingie, all of whom wanted to remote control my computer and do stuff completely irrelevant to the problem (I'll spare y'all the gory details), but I FINALLY convinced the fourth one who pretty much summed the issue as a bug which, he wanly suggested, would be looked at by MS engineers who'll send out a fix whenever they dang well feel like it.
So there we have it. MS "fixed" what ain't broken; i.e., the netsh command to install a v6v4tunnel doesn't work due to a "bug" and now the geniuses who broke it are gonna fix it.
So they say.
So did someone actually login to your machine? What did they try?
Anyway, there's also this thread on TechNet:
https://social.technet.microsoft.com/Forums/windows/en-US/af68159a-87fc-4e39-92a9-c5f209aa4058/will-v6v4tunnel-be-fixed-in-final-version-of-april-2018?forum=win10itpronetworking
It appears as if Microsoft acknowledges this issue. However, I am not sure how serious they treat this issue and how fast it might get resolved. The statement doesn't sound too promising, to hopefully fix it with the next release. And I hope by "release" they mean cumulative update, not Redstone 5. Maybe if more people post over there it'll spark more interest to tackle this bug.
All in all it's probably really only a handful of people affected, since most will have a non-Windows upstream device serving as the local tunnel endpoint.
Quote from: tjeske on May 18, 2018, 09:00:26 AM
So did someone actually login to your machine? What did they try?
Yes, and one wanted to do a System Restore (NO!), another wanted to update the network driver (duh, not the problem), the third did a network reset (which served to do absolutely nothing) and the fourth had me try to use the lengthy version of the netsh command:
netsh interface ipv6 add v6v4tunnel interface=private localaddress= "Your local address" remoteaddress= "remote address given to you" (with the proper numbers put where they belong.)
...which did bupkis. Same answer: "no driver selected...."
He (the fourth guy) also wanted to be sure that the mobo drivers were up-to-date. This is what I meant by irrelevant, and my drivers are ALL up-to-date. I'm OCD that way.
Quote from: tjeske on May 18, 2018, 09:00:26 AM
Anyway, there's also this thread on TechNet:
https://social.technet.microsoft.com/Forums/windows/en-US/af68159a-87fc-4e39-92a9-c5f209aa4058/will-v6v4tunnel-be-fixed-in-final-version-of-april-2018?forum=win10itpronetworking
It appears as if Microsoft acknowledges this issue. However, I am not sure how serious they treat this issue and how fast it might get resolved. The statement doesn't sound too promising, to hopefully fix it with the next release. And I hope by "release" they mean cumulative update, not Redstone 5. Maybe if more people post over there it'll spark more interest to tackle this bug.
All in all it's probably really only a handful of people affected, since most will have a non-Windows upstream device serving as the local tunnel endpoint.
At least I know that it's not just me (or you) having this issue, but for FOUR techs not really having the first clue as to what I talking about is troubling at the least, annoying (and more) at most. So, looks like we'll just have to twiddle our collective thumbs until MS gets it into gear (without too much grinding?). The fourth tech said
maybe a week or two. Maybe....
In the meantime, the fourth tech also suggested that as many people as possible submit feedback through their feedback hub so the engineers can spot it. Yes, that's what he said, so hop to it, readers of this forum. Light a fire under their bums and let's get this fixed, ASAP. Here's the link: https://aka.ms/AA1dxur
P.S. I am not a Windows Insider, I have Window 10 Pro x64 v1803(OS build 17134.48), the April 2018 Spring Update with subsequent quality update of KB4103721 (5/10/18).
Okay, so I tried to investigate a bit more. At least I found something that was different from 1803 to 1709. If you run this command:
netcfg -s n
you will get a list of network adapters, network protocols, and network services. If you scroll through the list you'll find an item called "ms_tcpip6_tunnel - Microsoft TCP/IP version 6 - Tunnels". On 1709 this is listed under "Network Protocols", together with "ms_tcpip6", while on 1803 "ms_tcpip6_tunnel" is listed under "Network Services", while "ms_tcpip6" is still in the "Network Protocols" group.
I was able to delete ms_tcpip6_tunnel and afterwards add it again as a protocol, instead of a service. While on 1709 this was possible with simple administrative privileges, on 1803 I had to run it as "TrustedInstaller". Even though it is listed now in the correct category, it still doesn't work. This is also understandable from the output of "nvspbind.exe", which is a separate tool by Microsoft. The output shows all services or protocols bound to specific network adapters. While on 1709 I can find both "ms_tcpip6" and "ms_tcpip6_tunnel", I can't find the latter on the affected 1803. I haven't found a way yet if it is possible to somehow manually add a protocol. The nvspbind-utility doesn't have an option for this, only to enable or disable already bound protocols.
EDIT:
I think it's because nettun.inf is missing from 1803. I find it on 1709 under HKEY_LOCAL_MACHINE\DRIVERS\DriverDatabase\DriverPackages\ but it's missing completely on 1803. Maybe possible to transfer the INF over and do a manual install.
Okay, after a little more digging I wanna share my new insight:
It seems to be indeed nettun.inf and the associated driver tunnel.sys which is used to set up the 6in4 tunnel. If you start a tunnel, it will appear as "Microsoft Direct Point-to-Point Tunnel Adapter" in the device manager. The inf-file also holds all the driver information for Teredo, ISATAP, 6to4, and some more. The bad news about this is that 6in4 is therefor indeed the "Direct Tunnels" which where marked deprecated as of 1803 along with all the other IPv6 transition technologies. So I fear that even if it should be able to enable it somehow, Microsoft will not honor this bug and leave it unfixed.
So, I've tried to fix it myself by copying over the driver from a healthy 1709 installation. First pitfall, I can't find to copy the signed driver (inf file misses signture?), and therefor installation is only possible with driver signature enforcement turned off during boot. After that, it installs without error. When I try to set up the tunnel, it still doesn't work, but the error message changed to a simple "Element not found". Checking device manager, I get the Direct Tunnel adapter with a yellow sign and error code 56, manually adding the driver fails with a time out.
What seems still different is that the driver is listed in the registry under some oemxx.inf-key, whereas on an original installation it's simply called nettun.inf. I'll try to copy over some registry keys and see if that helps.
Fingers crossed.
Found this after months of researching on an MS site:
https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803-removed-features
IPv4/6 Transition Technologies (6to4, ISATAP, and Direct Tunnels) 6to4 has been disabled by default since Windows 10, version 1607 (the Anniversary Update), ISATAP has been disabled by default since Windows 10, version 1703 (the Creators Update), and Direct Tunnels has always been disabled by default. Please use native IPv6 support instead.
So does this mean there is no way to use a Tunnelbroker tunnel going forward? Or can someone more technical than me offer a suggestion?
You don't use any of these technologies with HE, HE is 6in4
But I am pretty certain now that "Direct Tunnels" is 6in4. Why? If I create an IPv6-tunnel with the "add v6v4tunnel", a "Microsoft Direct Point-to-Point Tunnel Adapter" gets added to "Device Manager". Furthermore, after fiddling with the driver for "Direct Tunnels", I was able to change the error message given by netsh.
Still broken in:
-RS5 insider build 17677.1000
Following an OOB Quality Update KB4100403 for Win10 to v1803 (17134.81), it's still broken.
Dangit.
Insider build 17682.1000 still broken, of course.
Add insider build 17686.1003 to the broken list, too...
I can only ask everyone to use Microsoft Feedback Hub to complain about this issue, please.
EDIT:
Windows 1803 build 17134.112 (June 2018 cumulative update) still broken.
Windows insider build 17692.1000 still broken.
Ladies and Gentlemen, be of good cheer!
I have found a way around the bustage and I credit TJeske for pointing me in the right direction. I am pleased to report that as a result of what I am about to share that I have an HE tunnel that gives me 10/10 (https://test-ipv6.com) and 20/20 (http://ipv6-test.com) using the HE tunnel script for Win 10.
Here we go:
From where one can find it, obtain the .iso for v1709 and extract it to the folder of your choice. Within it, search in Windows Explorer for nettun.inf. You will find several files with either that name or the name within the file name: (Caveat; you may have to Take Ownership of the files and the folders in which they go for the copy transfer to work.)
nettun.inf - copied to these folders: Windows\INF and Windows\WinSxS\amd64_nettun.inf_31b...(etc)
nettun.inf_loc - copied to these folders: Windows\System32\Driver Store\en-us and Windows\WinSxS\amd64_nettun.inf.resources_31b...(etc)
amd64_nettun.inf.resources_31bf3856ad364e35_10.0.16299.15_en-us_7612c139e588cebb - copied to Windows\WinSxS\Manifests
Now, do a search for tunnel.sys. You will find:
tunnel.sys - copied to these folders: Windows\System32\drivers and Windows\WinSxS\amd64_microsoft-windows-tunnel_31b...(etc)
tunnel.sys.mui - copied to these folders: Windows\System32\drivers\en-US and Windows\WinSxS\amd64_microsoft-windows-tunnel.resources_31b...(etc)
Now, run the tunnel config script from HE, check the results with ipconfig /all, and you should have your v6v4tunnel tunnel in place.
I must caution, however, that I did run into a few snags while going through all this. You may well have the Microsoft Direct Point-to-point "Adapater" (yeah, that's what it says) but it has a yellow flag by it due to it not recognizing the driver as being digitally signed. This is the sucky part. Test the driver by drilling down to Windows\INF to nettun.inf, right click it, click Install and see what happens. You might get a warning about a third-party driver signature issue in which case you'll have to do this:
Reboot by holding the Shift key while clicking Restart, choose Troubleshoot, then Advanced Options, then Startup Settings. When the reboot comes around, you'll have a menu from which to choose. Pick Option 7 Disable Driver Signature Enforcement and let the reboot continue to its end. Drill back down to Windows\INF nettun.inf, right-click it, click Install, and this time you'll likely get a warning with the option to "continue anyway". Choose that, and you're good.
If for some reason things get botched and you want to delete the "adapater", go to Device Manager, click View, show Hidden Devices, right click on the "adapater" and Uninstall. Re-run your HE config script and THIS time things should be good to go.
Having typed all this, I have possibly left out some more caveats with all the trial-and-error I went though before I succeeded, so if there are any snags you hit along the way, I'll gladly try to walk/talk you through a solution.
Good luck, folks, and happy IPv6ing!
That sounds interesting. And quite similar to my approach. No idea why I had no success :(
Anyway, I guess with this method you have to turn driver signature enforcement off with every boot? Maybe an alternative for that would be to use a self-signed driver (i.e. to sign a driver with your own certificate, that you create somewhere somehow). Then you only need to turn "testsigning" on, which is much more secure than no signature enforcement at all.
Although I wonder what breaks the certificate of the old driver? Shouldn't it still be fine with MS old driver? Maybe if we also swap out tunnel.sys? Or does it need to be packed with the .cat-file and installed from there?
Quote from: tjeske on June 20, 2018, 10:57:10 AM
That sounds interesting. And quite similar to my approach. No idea why I had no success :(
Anyway, I guess with this method you have to turn driver signature enforcement off with every boot? Maybe an alternative for that would be to use a self-signed driver (i.e. to sign a driver with your own certificate, that you create somewhere somehow). Then you only need to turn "testsigning" on, which is much more secure than no signature enforcement at all.
Agreed, and as it has turned out, yes, I had to turn off driver signature enforcement with a subsequent reboot. Grrr....
Quote from: tjeske on June 20, 2018, 10:57:10 AM
Although I wonder what breaks the certificate of the old driver? Shouldn't it still be fine with MS old driver? Maybe if we also swap out tunnel.sys? Or does it need to be packed with the .cat-file and installed from there?
Yup, you'd think that tunnel.sys from v1709 would be fine, but noooo.... It's the one I used to replace the one in v1803. If you find a suitable replacement and its source, I'm sure you'll let us know. I'm thinking I can locate the v1803 version of it and replace the one from v1709. Worth a shot, ya think? It just might solve the driver signing issue. No time right now to test that but I'll give it a go and see what happens.
Sorry, I didn't fully understand your answer.
So did you take the tunnel.sys from 1709 and copied it to the 1803 installation? Or did you just leave the tunnel.sys from the 1803 installation?
I just tried copying the nettun-files, but it didn't solve it for now. But I also messed up my registry during my first tries. Fortunately I am just experimenting inside a VM until I find the proper method.
Yes, I took tunnel.sys from v1709 and copied into the v1803 installation. I tried putting the v1803 version back but I kept getting "element not found" when I ran the HE CMD script.
Registries need not be altered, and just a reminder, the nettun files go as follows:
nettun.inf - copied to these folders: Windows\INF and Windows\WinSxS\amd64_nettun.inf_31b...(etc)
nettun.inf_loc - copied to these folders: Windows\System32\Driver Store\en-us and Windows\WinSxS\amd64_nettun.inf.resources_31b...(etc)
amd64_nettun.inf.resources_31bf3856ad364e35_10.0.16299.15_en-us_7612c139e588cebb - copied to Windows\WinSxS\Manifests
Sadly, the driver is still showing as unsigned. Darned if I know why, so it looks like we'll still have the unsigned driver thing to deal with upon reboot.
Thanks. So, I have possibly found a cleaner method. However, the embedded certificate of tunnel.sys (which weirdly is not shown when opening file properties, contrary to other .sys files!) is only valid till Aug 11th, 2018. But all other .sys files of a 1803(!) installation have the same certificate validity. So I don't know what will happen after Aug 11th, 2018. Also, I only confirmed this workaround for now on my insider preview installation running RS5 build 17692. Will report back if it also works on my main machine with 1803 final, or not.
What I have done:
- You need the tool "RunAsTI" (short for "run as TrustedInstaller"), which is needed to edit files in C:\Windows\system32\drivers. It will open a cmd-window with TrustedInstaller privileges. Therefor, you don't need to change ownership or fiddle with any other access permissions. (it's a very useful tool for troubleshooting in general. E.g. it enables you to access ALL keys in the registry, even ones that are hidden from administrator! Unfortunately, the 32-bit version is flagged as virus/hacktool by Windows Defender)
- use the tool to rename the old tunnel.sys (e.g. rename to tunnel.sy_)
- use the tool to copy the tunnel.sys from 1709 into c:\windows\system32\drivers.
- copy the nettun.inf from 1709 somewhere (e.g. desktop, documents folder, download directory, whatever...)
- right-click nettun.inf and click "Install".
That's it. This way it should install fine with the old certificate and you can setup the tunnel as usual. Since it's even signed by Microsoft, not only don't you need signature enforcement turned off, even testsigning mode isn't needed anymore, which further allows you to keep SecureBoot turned on.
However, I don't feel comfortable using this method, as it will suggest to Microsoft that the issue doesn't exist anymore, and it probably won't work indefinitely.
I'm baffled AF on two counts:
1) Is the v1709 version of tunnel.sys you use actually signed? Mine, for some odd reason (even though it's from Microsoft, I think?), is not.
2) I cannot for the life of me get v1803 tunnel.sys to work at all, even with signature enforcement turned off and right-clicking nettun.inf "install", with it saying the action was completed. I keep getting "element not found"
I searched high and low for ways to sign an unsigned driver and most of them involve a looong process with Windows Development Kit (and one other whose name escapes me) and even then, the instructions were above my pay grade to understand.
So, it appears that even though I followed the command prompt of "bcdedit /set testsigning on" and "bcdedit.exe /set nointegritychecks on" to permanently disable signature verification, it does not "stick" and I am left with having to go with Shift+Restart>Troubleshoot >> Advanced Settings >> Windows Startup Settings >> Restart>7 Disable Signature Verification EVERY time I reboot in order for the driver tunnel.sys to remain loaded. SecureBoot is turned off, btw.
You can't permanently disable driver signature enforcement without any additional tools. One example seems to be "ReadyDriver". But, since Windows 10 the Windows Development Kit is not needed anymore. Then necessary tool is included with PowerShell: "New-SelfSignedCertificate". See the last answer here:
https://stackoverflow.com/questions/84847/how-do-i-create-a-self-signed-certificate-for-code-signing-on-windows
Regarding your other comments:
1) I don't know for sure. When I open the file properties for tunnel.sys (new or old) it's missing the "Digital Signatures" tab. However, I was able to extract a certificate from the file. So I think it does have one. Why it doesn't show? No clue...
2) did you also edit nettun.inf to reflect the correct version number (i.e. 10.0.17134.1)?
But whenever I tried to edit nettun.inf it resulted in missing certificate. I wonder what certificate checks nettun.inf integrity. Must be somewhere else, cause the .inf-file doesn't contain an embedded signature.
BTW: I haven't been able to install the 1709 version without testsigning. It still complains about missing signature of 3rd party INF. So I guess testsigning is necessary, which also means no SecureBoot.
I just can't find an iso for 1709 anywhere that seems to look safe. Lots of odd websites, but nothing official looking.
Quote from: Hoser13 on June 27, 2018, 06:33:51 PM
I just can't find an iso for 1709 anywhere that seems to look safe. Lots of odd websites, but nothing official looking.
I can only suggest what I used, since MS does not offer a direct link to the desired .iso, (and most of the .iso files I did find did not contain the necessary files) and that is this:
http://sihmar.com/download-windows-10-build-16299-15-esd-files-direct-links/
...which will give you several flavors of v1709 in .esd format. No need to convert it to .iso, so save yourself the trouble.
Here's where it sucks eggs; this file (I chose Win10 Pro x64, ~3GB) is extractable by, say, 7-zip (which I use) but it expands to 130GB so hopefully you have enough room to do that. Just to extract took me just under 51 minutes.
Then, you'll have 12 numbered folders, each of which (except for Folder 1) will contain the necessary files to copy (as mentioned in a previous post) which also means you only need one of them. Just choose one and delete the rest which will take another lengthy amount of time.
Windows 1803 build 17134.112 (June 2018 cumulative update) still broken.
Windows insider build 17704 still broken. <- newest release after bug bash event.
BUT: I have some seemingly insider info that a fix is supposedly scheduled for the next build 17709. I don't have more proof than this anonymous statement, but mentioning a future build number makes it seem rather legit to me. EDIT2: Also, supposedly only for the insider build and following. 1803 probably won't receive a fix.
So, insider build 17711 is out. It seems fixed. But it looks like it's not nettun.inf anymore. However, I am not 100% sure, as I just updated the previous 17704 insider build where I applied the manual fix. Will do a fresh install now and report back. Also note that this hasn't been mentioned in the changelog.
Okay, great! Microsoft really did it in insider build 17711 and brought back native 6in4 tunneling!
However, nettun.inf isn't there anymore, tunnel.sys is though. But I am not sure if it is still being used, because there's no device visible in device manager anymore. The tunnel works, it's device is listed using netsh. But I have no idea which driver is being used now. It just works™. Probably I'll have a look in the registry, but for now I am satisfied.
Let's hope they keep it running! Again: it's probably not going to be backported to RS4 aka 1803. Everyone who wants to use it needs to update to become a Windows insider and update to the current build. Fortunately, insider builds seem already quite progressed and I'd even use it in a mild production environment. But that's for everyone to decide on his/her own.
I was able to get the tunnel running on 17713, but could only get a score of 16/20 with a warning that my browsers could not fall back. Problem is, as soon as I reboot, the tunnel is gone. Oh well. Back to the drawing board.
I think that's always the case that the tunnel is lost upon reboot. That's why I setup a netsh-script with task scheduler to be run on every boot. Browsers not being able to fall back could be firewall blocking certain types of ICMPv6 pings, I believe.
This is what my script looks like:
pushd interface ipv6
add route prefix=::/0 interface="IP6Tunnel" nexthop=2001:470:xxxx:zzzz::1 publish=No
set interface interface="IP6Tunnel" forwarding=enabled advertise=enabled nud=enabled routerdiscovery=disabled
add address interface="IP6Tunnel" address=2001:470:xxxx:zzzz::2/64
### Forwarding and advertising
# for LAN segment
add route 2001:470:xxxy:zzzz::/64 "Ethernet" publish=yes valid=1d preferred=1h
# for VMs running on local system
add route 2001:470:xxxy:zzzz::/64 "VirtualBox Host-Only Network" publish=yes valid=1d preferred=1h
set route ::/0 "IP6Tunnel" publish=yes valid=1d preferred=1h
set interface "Ethernet" forwarding=enable advertise=enable otherstateful=disable
set interface "VirtualBox Host-Only Network" forwarding=enable advertise=enable otherstateful=enable
set interface "IP6Tunnel" forwarding=enable
I also have a tiny DHCPv6 running on my system for stateful-IPv6 (that's why I wrote otherstateful=enable above). The piece of software is called "dibbler" and works like a charm! This is needed if you also want to publish a DNS server to your clients, cause Windows doesn't support RDNSS (at least it didn't two years ago). Otherwise, IPv4-DNS usually does report IPv6-records as well, so lookups will still need a working IPv4.
Anybody tried the tunnel on the final 1809? I ended up setting up a router after all...but because it's very very old (2003 or so) it can't handle more than 20 MBit/s. However, it works and it doesn't rely on my main machine running all the time.
Yup, tried the HE script in v1809 and it works!
10/10 and 20/20 (with an ICMPv6 Echo Request exception in firewall) for www.test-ipv6.com and www.ipv6-test.com, respectively. ;D
Best of all, it survives a reboot. 8)
Odd thing is, the "Microsoft Direct Point-to-point Adapater" doesn't show up in Device Manager, even with Show Hidden Devices. ???
Yep, that's normal. A Microsoft guy told me they changed the way those tunnels are handled, it doesn't use the Direct Tunnel thingy anymore. This is what initially broke it in 1803.