Node Requirements: Elevating DHCPv6 from MAY to SHOULD

Thomas Narten <narten@us.ibm.com> Fri, 13 May 2011 13:39 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5548EE06D7 for <ipv6@ietfa.amsl.com>; Fri, 13 May 2011 06:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXF9HHKEFnOp for <ipv6@ietfa.amsl.com>; Fri, 13 May 2011 06:39:15 -0700 (PDT)
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id CA5CDE069B for <ipv6@ietf.org>; Fri, 13 May 2011 06:39:15 -0700 (PDT)
Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4DDRblj004058 for <ipv6@ietf.org>; Fri, 13 May 2011 07:27:37 -0600
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4DDbhFr215660 for <ipv6@ietf.org>; Fri, 13 May 2011 07:37:44 -0600
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4D7bf9g006531 for <ipv6@ietf.org>; Fri, 13 May 2011 01:37:41 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-65-244-19.mts.ibm.com [9.65.244.19]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4D7beII006423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipv6@ietf.org>; Fri, 13 May 2011 01:37:40 -0600
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4DDbdao009901 for <ipv6@ietf.org>; Fri, 13 May 2011 09:37:39 -0400
Message-Id: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com>
To: ipv6@ietf.org
Subject: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Date: Fri, 13 May 2011 09:37:39 -0400
From: Thomas Narten <narten@us.ibm.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2011 13:39:16 -0000

Per a previous thread, there are indications that the WG may now be
willing to recommend that DHCPv6 be a SHOULD for all hosts. This is
based on the following rationale:

Thomas Narten <narten@us.ibm.com> writes:

> I personally would support having DHCP be a SHOULD rather than a
> MAY. The justification in my mind is that if you want the network
> operator to have the choice of whether they want to use  Stateless
> addrconf OR DHCP, they only have that choice of devices widely
> implement both.

This was supported by some others, particularly now that it is clear
there are more implementations of DHCPv6, e.g.:

Bob Hinden <bob.hinden@gmail.com> writes:

> While my personal view is that DHCPv6 won't be used for host
> configuration in cable/DSL deployments (except for provisioning the
> prefix to the home router), it appears that DHCPv6 is being widely
> implemented in host OS's because it is needed some environments.
> There are enough variations in deployment models that a host
> developer will need to support both.

> Based on this, I think a SHOULD is OK. 

Let me propose the following change be made to the node requirements
document:

OLD/Current:

   DHCP can be used to obtain and configure addresses.  In general, a
   network may provide for the configuration of addresses through Router
   Advertisements, DHCP or both.  At the present time, the configuration
   of addresses via stateless autoconfiguration is more widely
   implemented in hosts than address configuration via DHCP.  However,
   some environments may require the use of DHCP and may not support the
   configuration of addresses via RAs.  Implementations should be aware
   of what operating environment their devices will be deployed.  Hosts
   MAY implement address configuration via DHCP.

New:

      	<t> DHCPv6 <xref target='RFC3315' /> can be used to obtain and
	configure addresses. In general, a network may provide for the
	configuration of addresses through Router Advertisements,
	DHCPv6 or both.  Some operators have indicated that they do
	not intend to support stateless address autoconfiguration on
	their networks and will require all address assignments be
	made through DHCPv6. On such networks, devices that support
	only stateless address autoconfiguration will be unable to
	automatically configure addresses. Consequently all hosts
	SHOULD implement address configuration via DHCP.</t>


Is this acceptable?

Please respond yes or no. Given the WG's previous hesitation to having
DHCPv6 be a SHOULD, it is important that we get a clear indication of
whether or not the WG supports this change.

Thomas