When configuring 6to4 IPv6 tunnelling, an unreachable route should be added for the 2002:WWXX:YYZZ/48 network, which is expected to be available _behind_ the IPv4 address ww.xx.yy.zz. Without this, packets received for anything in that network will be routed immediately back _out_ the tunnel, triggering urgent kernel warnings about the broken routing: redirect: no link_local addr for dev Dead loop on virtual device tun6to4, fix it urgently! Add somewhere the line: ipv6_exec_ip route add unreach ${ipv6to4prefix}::/48 Also, the division of this /48 into subnets for each interface is duplicated, between the IPV6TO4_ROUTING variable in /etc/sysconfig/network-scripts/ifcfg-ippp0 (for example), and /etc/radvd.conf. Setting up only the latter left me with radvd advertising addresses on those subnets, but without the system having _routes_ to them. Pinging the main IPv6 6to4 address of the system from one of the internal clients then causes an immediate crash.
Thanks for the report. The first issue seems to be very valid, will fix ASAP. The second issue seems to be caused by poor documentation; I think the correct remedy is to enhance ipv6-6to4.howto a bit on how to use IPV6TO4_ROUTING (as radvd and initscripts are really two different beasts). Will do.
Adding routes in IPV6TO4_ROUTING works only for one of my three interfaces. The internal Ethernet eth0 is fine -- PCMCIA wavelan and the bridge for bluetooth don't get their routes added since they're brought up later (not that radvd on the bridge works anyway -- cf. #103469) I'm going to assign static addresses for them since my IPV4 address is static. Perhaps each _interface_ should have an IPV6TO4_PREFIX and get its IPv6 address in its _own_ scripts, rather than having it done from the main IPv4 ifup script?
The simplest fix in this case would be to ensure that the wlan/bluetooth interfaces are up and running when 6to4 startup is initiated. Not sure if that's doable, but could be. The prefix/suffix point is more generic than just 6to4. It would be useful to be able to specify the prefix (and length) somewhere (in _one_ place), and use it as a basis to build the addresses based on the prefix. Note also that this model would have to support the scenarios (E.g. 6to4) where the prefix is not explicitly configured, but is changing.. That way, when changing the prefix/suffix, one would only have to change it in one place. But this is a bigger change that needs more thinking, clearly out of scope for this timeframe.
Initial issue fixed in cvs, should be in 7.31-1 or later.
Closing based on the initial issue; please reopen further bugs for more issues.