It is common knowledge among seasoned IETFers that the Dynamic Host Configuration (DHC) Working Group (WG) is old. But identifying exactly how old has proven to be a challenge. According to WG archives, its first email was posted1 on 12 July 2001. But that can’t be the right date, as its first Request for Comments (RFC) is RFC 1531 from October 1993. Datatracker history for DHC2 provides some clues, but the data appears incomplete: milestone updates go back to 2003, followed by a 13-year gap and two entries indicating that the WG was proposed and formed on 1 January 1991. If this is correct, it gives the WG an impressive 26 years of age—at least as old as the Web, whose creation is typically cited as either January (first public server available) or August (Sir Tim Berners-Lee announces the project to alt.hypertext newsgroup) 1991. However, there exists yet another clue that DHC is even older: the Active Working Group list on the IETF website3. While the page itself is a bit basic, the dates next to each WG name look like creation dates. And this page lists DHC’s creation as “1989-Apr-13”— almost 28 years ago.
So what has the DHC WG been doing all this time? Its original goal hasn’t changed. It was created to configure hosts in a dynamic way and that’s what it has done. If you think about it for a moment, modern networks look completely different than when the work was started. A so-called large network in the late 80s would likely comprise approximately 100 desktop computers. There was no concept of mobility and work on IPv6 hadn’t really started. Much has changed and DHC has done its best to stay on top of the changing reality. In the process, the WG published 96 RFCs that defined, clarified, and improved various aspects of devices’ autoconfiguration. Devices, because it’s much more than just hosts nowadays. And that raises the question: is there anything else that DHC still needs to do?
DHCPv6bis
Like most IETF Working Groups, DHC prefers not to spend time on legacy technologies, such as IPv4, except in cases when it’s helpful with IPv6 transition. In DHC terms, this means that the WG is almost exclusively focused on DHCPv6. This core protocol (RFC 3315) was published in 2003. A lot has changed since then. Most notably, the ability for routers, not just hosts, to participate. Routers usually use prefix delegation (PD) mechanism (RFC 3633). Also, with recent changes in how networks are organized, the original assumptions no longer hold. The distinction between hosts and routers is blurred (if you use your phone as a hotspot or run virtual machines on your phone, is the phone still a host?), the perceptions of trust have changed (do you trust the hotspot in the coffee shop you visit to be legitimate?), and so have our expectations (wait a whole second when logging into a network?).
The DHC WG is addressing some of these changing conditions via an initiative to republish the DHCPv6 specification. Today, this initiative represents the WG’s primary focus. A design team formed in 2013 took the original RFC (fun fact: it was in nroff format); cleaned it up; took all the erratas, corrections, and changes that had been introduced (e.g., RFC 7550, which improved several stateful issues); and published updated versions4. The work is organized around a dedicated issue tracker5. The document went through a very successful WG Last Call (WGLC) in 2016, in which nearly 300 independent comments were received. The design team holds biweekly meetings with a public spreadsheet on Google docs and an intermediate draft text in a public github repository. Remaining comments are expected to be addressed and presented during IETF 98 in Chicago. The intention is to publish the document as a Draft Standard RFC and advance it to Full Standard some time later.
Privacy and Security
The notion of security has also radically changed over the years. Both Edward Snowden’s revelations and RFC 7258 prompted many Working Groups to reevaluate certain mechanisms that can be used for pervasive monitoring and other attacks on privacy. In addition, the way people use modern networks has changed. Visiting a coffee shop that you know nothing about seems to be a more common use case nowadays than having your device plugged into a wired network, of which you personally know the admin. DHC spent a considerable amount of time going through mechanisms and options of both DHCPv4 and DHCPv6 with the goal of finding out which of them can be used to track devices and users. As a result, a recommendation called anonymity profile has been published in RFC 7844, which recommends certain changes for clients who want to protect their privacy. Clients who implement that recommendation do not reveal anything of use about themselves and don’t use any long-lived identifiers that could be used to track them.
At the same time, there are deployment models where almost the opposite is true: in certain deployments clients want to prove their identity to the network and verify that the network is really what it claims to be. Security and preventing pervasive monitoring is of great concern to all, and the lack of security (encryption and authentication) has been a long-standing issue with DHCP as it is used to connect to many networks. This work6 started in late 2013 and has had several restarts after review by the Internet Engineering Steering Group (IESG). The current document provides for encrypting client/server interactions. The work is expected to undergo WGLC in the near future, and hopefully it will have another attempt at IESG approval.
Going Forward
DHCPv6 is an extensible protocol with roughly 10 new options being defined every year. Most of those options convey new parameters that the server is expected to deliver to the clients—they do not change how the protocol operates. As such, more and more option definitions work is being conducted outside of DHC in dedicated groups that comprise subject matter experts, who can better verify the actual content of those parameters. In May 2014, DHC published RFC 7227, which provides guidelines for authors who work on new options. Nevertheless, there are several extension mechanisms being discussed that are specific to the protocol, so they belong to DHC. Defining YANG models, providing DHCPv6 failover, and tweaking how relay agents are operating are just some of the examples currently being worked on7.
You might ask: is the DHC going to wrap up anytime soon? When current chairs Bernie Volz and Tomek Mrugalski took over from Ted Lemon, Lemon made a comment that the group had maybe five years of work left. He then promptly added that when he stepped in, the outgoing chair made the same comment. And who knows? Perhaps Volz and Mrugalski will pass that same prediction to their successors.
1 https://www.ietf.org/mail-archive/web/dhcwg/current/mail402.html.
2 https://datatracker.ietf.org/wg/dhc/history/.
3 https://tools.ietf.org/wg/.
4 https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis.
5 http://tools.ietf.org/group/dhcpv6bis/.
6 https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-20.
7 https://datatracker/wg/dhc/documents and https://datatracker.ietf.org/wg/dhc/charter/.