IPv6 Deployment Series Part 4: Security

RYAN HARRIS | Sr. Network Engineer 

This blog post is part of a series detailing the various parts of planning and deploying IPv6 for enterprise networks. It is meant as a primer for the network engineer or architect to understand the various concepts they may be unaware of when developing their IPv6 production design. 

If you have not read the previous posts, I would highly recommend that you start at the beginning:  

• Part 1 – Hierarchical Subnetting Design 
• Part 2 – Routing Design 
• Part 3 – OSPFv3 

Inbound Firewalling 

One of the primary concerns of people new to IPv6 is the use of globally unique address space and the elimination (or near elimination) of NAT44. The concern stems from the idea that NAT44 is a security feature, NOT an inconvenient feature forced by the lack of v4 space. 

NAT overload is not a security feature aside from the fact that it adds opaqueness, but rather because its very nature forces the use of the true security feature in use by every network on earth: stateful firewalling. NAT overload gateways cannot allow 2-way traffic initiation without manual configuration of port-forwarding or uPnP (Universal Plug and Play). Traffic must be initiated from inside the firewall to the outside so that a stateful session can be created and the return traffic can be sent back to the correct host. 

The excellent news in all of this is that we can still implement stateful firewalling without the need for NAT. Traffic continues to be blocked at the firewall if initiated from outside the network. The only exception is when we manually configure access rules for hosted services like web servers, email, etc. 

Securing the Internet Border 

All deployments should implement rules to block bogons. A “bogon” is an IP address that is illegitimate for any number of reasons, be it an internal or private address or an IP address not assigned for public unicast traffic. Blocking traffic from these IP addresses ensures that traffic with a spoofed source address is not allowed into our network. In IPv4, this would typically be any RFC 1918 space (10/8, 172.16/12, 192.168/16), multicast space (240/8), etc. In IPv6, this would include address space such as the ULA space (FC00::/7), link-local address space (FE80::/10), multicast (FF00::/8), and more. When planning your deployment, search out a list of IPv6 bogons for filtering at your Internet edge. 

Privacy Concerns 

It is certainly a reasonable line of questioning when you learn about how IPv6 addressing works to become concerned about your privacy. If SLAAC is using my hardware MAC address to generate an IP address, would the last have of my IP address follow me everywhere? At work, home, Starbucks, could someone track my location throughout the day by correlating where I am accessing the Internet from? Well, the answer is yes; that is a vulnerability with SLAAC and why modern operating systems have dropped creating addresses using the machine MAC address in favor of randomized addresses. The process for generating these randomized addresses is described in RFC 4941 and is known as a Privacy Extensions for SLAAC. 

Your client will automatically generate a new, random address after a set period or when joining a new network. If you don’t disable privacy extensions, it eliminates client tracking through their IP address alone (other client tracking techniques are still valid). 

Securing the Local Gateway 

The LAN (local area networks) gateway in an IPv6 network needs to be secured just the same as an IPv4 network but some of the commands and specifics have changed. 

IP redirects, when a router sends an ICMP message to a client telling it to send traffic to another host on the same LAN segment, are often disabled to prevent a malicious client from high jacking traffic from clients. In IPv6, the same concern exists and its best practice to disable it with “no ipv6 redirects”. 

Next, it is best practice to implement unicast reverse path forwarding checks on every client-facing network. These checks are simple, and they verify that the source address of a packet against the outgoing interface from the routing table and dropping traffic that does not match. For example, if a machine on a LAN segment is sending traffic with a public IP address as the source address in the packet header, that could indicate that the host is compromised and attempting to send spoofed network traffic. The IPv6 version of this command is “ipv6 verify unicast source reachable-via rx allow-default”. 

Securing at Layer 2 

RA Guard 

Protecting clients from both accidental or malicious sources of addressing information and default routes is nothing new in IPv6. If a client is provided incorrect addressing information, this could lead to a man-in-the-middle attack, leaving users vulnerable. In IPv4, the Cisco platforms provide DHCP snooping and ARP inspection to help guard against rogue DHCP servers in the network. These features work by validating that DHCP offers can only come from trusted ports and listening into DHCP requests to tie an IP address to a MAC address. 

Since IPv6 changes to using ICMP router advertisements to provide both the default gateway for both SLAAC and DHCPv6, we need to validate and secure those packets, similarly to how we validate DHCP packets in IPv4. The solution is called RA Guard. 

RA Guard is configured as a policy and then applied to the upstream ingress interfaces on a switch to inspect the ICMP RA messages being received. The RA guard policy can inspect and enforce different aspects of the RA message, such as config-flag settings, prefix information, hop-count limit, and router-preference.  

IPv6 Snooping 

IPv6 snooping is a feature set that combines multiple layer 2 features to build and maintain a binding table of IPv6 addresses to the link-layer address. IPv6 snooping includes the features of IPv6 address gleaning and IPv6 device tracking. 

The IPv6 snooping feature allows for improved security and scalability of local LAN segments and mitigates vulnerabilities inherent to the neighbor discovery process. The IPv6 snooping feature tracks ND messages to build a trusted binding table and any ND messages that do not have valid bindings are dropped. 

IPv6 snooping can be used as a highly effective troubleshooting tool for network engineers. When attempting to track the port location of a client using just an IPv6 address, it can be time-consuming to correlate layer 3 to layer 2 mappings, and then correlate layer 2 to physical interfaces. The IPv6 snooping database can directly correlate layer 3 to layer 2 and physical interfaces with a single command on devices that may not have layer 3 interfaces in a particular VLAN. 

DHCPv6 Guard 

The DHCPv6 guard feature is used to block DHCP advertisements and replies from unauthorized DHCP servers. This feature set is similar in practice to the DHCP guard feature for IPv4. 

There may be some confusion on how this feature differs from RA guard due to prefix information being advertised by the router advertisement packets. However, DHCPv6 is still carried via its own protocol, not ICMPv6. DHCPv6 guard is not made redundant by RA guard but rather is a second separate check against rogue DHCP servers on a LAN segment. 

DHCPv6 guard works by creating a DHCP guard policy, one for both the client and server, and then applying that policy to an interface to monitor ingress traffic.  

IPv6 Access Control Lists 

In many ways, Access Control Lists are simplified in the world of IPv6. Cisco drops the confusing standard vs extended vs named access list convention, opting for a single format similar to the named format in IPv4. Additionally, Cisco also clarified the commands for applying access lists to interfaces, “ipv6 traffic-filter” vs the old “ip access-group” command. 

What may not be obvious to most is the nuances in which ICMPv6 is handled now. With IPv4 access lists, there is an implicit “deny” statement at the end of every ACL. Because ARP worked below layer 3, an explicitly configured deny statement would allow it to continue to function. However, in IPv6, neighbor discovery functionality has been moved to ICMPv6, which functions at layer 3 and is subject to ACLs allowing or denying it from responding. In most cases, configuring an access-list that does not permit ICMP neighbor discovery will break network connectivity. 

Unfortunately for us network engineers, the behavior of different network operating systems is inconsistent in implementing implicit rules. Cisco’s IOS-XE, for example, does not implicitly permit ICMPv6 ND packets, and they must be explicitly allowed when applying an access list to an interface. Cisco’s NX-OS has changed its behavior in older versions, having several implicit permit statements to allow ICMP neighbor discovery and router solicitations to remove these implicit permits and only use the implicit deny.  

I always recommend including explicit permit statements for ICMP ND in every access list or moving it to a common ACL and using access-list chaining.