Tech-Ed-2010 Session Summaries 7 More on IPV6

Not so long ago I reviewed Mark Minasi’s Tech-Ed 2008 IPV6 presentation. Frankly, it’s hard to imagine anything better, in terms of style and suppleness. Nonetheless, he does not deliver it every year, and others have come forward more recently to explain this technology. This year, Swiss maven Marc Michault presented a survey of IPV6 which covered much of the same ground, but with added depth on some aspects, making this a worthy session to summarize and review.

I. Packet Overview and IPV6 Addresses

Good overview of the packet construction. The header for the packet has been redesigned, and now weighs in at 40 bytes, mainly source and destination addresses; this simplifies the work of routing. The addresses are written in hex, rather than the standard 10-notation of IPV4. They also are rich in leading zeroes, all of which can be unwritten. Thus,

FD00:0000:0000:0021:0001:0000:0000:5143 becomes

FD00:0:0:21:0:0:5143, which can be further condensed to

FD00::21:1:0:0:5143. Note that this distillation of :0:0: to :: can only be done once.

Subnet Masks are also quite different, and come in at 16 bits (network ID is 48, and interface ID (local name)) is 64. This allows some 65,000 subnets. For most purposes this is enough.

Addresses are also different in terms of their number, in that a given node, or NIC, can have several IPV6 addresses.

Address Type #1. The Link Local, which always starts with FE80, is self-generated, just like current APIPA addresses. This is used, among other things, for router discovery. Now even though the number of available identifiers is truly vast, some have fretted that they might not be enough, and have proposed a way to in effect recycle them. This involves adding to the address a percentage sign (%), and then appending the name of the link/subnet on which this address resides. You know, just in case.

Address Type #2. Global Unicast Addresses are routable and can be used for global communications. The first three bits are set to give us values of “2” or “3”. Here, three bits are used to identify the type of address (currently just “2” or “3” is used) and then 45 bits provide the network ID, and are designed for global routing.

Address Type #3. Unique Local IPV6 Unicast Addresses are labeled as FD. These are not used for global routing, and are indeed for intra-organizational routing. Formerly known as link-local.

Address Type #4. Multicast addresses only work for link-local operations; broadcasting in IPV6 cannot be done. For this purpose, names start with FF. Here are some examples of the most common multicast addresses:

FF01::1 Interface-Local All Nodes

FF02::1 Link-Local All Nodes

FF01::2 Interface-Local All Routers

FF02::2 Link-Local All Routers

FF05::2 Site Local All Routers

Solicited Node, Link-Layer Multicast Address. This part was less successful, and after several re-listenings it remains unclear to me.

2. Auto-Configuration

Two types: stateless and stateful. The former is autopilot; the latter requires some upstream preparation and manual setting. Stateless involves link-local neighbor discovery, and router advertisement. Stateful continues to rely on DHCP for settings which cannot be provided by routers (time servers, DNS servers, etc.).

He makes points similar to those in Minasi’s presentation, including the problems of using MAC addresses in IPV6 addresses. Instead, machines self-generate addresses listed as “tentative’” until DAD has confirmed no duplicate exists. Then it is confirmed as “valid”.

Once the machine has identified itself and the other nodes on its segment, it next seeks to see beyond that segment. It looks for routers, with discovery messages sent in multicast; of course only routers respond. The router response gives the machine a prefix for that router’s network, and the machine appends this to its own segment, thus creating a globally routable address.

That’s the easy, stateless style of auto-configuration. Needless to say, the “stateful” style takes more effort. The addresses can be done manually. This is seldom desirable. However DHCP is also an option, allowing many, many settings to be provided, such as domain suffix, time servers, etc. For most corporate networks, this will remain in use for the foreseeable future. It’s only natural the some day soon, routers will be marketed that will provide these DHCP functions.

Michault does not mention this, but it is worth noting that at this point the machine may have four addresses: the initial self-generated one, the one used within its segment, and the one(s) provided by its router.

III. Name Resolution

