IPv6 Addresses - SLAAC

IPv6 has two methods that an interface can use to be assigned an address.  The first is the SLAAC, (StateLess Address AutoConfiguration) method, and the second is DHCPv6 (another post).

IPv6 addresses, besides being obviously longer than IPv4 addresses, are not terribly different from IPv4.  In most unicast addresses, the high order 64-bits are for the subnet mask (also called the prefix length) definition and the lower order 64-bits are for host addresses just as the IPv4 address can be broken into subnet and host values.  It is these addresses we will focus on address assignment with.  If you want more on specifics on IPv6 addresses types, go read Wikipedia.

SLAAC uses the aforementioned Router Advertisements to get the network configuration that the address will need for the higher order bits.  This will define how the subnet masks and gateways should be set.

The low order bits are then picked usually using one of two methods, EUI-64 or Privacy Extensions.  EUI-64 takes the MAC address of the interface, splits the 12 high and low order bytes in half and sticks 'FF:FE' between them.  When concatenated to the high order bits, we should now have an IPv6 address that should be completely unique.  Unfortunately it also means that the IP address is completely trackable globally, and this is a bad thing from a privacy perspective.

So, someone came up with Privacy Extensions.  Privacy Extensions adds some randomness to the IPv6 address creation function, which changes under a variety of scenarios.  This solves the problem of privacy, but can often make the IPv6 addresses difficult to track... an issue I will go into length about later.

Network configuration was a different thing back in 1998.  Nowadays IPv4 addresses are tightly controlled tracked and managed.  A device deciding on its own address is completely unheard of.  If your policies depend on that level of management, we've hit upon your first and possibly biggest hitch in managing IPv6 address space because DHCP, a common solution to IP address management problems, has a similar service available called DHCPv6.  But as we will see, it works very differently.

Neighbor Discovery Protocol: Part 3 - To Find Routers

NDP has one last really interesting feature.  NDP is responsible for announcing routers.  This is the first really new-to-us feature we've come across.

