Tech-Ed-2008- Session Summaries 6 Mark Minasi on IPV6

So often, when troubleshooting computer problems at home, I’ve typed ipconfig /all, and skipped all the weird hex, going straight for the good old IPV4 stuff. But they keep saying we’ll run out of IPV4 addresses around the same time the Mayan calendar winds down, and we’ll have not one but two global cataclysms. But unlike the Mayans, we have been able to see beyond the apocalypse: IPV6 will wrest order from this chaos.

That’s the promise. Mark Minasi has roared in where angels fear to tread, taken on this tough, complicated topic, read more RFCs than I can shake a stick at, and put together a kick-ass presentation on IPV6 to make it all clear. A truly exceptional insightful Tech-Ed session, one of the best.

Mark begins by asking Why Learn Now? and explains some facts and benefits.

- Fact: Chinese has 1.2 billion users and is already constructing an IVP6-based network. He points out that this raises the daunting prospect that future RFCs will be written in Mandarin.

- Fact: We are running out of IPV4 addresses, and you can even get an IPhone app that shows the countdown..

- Benefit: Better, easier automatic configurations, which will supersede DHCP for this purpose.

- Benefit: No broadcasts

- Benefit: Little need for hardware upgrades.

In his presentation, Mark covered the differences with IPV4, unpacked the serpentine names, explained name _types_, and showed how IPV6 works in practice.

How Does IPV4 Compare With IPV6? Currently, in IPV4, I can talk to you if we are in the same subject by shouting on Ethernet. Otherwise, I have my local router forward the message. So the question is should I shout or should I route. How to make this decision?

However, with IPV6, many things are different in word and in fact. There are almost never subnets; instead we say “link”. “Link” means connection to the network. And for IPV6, no DHCP is needed; the machine addresses itself. The next confusing thing is how to read addresses. After all, IPV4 addresses are 32 bits, and IPV6 ones are 128 bits (!). This allows for a truly astronomical number of addresses. Also, it uses hex digits. Colons are placed between each block of four simply “to improve readability”, according to an RFC. Even so, this is a chore to scan. So, there are various schemes for abbreviating them. There are several rules which allow this:

- Trim leading zeroes. :0831: becomes :831: and :0003: becomes :3:.

- A series of 0s can be collapsed to just :: So, for example, FD00:0:0:0:B13A:831:0:6789 becomes just FD00::B13A:831:0:6789.

- How is 127.0.0.1 expressed in IPV6? Very simply: ::1.

Network names are handled differently in IPV6. In IPV4, we would express a network as 210.2.3.0/24. This meant that the ISP controlled the left 24 bits (out of 32, remember), and you controlled the last eight. Things will soon be vastly different.

Names for Networks. In IPV6, about the only carryover is the use of the slash to indicate the number of bits reserved for the network. However in IPV6, this is referred to not as the “network number” but as the “prefix”, and since there are only two used (48 and 64) you hardly even need to articulate them. Old style subnet masks are not used. As someone who has learned and taught the art of subnet mask calculation, I can say that this will not be greatly missed. Mark gives a great example of how this works: “21FB:540A::/48” includes this information implicitly: the left 48 bits are not under the owner’s control, which means the owner has an 80-bit address to work with, and all the IP addresses will start with 21FB:540A:000:. This example is especially relevant because most assigned IPV6 addresses will reserve 40 or 64 bits. Going back to the example of having an 80-bit address space, this means that you are given this many addresses: 2 to the 80^th power. This is enough for most purposes, even for my book and music collections combined.

Mark also explained clearly how to get from a network name such as 21FB:540A::/48 to knowing what addresses will work for our network. It goes like this:

1. The /48 in 21FB:540A::/48 means that the ISP controls 48 bits and we control 80.

2. The 48 bits we do not have breaks down into 12 hex digits.

3. But when we look at 21FB:540A we see that only 8 are used. So four are missing. And since they are unspecified, we know they are zero.

4. Therefore all the addresses on this network start with 21FB:540A:000:

One benefit of using a straight 48-bit reservation for network purposes is that designing routers will be easier with a single consistent, almost universal metric for this. So, here’s how this will play out. Network authorities get 48 bits. The host address gets 64 bits. The remaining 12 bits go to subnet IDs (more later). This usage of “subnet” is what we used to refer to as a site. In this system, we can assign up to 65,000 sites (!), which is enough for most purposes. Then, since we still have 64 bits available for naming machines at each site, we can have 18 quintillion machines. And keep in mind that everyone gets a /48 network. The local Girl Scout team gets one. McDonalds gets one. The US Army gets one. So, the current IPV6 system allows up to 137 billion organizations (can be expanded even more to 250 trillion, if need be). Smaller organizations can opt for just one subnet of 18 quintillion addresses if they so choose. It’s pretty clear that IPV6 was architected with a long-term frame of mind.

Types of Addresses. So far we have reviewed some of the major features of how IPV6 works. Now, let’s take a look at the major types of addresses, since this is the aspect we will see most frequently, and of course which turns up most often on exams.

