Well you shouldn't do that, but it certainly shouldn't hang.

There is supposed to be loop detection code in the gif encap, so that
the second encap will simply fail.  See sys/net/if_gif.c, variable
'called' in gif_output and max_gif_nesting.  But, I think this doesn't
work due to queueing soft interrupts for the actual output (which IIRC
the original gif code didn't do).

So, I'd expect the packet to get bigger and bigger with each encap,
and then eventually fragment with the fragments each growing, leading
to a constant queue-full situation which will lead to an mbuf
shortage and perhaps expose a latent bad-things-during-error-returns
situation.  Or perhaps the system is just wedged in gifintr land and
is not actually 'hung', just doing nothing useful.  (I'd be curious if
you can still ping it when it is in this state.)

I'd set breakpoints for gif_output and in_gif_output and then watch a
packet being sent to see if this is indeed what's going on.

Or, force __HAVE_GENERIC_SOFT_INTERRUPTS to be off, so that
gifnetisr() is called from gif_output instead of being deferred.

-- 
        Greg Troxel <gdt@ir.bbn.com>