Router advertisements do not go through wired/wireless bridge

bridgeipv6routerwifi

The full setup:

  • A Netgear CVBG834G cable modem+router (4*Ethernet+WiFi)
    • configured in bridge mode (and WiFi shut down)
    • whose sole role is to serve a public IPv4 address on its LAN port to…
  • an Apple Time Capsule:
    • providing a WiFi AP
    • set up as the usual WiFi+Ethernet LAN bridge
    • NAT'ing aforementioned public IPv4 to said LAN
    • handing out DHCP IPv4 leases to the LAN bridge
  • a Linksys NSLU2 with Debian Lenny:
    • wirely plugged into the back of the Time Capsule
    • managing a Sixxs IPv6 tunnel
    • handling openvpn TAP connections over UDP (tap0) and TCP (tap1)
    • bridging its eth0 with tap* interfaces into br0
    • advertising a Sixxs /64 prefix on br0 via radvd
    • having an IPv6 from said prefix statically assigned to br0
  • a bunch of Apple machinery (3*Macs, 2*iPhones, 1* iPad)

The problem:

Wireless IPv6 clients do not receive an IPv6 address. If plugged via Ethernet to the back of the Time Capsule, the same clients do receive an IPv6 address and router configuration, and are able to ping6 and browse IPv6 sites.

Diagnostic steps:

  • 'radvdump' when ssh'd on the NSLU2 shows proper RAs
  • when associated with the AP:
    • NSLU2 can be ping6'd with its link-local address
    • if given any static IPv6 address from the advertised /64 prefix, NSLU2 is ping6'able
    • 'sudo tcpdump -i en1 icmp6' shows boatloads of RS from all the machinery but not a single RA
  • while plugged in via Ethernet 'sudo tcpdump -i en0 icmp6' shows RAs but no RS (except of course the plugged-in computer)

Conclusion:

  • Router Advertisements and Router Sollicitations do not cross the Time Capsule's LAN bridge.
  • Everything else does (including ICMPv6 and IPv6)

Historical facts:

  • the Time Capsule is a drop-in replacement for a DDWRT-enabled WRT54Gv5 (whose hardware became gradually unreliable), and with which the whole setup was perfectly working.
  • given the WRT unreliableness, an experimentation has been conducted to ditch it at no cost by using only the Netgear as a modem+router+AP. The very same problem showed up, thus finally reverting temporarily to the working WRT setup, while waiting for the TC.
  • right after really ditching the WRT in favor of the TC, I experimented with 6to4 set up on the TC, but it is suboptimal for a variety of reasons: RTTs are bad, cable WAN IPv4 is actually dynamic, and Mac OS X 10.6.5 now prioritizes IPv4 over 6to4.
  • the setup actually worked for quite a while
  • stopping radvd on the NSLU2 and using 6to4 through the TC currently works on both wired and wireless (I see RAs on both links) but as said before is widely suboptimal.

Note: I found only few references of people experiencing similar issues with radvd and manually built bridges (openwrt, even solaris)

So, ideas?

Best Answer

I suspect the TC is intentionally filtering RAs to prevent misconfigured Windows hosts (Connection Sharing turned on) from hijacking traffic and either providing suboptimal or completely broken routing. I don't have a TC/airport extreme handy, but there might be a setting somewhere to turn it off (might be called RA Guard, IPv6 antispoofing, or something like that). Otherwise, you're probably out of luck.

An alternative would be to use a tunnel broker with straight 6in4 encapsulation; the TC supports it with "Tunnel" mode IPv6. You could set up a www.tunnelbroker.net tunnel, statically configure it on the TC, and have a script hit the appropriate URL to update your IP whenever it changes.

Related Topic