On Wed, Sep 29, 1999 at 11:22:53PM +0900, itojun@iijlab.net wrote:
> 
> >We have set up an IPv6 only network. To get IPv4 connectivity between
> >two machines I used an IPv4 over IPv6 gif tunnel. Both machines run
> >route6d, one listens only the other advertises routes. I noticed 
> >something strange. After initial tunnel setup I lost all IPv6 
> >connectivity (from the machine with the listening route6d). 
> >
> >Looking at the routing table it seemed the machine had received
> >IPv6 route updates from the other side of the tunnel, i.e. over
> >IPv4. The machine effectively had all its IPv6 routes pointing
> >over the IPv4 tunnel now, instead of over the IPv6 Ethernet.
> 
> 	Could you please supply your network diagram.
> 	I'm not sure if I understand your problem correctly,
> 	Do you have IPv4 over IPv6 tunnel, or IPv6 over IPv4 tunnel.  Your
> 	text has both of them. (first paragraph says IPv4 over IPv6, and
> 	next paragraph says IPv6 over IPv4)

Ok, it's a IPv4 over IPv6 tunnel. The Ethernet between the two
machines carries *only* IPv6 packets. The IPv4 traffic is encapsulated
in IPv6 packets. I'm very bad at drawing stuff, so I'll add some
config output:

[  zila  ]                       [ server6 ]
    |                                |
    |                                |
    |<=====IPv4 over IPv6 tunnel====>|
    |                                |
    <--------IPv6 Ethernetworks------>   (i.e. zila and server6 are not on same link)

zila's ethernet interface config:

100 zila:~> ifconfig ex0
ex0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        media: Ethernet autoselect (10baseT)
        status: active
        inet6 fe80:1::250:4ff:feec:b1fa prefixlen 64
        inet6 3ffe:2a00:100:3004:250:4ff:feec:b1fa prefixlen 64

zila's tunnel config:

95 zila:~> gifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
        inet6 fe80:5::250:4ff:feec:b1fa  prefixlen 64 
        inet 192.168.2.2 --> 192.168.2.1 netmask 0xffffff00 
        physical address inet6 3ffe:2a00:100:3004:250:4ff:feec:b1fa --> 3ffe:2a00:100:3001::2

server6 tunnel config:

gif4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
        inet6 fe80:d::2c0:4fff:fed9:226d prefixlen 64 
        inet 192.168.2.1 --> 192.168.2.2 netmask 0xffffff00 
        physical address inet6 3ffe:2a00:100:3001::2 --> 3ffe:2a00:100:3004:250:4ff:feec:b1fa

partial routing table on zila (without the problem described):

96 zila:~> netstat -rn|more
Routing tables

Internet:
Destination                  Gateway                    Flags     Refs Use    Mtu  Interface
default                      192.168.2.1                UGS         8 14400   1280  gif0
127.0.0.1                    127.0.0.1                  UH          0 333673  32976  lo0
192.168.2.1                  192.168.2.2                UH          1 4   1280  gif0

Internet6:
Destination                  Gateway                    Flags     Refs Use    Mtu  Interface
::1                          ::1                        UH          0 0  32976  lo0
3ffe::/24                    fe80:1::250:73ff:fe05:baf2 UG          0 0   1500  ex0 =>
3ffe::/16                    fe80:1::250:73ff:fe05:baf2 UG          0 6   1500  ex0
3ffe:100::/24                fe80:1::250:73ff:fe05:baf2 UG          0 0   1500  ex0
<snip>

> >So, it seems to me that route6d assumes that when it receives
> >route updates over an interface, that interface provides connectivity
> >for both IPv4 and IPv6 (and/or the sending route6d makes a similar
> >assumption). I haven't tried whether route6d behaves in a similar
> >way with 2 Ethernet interfaces; one IPv6 only, and one IPv4 only.
> 
> 	If you receive route update over IPv6 over IPv4 tunnel, that will
> 	be put onto IPv6 routing table as a route over the tunnel.  This is
> 	what route6d is for.

What I saw, was that all routes in the IPv6 routing table changed from
pointing over the ex0 interface, to the gif0 interface. So, zila tried
to send (native) IPv6 traffic over the IPv4 over IPv6 tunnel, instead
of routing the IPv6 traffic directly over the ex0 interface. At least
that's what i believe happened. At the time I wasn't very eager to
reproduce the problem. I had to kill route6d, flush the routing table
and restart it with `-N gif0'.

Feico.