Tunnel vanished, gone ? :=(

[Ninho]

 :'(  

Hi H.E. ! My tunnel number = 35953 (Frankfurt)

which I've used for years successfully...
seems no longer to exist, suddenly !  

Temporary problems (I hope...) ?

Update: I have emailed ipv6 operations & just received an automated ack.

--
Ninho

[kasperd]

From here it looks like the tunnel exists, but your gateway is not responding.

Code Select Expand

traceroute to Ninho-1.tunnel.tserv6.fra1.ipv6.he.net. (2001:470:1f0a:922::1), 30 hops max, 80 byte packets
1  2a01:d0:839a:babe:d19e:266e:d66c:545c  0.100 ms  0.118 ms  0.145 ms
2  2001:470:1f0a:922::1  36.743 ms  37.151 ms  40.819 ms

Code Select Expand

traceroute to Ninho-1-pt.tunnel.tserv6.fra1.ipv6.he.net. (2001:470:1f0a:922::2), 30 hops max, 80 byte packets
1  2a01:d0:839a:babe:d19e:266e:d66c:545c  0.100 ms  0.114 ms  0.140 ms
2  2001:470:1f0a:1e45::1  41.623 ms  46.970 ms  52.974 ms
3  *  *  *
4  *  *  *
5  *  *  *
6  *  *  *
7  *  *  *Is your IPv4 address the same as when you created the tunnel?

[cholzhauer]

Might want to  email ipv6@he.net

[Ninho]

Thanks for caring, KasperD & CH. I got an email from ipv6 operations, my tunnel has been deleted because, wrote they, it appeared as having been unused, specifically not answering their IPv6 pings, for 2 years.

This is woefully inaccurate! I've been using my tunnel possibly not absolutely each day, but certainly several days in each week for years, and ICMP pings (v4 and v6) being allowed from the internet to my home network. My home IP v4 being a dynamic address, I was careful to update the tunnel broker when it changed. Naturally I am not online 24/24 7/7, and when online I am not always establishing the tunnel. But still, ISTM Hurricane Electric should have at least checked with me by email before deleting the tunnel... Not complaining about a free service without guarantee, just saying... What is your opinion, gentlemen ?

I don't know whether the checks and subsequent tunnel removal are human initiated or fully automated.  In any case they might be inadequate to the stated purpose of reclainming /unused/ tunnels.

Wouldn't it be better to check for *actual bytes* transported at the IP (v6 and or v4) level, over some defined period, before considering a tunnel as abandonned ? And of course, notify tunnel "owner" before cutting his access.

Other suggestion, as an enhancement to the system users could be allowed to tell the tunnel broker when their tunnel is temporarily down, inactive or inaccessible for any reason, so the system doesn't try to ping it meanwhile...


PS: As suggested by support, I have created a new tunnel (since the old one has been immediately reassigned) and would hope it to last, like "forever", as it is somewhat a PITA to have to change network numbers in scripts et cetera, also we'd like to consider our assigned tunnel IP ranges as "fixed" (even though we do not really "own" them, yet a feature of configured IP v6 tunnels is permanent IP addresses). Not to mention the annoyment of losing an old tunnel with v4 PPTP and IRC, which I assume new tunnels no longer carry :=(

--
Ninho

[broquea]

Could always ask for a quote on the paid tunnel service, then it wouldn't get reaped by the automated process regardless of downtime :) New tunnel will have IRC access if you passed Sage in the Cert Program. You just have to manually remove the filter inside the broker's webUI.

[kasperd]

it appeared as having been unused, specifically not answering their IPv6 pings, for 2 years.

I'd very much like to be able to read somewhere, what exactly is being checked. I have tunnels, which have never answered echo requests send to the IPv6 address specified as the client end of the tunnel. I use only the routed /64 and my gateway has an IPv6 address assigned to it from that prefix (and in the case of my laptop which has two tunnels the gateway actually has an IPv6 address from a NetAssist prefix).

Here is what it looks like, if you try to ping me:

Code Select Expand

PING 2001:470:27:940::2(2001:470:27:940::2) 56 data bytes
From 2001:470:28:940:5d75:c1f4:e0a0:f8ec icmp_seq=1 Destination unreachable: No route
From 2001:470:28:940:5d75:c1f4:e0a0:f8ec icmp_seq=2 Destination unreachable: No route
From 2001:470:28:940:5d75:c1f4:e0a0:f8ec icmp_seq=3 Destination unreachable: No route

--- 2001:470:27:940::2 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2002msIs that tunnel going to get deleted when I have had it for two years?

And what about the source address of the reply? If I were to be using a pair of redundant gateways on my network and follow the RFCs, I'd setup that address as an anycast address and have a unicast address assigned to each gateway. Then the reply would come from a different IP than the one the packet was send to. Is that going to be accepted as a reply?

[Ninho]

it appeared as having been unused, specifically not answering their IPv6 pings, for 2 years.

I'd very much like to be able to read somewhere, what exactly is being checked.

Ditto...

... I think I /may/ have guessed the cause of the discrepancy (spelling?) concerning my former tunnel.  For reasons I'll leave alone (security by obscurity?), I had renumbered the "host" on my side of the tunnel from ::2 to a more obscure number. The point to point tunnel doesn't really care and was working perfectly, BUT now I understand what has happened, HE had been pinging a non existent ::2 and erroneously concluded the tunnel wasn't in use!

Can you please KCochran confirm my deduction ?

In any case lesson learnt - I'll leave my new tunnel to using the standard IP...

I have tunnels, which have never answered echo requests send to the IPv6 address specified as the client end of the tunnel.

Methinks your tunnels are at risk under the current policies, but let the chief explain further...


--
Ninho

[kasperd]

Methinks your tunnels are at risk under the current policies, but let the chief explain further...

I'll wait and see if we get an official answer in this thread. If not, I'll try to ask ipv6@he.net.

[kcochran]

There are some additional checks, but in any case, since we did have a couple people get bit by this cleanup pass, nothing more is getting purged by this method until there's even more checks.

[Ninho]

There are some additional checks, but in any case, since we did have a couple people get bit by this cleanup pass, nothing more is getting purged by this method until there's even more checks.

Does the system not gather and keep at least some kind of data on established tunnels, like number of bytes carried, for statistical (or other) purposes ? If so, existence of traffic over some reference period  could be a more reliable check for marking tunnels inactive...

That, and a warning mail to the registered user /before/ purging tunnels would suffice to prevent most incidents, I believe.

[kasperd]

That, and a warning mail to the registered user /before/ purging tunnels would suffice to prevent most incidents, I believe.

I agree. If they are purged after two years, then a warning after one year would probably prevent most cases.

[Ninho]

I've made an interesting discovery. This applies to Windows XP with SP3, other people should check what goes with subsequent versions of MS Windows.

Even though the Windows firewall be configured to allow ICMP pings, the exception will not apply to pinging the local IP associated with the configured tunnel interface.

Hence the  standard (now suspended) ping test will always fail for people who terminate their HE  tunnel on a Windows (XP) computer unless they leave the Windows (dumb) firewall disabled.

I think this is one more reason why the former ping test is not suitable as an indicator of tunnel activity.

[kriteknetworks]

Because most people use Windows XP and IPv6.

[Ninho]

Because most people use Windows XP and IPv6.

And that means what, Kriket ? I'm afraid your remark is not just elliptic, it's cryptic   :=)

Just as a reminder to save time, the subject is not XP and IPv6, it's Windows+Windows firewall+IPv6+tunnel terminated on the Windows box. I don't know whether it's just XP, I've asked you all to check what gives with more recent Windowzes...

--
Ninho