I know that the content of this entry is common knowledge among certain circles, especially after an email to van Hauser of The Hackers Choice (THC), and some time spent this afternoon checking out a few mailing lists.

However this is not who I'm aiming this post at. Or that's what I'm telling myself so that I don't feel like I've wasted a few hours of my life over the course of 2 days. This post is aimed at those who do not have a large amount of experience with IPv6, be it system or network administrators, or just general passers by. Or people on facebook, where this will end up being syndicated.

If you want to skip this ridiculously long post, and check out the extremely quickly hacked together proof of concept code, head to github.com/theangryangel/deprecate-ipv6-slaac.

I'll start off with a quick bit on IPv6 address configuration. In comparison to IPv4, there are 2 ways to dynamically configure an interface with an address. Stateless Address AutoConfiguration (commonly called SLAAC), and DHCPv6. Both SLAAC and DHCPv6 require a router to be sending out multicast packets (called Router Advertisements, or RAs), stating what prefix(es) the router is capable of routing, what length these prefixes are, and a bunch of other details. For the purposes of the rest of this post I'm going to focus on SLAAC.

SLAAC addresses have 2 lifetimes attached to them; “preferred” and “valid”. Once an address has a preferred lifetime of 0, only pre-existing network traffic may use this address. Any new traffic MUST use a different one. The address is then marked as deprecated until the valid lifetime reaches 0, at which point the device must remove the address.

Now the clever guys and girls behind the relevant RFCs designed it so that any changed options between RAs for a prefix being used by a device, such as lifetime, must be honored when different from those previously collected. The only special case is that the valid lifetime cannot be set below 2 hours.

If you're following you should see that there's a very simple way of changing the values for many of the settings.

This isn't the biggest issue in my opinion - mostly because RAs are here to stay. That's been made abundantly clear in the last few years. There is a potential fix with SEcure Neighbor Discovery (SEND) (see RFC3971), but that in itself has other issues.

No, the big issue as I see right now is down to how the current tools we use to manage IPs display this information on desktop, server and embedded operating systems. All of the more commonly used tools and places that most sysadmins interrogate, state nothing about an IP being deprecated. Until an address has reached a valid lifetime of 0, the address is still displayed. It is not until you get down into lesser used components of some network tools, that you can see the state of these addresses. All the major OS’ that I played with have this problem. Windows ipconfig, and GUIs say nothing about addresses being deprecated, and ifconfig on all the unix-likes that I've played with also have the issue. However, if you get down into netsh or ip for example, then you will see the state. Even then it's not displayed under the commands that you would generally use.

This means that for all intents and purposes, with the right administrative team who doesn't know IPv6 well enough, you can knock out parts of an IPv6 network, causing it to fall back to other prefixes, or IPv4. If you've managed to MITM, or otherwise exploit IPv4, then you're laughing.

The sheer number of administrators who are not knowledgeable enough about IPv6, and the number of networks that are driving to be dual stacked, it has to make you wonder - what's the opportunity here? For the naughty people, obviously…

What about RA guard (RA equivalent of DHCP guard)? Fragment the packets and you've basically negated RA guard. I've only had the opportunity to test this on a few implementations, but it looks like THC are way ahead of me on this one. Other than that, SEND (which has no support anywhere effectively), and MAC filtering on switch ports I can't immediately see any other methods of mitigation.

If you're interested I've published a simple proof of concept tool, using Scapy, on github.com/theangryangel/deprecate-ipv6-slaac. It has 2 modes of operation; manual and fully automatic. Manual, where you must provide all the details of your target network's router, so MAC address, link local IPv6 address, prefix and so on. Automatic, where it will listen for the first RA and then steal all the information from that packet, and then send out on your behalf.

The proof of concept is very noddy and will fall over. It's written and tested under Linux only.

Next on my play list is DHCPv6 and DHCPv6-PD next. Thinking there's some fun to be had with the RECONFIGURE part of the protocol.