Under the theme, "The Future is Forever," ISOC's World IPv6 Launch on June 6, 2012 marked the largest industry commitment to and deployment of IPv6 in the history of the Internet. Participants of World IPv6 Launch included major ISPs, web companies and home networking equipment manufacturers from around the world.
In order for home router vendors to participate in World IPv6 Launch, ISOC required that the companies enable IPv6 'on by default' through their range of home router products and successfully complete the IPv6 Ready CPE Logo Interoperability testing at the UNH-IOL. Thus, in preparation for the launch, the UNH-IOL hosted its fourth home router test event allowing vendors to test the interoperability of their IPv6 implementations and satisfy the requirements for World IPv6 Launch participation.
During the UNH-IOL IPv6 CE Test Event, participants tested their IPv6 implementations against the IPv6 Ready CPE Logo Interoperability test specification using common interoperability test beds, including: Ethernet and DOCSIS networks, as well as DSL Wide Area Networks (WAN). Figure 1 below shows the network topology used during the test event.
Participants included both returning home router vendors that participated in previous UNH-IOL IPv6 CE interoperability test events and vendors that brought products to test for the first time. Vendors that attended previous events were validating updated implementations to meet the latest requirements in IETF 6204bis, such as DHCP SOL_MAX_RT. Those vendors attending the event for the first time were able to leverage other vendors' previous experience and resolve implementation issues more quickly than during the past events. This allowed them to proceed beyond the basic testing and validate more advanced IPv6 features.
Network
o The WAN interface of the CE Router was a DOCSIS, DSL or an Ethernet network
o Network Registrar (CNR) acted as both the DHCP-Server1 and DNS-
o Host devices connected to the LAN interface of the CE Router consisted of a mix of popular operating systems including: 7, and Mac OS X Lion
The test cases were performed to verify that a home router implements IPv6 routing specifically, that the home router properly looks up IPv6 addresses in the routing table and sends packets to the correct interface, and that the home router otherwise behaves as a proper IPv6 node as defined by the IETF.
Test Results
Tests were also designed to verify the WAN side configuration, where a node supports protocols necessary to enable IPv6 deployment on multiple network access architectures.
Detailed test cases for this event were developed from the requirements designated as "MUST" and "SHOULD" in the IETF Basic Requirements for IPv6 Customer Edge Routers.
Home routers successfully demonstrated support for a wide variety of existing IPv6 functions, as well as new features in anticipation of World IPv6 Launch. Functionality was tested for DHCPv6 clients, DHCPv6 servers, DHCPv6 prefix delegation, DNS, PMTU, and IPv6 routing.
It was noted during the event that there was an increase in implementations supporting DHCPv6 stateful servers on the LAN interfaces. This allows IPv6 devices on the LAN interface to use DHCPv6 to acquire an IPv6 address and DNS information.
It was also observed that three out of the 10 home router implementations demonstrated support for DHCPv6 prefix delegation allowing the router to further break up a large delegation of prefixes to a home network.
In addition to the required testing, some observations were made around 6RD, DS-Lite and DHCPv6 servers supporting prefix delegation on the LAN interfaces. There was a significant increase in the support for transition mechanisms in comparison to previous test events. Half of the implementations supported DS-Lite and 6RD. These features were added at the request of ISPs deploying IPv6.
Issues that were observed during the test affecting IPv6 home router implementations -- many of which were resolved post-event in order to satisfy the World IPv6 Launch requirements --included:
* DHCP Solicits Frequency. In early deployments of DHCPv6, some servers may be configured to assign addresses, but not delegated prefixes. If the DHCPv6 server is not delegating prefixes, home routers will continue to transmit DHCPv6 Solicits. DHCPv6 exponentially backs off its message retransmission until reaching a Maximum Retransmission Time for Solicits (SOL_MAX_RT), which is 120 seconds. Thus, the frequencies of Solicit messages in this scenario have been noted to cause too much unwanted traffic in ISP networks.
A requirement was recently added to IETF 6204bis to support a new DHCPv6 option that can update the default value of SOL_MAX_RT to 3600 seconds. ISPs can utilize this new option to lessen the aggregated traffic toward their DHCPv6 infrastructure. During the test event it was observed that about a third of the participating home routers supported the ability to increase the value of SOL_MAX_RT through some mechanism. One implementation demonstrated the ability to process a properly formatted SOL_MAX_RT option as described in the draft, which allows the variable to be set. Since the option-code had not been officially assigned, a temporary option-code was selected to demonstrate support for the new option at the event. The option was successfully processed by the client, which adjusted its max solicit timer to the value sent by the server. It is critical for home routers to support this option in order to avoid becoming a detriment to ongoing IPv6 deployment efforts.
* Renumbering. Service providers may change the delegated prefixes given to a subscriber during the lifetime of the home router. There are several options for renumbering a home router. One option is to use DHCPv6 Reconfigure/Reply. Another is to use DHCPv6 Renew/Reply with lifetimes that timeout the old prefix, while simultaneously supplying a new prefix. When these methods are used to renumber a home router, the LAN interface transmits a Router Advertisement setting the preferred and valid lifetimes of the old prefix to zero and lifetimes of the new prefix to non-zero. IPv6 devices connected to the LAN interface update their addresses to continuously communicate to the global Internet.
IPv6 devices on a LAN that have ongoing connections through the home router may try to continue using the old address that is deprecated to complete the communication. The behavior observed at the test event was that in these scenarios, ongoing connections were dropped with no notification to the host. According to 6204bis, a home router must transmit an ICMPv6 Destination Unreachable with a code 5 (Source address failed ingress/egress policy) to the host in question. If an IPv6 device receives this error message it has the ability to terminate the ongoing connection immediately and retry using the new prefix, thus improving the overall home user experience.
* No Default Route. When a route is no longer available on the home router's WAN interface, the router must transmit a Router Advertisement with a router lifetime of zero to the LAN interface. This advertises the inability for IPv6 devices to use the home router as a valid route to the global Internet. During initialization, 20% of the home routers were unable to transmit Router Advertisements until they received a Router Advertisement on the WAN interface with a valid router lifetime. Thus, if a router lifetime was set to a large value on the home router's LAN interface, and the router was rebooted, the IPv6 devices on the LAN interface would not realize the default route was no longer valid until the devices received a new Router Advertisement. Adversely, the home router would transmit a new Router Advertisement with a default lifetime of zero only when the router lifetime expired.
Two implementations at the test event demonstrated a new side effect of transmitting a DHCPv6 Release message for all IA_NAs and IA_PDs when a Router Advertisement with a router lifetime of zero was received on the WAN interface. This caused the loss of all global addresses for LAN IPv6 devices. The home routers would wait to restart the DHCPv6 discovery process until a Router Advertisement with a valid default router lifetime was received on the WAN interface. IETF 6204bis requires that a home router initiate DHCPv6 prefix delegation regardless of the content of the Router Advertisement, M or O flag state. During the event, both of the participants adjusted their implementations to continue DHCPv6 when a Router Advertisement was received with a router lifetime of zero on the WAN interface.
* Forwarding before Address Acquisition. During the test event a problem was encountered with IPv6 devices on separate LANs communicating after a home router is rebooted. After a reboot, there is a time period when a home router receives a Router Advertisement containing a valid router lifetime but the router has not yet received a delegated prefix through the DHCPv6 protocol. During this period it was observed that home routers were transmitting packets that were previously routed between the LAN to the WAN. This caused the edge router (ISP router) to forward the packet back to the home router causing a loop of packets in the network.
The technique to prevent this loop is requiring that home routers do not forward traffic before the address acquisition is complete. This will force the home router to treat the IPv6 traffic as unrecognized and transmit ICMPv6 Destination Unreachable message to alert the host to the problem. This behavior will prevent such loops from occurring in the network.
* DHCPv6 IA_PD & IA_NA Interactions. One issue that was uncovered during a previous test event was due to interactions with DHCPv6 Clients and Servers around multiple stateful DHCPv6 options being included in a DHCP message. This issue has not been addressed and was again observed during the April test event. The IETF has started a draft called "Issues with multiple stateful DHCPv6 options," which is aimed at addressing the issues as documented below.
According to RFC 3315, a DHCPv6 server must do the following: "If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID."
Also, a client must react according to the following text from RFC 3315: "The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user."
The IETF issued errata in August 2010 that change the behavior described in RFC 3315. The RFC has been updated to state the following for a DHCPv6 server: "If the server will not assign any addresses to an IA in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes the IA containing a Status Code option with status code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. The server SHOULD include other stateful IA options (like IA_PD) and other configuration options in the Advertise message."
Also the DHCPv6 client specification has been updated with the following behavior: "The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user."
The UNH-IOL will continue to support and follow the IETF work to address the issues that were uncovered during IPv6 CE testing at laboratory.
Conclusion
World IPv6 Launch gave home router vendors the opportunity to promote support of IPv6 in their products. Five home router manufacturers were able to participate and be listed on the World IPv6 Launch website, demonstrating their commitment to deploy IPv6 by default. The UNH-IOL test event not only supported World IPv6 Launch, but also ensured that participants thoroughly tested their home router IPv6 implementations prior to wide-scale deployment.
The experience and knowledge gained during the series of UNH-IOL IPv6 CE tests have been documented and made available to the IPv6 community, generating awareness of the issues that may need to be further addressed either in implementations or standards to ensure a seamless transition to IPv6. The test events will continue to support new functionality and standards developments as IPv6 becomes more widely deployed in the home. Future testing areas such as transition mechanisms, routing protocols, and DNS in the home will need to be addressed as innovations are made.
Going forward, the UNH-IOL will focus on testing for the IPv6 Ready CPE Logo so that home router manufacturers can promote their support of IPv6 using a test program that validates both conformance and interoperability. This testing will also allow home router manufacturers to address potential IPv6 issues prior to deployment in order to avoid potentially costly problems in the field. By confirming IPv6 readiness in home networking equipment, home router vendors will also help operators ramp-up for the delivery of reliable, uninterrupted Internet service(s) to their customers using IPv6 addresses.
About the UNH-IOL: Founded in 1988, the UNH-IOL provides independent, broad-based interoperability and standards conformance testing for data, telecommunications and storage networking products and technologies. Combining extensive staff experience, standards bodies' participation and a 32,000+ square-foot facility, the UNH-IOL helps companies efficiently and cost effectively deliver products to the market.
About the author: Winters is a senior manager of IP technologies at the University of New Hampshire InterOperability Laboratory (UNH-IOL). He works with companies from all over the world to develop broad-based, flexible testing strategies to cost effectively meet network interoperability requirements for the Internet Protocol version 6 (IPv6), Session Initiation Protocol (SIP), routing, and IP Multimedia Subsystem (IMS) communities. Winters is the United States Government IPv6 (USGv6) and IPv6 Ready Logo technical lead for the UNH-IOL.
in Network World's LAN & WAN section.