IPv6 Implementation Checklist

Scope of this document

This document is intended to aid in the planning for the implementation of IPv6 with a goal of meeting the 2012 requirements of the OMB IPv6 mandate. It is not intended to be definitive or to cover the more in-depth requirements for 2014.

Train network technical staff

Technical staff responsible for IPv6 implementation need to be familiar with IPv6. Training should be done before starting as IPv6 is similar enough to IPv4 to cause both confusion and a false sense of understanding of IPv6 operation.  An excellent starting point is the IPv6 Workshop run by Internet2.

While professional training is probably the best option, a "short" alternative is an IPv6 tutorial such as the one provided by the North American Network Operators Group (NANOG). The current tutorial is available on the NANOG YouTube channel. Look for "IPv6 Technology Overview Tutorial (Part 1 and  Part 2). The last half of the second part of this tutorial is specific to cable providers (DOCSIS). 

Check all required security, management, operational and accounting tools for IPv6 capability

You really don't want to be trying to manage IPv6 space by hand! If you don't have an IPAM tool, this is a good time to consider one. They are often integratd with DNS management tools.

Talk to your network security team. IPv6 imposes a somewhat different environment than IPv4 and it does have implications for things like firewalls and NAT. Most significantly, IPv6 is very dependent in ICMPv6 for normal operations. Any policy of blocking all ICMP packets will need to be adjusted for IPv6 to work at all. See RFC 4890 for guidance as to how ICMPv6 should be filtered and what must not be blocked.

Also, your security team should be made aware that IPv6 does not offer NAT. NAT is often incorrectly thought of as a security measure. While NAT has little security significance, implementing NAT requires a stateful inspection firewall. This does provide significant security benefits and should be used for IPv6 in most every case where NAT was used to provide security in IPv4.

ULA (Unique Local Addresses) is often referred to as NAT for IPV6. It is not NAT and it may have very painful long-term consequences. Use ULA only with great caution.

Determine the type of IPv6 address space you need

If you need to use multiple providers, you need Provider Independent (PI) space which must be obtained from ARIN (http://www.arin.net). ARIN will require a signed Registration Services Agreement (contract). It will need to be approved and signed by someone with signature authority for your organization. If you will use a single provider, you can use Provider Aggregatable (PA) space which you can obtain from your provider.

Determine the amount of space you will need

Normally every SITE should have a /48 but very large sites with complex network topologies may need more space. You will need a /64 per LAN.

Do not be excessively parsimonious with address space. There is a LOT of it! Use it in a manner that will simplify management. Using less than a /64 for a LAN is perfectly valid, but many software tools make assumptions about this. Also, it is required for Stateless Address AutoConfiguration (SLAAC).

Design an addressing plan (and expect to re-design it)

The initial design should spread the address assignments across the available space. Do not assign sequential subnets as that will constrain future growth and modification.

Read the SURFnet “Preparing an IPv6 Addressing Plan” manual.

Start out with assigning IPv6 subnets where you have IPv4 subnets. This will ease design for the implementation, but do not constrain future designs to fit policies designed to maximize efficient utilization of a scarce resource (IPv4 addresses).

Audit all network hardware for IPv6 capabilities including firewall and/or intrusion detection/prevention equipment

Small routers/switches which do not support IPv6 but do support VLANs may be bypassed by dragging IPv6 packets over VLANs to a system which is IPv6 capable. Don't forget to replace the non-compliant equipment as soon as possible as the use of VLANs will complicate network management over time.

Establish IPv6 connectivity with your network provider(s)

Test to the router and to major Internet sites such as http://ipv6test.google.com/, http://arin.net, http://test-ipv6.com, and http://linux.mirrors.es.net, as well as facilities you plan to access via IPv6 (if any).

Decide if you will use StateLess Address AutoConfiguration (SLAAC)

This assumes that only designated, statically addressed servers will be IPv6 accessible. This will prevent IPv6 from becoming active on systems where it is not intended to be enabled. Most modern computer systems enable IPv6 by default and prefer it when both IPv4 and IPv6 are available for connections. Enable IPv6 on all network equipment between your CE router and the servers which will be providing public IPv6 services.

Test connectivity to external systems.

Test all network management and security tools for proper operation on IPv6. Adjust procedures as needed to account for any restrictions or limitations found. If needed, replace non-IPv6 capable tools or augment them with similar tools that are IPv6 capable.

Enable IPv6 for DNS

DNS is an excellent service to start enabling IPv6. It is easy to turn on and has no impact until the IPv6 address is added to the "glue" in the parent zone. Test this for general reachability from both internal and external systems ( Do not add any AAAA records into DNS until you are ready for them to be used!)

Enable IPv6 for other services

We suggest doing mail next and save web service to the last. Test by using an alternate name for the V6 service and/or testing on a temporary server. Until the production name has a AAAA record added to DNS, it will not impact your production service. Remember to enable IPv6 on other public services such as NTP, anonymous FTP, etc.