Hi,

On Mon, Nov 06, 2006 at 08:42:54PM -0500, Thor Lancelot Simon wrote:
> On Mon, Nov 06, 2006 at 11:12:02PM +0100, Gert Doering wrote:
> > 
> > While at it, the gre(4) man page needs serious rework - the configuration
> > example actually *suggests* that it might be a fairly normal thing to have 
> > the same IP address for "tunnel inside destination" and "tunnel outside
> > destination":
> 
> It was probably copied from the gif(4) manual page.

Yes, looks very much like it.

> I doubt it matters much for gre, but if this configuration stops working
> with gif, it will become _impossible_ to talk to IPsec peers which do not
> implement transport mode.

Is this for IPsec tunnel mode, implemented somehow via gif(4)?

If yes, it might be worth mentioning this in the gif(4) manpage :) - as
far as I understood it, I assumed gif(4) only did unencrypted IPv4/IPv6
over IPv4/IPv6 tunneling:

------------- snip --------------
DESCRIPTION
     The gif interface is a generic tunneling pseudo device for IPv4 and IPv6.
     It can tunnel IPv[46] traffic over IPv[46].  Therefore, there can be four
     possible configurations.  The behavior of gif is mainly based on RFC 2893
     IPv6-over-IPv4 configured tunnel.  gif can also tunnel ISO traffic over
     IPv[46] using EON encapsulation.
------------- snip --------------

> I believe we don't run into the recursion with gif because of the (rather
> frightening) way packets actually are fed into gif for encapsulation in
> the IPsec case.

How exactly does this work?

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-35655025                        gert@net.informatik.tu-muenchen.de