IPv6 Network Administration

Worked Examples

In this section we present an overview of the deployment of IPv6 in some representative networks. We look at both the technical and organizational aspects of same. The first example we look at is that of an enterprise-class IPv4-connected network, the second a transit ISP, and the third—a special case—an Internet Exchange Point.

Enterprise-class IPv4-connected network

Step 1

XYZ Corp, a company owning its own network, decides to implement a pilot IPv6 program to provoke a thorough audit of their in-house applications, which recently demonstrated fragility in the face of network instability. The pilot IPv6 programme will establish the minimum necessary IPv6 connectivity to test the applications on the internal desktop and server networks. External IPv6 connectivity is not absolutely required but will be delivered if possible.

The development team are instructed that when they are going through the code-base for the company applications, they should alter the code to be address independent and to be more resilient to failures. The implementation team have to deliver a working IPv6 platform not for the development team, who are anticipated to take quite some time when reworking the code, but for the testing team, so there is ample time for the deployment to take place.

Step 2

The deployment team begin the communication process by running an internal IT staff course in IPv6; they might use this book, vendor materials, and so on. They set up a machine for the IT department which has a tunnel via a tunnel broker, enabling them to become familiar with addressing, routing, and new features like router solicitation in an environment where it doesn't particularly matter whether connectivity is up or down. (Attempting to deploy a new protocol where a sizable proportion of staff have never executed any IPv6 related command is not recommended.)

They begin the network analysis process, and arrive at the conclusion that three things need to change: desktop network, server network (which are both separately addressed and routed networks in IPv4, and should remain so in IPv6) and egress routing. The company has decided that fiddling with their single egress router is not something they want to do, and therefore elects to get external IPv6 connectivity via some spare commodity kit they have lying around. Neither do they want to dual-stack all the internal routers between the egress router and the desktop network in question, so they decide on tunnelling as a "quick fix."

Step 3

The network design process results in an addressing architecture and subnetting architecture that looks very similar to the existing IPv4 network, except that where an existing RFC 1918 /16 was used for the internal network, the company's upstream ISP agrees to supply them with a tunnel and a /48 from their PA space. From an addressing point of view, they assign a single /64 to each WAN link for their remote offices, who are not yet IPv6 enabled, and reserve /64s for their server and desktop networks. Any tunnels between routers will also be numbered out of consecutive /64s. While it may not be optimal, it should work. The formal deployment plan now consists of commissioning a tunnel-capable router, dual-stacking the internal router between the desktop and server networks, dual-stacking the desktop network, and then dual-stacking the server network, with approximately a week's worth of testing between each step. Internal IT staff are reluctant to push an IPv6 stack into the standard patching methodology, so a supervised manual install and reboot of approximately 300 workstations is done by ten volunteers, which goes slowly but without incident. Simultaneously with this, a spare Cisco 3600 series is found, and connected to the DMZ which hangs off the existing router. Tunnels are brought up to the outside world, and to the router of the internal desktop network, for which delicate holes are punched in the firewalls. Both are found to be working.

Step 4

Internal IT staff balk at the notion of a full conversion of the existing server farm, so only four servers are converted: the two on which the server-side of the application runs, and the DNS/DHCP servers. IPv6 addresses are kept in AAAA records in the same internal zone in the same internal DNS servers—no IPv6 is exposed to the outside world. The server upgrade exposes a bug in one of the being-rewritten applications where if it makes a quad-A DNS request and does not get an answer, it returns a strange error to the user instead of falling back to A requests.

Step 5

The development team has IPv6 service enough to test their reworked application, and solicits feedback. The project is declared closed until the issue is re-opened by a later management fiat.

Transit-providing medium-size ISP

Step 1

Management in the company decides that it is time to gain experience with IPv6. While there hasn't been much direct customer demand to date, there are a couple of large influential clients that have it on their long-term radar, and there is a need to gain understanding now so as to avoid buying new equipment that might impede IPv6 deployment over its lifetime in the network.

A single individual is tasked with the job of gaining familiarity with IPv6, setting up a small test network (one router, one server and connectivity to the IPv6 Internet) and beginning the process of educating the rest of the operations staff.

Step 2

The "IPv6 expert" procures a UNIX-based server and a spare Cisco 7200 router with Ethernet and ATM connectivity. An IPv6-in-IPv4 tunnel is configured to one of the ISP's peers who have already set up IPv6, and address space is obtained from them. At the same time, the ISP begins the process of requesting IPv6 address space from RIPE, which involves preparing a deployment plan.

After connectivity is successfully set up, a variety of IPv6-capable services are configured on the server, including a web server (Apache 2), an SMTP daemon (Exim), an IMAP server (Courier IMAP) and a DNS server (Bind 9). The server is placed in the domain ipv6.ISPNAME.net, and acts as the primary DNS server for that domain. The ISP asks its (IPv4-only) DNS secondaries to carry the forward and reverse DNS zones, thereby checking on an isolated subdomain whether the addition of IPv6 records causes any unexpected problems.

To begin the very first stages of integration, IPv6 connectivity is enabled on the local office LAN of the operations centre by means of VLAN trunking on the Cisco 7200. IPv6 is then enabled manually one machine at a time on the LAN, and any problems are noted and dealt with.

A policy is instituted that any new network equipment bought must either be IPv6 capable, or have a roadmap for native IPv6 connectivity in a short timeframe.

Step 3

Having gained experience with the initial deployment, it is time to begin expanding the network and taking the first steps to integration. Expertise begins to grow throughout the company.

