In muc.lists.netbsd.tech.net Michael van Elst wrote:

>dyoung@pobox.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?

>What exactly is the problem with this configuration?

"Where do you send packets to 10.0.0.2 to"?

Sending through the tunnel (where the "inside" route points to) will
lead to infinite recursion.  

Sending them via "outside" routes will mean "you can't ever reach the
inside point-to-point address of your tunnel peer via the tunnel".

One *could* solve that by sort of attaching flags to the packet that tell
the routing logic "I have been inside gre5006, do not consider gre5006
for further routing lookups", but that sounds massively ugly.

My vote would be to disallow such configurations - log a warning, and
set the tunnel interface to "DOWN".


Besides that: David, could you go into a bit more details about your
great GRE rewrite?  I don't claim to understand all the kernel IP 
routing / interface details - but I'm always interested in IPv6-related
work, and GRE tunnels are useful :-)

gert
-- 
I've got a signature breakdown! Anybody got a spare one?

Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-3243328                         gert.doering@physik.tu-muenchen.de