Putting tunnel to sleep...

[Ninho]

Dear Tunnelbroker,

is it possible to instruct your endpoint to put my assigned tunnel to sleep until instructed otherwise ?

My IPv4 is not fixed, being assigned from a pool belonging to my ISP by DHCP.
If my connection is broken, I will get another IP.

I would like to be able to unbind the tunnel before I disconnect, so that your POP doesn't send disturbing traffic to another client of the ISP - or something worse, possibly malicious, could result.

In case you haven't a procedure yet to cover this case, I'd suggest the user could set its home IP = 0.0.0.0 in the web interface to signify : please suspend the tunnel !

[Added:] PoP behaviour when receiving/sending packets apparently to/from the suspended tunnel should imvho be along the lines of :

- on IPv4 proto-41 datagram received from tunnel: MUST discard (presumably an error, or spoofing)

- on IPv6 datagram destined to tunnel : MUST discard; SHOULD send appropriate ICMPv6 (network unavailable?) back to originator.


What are the experts' opinions ?

Regards...

[broquea]

Or use a script that takes advantage of our web page for updating your endpoint. Unless you've bound a host to your IPv6 range we allocate, there wouldn't really be much traffic destined for your tunnel.

[Ninho]

Are you confirming I can set my IP to 0.0.0.0 and it will have the effect that the tunnel is inactive ?

Changing the IP from the web page, manually or by a script, is not the problem.

What I'm asking is if there is a way to tell your system my endpoint is going down for an indeterminate time. Otherwise ISTM there is the possiblilty bad things could happen, like somebody else getting that same IP and hijacking my HR tunnel.

I could well be missing something, sorry !

[broquea]

Are you confirming I can set my IP to 0.0.0.0 and it will have the effect that the tunnel is inactive ?

Changing the IP from the web page, manually or by a script, is not the problem.

What I'm asking is if there is a way to tell your system my endpoint is going down for an indeterminate time. Otherwise ISTM there is the possiblilty bad things could happen, like somebody else getting that same IP and hijacking my HR tunnel.

I could well be missing something, sorry !

No, there isn't a way to tell us your endpoint is going to be unavailable. You cannot set 0.0.0.0 because the system will say "oh, hey, I can't ping that, please try again" because the system wants valid pingable IPv4 endpoints.

[Ninho]

No, there isn't a way to tell us your endpoint is going to be unavailable. You cannot set 0.0.0.0 because the system will say "oh, hey, I can't ping that, please try again" because the system wants valid pingable IPv4 endpoints.

OK, that is as I thought indeed. Hence I am resubmitting my suggestion for your consideration, please add one bit of status for tunnels (ON/OFF) and allow users to set the tunnel state. Would that be complicated, or costly ?

Cheers...

P.S. What if I point my tunnel end to one of Google's IP ? Certainly they answer pings. Just kidding, of coarse...

[snarked]

For those on dynamic IPv4's, that seems to be a reasonable request (and "sleeping" a reasonable state).  However, is it needed?  If your machine isn't going to be reachable for hours at a time, shouldn't you be using a 6to4 tunnel ("2002::/16") instead of a fixed IPv6 allocation?  The main reason to have a fixed address is if one is running server processes, but what good are those if one is offline for substantial periods at a time?  In other words, I can see the reason for the request, but what's the point?

I have a tunnel still allocated, but have native IPv6 support at my co-location facility (and HE is one of the transit carriers).  For a fixed IPv4, all that is needed is to allow the encapsulated traffic (protocol 41), and to respond to an ICMP6 echo-request from the tunnel endpoint's "...::1" with an ICMP6 echo-reply from your tunnel endpoint's "...::2".  My tunnel is active only for these pings.  If I need it again, all I have to do is change one setting plus my forward DNS zones and reboot (only so everything is recognized at once; alot easier than restarting several servers).

[Ninho]

Hello, Snarked ! I'll try to adress your points as much as I can

For those on dynamic IPv4's, that seems to be a reasonable request (and "sleeping" a reasonable state).  However, is it needed?  If your machine isn't going to be reachable for hours at a time, shouldn't you be using a 6to4 tunnel ("2002::/16") instead of a fixed IPv6 allocation? 

Thank you for calling my request a reasonable one ;=)

Using 6to4 with an anonymous PoP (192.88.99.1) is indeed a possibility, but slower than a direct tunnel as M. Broquea has explained in answer to my first post here. OTOH, 6to4 with a tunnel broker (non HE) might require running a client in my OSes (heartbeat, time sync...)  which I'm not willing to do for multiple reasons. I like the simplicity of 6in4, and can take care of the NAT myself.

The main reason to have a fixed address is if one is running server processes, but what good are those if one is offline for substantial periods at a time?  In other words, I can see the reason for the request, but what's the point?

I have a dynamic IP, but which changes seldom, so I can run servers albeit intermittent and (in IPv4) with the convenience of dynamic DNS. I do see potential use for a few out of the bazillion IPv6 addresses newly delegated to me :=)

Really the only (mild) problem I can see ATM is being unable to suspend or let's say hibernate the Tunnel, which I envisage as an enhancement potentially beneficial both to me (the user) and to Tunnelbroker (the provider). ICBW...

I have a tunnel still allocated, but have native IPv6 support at my co-location facility (and HE is one of the transit carriers).

So you're one of those pioneers, congrats ! And thank you for taking the time to help us petit ones.