IP addresses are handled quite differently in this new system. The good news is that our hardware is already able to handle this. There is no bad news. With IPV4, normally a NIC has but a single IP address. However with IPV6, multiples are the norm. In fact, normally your machine will assign itself a bogus temporary address just to find routers, and then it gets a real, routable address.

Now, IPV6 addresses can be divided into three main types. Mark lays out their differences.

Unicast: Addresses aimed at a single connection on a single machine. And there are four sub-types of these:

Global Unicast: These are routable across the Internet.

Link-local Unicast: Only works within a link/subnet. Packets from these are dropped by the first router they encounter.

Site-local Unicast: Can be routed within your organization, but not outside to the Internet.

Unique local Unicast: like private or 192.168.x.x addresses.

Multicast: Used for one-to-many connections. They provide some of the features of broadcasts in IPV4 (but not all). And they also are used to find your local router and other members of your link/subnet. This is in essence a discovery service.

Anycast: Used to find routers mostly. Can also be shared.

Broadcasts are not included within IPV6; multicasts are intended to handle this. With IPV6, machines join a multicast group and are remembered by major hardware such as routers and switches. The addresses used for multicasting have a distinctive feature and start with FF0 or FF1. There is also a single “magic” address for multicasting; send a message to this and it is forwarded to all link/subnet members. Some other multicast addresses are tasked with specific functions. Minasi gives the example of FF02::2; messages sent to this address will go to every router on your link/subnet. So, when a machine comes on, it makes up an address to send a message to this address to see if anyone else is there. Once it received a response, it then fabricates its own proper address for that link/subnet.

Global Unicast addresses: These are globally routable. Their top three bits are 001, and the remaining one can be 0 or 1. Since 0010 equals 2 and 0011 equals 3, this means that global Unicast addresses always start with 2 or 3. Internet-connected routers only forward packets from these types of addresses; all other are discarded.

Link-local Unicast address. Only used for communication within a link/subnet; routers discard them. Note that their top 64 bits are FE80:000:000:000, or FE80::/64. Formerly, the rest of this address was the hardware’s MAC address, but this was too prone to abuse, and now is simply random. Comparable to APIPA addresses.

Site-local Unicast address. They cannot be routed across to the Internet, but they _can_ be routed within a “site”, and are meant to be so associated. Their top 64 bits are felicitously named FEC0:0:0:FFFF. However, the effort to program for this was daunting, and it is being shelved. Microsoft added to this by defining a “well-known” address clients can use to look for DNS servers, and posited three such: FEC0:0:0:FFFF::1, 2, and 3. Regrettably, IPV6 is evolving away from this.

Unique Local Unicast Addresses. Starts with FD00. This seems to have been established mainly as a transitional device for organizations used to 10.x.x.x addresses, and who do not want to give this up.

So, in summary, we see:

FE80: Unicast link-local.

FEC0: Probably DNS server (going away)

FD00: A private address.

FF0 or FF1: A multicast address.

2 or 3: a globally routable Unicast address.

What if an address starts with 0, 1, 4, etc., all the way up to E? Currently undefined.

That does it for the top 48 or 64 bits.

But what about the bottom 64? MAC addresses, already unique, might seem a reasonable source. Use them, or run them through an algorithm to get a 64-bit value might seem an easy way to proceed. However it is estimated that MAC addresses will run out in less than a hundred years. The only issue with this is that any address based on MAC addresses would be individually identifiable anywhere. There are few occasions when this would be desirable, except to Australia or Chinese governments. So IPV6 now auto-generates the 64-bit address value instead.

So currently, address acquisition goes like this. First device self-generates an FE80 address, and looks for routers. The routers provide the top 64 bits of the address. Then the bottom 64 bits are randomly generated. And that’s it! Now, in IPV6 DHCP still exists, but with different functions. It might provide other referential addresses (like time-servers, for example), or it might provide a static address, or a DNS suffix. Etc.

Getting back to the random generation point. It’s always possible that in a sufficiently large organization, like the federal government, two identical random addresses might somehow be generated. An IPV6 function called DAD, or Duplicate Address Detection) addresses this, by querying if anyone else is using a given address. Since the chance of addresses coinciding is so remote, the address goes into service while this DAD check is taking place.

Globally routable addresses are obtained the same way: from routers. Here, two addresses are given. One for two-way communication, and the other for random web surfing.

Mark ended with some brief comments on DNS and name resolution in IPV6. There’s no NetBIOS or WINS. A new name record, AAAA, represents the existence and availability of an IPV6 address.

Once again, Minasi has taken the most complicated, mind-numbing technical topic, and made it so easy even a board of directors could understand it. For a brief, clear outline of how IPV6 works and its salient points, this presentation, still available at Tech-Ed Online, is the place to start. The only thing I would add to this presentation is that with so many addresses being allocated for each individual, it’s inevitable that people will start constructing their own cute IPV6 names, and some will start designing ways to choose “lucky” IPV6 addresses based on one’s astrological sign.

In 2010, last month in fact, Marc Michault returned to this subject with a presentation that covers much the same ground with some new insights. I’ll cover this next.