Hurricane Electric's IPv6 Tunnel Broker Forums

Please login or register.

Login with username, password and session length
Advanced search  


Welcome to Hurricane Electric's forums!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - aandaluz

Pages: [1] 2
the issue is finally fixed in build 14393.953 (March CU update) :)

I have installed Windows 10 creator's update (build 15014.1000) today and it seems that the issue is fixed, as my wlan adapter configures ipv6 dns servers automatically.  Let's hope this makes it to current stable builds as soon as possible  :D
EDIT: a fix will be available as an cumulative update in march for RS1

The fix should be expected to release with the March 20107 CU for 1607 clients if everything goes well.

A fix will be available shorty in insider builds. However, 14393.XXX have to wait until Q1/2017. So basically no real fix until Windows 10 creator's update (1703) in march/april
So the fix for RS2 should be in the WIP builds, if not, should be in the next few build releases.
In regards to the RS1 code fix, we are targeting Q1 of 2017 as long as testing/validation are successful. Once I have an exact date and KB article, I will update this thread again.
For temporary workaround, would recommend to configure a startup script to do ipconfig /renew6 on the machines.

Thank you to the folks who have reached out to me with the logs and data. At this time, the product group is investigating further to determine root cause. I will update this thread as soon as I have some more information.
Avatar of ARUDELL
ARUDELLMicrosoft (MSFT) 975 Point
EDIT: also reported in ipv6-ops mail list

more users are experiencing this issue

A temporal fix is to request  ipv6 dns servers via dhcpv6 using the
ipconfig /renew6 command

This issue is not fixed in 14393.105 (current stable build)

a long time ago Andrews And Anorld Ltd had a dns64 gateway which was reacable from  (2001:8b0:6464::1 and 2001:8b0:6464::2). I haven't checked lately if it still still operating for current tunnels:

It seems that since the widnows 10 1607 (14393.51) release, windows does not pick up ipv6 dns servers from dhcpv6. I've seen this in my network, but I was wondering if this is a general issue.

I have noticed that on all my Windows 10 machines with the Anniversary Update, they no longer receive IPv6 DNS from DHCPv6 servers if network is configured for Stateless DHCP (Managed Flag unset, Other Flag Set in RA).  They receive IPv6 information correctly if the network is configured for Stateful DHCP.
It isn't just you.  DNS servers aren't picked up after the AU via either RDNSS (which never worked) or stateless DHCPv6.  Several others have made the same observation - something is clearly broken.

I'm also affected by this block, althogh my endpoint is in Paris, so not much would have changed over ipv4 right no(  tunnel server at  Paris).

It is sad to force netflix to work over ipv4 for the time being until my isp deploys ipv6 natively. But is seems that Hollywood and media producers still don't get what global entertaiment consumers really want...

My setup is similar to yours. According to Apple, happy eyeballs on elCapitan will fallback to ipv4 if the difference in responses for both protocols is greater than 25 ms. Getting around Apple's "Hampering Eyeballs

Perhaps at some point ICMP responses with " "packet too large" may not be reaching your router. Try setting your MTU to the minimum supported value (1280 instead of 1480). You can do this from your tunnelbroker account, or via your router ipv6 config. See
[Connection Problems] [Hint: MTU] Reducing MTU for tunnel


Questions & Answers / Re: "Request Error" with DDNS update
« on: August 22, 2015, 08:37:19 AM »
I can confirm that my Tunnel endpoints updates are working again since Sun. 22nd Augut 13:00 (UTC).
Just for reference,  Asus routers wrt firmware only requests tunnel updates when the public ip changes, but there is also a forced refresh interval every 21 days by default.

Questions & Answers / Re: "Request Error" with DDNS update
« on: August 17, 2015, 02:41:50 AM »
I'm seeing this issue too in my Asus RT-AC87U. Tunnel endpoint updates stoped working two days ago. I've even set a new tunnel to see if there was an issue specific to my endpoint (paris), but it still did not work.

