In muc.lists.netbsd.tech.net der Mouse wrote:

>[Daniel Carosone <dan@geek.com.au>, replying to me]

>>> I find myself needing to encapsulate IP in TCP, for reasons not
>>> really worth going into here (the principal part is a NAT box whose
>>> configuration is out of my control).
>> Does it have to be TCP?  Could UDP work as well?

>I'm not certain, but I'm inclined to doubt it.  One problem with that
>is telling what addr/port on the NATted end to send packets to,
>especially after idle.

TCP will not *really* save you here.  If the idle period is long enough,
and the NAT device is stupid enough, it might very well time out your
TCP NAT table entry (without telling the endpoints, of course).

Things like Teredo work around NAT-timeouts-with-UDP by sending "bubbles"
in regular intervals.  Like "if the link has been idle for 5 seconds, 
send an encapsulated ICMP echo request to the other side" - the bubbble
period needs to be adjusted to the UDP timeout of the NAT device, of
course.

[..]
>connection back up).  After the second time, I had the NATted machine
>ping the other machine through the tunnel once a minute, which might
>prevent the state loss and even if it doesn't would bring the tunnel
>back up; since then, I've noticed no failures.

That's the same issue, yes.  If you are pinging anyway, using UDP might
be worth a try.  Or even GIF/GRE tunneling, depending on the NAT box's
capabilities (I have a NAT box that understands GRE, but not GIF...).

[..]
>I should look into UDP more; the NAT box is known to keep _some_ state
>for _some_ UDP traffic, so I might be able to make it work.

Yep.  It *has* to keep UDP state, to make things like "RealAudio" work,
which will lead to windows-user complaints if it doesn't work...

gert
-- 
gert@greenie.muc.de   fax: +49-89-35655025   http://alpha.greenie.net/mgetty/

I'm forgiven. My brothers and sisters of the continuum have taken me back.
  I'm immortal again, omnipotent again.
Swell.
                -- Q and Riker, "Deja Q", stardate 43539.1