Today the UK IPv6 Council held their annual meeting. These have been great events for many years (e.g. see 2019, 2018, 2017). Many thanks to Veronika McKillop and Tim Chown for organizing it! In the following I’ll discuss some of the talks (full agenda here).
Colin Donohue & Ian Hallissy: The AIT Experience with IPv6 Only Wifi
Colin and Ian work at the Athlone Institute of Technology (AIT), a technical university in the Irish Midlands with 6000+ students. They started their IPv6 journey back in 2012, and decided to use a 2020 refresh of the Wifi infrastructure to switch from dual stack to IPv6 only incl. the management plane and the control plane. This would allow to easier identify IPv6 issues, to manage one protocol instead of two, and to provide a live IPv6 environment for research, testing and development. Here’s some relevant technical details of their approach:
They implemented the infrastructure with Aruba components (related vendor material with some technical details on the case study here ;-), and the NAT64 function is handled by Fortigate firewalls, with seemingly sufficient performance. With some small exceptions everything could be done in a v6-only way:
Ondřej Caletka from RIPE NCC asked how they (plan to) achieve their stated goal of traceability (e.g. in case of security incidents) given they only use SLAAC (yes, DHCPv6 might not be needed to achieve that objective). They responded that they expect (Aruba) ClearPass to handle this.
Another question was if they had a fallback plan in case some important application didn’t work properly without IPv4. Such a plan does not really exist – their stance was: “if urgently needed, we could add IPv4 on a VLAN basis, but we strive to avoid this”.
Overall a super-interesting presentation which clearly showed, like Jen Linkova’s recent talk at RIPE81, that v6-only Wifi (even for a heterogeneous user base) is doable in 2020.
Slides can be found here.
Pavel Odintsov: DDoS Challenges in IPv6 environment
and how he dealt with those when adding full IPv6-support to the latest FastNetMon community editions.
Slides can be found here.
Sam Defriez: Community Fibre IPv6 Update
This was one of the provider case study talks I really love at the event. Community Fibre is a London-focused (commercial) broadband ISP. The main objective of their IPv6 deployment was simply to avoid spending a fortune on IPv4, but instead use the money on “putting fibre in the ground”, as Sam phrased it. Seems reasonable and much more sustainable to me as well ;-). He discussed a few challenges during their IPv6 implementation, nicely illustrated by this chart:
They do DHCPv6 based on ISC’s Kea which had a few teething problems. Furthermore about 20% of their BNGs didn’t support DHCPv6 relay which was later fixed by Huawei, supposedly due to pressure from another, bigger ISP. Finally they suffered from the Cogent-Google (de-) peering issue (for those not aware of this see this discussion on the NANOG mailing list), which they solved by peering directly with Google.
Slides can be found here.
Erik Nygren (Akamai): CDN Provider’s view of IPv6 in 2020
Erik explained Akamai’s IPv6 efforts and developments since they first enabled it for HTTP traffic back in 2011. He then discussed in which spaces they see below-average IPv6 deployment: enterprise organizations (presumably due to backend systems & supporting processes not being IPv6-ready) and in the gaming industry (probably no incentives to add IPv6 once initial launch was v4-only).
He also mentioned a recent peak of 28 Tbps IPv6 traffic due to a specific event. (I wonder if that one happened in July? 🤔😉). Here are some interesting numbers he showed:
Asked if they see DDoS attacks happening over IPv6 he mentioned that they see a few, but they don’t consider this a relevant issue so far (not least as Prolexic, their DDoS protection service, supports IPv6 now).
Fernando Gont: Deeper dive into the recent Windows ICMPv6 vulnerability
Fernando spoke about CVE-2020-16898, an RCE vulnerability in the Windows 10 IPv6 stack due to (mis-) handling of router advertisements (for the initial Microsoft advisory and some related discussion see here). The details of this vulnerability are quite interesting, and they were laid out in two independent posts, one from Francisco Falcon and the other one from Adam Zabrocki. In a nutshell the underlying problem is incorrect parsing of the (length of the) RDNSS option which in turns leads to improper buffer management. This can only be exploited once the malicious RA is sent heavily fragmented. Such a (fragmented) local ICMPv6 datagram shouldn’t be processed at all if the Windows IPv6 stack correctly implemented RFC 6980, which Fernando authored in 2013 (a related post about the latest Windows IPv6 stack here).
A very similar vulnerability was just recently identified by Francisco Falcon in FreeBSD (see here).
The slides can be found here.
Another great event from the UK IPv6 Council. Apparently 48 people joined, and there were some real good discussions among IPv6 practitioners. I expect the videos to be published soon, and I will update this post once that has happened.
Happy holidays to you all. Stay safe and healthy!