29 May 2012

Managed IPv6

In the IPv4 world that many of us grew up in, we had 2 quite simple options for configuring hosts; Static Addressing and DHCP. On (very) small networks, and for servers, we would explicitly configure one or more IPv4 addresses on a host that would be there (in theory) no matter what. No dependence on external resources to have an address configured. You didn't even need to have a physical network cable plugged in! (Although that would somewhat defeat the purpose in most situations)

As you would expect, things are a little different in IPv6..! In my not-so-humble opinion, this is the biggest "problem" facing IPv6 adoption, but the whole arrangement is still undergoing refinement.

We now have 3 methods for configuring addressing under IPv6:

  1. Static Addressing
  2. DHCPv6 (Also called "Stateful Autoconfiguration")
  3. Stateless Address Autoconfiguration ("Autoconf")
This article will go briefly through each option and how it applies when trying to manage a network.

Static Addressing

Nothing much has changed here; you can still configure your server with one or more fixed addresses


This isn't too much different save for one thing; hosts do NOT automatically attempt DHCP when they first connect to the network. First, they try Autoconf....

Stateless Address Autoconfiguration

This is the all new "whizz-bang" method that a host will use as it's first method for configuring an address when it connects to a network. For all the gory details, check-out RFC-4862. I'm going to focus on how this affects us when we're trying to manage a business network.

Getting Connected

For most of us, part of running an IPv4 network includes a DHCP server (and possibly a backup DHCP server). When you connect a new computer to the network for Sue in Accounts, this is what happens (normally, in a functioning environment):
  1. The OS realizes that the network cable is plugged in (Layer 1 UP)
  2. A DHCP_DISCOVER is broadcast to
  3. Our DHCP server picks up the request and make a DHCP_OFFER
  4. The client accepts the DHCP_OFFER and replies with a DHCP_REQUEST
  5. Server approves the request with a DHCP_ACK
It's simple, the client picks up ample information in addition to it's address:
  • Default Gateway
  • DNS Servers
  • Time Offsets
  • NTP Servers
  • WPAD Addresses
  • Domain Name(s)
Now let's add IPv6 into the mix... The most basic process assuming you have an IPv6 enabled router on the local subnet goes something like this:
  1. The OS realizes that the network cable is plugged in (Layer 1 UP)
  2. An ICMPv6 ROUTER_SOLICITATION is multicast to FF01::2
  3. Any (and all) IPv6 routers on the network reply with an ICMPv6 ROUTER_ADVERTISEMENT
  4. The client receives the advertisements which advise it only of the local subnet in use (ie: "You are connected to 2001:db8::/64")
  5. Client then generates it's own IPv6 address, prefixed with the network advertised by the router.
That's the basic process, which has several shortcomings:
  • The client has very little information about the network and it's place in it. Of the list of information we provided in IPv4 (above), we now only have ONE piece of this information: a gateway we can use. We don't even know where to find a DNS server (!!) which or our domain name. Of course, a domain name is pretty useless without a DNS server anyway!
  • The router has no idea who the client is, or what address it has taken, since there is no bi-directional communication between the client and the router to "arrange" connectivity configuration.
What is the impact to us?
  • Without DNS, Time offets, Domain Names etc, the client is still pretty "dumb". We have to configure more manually.
  • Without any form of 2-way configuration, we have no records of who had what address when; with IPv4 we would be able to review our lease pool and/or logs to see (at minimum) the mac address of a client, and usually the hostname of the client to help identify it.
  • A sneaky client could connect to the network without sending a ROUTER_SOLICITATION since routers send ROUTER_ADVERTISEMENTS at regular intervals anyway. A host could configure itself without ever sending a single frame onto the wire, and in a subnet with 18,446,744,073,709,551,616 addresses, that's a lot of room to hide (or lose) a host.

Enter DHCPv6...

While this is a pain in the proverbial, part of the ROUTER_ADVERTISEMENT message includes 8 one-bit flags; two of these help us:
  1. Managed Address Configuration Flag
  2. Other Configuration Flag
RFC-4861 explains these best:
"Managed address configuration"When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information.
"Other configuration": When set, it indicates that other configuration information is available via DHCPv6.  Examples of such information are DNS-related information or information on other servers within the network.
So, by configuring our router to set these flags appropriately, we can ask the client to request further information using DHCPv6... Yay!

This is fairly straight forward for the most part if you're familiar with IPv4 DHCP. Many of the current DHCPv6 servers are somewhat immature and still require more development work, particularly in terms of logging, and integration with existing DHCPv4 configuration, but at least they will let you get the required configuration information out to the clients without having to manually configure each.

The catch!

The observant will notice that I said the flags within a ROUTER_ADVERTISEMENT can ask a client to use DHCPv6; nothing forces the client to do so. It can still just take the advertisement, disregard the Managed and Other Configuration flags then configure it's own addresses. Of course, this isn't very different to a mischievous IPv4 client capturing traffic on the wire to find the local subnet then configuring it's own address, but IPv6 makes this much more simple.

Finally, some hosts do not even have DHCPv6 client support..! Linux for example has Autoconf support in the kernel; it will take a ROUTER_ADVERTISEMENT and configure itself (unless disabled with sysctl). Unless you explicitly install a DHCPv6 client and configure it, you will have either an Autoconf address, or have to configure static addresses. Unfortunately, other platforms such as Windows are ahead of Linux here.


The whole process has become much more complicated; we now require a router to actively advertise itself to the local network, as well as a DHCP server, AND the clients need to respect the Managed and/or Other flags of the advertisements sent by the router.

I have been running radvd and ISC DHCP on our local network, although static/manual configuration is still the primary method used to configure hosts. I believe recent development to ISC DHCP has considerably improved it's functionality however I have not had the opportunity to experiment yet.

Please let me know your experiences with managing IPv6 address configuration.

No comments:

Post a Comment