Networking Project - IPv6 Migration

DHCPv6 Stateful Addressing working

2010-04-16T08:35:00.000-07:00

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

2010-03-31T08:58:00.000-07:00

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

2010-03-26T07:00:00.000-07:00

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

2010-03-19T08:52:00.000-07:00

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

2010-03-17T08:24:00.000-07:00

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

2010-03-11T07:42:00.000-08:00

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

2010-02-26T08:59:00.000-08:00

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.

Second VLAN

2010-02-25T08:41:00.000-08:00

IPv6 has been enabled on a second VLAN and the two are happily exchanging packets across the core. I shifted gears on the project and spent the day building a server that's not directly related to the project. I want to conclude my research on Prefix Delegation on Friday.

Home Network Configs Posted

2010-02-18T17:36:00.000-08:00

The configs for my Cisco devices on my IPv6 tunnel experiment at home can now be viewed. Check "Sections" at the top of the blog.

Surfin' IPv6

2010-02-18T09:50:00.000-08:00

I finally succeeded in building my home network IPv6 experiment using the Hurricane Electric tunnel broker.

To make it work I used a Cisco 2612 Router and a Catalyst 2950 24-port switch. I used sub-interfaces to divide up the single Ethernet port on the 2612. One interface is facing the Internet, the other is facing my home network. The 2950 is used to trunk the VLANs and give me as many ports on either side as needed.

The first step is to get IPv4 working. I created an IPv4 DHCP server on the router to assign IPv4 addresses internally. On the outside, I set the interface to be configured via DHCP from my ISP. I used RFC 1918 addresses inside and implemented NAT. Once everything was turned on and configured I was able to surf normally on the IPv4 internet.

When you sign up for a tunnel from Hurricane Electric, they supply you with a Tunnel configuration. I transferred this to my router, then supplied an IPv6 prefix for my inside interface. I plugged in the workstation and address autoconfiguration took over and assigned an address from my allocated prefix. Beautiful!

I was curious to see how the network would behave with dual-stack enabled on the host. When pinging various sites, I found that some would respond with IPv6 ping replies, others would continue to use IPv4. It seems the operating system tries IPv6 and the fails over to IPv4. I was surprised at how simple everything was and how well it worked without any sort of special attention. Both protocols coexist peacefully. I then turned off IPv4 and surfed solely on IPv6. Some sites work, such as Google or YouTube (although some of the ad banners failed to resolve =D ) but it appears that many services are still not IPv6-enabled.

It was a fun experiment and I gained a good picture of how IPv6 is manipulated on Cisco IOS, as well as how the two protocols behave together. I'll post the configs somewhere a little later today or tomorrow.

IPv6 Enabled on the Core!

2010-02-17T08:52:00.000-08:00

I am pleased to report that today we successfully enabled IPv6 on one of the two core routers here on campus. We configured one of the existing VLANs with the necessary statements to enable IPv6 with address autconfiguration. The config differed slightly from the lab environment. On the 6509 switch with IOS 12.2SX, ipv6 unicast-routing was required globally. The config resembled this:

   ipv6 unicast-routing
interface vlanXX
      ipv6 enable
   ipv6 address 2001:db8::/64 eui-64

The ipv6 enable command is likely redundant but I added it just in case, if for no other reason than being a clear flag saying that an interface is enable for IPv6. We'll need to document everything up to this point and start researching what will be involved in making our network services IPv6 reachable.

Weekly Update

2010-02-17T08:43:00.000-08:00

This is a little late, but here's last week's update:

ARIN has responded to our request for IPv6 allocation this week. The request has been granted and we are approved for IPv6 allocation. The only problem is that they are requesting a yearly fee of $1250.00 USD. After discussing it with networking team here, we have decided that the cost cannot be justified at this point. We are going to have to explore an alternative option of we want to connect our IPv6 network to the public Internet.

