Note: This article does not provide a complete summary of all IETF activities in this area. It reflects the author’s personal perspective on some current highlights
The DHCPv6 protocol has been in existence for several years, but only recently have a number of independent, production-ready implementations been available on the market. Initial lab tests pointed to some interoperability issues between codes of different origins. With the help of the Internet Systems Consortium (ISC), the office of the chief technology officer of Comcast decided to organise a DHCPv6 bake off (see sidebar, page 23) for the purpose of testing as many implementations as possible for interoperability, operational impact, and usability.
The DHCPv6 bake off was held 14-16 March, just prior to IETF 68, at the RIPE NCC in Amsterdam. Fourteen engineers, representing seven vendors and/or open-source providers developing DHCPv6 software, gathered for two and a half days of intensive testing. One participant was connected remotely from California and was in constant contact via e-mail and instant messaging. The tests involved 13 independent DHCPv6 implementations: five clients, five servers, and three relays. The workshop enabled the participants to meet and discuss their software, assess whether it works with other implementations, find bugs, and exchange experiences and ideas.
The test plans were articulated around three axes:
- The first axis covered X-versus-Y tests, whereby each client was put in front of each server to verify basic interoperability.
- The second axis covered client tests in which the host interactions with IPv6 stateless autoconfiguration and router advertisements were explored.
- The third axis targeted relays/servers tests building increasingly complex network topologies, including a series of up to three relays, multicast relaying and high availability, and redundancy achieved through a set of anycast DHCPv6 servers.
The key take away from the bake off is that the basic DHCPv6 technology works very well. One implementation, designed by someone who’d never attended an IETF meeting before, interoperated well with implementations performed by more-seasoned IETF participants, experiencing only minor bugs, which were quickly corrected on-site. This is certainly a tribute to the quality of RFC 3315, the DHCPv6 specification.
However, problems with RFC 3315 arose, including 16 issues that were discovered and discussed in the course of the bake off. While the issues were varied and diverse, the most significant ones are described here.
- Interaction with router advertisement. An option describing the length of the prefix associated with the assigned address would be helpful.
- Interaction with the Domain Name System (DNS). The DHCPv6 client would benefit from feedback from the DHCPv6 server performing dynamic DNS update on its behalf.
- Client/server interactions and the semantics of the negotiation of certain parameters, which raises the question: What should happen when a client requests a particular address and the server does not agree to the request?
- Relay/server interaction. What is the best way to keep track of the different levels of relaying, and how and when – if at all – should multicast be used?
The issues were again discussed with the DHC working group during the IETF meeting in Prague, and the discussions will be documented through an Internet-Draft that could become the basis for an update to RFC3315.
Many thanks go to the RIPE NCC for organisational support of the workshop (networking hardware and staff to help run tests) as well as for the meeting venue; to ISC for the organisation of the test plan; to the Comcast crew that made the bake off possible; and, of course, to the participants, who came from three continents, and to their employers.
Given the success of the bake off and the unanimous feedback from the participants, we are now considering organising a second DHCPv6 bake off to be held this coming fall, tentatively scheduled for the week before IETF 70 in Vancouver, Canada. The exact location is still to be determined.
In the early days of the development of TCP and IP, when there were very few implementations and specifications were still evolving, the only way to determine if an implementation was correct was to test it against other implementations and then argue that the results demonstrated that your implementation worked. These tests and discussions could, in those early days, as likely change the specification as change the implementation. There were a few times when this testing was focused, bringing together all known implementations and running through a set of tests in hopes of demonstrating the N squared connectivity and correct implementation of the various tricky cases. These events were called bake offs.