DHCPv6 Stateful Addressing working

We now have DHCPv6 running on our test network. I have been experimenting with two different DHCPv6 servers. They are WIDE DHCP which is IPv6 only, and ISC DHCP server, which has IPv6 capability as of version 4.x.x.

WIDE DHCP server was very simple to configure, and I will post the configuration I used in the configs section. I was able to assign an address along with DNS configuration to the hosts. It is unclear how I would use this server to assign addresses for multiple subnets as up-to-date documentation on the subject seems scarce.

Today I compiled and configured ISC DHCP server. It is currently assigning addresses, but I have something wrong in the config for assigning a DNS server. Once I have that worked out, I can post the config. I am about to test DHCP relay so that my server will be able to assign addresses for multiple subnets. More on that once I get it working.

Basically we will be going with the ISC server because we are currently running that same server for our IPv4 network. The structure of the configuration file is similar so learning it should be easier. We cannot server both IPv4 and IPv6 addresses through the same process with ISC DHCP, therefore in the production network it will be necessary to run two instances of the server on the machine, one listening for v4 and the other for v6 in order to maintain our dual-stack system.

DHCPv6 vs. Stateless Autoconfig vs. Stateless DHCPv6

The DHCPv6 server has been successfully configured today. Hosts now receive DNS configuration information from it during automatic host configuration.

Now that we have the components in place, there is an opportunity reflect on the options available to us for host configuration. Basically there are four ways to configure an IPv6 host.

1. Manually: Hosts can be given a static IPv6 address set manually. This is suitable, and necessary even, for servers, but obviously not very scalable to apply to hosts.

2. Stateless Address Auto-configuration: Hosts receive a prefix assignment from their IPv6 gateway router and automatically generate a host address.

3. Stateless DHCPv6: Hosts perform Stateless Auto-configuration for their IPv6 address and then are instructed by the router to use DHCPv6 for additional information such as DNS, WINS, NTP, etc.

4. Stateful DHCPv6: Functions exactly the same as traditional IPv4 DHCP in which hosts receive both their IPv6 address and additional parameters from the DHCP server.

Which of these option should be used is a subject of controversy in the networking community. Auto-configuration is a very streamlined process which is built into the protocol itself. This means that it will work on ANY IPv6 implementation. Indeed there are situations where auto-configuration makes sense such as on home networks.

In terms of the enterprise, there doesn't seem to be any real advantage to using auto-configuration, particularly when it lacks a mechanism for DNS configuration. Since we must use a DHCP server to assign distribute this information to hosts connecting to the network, why not just assign an IP address along with it?

By using this model, we are also provided with better accounting of address usage in the network, knowledge of who has which addresses and when, comprehensive configuration flexibility, and detailed logging. Furthermore, we can still make use of auto-configuration in parallel with Stateful DHCPv6 when and if it becomes necessary.

Therefore, I will switch the network over to full DHCP in the coming days. 

Building a DHCP Server

The one thing that has not yet been experimented with in this project is DHCPv6. The next step, and likely the last one in this project, will be to build a DHCP server to work with our IPv6 network.

At this point, we are using Stateless autoconfig to deploy host addresses. We would like to retain that funtionality moving forward. One of the caveats of SLAC is that it does not provide a mechanism for distributing other host information such as DNS servers. Fortunately, DHCP can be used to provide hosts with this configuration without assigning an IP adddress.

This will involved configuring the server, and also changing the IPv6 advertisement on the router in order to indicate to hosts that they will need to contact a DHCP server to obtain their DNS configuration.

In the future, we may also be using the DHCP server to distribute new prefixes on the network.

Reverse Lookups

I am pleased to report that reverse lookups of IPv6 hosts on DNS are working. I will post the configs here for anyone who wants to see what they look like.

IPv6 DNS

For the past few sessions I have been reading documentation and working on building a DNS server that is both accessible via IPv6 and will resolve IPv6 hosts.

So far I have a simple configuration using BIND9 and it is working with forward lookups. I am still wrestling with the reverse lookup zones. BIND is ignoring them and throwing some sort of error when it starts. I will continue to work with the system this week and hopefully "resolve" the issue (bad DNS pun).

Once we have this working, we'll be able to make our external services available on IPv6 pending the acquisition of a public address routed to us.

Weekly Update

Here's one of my update submissions for the week before Spring Break.


IPv6 has been enabled on a second subnet on the campus core router. We are now assured that the equipment can seamlessly enable IPv6 on a given subnet without any sort of disruption to the existing network services, and the equipment is capable of routing traffic between subnets with minimal configurations. Both protocols function as separate networks and co-exist peacefully. 
In order to facilitate a wider deployment, an addressing schema is needed to determine how logical addresses will be distributed throughout the network. This week, I pulled up the documentation for the existing IPv4 schema and used it as a template for a proposed IPv6 layout. Since IPv6 includes a dedicated section of the address for the purpose of subnetting, this eliminates the need for complex address conservation schemes. I have opted to use the VLAN ID numbers as the subnet address. In this manner, it is easy to tell which subnet traffic is going to or from by simply looking at the address. This will help ease troubleshooting when dealing with very long 128-bit addresses.
We are still awaiting a public allocation from ORION. They have responded to our request for an address block, but we could be waiting some time for it to be added to their infrastructure. We also need to establish how they handle renumbering situations.
Because of the large address space in use with IPv6, it may be necessary for ARIN to change allocations of IP blocks in order to make summarization of routes more efficient. Because of this, we will need to come up with a method to renumber our network in at the very least, a somewhat automated fashion. This has been the subject of some research this week and research will continue in the coming weeks, hopefully with some input from ORION.
For the coming week, researching the mechanics of network renumbering will continue. If we receive our public addresses from ORION, then we can begin testing public IPv6 access and network edge/firewall considerations. Also, I would like to take some time to evaluate how far we’ve come so that I can better understand where we can get this project to by the end of the semester.

Prefix Delegation Research

The majority of time this week has been spent on researching DHCPv6 and Prefix Delegation.

DHCPv6 can be deployed in an IPv6 environment with varying degrees of usage. One way is to use it just like in IPv4, where each host requests both an IP address, and additional configurations such as DNS, gateways, etc. This method provides precise control over address assignments and detailed tracking of host addresses. It is often used in Enterprise environments because many administrators feel there is a need for that level of control.

Another option is to have host addresses assigned through the Stateless Address Auto-configuration (SLAAC) mechanism provided in IPv6. Using this mechanism, the router advertises the network prefix for the subnet, and the hosts on that subnet automatically generate their own interface address (usually 64-bit). This mechanism works for obtaining an IP address ONLY. Additional configuration such as DNS is then obtained by contacting a DHCP server. In this case, the router informs the host through the Router Advertisement message that it should use SLAAC for it's address and DHCP for additional parameters.

We are leaning towards the stateless option.

In addition to host configuration, I have been investigating the conept of "Prefix Delegation" in IPv6 networks. Because it is possible that an organization using IPv6 may need to change it's Global Prefix, there must be a mechanism for renumbering the entire network. The is where prefix delegation comes into play.

There is a "delegating router" which passes out new prefixes to the rest of the routers on the network (requesting routers) which they then advertise for hosts to use in SLAAC. In most of the examples, the prefix delegating router is on the ISP network. We will need to contact our IPv6 ISP in the near future to find out if they use this mechanism and hopefully they can clarify exactly how the process works.