Law & Disorder / Civilization & Discontents

US government getting more interested in IPv6

With IPv4 address space running out, the FCC and National Institute of …

The US federal government seems to have IPv6 on the brain as of late: both the Federal Communications Commission (FCC) and the National Institute of Standards and Technology (NIST) came out with IPv6-related documents recently. The FCC document is a collection of previously known information—it's not about FCC policy—but they managed to include a few things we weren't aware of.

It discusses the transition from NCP, the protocol used with the original ARPANET, to the current TCP/IP back in the early 1980s:

The NCP-to-IPv4 transition had two characteristics that distinguish it from the current transition: a flag-day transition date and a clear directive from an authority that could back it up. On January 1, 1983, NCP would be turned off. Those networks who had failed to prepare—there were a significant number of them—fell offline, and proceeded to spend several panicked months attempting to upgrade their computers and regain connectivity.

The meatier NIST document is intended for federal agencies, but "may be used by nongovernmental organizations on a voluntary basis." It goes into much detail about the differences between IPv6 and IPv4, and how those differences impact security. For instance:

Reconnaissance attacks in an IPv6 environment differ dramatically from current IPv4 environments. Due to the size of IPv6 subnets (264 in a typical IPv6 environment compared to 28 in a typical IPv4 environment), traditional IPv4 scanning techniques that would normally take seconds could take years on a properly designed IPv6 network.


Prevention of unauthorized access to IPv6 networks will likely be more difficult in the early years of IPv6 deployments. IPv6 adds more components to be filtered than IPv4, such as extension headers, multicast addressing, and increased use of ICMP.


A misconception about IPv6 is that IPv6 by itself introduces many more security risks than the IPv4 protocol. Perceived risk can cause an organization to delay deployment despite the fact that IPv6 enabled equipment is already on hand. As discussed in Section 2.4 of this document, IPv6 is no more or less secure than IPv4.

The report recommends using randomized interface identifiers and subnet numbers to make scanning difficult. It also recommends stricter filtering than for IPv4, such as using a "default deny" policy, for the time being, while gaining experience with the new protocol.

The document spends a lot of time discussing ICMPv6. ICMPv6 not only provides the functionality that's in IPv4 ICMP, such as conveying unreachability or performing ping, but also includes Neighbor Discovery, the IPv6 replacement for ARP, and more. Another topic in the NIST doc is Path MTU discovery—already a problem with IPv4, but it could easily be worse with IPv6. 

If two systems that can handle 1,500-byte packets communicate over a path that is limited to 1,280 bytes somewhere in the middle (a common situation with tunneled IPv6 connectivity), then the router terminating that 1,280-byte link sends back a message that the sender needs to send smaller packets. Unlike IPv4, an IPv6 router can't fragment packets. However, if the sender of the original packet never receives the ICMPv6 message that informs it of the reduced packet size, it will keep sending large packets, which won't make it to the destination. So it's important to allow these "packet too big" messages.

However, the authors of the NIST document don't seem to be familiar with a nifty security feature that's in the ICMPv6 specification: for ICMPv6 packets that are only supposed to be local, the hop limit field in the IPv6 header—that would be the time to live field with IPv4—is set to the largest possible value, 255, when the packet is transmitted. Upon reception, the IPv6 system can then check if this value is still 255. If so, the packet was transmitted over the local network: if it came from elsewhere, one or more routers would have decremented the hop limit value so it couldn't have been 255. This way, non-local but supposed-to-be local packets can be rejected without explicit filters or cryptography.

One thing that I'm not entirely comfortable with is the recommendation to ruthlessly turn off IPv6 on hardware, OSes, and applications if IPv6 isn't going to be used in a particular network. In a government setting with fixed computers, this makes sense—although I wouldn't want to be the admin that has to turn it all back on later. But turning off IPv6 on a laptop may create unforeseen problems when it's connected to a different network where other systems may want to talk IPv6. This is especially true if in the near future ISPs start to deploy IPv6. 

But even today, many types of local communication use IPv6, and may fail or work slower if one system tries IPv6 while the other only has IPv4. For instance, Apple uses IPv6 link local addresses to configure its WiFi base stations, and Microsoft has warned that its software for Windows Vista and Windows 7 isn't tested with IPv6 turned off—your IPv4-only mileage may vary.

The FCC document provides some interesting background and isn't too long, while the NIST document is a good introduction to the nuts and bolts of IPv6 and provides some good security information. Both are recommended reading.

Expand full story

You must to comment.