Deploy360 24 February 2015

IPv6 Security Myth #7 – 96 More Bits, No Magic

Chris Grundemann
By Chris GrundemannGuest Author

Security in an IPv6 WorldThis week’s myth is interesting because if we weren’t talking security it wouldn’t be a myth. Say what?

The phrase “96 more bits, no magic” is basically a way of saying that IPv6 is just like IPv4, with longer addresses. From a pure routing and switching perspective, this is quite accurate. OSPF, IS-IS, and BGP all work pretty much the same, regardless of address family. Nothing about finding best paths and forwarding packets changes all that much from IPv4 to IPv6. For many experienced network engineers, instruction in IPv6 contains a lot of things that can be described to “work just like in/with IPv4.”

This likely explains why virtually every transit provider and backbone operator on the planet has already rolled out IPv6. If all you’re concerned about is moving data, the phrase is true: IPv6 is 96 more bits, no magic.

From a security perspective however, that view has some complications.

Myth: 96 More Bits, No Magic
Reality: IPv6 Address Format is Drastically new

Routing 128 bit addresses is really not much different from routing 32 bit addresses. There’s a source address, a destination address, and hopefully a path or more between them.

Things get more complicated when we start talking about securing the network though. In addition to IPv6 addresses being 96 bits longer, they are also represented in hexadecimal notation instead of decimal. They use colons as delimiters instead of periods. They also introduce zero compression, in addition to zero suppression, expanding the possible formats that an IPv6 address may be represented in.

So what? Well, a lot of network security involves either filtering or forensics, both of which are often heavily (or completely) reliant on identifying nodes by IP address. You can no longer grep logs for decimal numbers separated by periods to find all instances of IP addresses. Now you need to look for hex characters and colons – and don’t forget to think about those double colons! Scripts, filters, and other tools written with IPv4 addresses in mind must be updated to handle IPv6 addresses.

Myth: 96 More Bits, No Magic
Reality: Multiple Addresses on Each Node

To make matters even more complicated, IPv6 nodes (hosts) are pretty much assumed to always have multiple addresses. At the very least they should all have a link-local IP address and a Global Unicast Address (GUA / public IP address), likely in addition to a legacy IPv4 address. Many nodes will also have a Unique Local Address (ULA – somewhat similar to RFC1918 address space in IPv4), one or more constantly changing privacy addresses, and other GUAs as needed.

This means that the node you are searching for may have a different IP address in the logs than the one you are looking for. It means that you may need to filter multiple addresses to have the desired affect on a single node. It means a paradigm shift in how you think about IP addresses as they relate to securing your network.

Myth: 96 More Bits, No Magic
Reality: Syntax Changes

In addition to changing how we think about IP addresses in this new IPv6 enabled world, we must also deal with syntax changes on our gear.

One of the great things about deploying a new version of IP is that we can use the opportunity to fix mistakes made in the old version. This is as true at the software and hardware level as it is at the network and security levels. The downside of this is that improvements at many equipment manufactures mean new syntax for network operators and security experts alike.

Instead of just ping, we now must remember to ping6. Our old friend tracert requires that we add -6 when executing an IPv6 traceroute. The ‘show route’ command is now supplemented by ‘show ipv6 route’ on some routers. The list goes on and on, and is different for each platform or vendor.

These changes affect everyone. As we learned in Myth #1; ignorance is no protection, and no excuse. To keep your network secure today, you must learn the new syntax of IPv6.

Myth: Configure IPv6 Filters the Same as IPv4
Reality: DHCPv6 and Neighbor Discovery Introduce Nuance

This is a more specific version of the ‘no magic’ myth and again, it’s not far from the truth. From a policy perspective you really should treat IPv6 and IPv4 security the same. For example: If a particular activity, destination, or traffic type is blocked for IPv4 it should very likely be blocked for IPv6 as well. The nuts and bolts of doing this aren’t quite the same however.

We’ve already talked about how address format, multiple addresses, and syntax changes may affect your configurations and actions. In addition to these general considerations, firewall filters have a couple of additional things to remember.

One of the biggest things to keep in mind when creating IPv6 filters is that Neighbor Discovery (ND) uses ICMP. This of course means that default ‘deny all ICMP’ rule you are likely to be using in legacy IPv4 filters can’t be copied over directly. Another consideration that may not be obvious at first is that DHCPv6 messages use link-local addresses, which you may typically want to filter out (why would link-local traffic be transiting a router?).

Here is an example stateful firewall filter for a Mikrotik router:

Flags: X – disabled, I – invalid, D – dynamic
0 ;;; Not just ping – ND runs over icmp6.
chain=input action=accept protocol=icmpv6 in-interface=ether1-gateway
1 chain=input action=accept connection-state=established in-interface=ether1-gateway
2 ;;; related means stuff like FTP-DATA
chain=input action=accept connection-state=related in-interface=ether1-gateway
3 ;;; for DHCP6 advertisement (second packet, first server response)
chain=input action=accept protocol=udp src-address=fe80::/16 dst-address=fe80::/16
in-interface=ether1-gateway dst-port=546
4 ;;; ssh to this box for management (note non standard port)
chain=input action=accept protocol=tcp dst-address=[myaddr]/128 dst-port=2222
5 chain=input action=drop in-interface=ether1-gateway

As you can see, rule 0 is in place to allow ND to work and rule 3 allows the node to hear its own DHCPv6 reply. This is just an example but hopefully it illustrates the point: There are subtle differences between IPv4 and IPv6 that must be considered when securing modern networks.

That’s it for this week, but you don’t have wait for the next IPv6 security myth; get started with IPv6 today!

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...