Questions & Answers / Re: Getting around Apple's "Hampering Eyeballs"
« on: July 10, 2015, 11:42:30 AM »
Sorry for the thread necromacy, but it seems that osx elcapitan and ios9 will finally get rid of hampering eyeballs  :D
Hi everyone,

Today Apple released the first public seeds of iOS 9 and OS X El Capitan.
These seeds (and the third developer seeds released yesterday) include an improved version of Happy Eyeballs.

Based on our testing, this makes our Happy Eyeballs implementation go from roughly 50/50 IPv4/IPv6 in iOS 8 and Yosemite
to ~99% IPv6 in iOS 9 and El Capitan betas.

While our previous implementation from four years ago was designed to select the connection with lowest latency
no matter what, we agree that the Internet has changed since then and reports indicate that biasing towards IPv6 is now
beneficial for our customers: IPv6 is now mainstream instead of being an exception, there are less broken IPv6 tunnels,
IPv4 carrier-grade NATs are increasing in numbers, and throughput may even be better on average over IPv6.

The updated implementation performs the following:
- Query the DNS resolver for A and AAAA.
   If the DNS records are not in the cache, the requests are sent back to back on the wire, AAAA first.
- If the first reply we get is AAAA, we send out the v6 SYN immediately
- If the first reply we get is A and we're expecting a AAAA, we start a 25ms timer
   - If the timer fires, we send out the v4 SYN
   - If we get the AAAA during that 25ms window, we move on to address selection
- When we have a list of IP addresses (either from the DNS cache or by receiving them close together with v4 before v6),
   we perform our own address selection algorithm to sort them. This algorithm uses historical RTT data to prefer addresses
   that have lower latency - but has a 25ms leeway: if the historical RTT of two compared address are within 25ms of each
   other, we use RFC3484 to pick the best one.
- Once the list is sorted, we send out the SYN for the first address and start timers based on average and variance of the
   historical TCP RTT. Roughly speaking, we start the second address around the same time we send out a SYN retransmission
   for the first address.
- The first address to reply with a SYN-ACK wins the race, we then cancel the other TCP connection attempts.

If this behavior proves successful during the beta period, you should expect more IPv6 traffic from Apple products in the future.
Note however that this only describes the current beta and all these details are subject to change.

Please test this out if you have the means to, we'd love to see test results and receive feedback!

I would like to personally thank Jason Fesler and Paul Saab for their help investigating these issues and testing this.

David Schinazi
CoreOS Networking Engineer

Questions & Answers / Re: unreachable over he tunnel
« on: January 19, 2015, 11:21:59 AM »
Lowering my ethernet adapter MTU to 1280 on OSX did the trick, and now I can reach google and youtube  over ipv6 again

. I hope google's team fixes this issue asap   :-[

Questions & Answers / Re: unreachable over he tunnel
« on: January 19, 2015, 03:47:51 AM »
it seems that other tunnel brokers have the same problem

Questions & Answers / Re: unreachable over he tunnel
« on: January 18, 2015, 07:54:16 AM »
I'm experiencing similar issues since yesterday (tserv10.par1). Some sites work (, others  (,, don't. In fact, I cannot even reach hurricane electric forums ( or unless I disable ipv6 in my network adapter, although every url is pingable

 I can also confirm that
ping6 2a00:1450:4005:800::1014  hangs if  -s >1232

ping6 -s 1232 2a00:1450:4005:800::1014
PING6(1280=40+8+1232 bytes) 2001:470:1f13:130a:614d:7833:5c3b:6c18 --> 2a00:1450:4005:800::1014
1240 bytes from 2a00:1450:4005:800::1014, icmp_seq=0 hlim=53 time=49.470 ms
1240 bytes from 2a00:1450:4005:800::1014, icmp_seq=1 hlim=53 time=48.019 ms
--- 2a00:1450:4005:800::1014 ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 48.019/48.745/49.470/0.725 ms

ping6 -s 1233 2a00:1450:4005:800::1014
PING6(1281=40+8+1233 bytes) 2001:470:1f13:130a:614d:7833:5c3b:6c18 --> 2a00:1450:4005:800::1014

Pages: [1] 2