gre encap destination = point-to-point destination

On Sat, Nov 04, 2006 at 10:26:51AM +0000, Michael van Elst
wrote:
> dyoungpobox.com (David Young) writes:
> 
> >gre5006:
flags=d051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu
1476
> >        tunnel inet 10.0.0.1 --> 10.0.0.2
> >        inet 10.0.0.3 -> 10.0.0.2 netmask
0xffffffff
> >        inet6 fe80::a00:20ff:fef9:60ee%gre5006
->  prefixlen 64 scopeid 0x112d
> 
> >Can anybody explain, what is use such a
configuration as above?  Is there
> >no other way to create a similar network?
> 
> Maybe 10.0.0.1 -> 10.0.0.2 is a point-to-point route
itself or
> the network filters other addresses? Then you have to
tunnel
> other addresses and this is one method to avoid
additional
> addresses on the target.

This sounds like a hypothetical example.  I am want to ehar
from people
who are personally invested in this quirk of gre(4)
operation, so that
I can understand why before I change it.

> What exactly is the problem with this configuration?

NetBSD will install a route to 10.0.0.2 that points at the
tunnel
pseudo-interface.  Thus, if you send a packet to 10.0.0.2,
it ought to go
through the tunnel.  The encapsulated packet, whose
destination is also
10.0.0.2, ought to go through the tunnel again.  The
doubly-encapsulated
packet, too, will go out the tunnel again.  That is, a
reasonable
interpretation of this configuration is that it leads to
recursion.
In fact, the same configuration of a gif(4) tunnel does lead
to recursion.
Where gif(4) detects the recursion and drops the packet,
gre(4) fiddles
with the routing lookup to break the recursion, leading to a
surprising
and somewhat arbitrary routing of the encapsulated packet.

Dave

-- 
David Young             OJC Technologies
dyoungojctech.com      Urbana, IL * (217) 278-3933