Subject: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 12 Aug 2013 19:21:41 +0000

Hello:

During the Berlin IETF-87 DHC WG session, it was suggested that we initiate a standards action request to move RFC 3315 (and RFC 3633), which are presently Proposed Standards, to Internet Standard. While we plan to work on a 3315bis which would merge the work, it was pointed out by several people (include our Area Director) that there is technically no need to wait for that to advance the standards.

The requirements for advancement are outlined in RFC 2026 and RFC 6410 (which removed Draft Standard).

Per RFC 6410:

The criteria are:

   (1) There are at least two independent interoperating implementations
       with widespread deployment and successful operational experience.

   (2) There are no errata against the specification that would cause a
       new implementation to fail to interoperate with deployed ones.

   (3) There are no unused features in the specification that greatly
       increase implementation complexity.

   (4) If the technology required to implement the specification
       requires patented or otherwise controlled technology, then the
       set of implementations must demonstrate at least two independent,
       separate and successful uses of the licensing process.

Please provide input as to whether you support making this request of the IETF/IESG (via the Internet Area Directors) or whether you feel there are issues (based on the above criteria). If you feel one document is ready but the other isn't, please let us know about that too.

Assuming we can move forward, proposed request text is below - you can comment on that too.

The DHC WG co-chairs, with the support of the DHC Working Group, requests that the following documents be reclassified as Internet Standards instead of Proposed Standards as they presently are per RFC 6410:

RFC 3315 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
RFC 3633 - IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6

Both of these Proposed Standards have been widely implemented by multiple vendors and demonstrated to interoperate. This is most evidenced by the large scale deployment by Comcast Cable (in the v6ops WG meeting at the Berlin IETF, John Brzozowski indicated that Comcast has about 3 million subscribers with native IPv6 access using CableLabs standards, which includes RFC 3315 and 3633).

Many networking shows and events (including the IETF meetings have provided IPv6 and DHCPv6 support (sometimes just stateless but also stateful) to participants without any issues.

The University Of New Hampshire Interoperability Laboratory also has performed interoperability testing as well as conformance testing under the USGv6 testing program. Results are available at https://www.iol.unh.edu/services/testing/ipv6/usgv6tested.php?company=&type=&test_dhcpv6_client=DHCPv6+Client&test_dhcpv6_server=DHCPv6+Server#eqplist and (at the time of this writing) had 11 vendors with products on the tested list.

Note that CableLabs also has had many interoperability events that tested CPEs (client implementations), CMTSs (relay agents),
and servers. These tests include stateful address assignment as well as prefix delegation, and this includes support of the Reconfigure Key Authentication Protocol.

There are a wide variety of implementations of DHCPv6 clients by almost all major operating system vendors (Microsoft, Apple, Red Hat, IBM, just to name a few). There are public domain implementations available (for clients, relays, and servers) such as Dibbler (http://klub.com.pl/dhcpv6/) and from the Internet Software Consortium (http://www.isc.org). Most routers have implementations (client, relay, and server). Many consumer grade home gateways also include implementations (client and stateless server). And, there are commercial, high performance, servers available from multiple vendors (Cisco, Nomimum, etc.).

The two documents do have several errata, but these are mostly minor corrections and typographic errors and have not been critical to the successful implementation and interoperability of the standards. In any case, they are available to implementers of the standards.

There are no IPR claims related to the these specifications.

Therefore, we believe that these documents have demonstrated a high degree of interoperability and deployment over the past 10 years and therefore deserve to be Internet Standards.

-          DHC WG Co-chairs (Tomek Mrugalski and Bernie Volz)

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 19 Aug 2013 20:51:54 +0200

On 12.08.2013 21:21, Bernie Volz (volz) wrote:
> During the Berlin IETF-87 DHC WG session, it was suggested that we
> initiate a standards action request to move RFC 3315 (and RFC 3633),
> which are presently Proposed Standards, to Internet Standard. While we
> plan to work on a 3315bis which would merge the work, it was pointed out
> by several people (include our Area Director) that there is technically
> no need to wait for that to advance the standards.
> 
There are many more than just two.

>        new implementation to fail to interoperate with deployed ones.
There are known issues, e.g. those described in
draft-ietf-dhc-dhcpv6-stateful-issues, but these are more of annoyance,
rather than interoperability breaking problems. New implementations are
interoperating with existing ones without problems.

>        increase implementation complexity.
That's an interesting question. Are there any implementations that
implement the whole RFC3315? I mean really everything: reconfiguration,
reconfigure-key, delayed auth, replay detection, sending CONFIRM when
link state changes, sending DECLINE if DAD fails, rapid-commit,
supporting 32 relays, all 3 duid types etc.?

That's a trick question. I have my own answer for it, but I'd like to
hear WG opinion on that matter.

>        separate and successful uses of the licensing process.
There are no IPRs claimed against RFC3315 and RFC3633.

Ok, so in my opinion all criteria are met.

> Please provide input as to whether you support making this request of
> the IETF/IESG (via the Internet Area Directors) or whether you feel
> there are issues (based on the above criteria). If you feel one document
> is ready but the other isn’t, please let us know about that too.
I feel that we should move forward with this for both 3315 and 3633.
There's almost 7000 RFCs published, but there are only 96 that have
Internet Standard status. I strongly believe that DHCPv6 is one of core
Internet protocols. This status change would reflect that.

With my chair on, I'm disappointed that nobody responded to this mail so
far. Chairs got couple comments off the list, but nobody said anything
on the list. I don't know, perhaps people are not that much interested,
because this move does not have any immediate practical repercussions.
Or perhaps it is a middle of vacation time...

Come on, guys. Saying +1 doesn't take much time. ;-)

Tomek