As anyone who has tried to manage a network knows, configuring the hosts on it can be difficult and tedious using static addressing.  DHCP is a necessary feature.  With the increase of address space, the lack of a true broadcast, etc, the thoughts of the designers was that the network could configure itself.  IPv6 can configure itself (we'll talk about how later), but one of the mechanisms it uses to pass data on network configuration to a host is via a 'Router Advertisement'. 

Router advertisements contain details of how network hosts should be configured and what the network looks like from the client's perspective.  It only contains IP addressing details and NOT DNS/NTP/WINS and other such features we expect from DHCP.  Oh, and router advertisements are ideally _only_ sent by routers.

In 1998, the term 'router' was very specific.  Routers were run by network administrators, and very few OSs (and even fewer deployed) that had the features to route traffic in any sort of robust fashion outside of a device specifically built to route packets.  NAT devices were not as widespread as they are now.  So in 1998, it was completely expected that only routers would want to advertise routes.  This is somewhat laughable in 2010, but this is how it works.  It is a non-negotiable function of the protocol.

A device which presents as a 'rogue router' works in much the same way as a 'rogue DHCP' server.  It would have the potential to knock a system offline.  There is a priority feature, so what happens to hosts depends on what a client's default behavior is, what the legitimate routers are doing, and what the particular circumstances of the rouge router is.  We're going to talk about some of the security issues around this later, but lets move on to what these route advertisements are used for.... configuring IPs.

Neighbor Discovery Protocol: Part 2

When we last left NDP, we were talking about ARP, and why it won't do what we want it to do.

From RFC 4681:

IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reach-ability information about the paths to active neighbors.

In other words, its more than ARP, its an Adventure!  Let's go through each one of these.

"To determine each other's presence, to determine each other's link layer addresses"
So, this is the original ARP protocol's functionality. ARP determines if an address within a subnet is contactable and determines what addresses are configured on specific hosts. A quick tcpdump of such a packet looks like this:

22:15:26.847304 IP6 fe80::a14a:be36:4596:890d > ff02::1:ff89:7f9d: ICMP6, neighbor solicitation, who has fe80::81a0:12e8:7e89:7f9d, length 32

This is an ICMPv6 packet (more on ICMPv6 later) which is called a 'neighbor solicitation' which queried a well known multicast address called the "all-nodes multicast address" (which sounds like a broadcast, and effectively is, but its not... just trust me on this for now).  In the same fashion as ARP, the machine with this address responds with a 'neighbor advertisement' via unicast (more on unicast vs. multicast later). 

This process happens completely in the IPv6 layer.  There are no MAC addresses being passed back and forth and we've eliminated broadcast traffic.  So in this one feature, we've completely replaced ARP already.

"to maintain reach-ability information about the paths to active neighbors" 
(Yes, we skipped one)

Because there is a looser coupling between MAC addresses and IPs, and because we want to reduce the need to broadcast things on the network (which still means less packets to the "all-nodes multicast address"), NDP includes a way to check on whether one node can still reach another node and sends the same 'neighbor solicitation' messages via unicast.  This only happens when traffic is actively being sent to the host to eliminate reliance on protocols further up the chain to do the right thing.

I think we'll talk about finding routers tomorrow.

Neighbor Discovery Protocol, Part 1: The History

IPv4 networks are interconnected with routing protocols to move data between networks of different institutions.  An institution's network might be subdivided into sub-networks or 'subnets' that also use routing protocols at the IP later, but inside a subnet IPv4 needs to interact with another protocol called ARP.  The Address Resolution Protocol is another old protocol used to help two PCs connect to each other by mapping Ethernet(MAC)addresses (Layer 2) to IPv4 addresses (Layer 3).  Computers keep track of these addresses in small tables and one can almost universally look at this table on a command line by typing 'arp -a', so give it a shot to see what I mean..

ARP uses Ethernet broadcasts to find machines who have a specific IPv4 address.  Essentially, one PC sends a particular 'request' packet out on the network to a specific Ethernet address which is heard by all devices on a subnet, and waits for responses which are directly sent to the requester from a station that knows.  Because of this behavior, ARP is sometimes considered a layer violation, although a necessary one.

There are several issues with this protocol which makes it unwelcome in the IPv6 space.

• Its not a pure IP solution.  We don't like mixing our Ethernet and our IPv4, and we don't need to in IPv6 if we fix this right.
• It relies on broadcasts, which we'd like to minimize if at all possible because IPv6 makes our subnets real big and we don't want network-wide broadcasts on real big networks.
• There is a lot more that can be done with the idea of mapping IPs in a subnet, but ARP only maps IP addresses to physical MAC addresses.  Its a one trick pony. 

IPv6 addressed these problems with a new protocol, NDP,or the Neighbor Discovery Protocol. More in Part 2 tomorrow.

IPv4 vs IPv6

Although the implied version increase that comes in the names of those two protocols might suggest something better in IPv6, I will once again reiterate that things are just different.

Much has been said about the physical differences in the packets and one can look them up if they want to see them.  I just want to focus on a few points.

Quality of Service in now deeply embedded in the packet in two fields, traffic class (sometimes called priority) and flow label.  This allows routers to more efficiently handle packets according to some sort of administrative schema.  There is no real need for routers to guess at how the packet should be handled.   This essentially replaces the ToS field of an IPv4 packet, which is currently used to provide QoS through Diffserv.
.
Pre-1998, this was very, very important to network connections which were often overwhelmed, even then, with the various types of real-time vs. best-effort data streams.  Today, you get bandwidth fire-hosed at you, so there is less and less of a need for this the closer you get to the network edge.  Its still terribly important for IP Phones, teleconferencing, and other applications where near perfect 'real-time' no-latency delivery is necessary, but I don't see much use beyond applications like that.

'Next Header' replaces anything resembling a protocol field.  It is used so that rather than track a protocol following a specific format and size, a packet can just contains what the next header is.  When a device needs that next layer, it just jumps down the packet.  More than one header might exist in the packet, and we'll talk about some of the ramifications of this later.

There are two other things one should notice.  Number one, the lack of an IP checksum in v6, which is almost a direct result of the stability of networks and the acknowledgment that layers above IPv6 often have checksumming routines in them.  Additionally, basic IPv6 packets, are a uniform size.  This drastically speeds up processing of packets in routers.   Designers realized networks are getting larger, both in bandwidth and in users, and making the protocols as fast as efficient as possible was a good idea.

The goal here was efficiency.  Routers were limited in CPU, memory, and bandwidth available.  It was critical to wring out as much in IPv6 as possible.  IPv6 packets are larger and routers need all they can get to push packets around.  This is as much true today as it was then, maybe even more so since large companies push several gigs a second, which is a far cry from 1998.

Please note, I didn't use the word 'security' once in that post.  I didn't need to, there is no more security there than in IPv4.