IPv6 Focus Month: Addresses

Published: 2013-03-04
Last Updated: 2013-03-04 17:09:40 UTC
by Johannes Ullrich (Version: 1)
7 comment(s)

I would like to start our focus month with a simple post about what many consider the IPv6 killer feature: Addresses. There are a number of issues that come up with addresses, and you need to understand them when you deploy IPv6.

First of all, the IPv6 address is 128 Bits long. But unlike for IPv4, subnetting is a bit more restricted. The first 64 bits specify the network, while the second half of the address identify the host. Other then in a few, very specific cases (e.g. P2P links), you will never see a subnet smaller then a /64.

Here, I would like to focus on different ways to come up with the last 64 bits. There is a reason we have so many bits. The goal is to allow each host to configure itself without running into any conflicts. The simplest way to do this on ethernet is to derive the "interface id" from the MAC address. The mac address is only 48 bits, and it has to be unique for each host on the local network. As a result, we can just use these 48 bits as our interface ID. This works really nice, but has privacy implications: You will now pass your MAC address to each host you communicate with, and this part of the IP address will never change even if you move to a different network.

To respond to this we do have privacy enhanced temporary addresses. In this case, an address is picked randomly, and once a day the host will pick a new random interface ID. Chances of an overlap are pretty small and the host will check if the new address is already in use.

These methods don't require any infrastructure. A router will advertise the network part of the address, and the hosts will just "pick" the interface part using their prefered mechanism. But for us security people, the scary part is that there is no logging happening. We can't show who owned what address when. In particular the idea of temporary addresses is quite scarry for an enterprise network.

The solution, just like in IPv4, is DHCP. DHCPv6 can be used just like in IPv4 to assign addresses. However, if you try to achieve some kind of accountability, you have to make sure that these are the only addresses used. For example, you could use a firewall to restrict network access to allow only access from addresses within the valid DHCP range.

Of course, users could always manually configure an address within the range that is valid on your network, just like they could in IPv4. In IPv6, this is a bit easier as you have more addresses to pick from. You probably would like to have some form of passive system to monitor for new IPv6 addresses. However, in IPv6, you can not use ARP traffic. IPv6 replaces ARP with Neighbor Discovery (ND) and you need to find a tool that supports ND.

Here are a couple of guidelines:

- For an "unmanaged" network (home network, guest wifi), autoconfigured privacy enhanced addresses are probably what you want.
- For a "managed" network (business, enterprise...), you should still use DHCP or static configured addresses just like in IPv4.
- the basic attacks are still the same in IPv6, nothing really changed. IPv6 has an option called SEND to make ND and router advertisement more secure, but the protocol isn't implemented in any of the major OSs yet.

Vulnerabilities and Attacks:

The ND protocol is subject to many of the same attacks as ARP:

- ND spoofing to play MitM attacks
- Denial of service attacks by responding to all ND requests
- address spoofing

The "THC IPv6 Tool Suite" has implementations for many of these attacks. We will talk about this suite in a future "Focus Month" diary, as well as about scapy, probably the most powerful tool to create IPv6 traffic.

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

7 comment(s)

Comments

Thanks for mentioning DHCPv6 on managed networks. Almost every time I have mentioned DHCPv6 I have gotten jumped on by people saying that there is no need for DHCP in IPv6 because of all of the nifty auto config options in IPv6 and that I should embrace the new IPv6 way of doing things and not stick to the outdated IPv4 way of thinking.
yes, IPv6 having all those "nifty auto config options" was a rather good idea for the home network, but in any sort of managed company/corporate network, one does not really want the devices bargain among each other for their network capabilities. Either we'll have to get used to DHCPv6, or need vastly expanded configurability on routers and their ND responses and assignments.

It's a shame that IPv6 has been shunned and avoided for so long, instead of embraced early. We've had more than ten years headstart time on the address space problem and subsequent migration, but nobody (network infrastructure manufacturers, security software developers, ISPs) really wanted to have a go at it. Now we have to catch up those lost ten years within a rather short timeframe and suffer the consequences of quick'n'dirty hacks instead of polished tools.
Regarding DHCPv6 - unlike DHCP for IPv4, for DHCPv6 there´s no option for default router in the RFC's (draft dhcpv6-option-router-05 expired Feb 25). You still need RA's.
I tried setting up a DHCPv6 server at work. All of my DHCPv6 clients got IPv6 addresses but they each had 3 or 4 IPv6, a temporary address, an IP from the DHCPv6 server, the privacy enhanced IP, an a second IP from the DHCPv6 server. Next no DHCPv6 client could ping or access any IPv6 device because I do not have a IPv6 compatible router. I just turned off the DHCPv6 server and let the addresses expire. The short version is you really can't use IPv6 unless you have a IPv6 router available.
DHCPv6 will become important when you do*not* run dual stack but native IPv6.

And: DHCP was never a replacement for NAC (network access control). It might support NAC via "dhcp snooping" on your switches but has that really been implented for IPv6?
Talking about ND reminded me of the ndisc6/rdisc6 tools which are kind of the arping replacement for v6. Sometimes helpful when hunting ND problems.
Thanks for the focus on IPv6 this month. I've avoided it as long as possible. I'm now reading IPv6 Fundamentals; A Straightforward Approach to Understanding IPv6 by Rick Graziani. After 130 pages, I definitely recommend it. Thanks again for this series. The comments are "icing on the cake!"

Diary Archives