Based on the nature of name acquisition, one would think that this should be straightforward. One would be wrong. Michault found three points to make:

1. Local subnet, with Link-Local Multicast Name Resolution (LLMNR). As of mid-2010, the details for DNS-related multicasts are still being worked out. In this case, hosts can contact the multicast address and the message will be forwarded to each machine on the segment, who will in turn respond. This also replaces the browser service.

2. Internet, with Peer Name Resolution Protocol (PNRP). LLMNR is okay for identifying and contacting neighbors. More is needed for large scales of communication. This is also used in non-IPV6 networks. This hashes the host’s machine name and defines a proximity based on this. Now, each node (computer) maintains hashes of neighborhood machine names. These are then reviewed. Successively closer and closer nodes are contacted, eventually (it is hoped) yielding a match.

3. Internet, with DNSV6. Few major differences. Though since addresses are much longer, the A record is replaced by an AAAA record. In addition, since reverse notation is in hex, the PTRs can become quite long. Other than this, there are few changes.

Michault summarized by discussing some current technologies of note which run on IPV6. DirectAccess was the foremost example here.

4. Transition Technologies

Michault finally reviewed some important transition technologies for making this work.

Tunneling. Like other types of tunneling, this approach takes IPV6b packets, breaks them up, and gives them IPV4v headers. Normally this is done for encryption, however in this case there is no added security.

ISATAP, or Inter-Site Automatic Tunnel Addressing Protocol. This provides support for IPV6 applications running on an IPV4 network. This is done by adding in effect an IPV6 prefix to an IPV4 address. For private networks, this prefix would be ::0:5EFE; for a public network this would be ::200:5EFE. Michault gave a good explanation of how this works for transporting IPV6 traffic through an IPV4 network, and also for how this would work in a mixed network of IPV4 and IPV6 segments.

6to4. This is intended for IPV6 organizations that must continue to interact with IPV4 ones. It works by viewing the IPV4 network as the 2002:WWXX:YYZZ:: range and then having a gateway turn the IPV4 address into a hex value, which receives a prefix from the gateway. This prefix-plus-hash is then represented to the routers in the organization.

Teredo. “a pain and a bit of a bitch”, to quote Michault. This allows IPV6 hosts to communicate through IPV4 NATs. This transitional technology should soon fade. In this system, hosts get Teredo addresses which include the assigned Teredo address range (2001::/32), the public IPV4 address of their Teredo server, and the obscured public IPV4 address and port for Teredo traffic on their NAT. Communication runs through a complicated process, including NAT1 to NAT2, then NAT2 to Teredo Server 2, and then Teredo Server 2 to Target Host2, followed by Target Host2 to NAT2 to NAT1 to Target Host1. Michault referred the curious to whitepapers and Joseph Davies’ second edition of Understanding IPV6. Perhaps the most reassuring lesson here is that it’s a transitional technology, not intended for permanent presence.

Conclusion: Few are willing to quickly and fully embrace IPV6, whatever its benefits. Yet its strengths are compelling, and most importantly, the world will soon run out of IPV4s. This will be the IP backbone for the rest of our lives, and it behooves us to understand it. Michault’s presentation was valiant, especially for a second language presenter. The pacing, to me, seemed weak. The arcane was presented at times with too little explanation and sometimes, frankly, seemed unnecessary. Explanations were not always strong, though the speaker was articulate, intelligent, and focused. That being said, the explanations sometimes could have been clearer, and the scope for this talk was perhaps too broad. In retrospect, I’d have recommended a shorter list of topics, covered in more depth.

Post-Script: In an age where we have enough IPV6 addresses for every hair on your head to be uniquely identified, it’s inevitable that some day our coffee-makers, credit cards, and pets will have their own unique addresses. Additionally, now that addresses have six letters as well as ten digits, it’s inevitable that people will look for lucky numbers or ways to include messages in their addresses. Rude suggestions to the FBI, DOD, CIA, for example, could be built into addresses. More reflection on these likely futures would be worthwhile.