Internet Protocol version 6 laboratory
- See also: Internet Protocol version 6 deployment
To become familiar with IPv6 in the real world, at some point, it is wise to have an Internet Protocol version 6 Laboratory. This article describes a step-by-step approach to learning the basic concepts, which are defined as the operation of IPv6 by itself, not in a coexistence or IPv4 transition environment.
It is quite appropriate, after the basics are under control, to extend the laboratory to involve more advanced topics. At this point, however, the "core" path will start to branch. One basic branch will be determined by whether one's interest is more in IPv6 applications (i.e., client and server operations) or in IPv6 networking; the latter ranges from internal routing, to Internet or virtual private network access in a pure IPv6 environment, to the relatively simple point-to-point tunneling of IPv6 through IPv4.
The beginning
It would be hard to be simpler than one client and one server, and, indeed, that may be slightly too simple, as in the figure, "Basic setup". If things were that simple, the two devices could be connected with a simple IEEE 802.3 crossover cable.
Unfortunately, with direct connected client and server, there is no way to observe and troubleshoot the interaction. Minimally, it is wise to connect the two devices to an internetworking device, such as a bridge (i.e., "layer 2 switch") that has port mirroring capability. Port mirroring allows a computer to receive, monitor and analyze all traffic on a server or client port. Another critical requirement of that switch is capturing the MAC addresses it sees on a port.
A reality may be that it is not necessarily feasible to set up and administer these first machines with native IPv6. The initial setup, therefore, admits that a dual stack might be needed, for running IPv4 from a system administration machine to second IPv4 network interface cards (NIC) on the IPv6 hosts.
Assuming that manual address configuration is supported, connect one application client and one application server, preferably to a L3 switch that has port mirroring.
Testing support
To the mirroring jack, and possibly to a second interface on the subnet if there is a separate NIC, connect a Linux “tools server”, much as one might have in a sinkhole. See the figure, "First Dymamic Addressing". At a minimum, this would be an open-source (or proprietary if they are on hand) protocol analyzer such as Wireshark or a network intrusion detection system (NIDS) such as Snort. If the hosts support the Simple Network Management Protocol (SNMP), open source SNMP analyzers are available; see the SNMP article. A support host should run syslog.
This will let the operations staff gain experience writing out the address formats (at least global and ULA should be tried), observe basic neighbor discovery and ICMPv6 if a protocol analyzer is used, etc.
The fundamental question: what do I ping?
Even in a DHCPv4 environment, a user support desk that gets a problem report can have real challenges in determining the IP address of the user host, in order to use common tools to test connectivity to it. User IDs in DHCP requests aren't always the answer, unless the organization has some way of knowing what address is associated with which physical machine.
Dynamic DNS update can help, but there is still the problem of determining the unique identifier of the user. In an enterprise that has a structured wiring plant, one approach is to have each user computer connected to a layer 2 or 3 switch port that will capture the MAC address coming into it from the user. If the ports are identified in a manner that can map to the user (e.g., Campus A, Building 3, Floor 2, Office Q, Desk 77), then one can use SNMP to query the switch to find the MAC address of the attached host. With that information, you can then search the DHCP server log to find the IP assignment, even in the absence of dynamic IP update. Of course, if your user hosts can be preconfigured with an identifier that is unique to a location, this becomes all the better.
A similar approach can apply with DHCPv6, with due regard for converting the MAC address to a 64-bit host identifier. SLAAC, however, is much more challenging, because there is no server log. In such a case, interrogating access switches to find the host MAC address for the physical location, and then computing the IPv6 address, may be the only alternative.
Adding incremental IPv6 capabilities
Next, to the same subnet, add, either to the tools box or one of two new servers, DNSv6 with dynamic update and the appropriate PKI. The lab might start with DHCP and DNS on the same machine, but it would be highly desirable to test dynamic update between DHCPv6 and DNS, across the local network, before teting the harder to reconstruct SLAAC.
Have at least one application server, running the operating system that will run your regular applications.
Anycast is worth investigating. You will need at least two servers, running some application that is either read-only or for which multiple updates will not corrupt the data. In the interest of stability, at first use only a unicast address on same host that runs DHCP, syslog, or other services that are critical to bringing up hosts, and are stateful.
If there are no readily available user applications that are read-only or can tolerat multiple updates of the same data, consider three inexpensive servers, two of which might have only DNS running on them and the other having the critical tools. By doing so, you should be able to disable either DNS host and still get name resolution from the local workstations. Anycast should be investigated further on any other server operating systems that may be used, as well as having the address accessible through different physical subnets; the latter will wait until IPv6 routing is up.
Basic IPv6-only routing
In the discussion below, "routers" may be dedicated two-port IPv6 physical routers, multiple ports on a lesser number of routers, or software simulating a router. These also can one or more layer 3 "switches" with three virtual local area network (VLAN) subnets.
Now, set up a second subnet, with at least another DNS tools server, and connect it to the first using two routers from the main subnet. If these are all interconnected via the same physical box, you must be able to put different preferences on the routes.
You are now ready to try multiple-subnet anycast. The simplest way to do this would be with additional DNS servers. Adding application servers on one of the "remote" subnets will allow testing application failover, remote address assignment, etc.
Putting additional application clients and servers on remote subnets, however, will allow more exploration of failover and load sharing.
More advanced IPv6 interior routing
Add enough additional subnets, which need not have more than a single server or client, so that there can be dynamic, multi-hop V6 routing of various flavors.
Open Shortest Path First, the IPv6 version, is probably the best dynamic interior routing protocol to use here. If you use RIP, you must be able to artificially increase the hop count associated with interfaces.
If they are familiar, this is a good time to start out router management tools such as RANCID and Nagios, if they can work with IPv6.
Initial Internet connectivity
Enable BGP on one router, and connect to a simulated ISP router with, preferably, a minimal user AS or two, with a server or two, on the far side. See the figure "Basic Internet connectivity".
Start with provider-independent (PI) addressing. If you like, experiment with provider-assigned (PA) routing dynamically learned with the Router Renumbering Protocol.
Basic Internet single-ISP multihoming
Next, enable BGP on 2 or more of the existing routers, so you can do multiprotocol iBGP in the "enterprise", and use RFC1998 multihoming to multiple POPs of a single ISP.
If enough router ports are available, have one of the eBGP connections run through a Generic Routing Encapsulation IPv6 tunnel over IPv4 physical interfaces.
More advanced Internet multihoming
Next, enable BGP on 2 or more of the existing routers, and set up at least 2-3 routers simulating ISPs, with, preferably, a minimal user AS or two, with a server or two, on the far side. Start out with basic v6 multihoming with all PI-addressing, but this gives a path to such things as shim6.
The complexity of multihoming is specific to the degree of difficulty of your real-world connectivity. It will this is a lab for an enterprise or a service provider.