Two options were explored previously. One was using a tunnel broker such as Hurricane Electric (http://www.tunnel-broker.net) to give us a free allocation and tunnel it over our existing IPv4 connection. This solution is really only practical for a testing situation and would not be a final solution. The second option is to obtain an allocation from one of our ISPs. The reason we decided against this initially is because we wanted to keep the same address prefix regardless of which ISP we are currently with. If we obtain an allocation from the ISP, we will lose it if and when we change ISPs. Nevertheless, I have discovered during my research that IPv6 contains mechanisms which simplify network renumbering, so it shouldn't be a real problem at this point.

In other news, I have successfully built a test network and connected the lab machines to it. IPv6 address autoconfiguration is working and basic connectivity between hosts has been achieved. I was also able to implement a dual-stack environment in which hosts on the subnet were reachable by either IP protocol (6 or 4). The next step was to test IPv6 routing between two subnets. I learned that IPv6 routing was very simple to implement and functioned in a nearly identical fashion to that of IPv4. At that point, the network administrator had me do a quick test involving configuration of an IPv4-only network, then enabling IPv6 and seeing what effect (if any) there was on IPv4 connectivity. The results were satisfactory and we are now ready to experiment on the production network.

For next week, we will construct a network which is connected to the core and has IPv4 reachability to all campus services. Lab machines will be connected to it, and IPv6 will be enabled.

Additionally, we need to start investigating how we will receive a public IPv6 allocation from one of our ISPs. If implementations for next week go well, we will document everything up to this point and I will begin researching conversion of network services like Active Directory, DNS, DHCP, Web, etc.

Lab Built

2010-02-10T11:49:00.000-08:00

The isolated test lab has been built. It features three workstations (WinXP, Win7, and Linux) to use for testing. The Cisco ASA 5505 has been configured with VLAN interfaces. There are two interfaces, each corresponding to a different IPv6 subnet. When the workstations are plugged in, autoconfiguration kicks in and works beautifully.

I have observed that the IPv6 default gateway on the client machines is actually the "link-local" address of the router. This means that you don't have to burn up global addresses on router interfaces. Very cool! So far pinging only works on the local subnet. It seems the Cisco ASA 5505 will not do inter-vlan routing, so we'll have to insert some sort of router.

The interface config is very simple:

    interface vlan 1
     no shutdown
     ipv6 enable
     ipv6 address 2001:db8::/64

Autoconfig takes over and assigns host addresses. There are more commands available to adjust the router discovery process, and that may be necessary when we start playing with DHCP, but for now, there it is.

Weekly Update

2010-02-08T07:43:00.000-08:00

Efforts this week consisted of assembling the information needed to be submitted to ARIN for our IPv6 address allocation. A form is provided via e-mail from ARIN with a series of questions regarding existing address usage and proposed usage of the new assignment. The bulk of the work was in digging up documentation and updating it on how the current IPv4 allocations are being used. It has been quite some time since these assignments have been reviewed.

After assembling that information on the form and answering the remaining questions, the form was presented and approved at our weekly meeting. It should be submitted by this morning. Project timelines will need to be adjusted once we have an idea of how long ARIN will take to process our request.

In parallel to the ARIN form, I have been experimenting with a Cisco ASA 5505 in order to understand how it will be used to set up our test lab. I have learned that the device can be configured as an IPv6 router and should suit our purposes in the coming weeks quite well. The configuration should be complete and ready to be connected to our lab. A physical space has been cleared to build the lab. It will consist of about three workstations, including at least one Linux machine. We may also attach a server.

Time next week will be spent setting up the workstations and getting basic IPv6 connectivity between them. Using this functioning lab, we can evaluate how router configurations and host configurations will interact on the rest of the production network. If time permits, we will also experiment with dual-stack IPv4/IPv6 configurations on both the hosts and routers. It is doubtful that we’ll be able to get any farther than that, but the next milestone on the time line (approx. 3-4 weeks from now) is to have network services such as active directory, DNS, DHCP, etc, working in the lab. To do this, dual-stack will need to be running on hosts.

Cisco ASA

2010-02-03T11:28:00.000-08:00

I've borrowed a Cisco ASA today for experimentation. I'll be returning it Friday. It should function as my switch that supports 802.1q.

The plan is to use subinterfaces on the 2600 router and trunk them to physical interfaces on the ASA. Judging by the poking around I've done in the IOS on the appliance it should suit my purposes. However, if I plan to keep the solution up and running I'm going to have to find a more permanent fix using equipment I won't have to borrow.

Additionally, since I'll be using the ASA as the edge device of my IPv6 test network, this will serve to familiarize me with configuration of the device. I would like to install the ASA on the test network on Friday after our meeting. Later this evening I'll be producing a project timeline and hopefully submitting our application to ARIN. I'm still unsure how long it will take to have the allocation.

I'll post again if I get IPv6 connectivity at my house tonight!

Tunnel Brokers

2010-02-01T13:39:00.000-08:00

I have applied for a free 6in4 tunnel from Hurrican Electric. The tunnel enables you to connect to the IPv6 internet. In order for it to work, you need a router that has a public IPv4 interface (it can be DHCP from your ISP) and the router must be IPv6 capable. Once the tunnel is registered, they will allocate a /48 block for use on your network.

Essentially, it takes the IPv6 traffic on your network and encapsulates the IPv6 packets inside IPv4 packets for routing across the Internet. On the other end of the tunnel, Hurricane Electric de-encapsulates the packet and then forwards it to the rest of the IPv6 routers. By using this I can experiment with IPv6 on my own network without the need to be present at the college.

Plus it's just plain awesome :)

I will be using a Cisco 2600 router that I have laying around as my gateway router. I'll post the configuration when I have everything working. Since the router I have only has one Ethernet interface I'm going to create subinterfaces on that port and then trunk them using a Cisco Catalyst 1900 switch.

I discovered when I hooked everything up a couple days ago that the switch does not have IOS, and it's trunking protocol is ISL. I'll need to get IEEE 802.1q working on the switch since that is the only protocol the router speaks; a minor snag which I hope to have worked out in the next day or so.

I'll post configs somewhere when it's done as an example.

Anyone interested in building their own IPv6 network can do so by registering at http://www.tunnelbroker.net

UPDATE: Apparently Catalyst 1900 switches cannot be made to use 802.1q and the version of IOS on my router, as well as a few other versions I have, do not support ISL!! My remaining options are to track down an ISL capable IOS, or purchase/acquire a interface module for the 2600 router so I don't have to do subinterfaces. I won't be making any furthur progress until Wednesday.

Acquiring Address Block from ARIN and Building a LAB

2010-01-30T15:40:00.000-08:00

I've spent the week researching some of the technical details of IPv6. We need to figure out how we will be addressing the network. We will be building a small pilot network in a lab environment. It will be demarcated from the rest of the network by some sort of firewall/routing device.

After a meeting we've decided that our first order of business will be to acquire a block of IPv6 space from ARIN. During the next week I'll be putting together the request and having it all checked out and ready to go by next Friday. Once we have the addresses we can begin addressing our lab environment. We're looking at using DHCPv6 rather than the stateless autoconfig option as the autoconfig assigns an address only and not DNS information. DHCPv6 should allow a more fine grained control over the deployment.

Also on the list this week is to configure the device we are using to sit between the pilot IPv6 network and the rest of the campus equipment. We will likely be using a Cisco ASA and a few workstations for the inital lab. After everything is connected and addressed we can begin testing network applications to work out the kinks for a campus-wide deployment some time in the future.

I'll be producing a timeline for what I want to accomplish by the end of the semester and posting it here.

Project Overview

2010-01-27T07:49:00.000-08:00

The subject of my project will be to migrate a corporate IPv4 network to IPv6. This will involve researching the nature of IPv6 networks including functional differences to IPv4, network design paradigms, routing, and optimization. The project will be carried out at Sault College in Sault Ste. Marie, Ontario. The initial phases of the project will consist of familiarization of IPv6 functionality, followed by a readiness assessment of the existing network infrastructure and systems. This information will be used to determine the approach to migration. A major question that will need to be answered is whether or not the network administrator will want to migrate a small portion of the production network, migrate the entire network, or build an autonomous “pilot” network and integrate as required. Once an approach is determined and a scope is defined, a network will be designed to meet the criteria and then implemented. A migration of at least a small portion of the production network is a desired outcome, as one of the learning goals is to solve this type of challenge. To that end, detailed documentation will be the emphasized in hopes that others can learn from the challenges encountered during the project should anyone else be undertaking their own migrations.

According to the IPv4 exhaustion counter by Geoff Huston, Adjunct Research Fellow at the Centre for Advanced Internet Architectures, the projected date of IPv4 address pool exhaustion is September 2011 based on current trends. The time for smooth transition has likely already passed, meaning that there is a possibility of disruption of internet services as we are all forced into transitioning our networks. This project will serve to discover what challenges will be involved in migrating networks to the new addressing scheme. Based on the forecasts, the skills and documentation developed will be in extremely high demand in the coming years.

Upon the completion of this project I hope to have developed a working knowledge of IPv6 networks and to be as comfortable working with them as I am with IPv4 networks. In addition to understanding the protocol itself, I will learn about its effects on existing network design paradigms, ancillary systems such as DNS and DHCP, and how local ISPs carry the IPv6 internet in the process of connecting our IPv6 network with the internet.