Bug 103468 - No unreachable route for IPv6 6to4 subnet.
No unreachable route for IPv6 6to4 subnet.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux Beta
Classification: Retired
Component: initscripts (Show other bugs)
beta1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-31 11:30 EDT by David Woodhouse
Modified: 2014-03-16 22:38 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-22 15:51:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2003-08-31 11:30:34 EDT
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.
Comment 1 Pekka Savola 2003-09-01 01:50:55 EDT
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.
Comment 2 David Woodhouse 2003-09-01 03:27:57 EDT
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?

Comment 3 Pekka Savola 2003-09-01 06:30:50 EDT
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.
Comment 4 Bill Nottingham 2003-09-03 19:16:24 EDT
Initial issue fixed in cvs, should be in 7.31-1 or later.
Comment 5 Bill Nottingham 2005-02-22 15:51:53 EST
Closing based on the initial issue; please reopen further bugs for more issues.

Note You need to log in before you can comment on or make changes to this bug.