What is happening to IPv6?

I have read several articles lately on the state of IPv6. Most of them take the position that implementation is moving slowly, and that is just fine. I went to a conference a few weeks ago that gave me a fairly different impression. It brought together people from the US federal government, business, and academia to describe the state of IPv6 in the government, and start a discussion of where to go next. My main interest in the conference was the security issues surrounding IPv6, and of course, there is no serious discussion about the Internet that doesn't include security. However, I did learn some interesting things about the status of IPv6.


At the time, the government was on the verge of announcing that agencies could demonstrate IPv6 capabilty. This basically amounts to the fact that they have a plan in place to only purchase equipment that supports IPv6, although some have pilot programs in place. The DoD is apparently furthest along, but is nowhere near ready to "flip the switch". However, there has been quite a bit of planning and NIST is working on setting standards for testing equipment, that will eventually lead to purchase specifications.

The government, and in particular the DoD, is not very concerned about the increased address space or encryption/authentication features of IPv6. Instead, their interest is in mobile networks, especially the auto-configuration features, and multicast. This is for using dynamic networks on the battlefield, and while they didn't give any details on the subject, it isn't hard to imagine how both features could be used. There is a pretty good article from Linux Journal on IPv6 mobility in Linux, which starts with a really good overview of the principles of using it.

Near the end of the conference, there was a panel discussion which included a couple of government representatives, a guy from Cisco and one from AT&T, and a member of the IETF IPv6 working group. The guys from industry said that there is a steady, and fairly significant increase in the IPv6 network infrastructure. If you live in the US, you are probably used to reading articles that claim deployments are almost non-existant and are surprised to hear this. However, the deployments are happening in Asia primarily, and to a lesser extent in Europe.

I don't know how true it is, but someone at the conference said that the University of Califonia system has more IPv4 addresses than the entire country of China. Even if it isn't the case, the point is well taken. Latecomers to the Internet got the crumbs of the IPv4 address space, and now they are desperate to use IPv6.

This has many implications. The entire set of TCP/IP and related protocols are very loose. In some people's minds, the rollout of IPv6 is an opportunity to get several things right that IPv4 didn't. However, implementations will not all support the same features. The reason for this is that IPv6 has a common header with very little in it other than the source and destination addresses. The new features are in extension headers, which are optional. And the protocols to be used for encryption and authentication are continuing to be developed:

• Security Architecture for IP: RFC1825 obsoleted by RFC2401 obsoleted by RFC4301 (IPSec) and updated by RFC3168


• IP Authentication Header: RFC1826 obsoleted by RFC2402 obsoleted by RFC4302 and RFC4305 obsoleted by RFC4835

The newest of these is dated April, 2007. And none of them specify algorithms or methods, just the requirements for using them. Meanwhile, thousands of routers for IPv6 networks have already been deployed and the number is growing steadily.

The question was raised during the panel discussion of how much assurance agencies will have that the products they purchase will support the requirements that are mandated. The answer was a resounding, "Well ..." The member of the IETF pointed out that they are not a standards committee, but more like the maintainer of the documentation. RFCs have their status upgraded to Standard by concensus. And the Asian and other countries using IPv6 as 'IPv4 with big addresses' are not interested in spending time haggling over features that interfere with their deployments.

But as I said before, my interest was in the security concerns for IPv6. The main ones are the same as in IPv4. To begin with, a very small percentage of exploits go against the IP layer. And security issues for the upper layers of the stack will not change.

But once mobile IPv6 networks with auto-configuration begin to be deployed, there will be vulnerabilities to be dealt with. Of course, the first vulnerability will be admins on the learning curve. Hopefully, these folks will be motivated and supported to get good training early on. To get a taste of actual protocol issues, read the RFC for Secure Neighbor Discovery (SEND) mechanisms.

I certainly hope that the admins don't get stuck with the bulk of the responsibility for security. But the current state of networking products, according to someone who is testing them for the NSA, is that the low level infrastructure (routers, host OSes) is fairly good, but not 100%. Even a little way up the stack, that falls to little, if any, support for IPv6. This includes firewalls and IDSes, and some server applications.

So what has to be handled? Well, the first step is to find the upper level data, such as a TCP header. This means parsing the extension headers, which is a little weird. First, the header type is not in each header, but in the preceeding header. So the first two octets of each extension header are the type of the next header and the length of the current header.

Then there is tunneling. It is possible to tunnel IPv6 in IPv4 or vice versa. What this means for finding the upper level header is that first the IPvX header must be parsed, then the IPvY header. And this could be done more than once in crafted packets. I sure hope that normal traffic at the point of a firewall would not have multiple IPv4 and IPv6 tunnels.

The other issue is the order and number of IPv6 extension headers. Most packets are only allowed to have one of each type of extension header. The exception is the Destinations header, and there may be two of these. Oh, and the order is not mandatory, just recommended.

