I like having an IPv6 connection at home, but after running into some weirdness with pfSense 2.1-RELEASE that seems correlated with having the pfSense box as the GIF endpoint / IPv6 router (things would kinda get slow, then eventually sort-of fail) I started looking for other options. I have an Apple AirPort Extreme running in bridged mode which I use to provide wireless access to the LAN, and it has the ability to tunnel out to an IPv6 network, so I decided to set that up†.
However, in the midst of getting this setup I ran into a very frustrating problem: only wireless clients connecting via the AirPort could use IPv6; wired clients wouldn’t work. The problem was my previous observation (and expectation), that turning the AirPort into a bridge would make all ports on the back of the device equal. It does not, and thus I needed to move the wired network connection from the WAN Internet port to one of the three Ethernet ports to have IPv6 work on the wired side.
Contrary to what it says, turning Router Mode to Off (Bridge Mode) doesn’t actually fully bridge; the WAN Internet port remains different from the internal ports. Specifically, the AirPort won’t service Neighbor Discovery Protocol (NDP) requests on the WAN Internet port when in bridged mode. Thus when I had the switch connected to this port wired clients couldn’t get an IPv6 address, couldn’t find the router, and wouldn’t configure IPv6 stack. I suspect that when Apple addressed CVE-2008-2476 via 7.4.1 they did so by wholly blocking NDP on the WAN Internet port and didn’t take Bridge Mode into account.
For reference, here’s the ipconfig output from a Windows 7 client on wired vs. wireless when the wired side was connected to the WAN Internet port:
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : home.nuxx.net
Link-local IPv6 Address . . . . . : fe80::3d96:1dd5:728c:fde3%12
IPv4 Address. . . . . . . . . . . : 192.168.0.162
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
Wireless LAN adapter Wireless Network Connection:
Connection-specific DNS Suffix . : home.nuxx.net
IPv6 Address. . . . . . . . . . . : 2001:470:1f11:d43:ddca:22b9:af55:639e
Temporary IPv6 Address. . . . . . : 2001:470:1f11:d43:e82f:53dc:7af4:940b
Link-local IPv6 Address . . . . . : fe80::ddca:22b9:af55:639e%13
IPv4 Address. . . . . . . . . . . : 192.168.0.147
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : fe80::216:cbff:fec5:162f%13
192.168.0.1
This can be seen in these two network captures: airport_bridged_lie_wired.pcap and airport_bridged_lie_wireless.pcap. These were recorded on OS X using tcpdump when the respective interfaces were down (either unplugged or with the internal wireless disabled), then brought up, then the capture stopped. Captures were then filtered with icmpv6.type == 133 || icmpv6.type == 134 to show only Router Solicitations (133) and Router Advertisement (134) then exported to these libpcap-format files.
In these captures one can clearly see that the wired connection (c4:2c:03:2e:5d:cf) makes some Router Solicitation requests but doesn’t receive a reply, while the wireless connection (d8:30:62:64:f4:ff) receives a Router Advertisement reply to its Solicitation.
After digging into all of this and initially declaring the problem to be wholly with the wired side I thought maybe there’d be a differentiation between the WAN Internet and Ethernet ports. I then tried moving the wired connection to one of the internal / Ethernet ports I was able to get IPv6 NDP responses to wired clients. Thus, Bridge Mode on the AirPort Extreme isn’t quite as bridged as the selection would imply: the bridge is a lie.
A bug (15716120) has been submitted to Apple on this issue.
—
† With an AirPort Extreme serving as an IPv6 tunnel endpoint behind a pfSense NAT device two settings need to be changed in pfSense to get it working. First, System → Advanced → Networking and check Enable IPv4 NAT encapsulation of IPv6 packets and set the IPv6 router’s IP address. This is needed because it’s not possible to add a NAT forward for IP protocol 41. Second, add an inbound firewall rule allowing TCP/IP Version IPv4 and Protocol IPV6. This will allow the tunnel on the AirPort to work.
The IPv6 tunnel is then configured as per the tunnel provider’s directions, which is well-documented elsewhere.
I don’t like opening up all the IPv6 wireless clients on my network to direct connections from the outside, and Apple seems to have figured that others don’t want this as well. By going into the AirPort Extreme configuration in AirPort Utility, selecting Network then Network Options… and checking Block incoming IPv6 connections, all inbound IPv6 connections are blocked and a Port Settings option becomes available allowing individual ports to be unblocked.