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

"Bernie Volz (volz)" <volz@cisco.com> Mon, 12 August 2013 19:22 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9A0A721F9E1D for <dhcwg@ietfa.amsl.com>; Mon, 12 Aug 2013 12:22:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.298
X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GJ6i-PYXHvlG for <dhcwg@ietfa.amsl.com>; Mon, 12 Aug 2013 12:21:59 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 762BA21F9E54 for <dhcwg@ietf.org>; Mon, 12 Aug 2013 12:21:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18949; q=dns/txt; s=iport; t=1376335303; x=1377544903; h=from:to:subject:date:message-id:mime-version; bh=oklqLh/FGggENLBcMX+flCLXClKLvJ2zkSMyevMHh9Y=; b=k35qfTWCAePO4BenLfmyjag6U66mLH7aQ8itZWRQYu1H/nDJw2VEFk9k LnT2fHHdlOqiwose0usP0sTDiizH2X4x5dzCvyqMM2oxv81swhHVt8KQ/ EL/eFKgk2WKUyo3AZdxG2yuZWuzcw8ESDrWW/6ICRw+nqHd0RAudIqp3P E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: An8GAHU1CVKtJV2Z/2dsb2JhbABBGoJCRDVQthmIPYEbFm0HgiYBBC1eASpWJgEEG4gIDDKVc6A2kAotgyZ2A5kQiwGFJIMbgio
X-IronPort-AV: E=Sophos; i="4.89,863,1367971200"; d="scan'208,217"; a="246412549"
Received: from rcdn-core-2.cisco.com ([]) by rcdn-iport-5.cisco.com with ESMTP; 12 Aug 2013 19:21:42 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com []) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7CJLggh004152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dhcwg@ietf.org>; Mon, 12 Aug 2013 19:21:42 GMT
Received: from xmb-rcd-x04.cisco.com ([]) by xhc-rcd-x11.cisco.com ([]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 14:21:42 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: Advancing RFC 3315 and RFC 3633 to Internet Standard
Thread-Index: Ac6XkNumLI/tVOa0T9WBrxY5XdrPwA==
Date: Mon, 12 Aug 2013 19:21:41 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E18654EE6@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E18654EE6xmbrcdx04ciscoc_"
MIME-Version: 1.0
Subject: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Aug 2013 19:22:11 -0000


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)