And what is the status of Realeyes IPv6 support? I have added the capability to find upper level headers in untunneled packets. And there is some capability to parse IPv6 extension headers. In particular, the number of each type of header is validated, and for now the recommended order is treated as mandatory, so a report is issued for packets that don't follow the recommendation.

The common IPv6 header is formatted in playbacks, but there is a hex dump of the extension header data. I will be gradually adding support for tunneling and formatting of the extension header data. It is similar to TCP options, so I don't see the code being difficult. The biggest problem is testing. I configured two hosts on my local network to talk to each other with IPv6, but that is a proof of concept, at best.

So that is my perspective of what is happening with IPv6. I suggest that if you work on networks, you show more than a passing interest in it, because it will probably be a case of hurry up and wait, until all of a sudden we need it yesterday.

Later . . . Jim

Modularity

Realeyes was planned with the intention of supporting IPv6, and now that the basic functionality is in place and (mostly) working, I am adding full support for it. This means several things, including:

• Deploying a Realeyes IDS sensor on an IPv6 network


• Analysis of IPv6 packets by the IDS application


• Inserting IPv6 addresses and data in the Realeyes database


• Defining rules for IPv6 addresses


• Displaying IPv6 addresses and headers from the user interface

I will describe this in more detail in a later post, but for the moment, I need a motivational boost, so I decided to give myself a pat on the back.

The way that IDS functionality is added is through plugins that perform specific functions. At this point, data collection and high level analysis are essentially complete. I am adding a few new features in the IDS only to the session handler and low level analysis plugins. In Realeyes terminology, this is the Stream Handler and the Stream Analyzers.

The Stream Handler parses the IP header to find the session ID, and set the location of the payload, such as TCP or UDP headers and their data. I set up two hosts on my local network for IPv6 connections. On a Linux system, this is as simple as issuing an ifconfig command on both systems and, for ease of use, adding the remote host to the /etc/hosts file:

host100> ifconfig eth0 inet6 add fec0:0:0:1::100/64

host100>/etc/hosts:
fec0:0:0:1::200 host200

host200> ifconfig eth0 inet6 add fec0:0:0:1::200/64

host200>/etc/hosts:
fec0:0:0:1::100 host100

Next, I established SSH and FTP sessions between them. I had the code to find the payload written, but this was the first time I had tested it. It took a couple of tries to get it right because the way IPv6 extension headers work is a bit tricky. But when I actually captured some sessions, they were displayed correctly in the user interface.

I then added the code to display the IPv6 headers in the user interface. This formats the main header and each extension header using human readable field names followed by the actual values. Because the header type of each extension header is in the previous header, this was also a little tricky to get working.

The IDS Stream Handler is also where IP fragments must be reassembled. I was really happy that after copying the IPv4 reassembly code and changing all instances of "v4" to "v6" and handling a couple of variables differently, the IPv6 reassembly worked. This is an example of the value of modularity and the use of variables in code.

As an aside, I learned this lesson in my first year of Computer Science. The grad student instructor had us program an assembler that could handle about 8 operations, each with one operand of 6 characters. The next assignment was to modify the assembler to add a couple of operations, some of which took two operands, and the length of operands increased to 8 characters. Those who hard coded the original assignment had a lot of work to do (I had hard coded some things, but not all). And yes, the third assignment was more of the same.

I hated that guy (as did most of my classmates), because while the lesson was legitimate, laboratory exercises are not applications that will grow in the real world. As first year students, most of us did not have enough experience to develop programs with even that level of sophistication, and he did not recommend that we incorporate it in the assignment. And with other classes to deal with, getting a single program to work at all took time that was in limited supply. His excuse was, in the real world we would constantly be faced with changing requirements at a moments notice, and thus he was doing us a favor.

Having been out here for over 20 years, I have yet to run into anything remotely like what he described, although I do make it a point to be anal about getting adequate requirements descriptions up front. The people I have worked for wanted me to succeed, because it reflected on them. Some were more helpful than others, but I have never worked on a task where the requirements changed wildly, making it impossible to complete. Maybe I'm just lucky.

Incidentally, the way I tested reassembly was to use the latest version of netcat, which supports IPv6 sessions. I created a file that had over 8K of test data, and then sent it over a UDP session, which tried to send the entire file in a single datagram, and forced the TCP/IP stack to fragment it:

server> nc -6 -u -l -p 2000 fec0:0:0:1::100

client> nc -6 -u fec0:0:0:1::200 2000 < test.data

Anyhow, I am now working on analyzing the IPv6 extension headers and expect that to be done within a week. After some tidying up, I will be building a new package for download with IPv6 and several other new features. So, back to work.

Later . . . Jim