Problems with IPv6 specific routes

From FreeMesh
Jump to: navigation, search


Problems with IPv6 specific routes advertised via SLAAC

This issue has been seen on: MacOS Sierra (10.12), iOS 10, Ubuntu Linux 14.04LTS (Linux kernel 3.13)
Confirmed working: Ubuntu Linux 16.04LTS (Linux kernel 4.4)

This document aims to explain for gateway maintainers in the Freemesh/Freifunk networks, why they may see problems for users, when it comes to IPv6

Sometimes advertising a default route via Route-Advertisements (SLAAC) is not suitable for networks, when there is no access to IPv6 portion of the internet. So depending on the gateway you're using, you may or may have Internet IPv6 access (all freemesh.ie gateways currently support Internet via IPv6, so this is not an issue here).

If the radvd.conf on the gateway contains the following line:

 AdvDefaultLifetime 0;

Your gateway will not provide you with a generic default route. In the case of freemesh.ie, we're also advertising the specific route for the freemesh network:

 route 2a0a:5780:f000::/40
 {
   AdvRouteLifetime 1200;
 };


The issue, that now has cropped up, is that the above operating systems don't seem to have support in the kernel for these route objects. An easy way to test it is to tcpdump for the icmp6 packets while connecting to the network.

 tcpdump -vvvv -ttt -i wlan0 icmp6 and 'ip6[40] = 134

The output should look something like this:

   00:00:00.616890 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 136) fe80::4490:3ff:fe8d:8f83 > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 136
       hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 0s, reachable time 0s, retrans time 0s
         prefix info option (3), length 32 (4): 2a0a:5780:f000::/64, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s
           0x0000:  40e0 0001 5180 0000 3840 0000 0000 2a0a
           0x0010:  5780 f000 0000 0000 0000 0000 0000
         route info option (24), length 24 (3):  2a0a:5780:f000::/40, pref=medium, lifetime=600s
           0x0000:  2800 0000 0258 2a0a 5780 f000 0000 0000
           0x0010:  0000 0000 0000
         rdnss option (25), length 24 (3):  lifetime 200s, addr: 2a0a:5780:f000::1
           0x0000:  0000 0000 00c8 2a0a 5780 f000 0000 0000
           0x0010:  0000 0000 0001
         mtu option (5), length 8 (1):  1380
           0x0000:  0000 0000 0564
         source link-address option (1), length 8 (1): f2:15:0c:21:6b:f5
           0x0000:  f215 0c21 6bf5

The interesting part here is:

         route info option (24), length 24 (3):  2a0a:5780:f000::/40, pref=medium, lifetime=600s
           0x0000:  2800 0000 0258 2a0a 5780 f000 0000 0000
           0x0010:  0000 0000 0000

In the case where it isn't working, we've seen this output:

         unknown option (24), length 24 (3): 
           0x0000:  2800 0000 0258 2a0a 5780 f000 0000 0000
           0x0010:  0000 0000 0000

And the only route, that is accepted, is the default route .. if the radvd is providing that.

A workaround would be to add manual routes to the network profile for that specific network. Not pretty, but workable for now.