Following my work with the FreeBSD implementation of RFC 6980 I was happy to present my work at last week’s DENOG 9 meeting.
To make it available to anyone who did not meet me there and go into some more detail that would have exceeded the boundaries of the talk, I will cover the topic here.
Looking at IPv6 deployment graphs like this one it becomes clear that IPv6 still is not widely deployed in enterprise space (the reason for the apparent oscillation in that curve is the difference between working days – where people use their office computers – and weekend where they preferably use their smartphones or their home equipment connected by means of broadband networks).
A while ago I wrote a short paper laying out options for an enterprise organization to get global IPv6 address space from the RIPE NCC, discussing the advantages and disadvantages of different approaches. As I think the topic may be of interest for others, too, I’ve distilled an anonymized version. It can be found here. I hope some of you find it useful.
Last week I had the pleasure to participate at the first RIPE IoT Roundtable Meeting in Leeds (thanks! to Marco Hogewoning for organising it). It was a day with many fruitful discussions. I particularly enjoyed Robert Kisteleki‘s talk on RIPE NCC’s own design & (security) process considerations in the context of RIPE Atlas (at TR17 NGI there was an intro to Atlas, too).
In this post I’d like to quickly lay out the main points of my own contribution on “Balanced Security for IPv6 CPE Revisited” (the slides can be found here).
As you may remember, back in 2014 we published a whitepaper (compiled by Antonis Atlasis) on the support of IPv6 in different pentesting tools. This is almost three years ago and we thought it is time for an update. In short not much has changed. Most of the tools which didn’t support IPv6 are still not supporting it or haven’t got any update since then.
This post will cover the tools where we could identify some progress on supporting IPv6.
Just recently we discussed IPv6 filter rules for NIC-level firewalls (in a virtualized data center) with a customer. I’d like to take this as an opportunity to lay out potential approaches for local packet filtering of IPv6, which in turn might somewhat depend on the address configuration strategy chosen for the respective systems (for the latter you may refer to this post or to this talk from the Troopers NGI event).
I’m on my way back from the RIPE74 meeting in Budapest. It was a great event: quite a few nice technical talks in the plenary, productive working group meetings and some really good hallway discussions.
Big thanks to the RIPE NCC team for the smooth organization and for taking care of us!
It is a pleasant surprise for many (us included) that Microsoft implemented support for the RDNSS (RFC 8106) option in Router Advertisements beginning with the Windows 10 Creators Update. Interestingly, I wasn’t able to find any official documents from Microsoft stating this. As we are involved in a lot of IPv6 related projects for our customers, the lack of RDNSS support for Windows and DHCPv6 for Android is a major pain point when implementing IPv6 in mixed client segments, as you need to implement both mechanisms to ensure that all clients do get the relevant network parameters. I won’t beat on the dead horse, but Microsoft’s decision is a huge step in the right direction and one can hope that one day Google finds a “compelling use case” to implement at least stateless DHCPv6 for Android. Continue reading “One Step Closer – RDNSS (RFC 8106) Support in Windows 10 Creators Update”