Given that Enno and I are network geeks, and that I am responsible for setting up the Troopers Wifi network I was curious which components might be used at Cisco Live and which IPv6 related configuration was done for the Wifi network to ensure a reliable network and reduce the chatty nature of IPv6. Andrew Yourtchenko (@ayourtch) already did an amazing job last year at Cisco Live Europe explaining in detail (at the time session BRKEWN-2666) the intricacies of IPv6 in Wifi networks, and how to optimize IPv6 for these networks. He was also a great inspiration for me when setting up the Troopers Wifi network a couple of weeks later. Thank You!
Coming back to the Wifi setup this year, there are two SSIDs available, one of which is an experimental IPv6-only SSID which leverages NAT64 to access IPv4 resources. However I connected to the “normal” dual stack SSID and looked around to see what I could observe by just passively listening for ICMPv6 packets received by my laptop.
Something that immediately caught my attention was that Router Advertisements were sent in a pretty short interval of three seconds. I didn’t understand it at a first glance as usually the goal is to reduce the chatty nature of IPv6 (and hence, maybe, go with a quite long RA interval). After examining the Router Advertisements in detail I found out that they are sent – of course! – to ff02::1, BUT looking closer at the data-link layer, they were actually sent to the unicast MAC address of my laptop’s interface. I am not 100% sure how this was achieved. Initially we assumed that sth like “IPv6 nd ra solicited unicast” (see slide #28 in the CLEUR 2014 session linked above) on the corresponding L3 interface somewhere was in place, but there’s two other facts which contradict this assumption:
- these weren’t RS triggered Router Advertisements but periodically sent ones.
- looking at other traffic apparently ALL traffic to ff02::1 was “converted” to unicast MAC addresses.
To be honest, right now we have no idea which feature or configuration led to the above behavior. Looking forward to ask Andrew for details in the BRKEWN-2006 session on Wednesday, provided he’s willing to share those ;-).
Another thing I noticed was that neither the M nor the O flag were set. I assume that the DNS server provided by the legacy protocols’s DHCP implementation was used for resolving AAAA records. At least I couldn’t find any DHCPv6 packets sent from my client (which makes sense taking the [lack of] corresponding RA flags into account).
Talking about RA flags, we furthermore noticed, a bit to our surprise, that no (high) “router-preference” was configured.
I also observed that the L-bit in the prefix information option was not set. When the L-bit is cleared, the clients do not install a route for the prefix in the local routing table which basically means that every packet (even the packets destined to clients on the same link) will be forwarded to the first hop router. We’ll have a closer look at this tomorrow… for example it will be interesting to see whether ICMPv6 redirects appear once we try to reach each other. Btw, Ivan Pepelnjak is going to discuss this stuff in his upcoming “IPv6 Microsegmentation Done Right” talk at the IPv6 Security Summit as well.
Besides the aforementioned configuration parameters, the router lifetime was set to 9000 seconds and the reachable timer was set to 3600 seconds (more precisely: 3600000 ms). The reachable timer specifies how long the entry of the first hop router stays in the reachable state in the neighbor cache of the clients, effectively reducing the NUD induced chattiness. We have some ideas as for the first-hop redundancy (FHRP) approach in place, but will have to reflect about this in a bit more detail (there might be a follow-up post then).
I also discovered that the “Wireless Client Isolation” feature (which prevents peer-to-peer communication) was not enabled. Looking at some legacy IP (read: IPv4) packets it seemed that about 4000 devices were active in the legacy /17 at the time… will be interesting to see how many it will be tomorrow. Based on further observations I assume that at least four WLC 5508 are used in the conference network.
The Wifi network was pretty stable the whole day and I didn’t experience any connectivity issues. So obviously the Cisco NOC crew did an awesome job. I hope it will stay that way the whole week. Thank you all!
Cheers,
Christopher