Reflections on the IPv6-only WiFi Experience during Troopers

Hello,

Troopers is (unfortunately) over. It was a blast (but I may be biased ;-))! After things have settled, I want to take the opportunity to reflect my thoughts and impressions on the IPv6-only WiFi we had deployed during the conference. To make sure that everybody is on the same page let’s start at the beginning.

In the last couple of years we had provided Dual-Stack connectivity on the main “Troopers” SSID but also had an additional IPv6-only SSID. This year we decided to spice things up and made the “Troopers“ SSID IPv6-only (with NAT64) while providing Dual-Stack connectivity on the “Legacy“ SSID. We wanted to get a feeling how many clients and applications can work properly in an IPv6-only environment. We intentionally didn’t announce it vastly beforehand, hoping that attendees would just connect to the main SSID without noticing anything. We were aware that some applications might expose issues but, as I said , we wanted to get a feeling to which degree problems actually occured.

In order to make sure that the Wifi networks performs properly, several optimizations were necessary due to IPv6’s heavy reliance on multicast. I won’t cover them in detail here, but if you are interested in the intricacies of IPv6 in Wifi environments, the slides of my IPv6 Security Summit talk covering this topic can be found here.  The following optimizations were done on our WLC to reduce the amount of multicast traffic on the Wifi:

• Neighbor Discovery Caching (enabled in the default configuration)
• RA Throttle

In addition to the optimizations performed on the WLC, I tweaked some RA parameters on our ASR 1002 to further reduce the chatter of IPv6. The values I used were suggested/mentioned by Andrew Yourtchenko in several Cisco Live presentations he gave on the topic. Thank you!

Here’s the configuration of the respective interface on the ASR

interface GigabitEthernet0/0/0.30

 description ====TRP-NAT64===

 ipv6 address FE80::1 link-local

 ipv6 address 2A02:8071:F00:64::1/64

 ipv6 enable

 ipv6 mtu 1280

 ipv6 nd reachable-time 900000

 ipv6 nd other-config-flag

 ipv6 nd router-preference High

 ipv6 nd ra solicited unicast

 ipv6 nd ra lifetime 9000

 ipv6 nd ra interval 4

 ipv6 nd ra dns server 2A02:8071:F00:64::251

 ipv6 dhcp server DHCP-TRP-NAT64-v6-POOL

 nat64 enable

 

The highlighted parameters were explicitly configured to reduce the amount of multicast on the WiFi side.

The first one (ipv6 nd reachable-time 900000) was configured to tweak how long the neighbor cache entry for the default gateway will stay in the reachable state (on the connected clients) in order to reduce the traffic induced by NUD (Neighbor Unreachability Detection). The reachable time is configured in milliseconds (so the above value equates to 900 seconds) on the ASR.

The second parameter (ipv6 nd ra solicited unicast) was recently introduced for IOS/IOS-XE based devices (it has been available on NX-OS for quite a while). As the name of the command implies, when the router receives a router solicitation from a newly connected client, it will not send out a multicast RA in response but will send an unicast RA to the requesting client which further reduces the amount of multicast traffic.
See also RFC 4861, section 6.2.6, where it’s stated: “A router MAY choose to unicast the response directly to the soliciting host’s address (if the solicitation’s source address is not the unspecified address), but the usual case is to multicast the response to the all-nodes group.”

The third and last one (ipv6 nd ra lifetime 9000) increases the lifetime of the RAs to 9000 seconds. This was done so that I could configure a tighter RA Throttle to even further reduce the amount of multicast traffic.

Coming back to the overall “user experience” of the IPv6-only SSID:

I am pretty satisfied with the overall results. I myself was associated to it approximately 80% of the time during the whole week. As we have a dedicated SSID and prefix for the management of our infrastructure, I spent the remaining 20% there in order to check that everything was running smoothly :-). The stats from our monitoring solution (a detailed blogpost as well as the configs will follow shortly) supported my impression. Looking on the stats for Wednesday:

we can see that approximately 40% of all connected clients used the Troopers SSID. I consider this a huge success and I am very happy about these figures. Compared to 2014, when we had a total of 33 connected clients to the IPv6-only SSID, this is a significant increase. Hopefully the numbers will climb even more in 2017 ;-). Next year I want to take it a step further and also deactivate the legacy protocol in our management network!

Evidently there were some applications that didn’t work properly in the v6-only SSID. Ivan Pepelnjak (@ioshints) was so kind and provided me his experiences:

• The Dropbox client didn’t work in the IPv6 only SSID.
• The Apple mail client didn’t work for him on his Mac.

Another attendee mentioned that he had problems with the British Airways app when he wanted to check-in for a flight. That’s all we heard; please let us know your observations and/or issues.

Again thank all of you who used the SSID extensively during the week and hopefully we will meet again in Heidelberg in 2017!

Do you have experiences you want to share? Please leave a comment or contact me on Twitter.

Happy Easter everybody!

Cheers,

Chris