The ISP receives its own address space from RIPE and, while the deployment is still small, renumbering begins. This involves developing an addressing plan that will scale into the future. The organization has been granted a /32 prefix from RIPE. In the addressing plan, one-quarter of this (a /34) is assigned for the deployment project, with the rest reserved for future use. This space is then divided into four chunks of size /36 each, one for each region in which the network operates.

In line with the rules of their Regional Internet Registry, the plan then allocates one /48 to each PoP in the network. Note that these are not configured yet and may not be for quite some time—they are reserved in the addressing plan for when that time comes. As infrastructure in any one PoP is dual stacked, addresses are assigned from the appropriate block for that PoP. Customers in each region will be given allocations from the corresponding /36, which will allow the routing protocol to aggregate announcements between PoPs.

With renumbering complete, the way is now open for the ISP to run BGP and arrange peering and transit in the usual manner from other networks.

The ISP has an infrastructure based on, among other technologies, ATM and wide-area Ethernet. An additional router is procured and a dedicated IPv6 wide-area link is set up over ATM to another PoP. Private peering is arranged with a willing ISP that is also located at the same data center. This is still separate from the existing IPv4 routed network, but shares some of the switch infrastructure that, as it was used in the previous step, has been shown to be agnostic of IPv6 traffic.

Meantime, a policy is instituted that any service upgrades and new services should be IPv6-capable. Managed services staff can use the experience gained from the IPv6 server set up in the previous phase, and can carry out further experiments there before deploying IPv6-capable services in production.

Now that the prerequisites for deploying an IPv6 routing infrastructure are understood, the ISP surveys its existing network with a view to supporting dual-stacked operation. The policy of purchasing IPv6-capable equipment initiated in step 1 begins to pay dividends as the impact of IPv4-only equipment is minimized.

Early-adopter customers who are willing to participate in the IPv6 rollout can now be facilitated by means of IPv6-in-IPv4 tunnels or dedicated virtual circuits or VLANs on their wide-area links.

Step 4

The time has come to integrate IPv6 support with the existing network, upgrading or deploying workarounds where necessary. Training is provided for all operations staff, conducted by those who have gained experience in previous phases. A deployment plan is drawn up by the IPv6 team and, after an initial run-through on a single router, is handed over to the operations team to implement (with support from the IPv6 team) so that they are happy that they have the expertise to deploy and support IPv6 on their infrastructure.

In the meantime, the remaining IPv4-only managed services are undergoing upgrades drawing on the experience of dual-stacking services in the previous step. IPv6 is now provided in the routing infrastructure and on managed services as a matter of course.

As necessary for a production deployment, the monitoring infrastructure is adjusted and upgraded to ensure that IPv6-specific faults are detected and dealt with.

Customers, who are dealing with internal requests for IPv6 connectivity, can be facilitated by means of transition mechanisms and, as the rollout proceeds, with native connectivity as and when they are ready to take advantage of it.

Step 5

IPv6 is now rolled out and supported network-wide. Ongoing upgrades maintain existing IPv6 connectivity, removing workarounds where they were necessary and improving performance where only software-based forwarding was available on hardware-based routers. The IPv6 routing policy is brought into line with IPv4 and native peering is preferred over tunnels with existing peers and transit providers.

Special case: Internet Exchange Point

Introduction

An Internet Exchange Point (IXP) is a facility that provides a place multiple for Internet Service Providers to meet and exchange traffic. Their aim is to save money for the ISPs and improve connectivity for their customers. Think of it as a switch into which multiple customers connect over WAN links; it's a way to get direct peer-to-peer connectivity in a scalable fashion.

There are two basic scenarios for how IPv6 might be used within the context of an IXP. First, an exchange itself might like to enable IPv6 services to offer to its members, and second, a member might like to participate in IPv6 peering across an exchange.

Step 1

The members of the IXP decide to implement IPv6 as fully as possible within the exchange as part of the goals for the next financial year. As part of the usual schedule of rolling switch upgrades they specify that vendors will be unable to respond to tenders without including details on their level of support for IPv6.

Step 2

IXP operations decides to do the easy bit first, and applies for special IXP address space from their nearest RIR. They examine the RIR Comparative Policy Overview,^[21] which specifies that to qualify for this space, "the IXP must have a clear and open policy for others to join and must have at least three members." The IXP qualifies, so they continue with their application. The exchange point mesh is itself "neutral" and should not be seen to receive transit from any particular member.

The address space that is received is for the peering mesh only. While it's assumed that the direct peers of an IXP will route this /48, it's likely that other more remote networks will reject advertisements of such a small network. The operations team therefore assumes that this address space, while unique, is not globally routable and so can't be reached from all places on the internet. Services such as looking glasses and NTP servers that need to be globally reachable must still get their address space from one (or more) transit providers. Thankfully in this case, one of the members is already providing IPv4 address space for the services LAN, and can persuaded to provide IPv6 address space for it too. There is little danger in this particular case of the members falling out and withdrawing address space, so it is viewed as an acceptable risk.

Step 3

Fully-capable IPv6 switches and operating system versions are obtained, and a scheduled upgrade is performed. This upgrade also dual-stacks the existing server in the services LAN, as well as its associated services. Testing reveals no problems.

Members now have the choice of presenting at the exchange with a second IPv6-only router, or simply dual-stacking their IXP router. Policies are rewritten to ensure members turn off RAs on their IXP present routers, and peering is negotiated between members as usual. The operations team extends its monitoring system to include member IPv6 addresses, implemented via a database. Successful peering happens within weeks of the upgrade, and the project is declared a success.

---

^[21] Found at http://lacnic.net/en/rir_comp.html.