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)


  • 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?

  • Given that your issues stem from using the Time Capsule as your wireless router, what Firmware version is that running and when you say the config was working do you mean this precise setup with all components at the current revisions worked? – Helvick Nov 13 '10 at 19:02
  • Firmware is 7.5.1. I was in fact quite happy when I switched from the Netgear to the TC precisely because I saw the NSLU2 RAs cross the TC LAN bridge. The only difference is that I actually used 6to4 for some time (a few days), until 10.6.5 started favoring IPv4 over IPv6 if one uses 6to4, whence I decided to switch back to Sixxs. – Lloeki Nov 22 '10 at 11:22

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.

| improve this answer | |
  • No such setting. Why would it protect across the brigde, but not on each interface (wired clients see everything on the wired side, and same for the wireless side)? – Lloeki Jan 24 '11 at 19:16
  • I followed your advice and created a working Hurricane Electric tunnel, which also has the property to ping the IPv4 endpoint for liveliness (thus not requiring to disable IPv6 firewall), and provides a web API to update the IPv4 endpoint, scripted on the NSLU2. – Lloeki Jan 24 '11 at 19:19
  • It's probably implementing the filtering in software, and the wired ports are all attached to a separate bridge chip. So, the software only sees (and can filter) frames when it's bridging them between wired and wireless, not within the wired bridge or the wireless AP. – Ben Jencks Jan 29 '11 at 22:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.