[dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard

Pekka Savola <pekkas@netcore.fi> Mon, 03 November 2003 22:24 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28431 for <dhcwg-archive@odin.ietf.org>; Mon, 3 Nov 2003 17:24:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGn7I-0004Na-1r for dhcwg-archive@odin.ietf.org; Mon, 03 Nov 2003 17:24:08 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3MO8XJ016828 for dhcwg-archive@odin.ietf.org; Mon, 3 Nov 2003 17:24:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGn7H-0004NL-UN for dhcwg-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 17:24:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28316 for <dhcwg-web-archive@ietf.org>; Mon, 3 Nov 2003 17:23:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGn7F-0006m9-00 for dhcwg-web-archive@ietf.org; Mon, 03 Nov 2003 17:24:05 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGn7E-0006m5-00 for dhcwg-web-archive@ietf.org; Mon, 03 Nov 2003 17:24:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGn7B-0004LS-OB; Mon, 03 Nov 2003 17:24:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGdoO-0001kl-KT for dhcwg@optimus.ietf.org; Mon, 03 Nov 2003 07:28:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29204; Mon, 3 Nov 2003 07:27:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGdoO-0004ci-00; Mon, 03 Nov 2003 07:28:00 -0500
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGdoN-0004cX-00; Mon, 03 Nov 2003 07:27:59 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA3CRRZ31436; Mon, 3 Nov 2003 14:27:27 +0200
Date: Mon, 03 Nov 2003 14:27:26 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: iesg@ietf.org
cc: dhcwg@ietf.org
In-Reply-To: <E1AFLj4-0003Pq-Or@asgard.ietf.org>
Message-ID: <Pine.LNX.4.44.0311031422590.30770-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

On Thu, 30 Oct 2003, The IESG wrote:
> The IESG has received a request from the Dynamic Host Configuration WG to 
> consider the following document:
> 
> - 'A Guide to Implementing Stateless DHCPv6 Service'
>    <draft-ietf-dhc-dhcpv6-stateless-01.txt> as a Proposed Standard

Comments below.  The document needs a revision, but does not have, AFAICS,
major issues to deal with, except for better considerations on how DHCP
relays work (or don't :-) in the stateless/full DHCP model.. that is, do 
you have "stateless relays" and "full relays", and potential problems to 
stateful services stemming from that or not.

Note: IMHO, DHCP spec should have been the other way around, stateless
first, adding stateful parts on top of that as an extension.  Can't be
changed now, but might be something to consider when going to Draft
Standard or the like.

substantial
-----------

1) the spec is not sufficiently clear how the relays behave in a mixed world
of stateless/stateful DHCP service.  That is, would deploying a
stateless-only relay (if such a thing is possible?) harm the stateful DHCP
clients?  Is the implementation of a relay any different for full/stateless
DHCP service, etc. ?:

   The operation of relay agents is the same for stateless and stateful
   DHCPv6 service.  The operation of relay agents is described in the
   DHCPv6 specification.

2) there are a few remnants on the spec which talk about "DNS configuration
parameters".  One should be more generic than that; these are listed in the
editorials section.

3) I'm not familiar with DHCPv6 spec, but I'd like a confirmation that the
last sentence is actually true, and to reword it for clarity if so:

   A DHCP server that is only able to provide stateless configuration
   information through an Information-request/Reply message exchange
   discards any other DHCP messages it receives. Specifically, the
   server discards any messages other than Information-Request or
   Relay-forward it receives, and the server does not participate in any
   stateful address configuration messages exchanges.  If there are
   other DHCP servers that are configured to provide stateful address
   assignment, one of those servers will provide the address assignment.

==> that is, do relays really *flood* these messages to all the DHCPv6
servers they know, so that if one doesn't process the request but silently
ignores it, the others can step up and handle the job?  See also the point
1) above.

editorial
---------

   the node's message with a Reply message that carries the DNS
   configuration parameters.  The Reply message from the server can

==> s/DNS//

   1-4:   give an introduction to DHCPv6 and an overview of DHCP message
      flows

==> some of those flows are redundant to Stateless DHCPv6 operation,
though.. :-)

5. Implementation of stateless DHCP
                                                                                                   
==> s/stateless/Stateless/

   DNS configuration information, it includes either or both of the DNS
   configuration options in the Information-request message.
 
==> one should list here the two kinds of DNS config options, or reword the
sentence.

5.1 Messages required for stateless DHCP
                                                                                                   
==> s/r/R/, s/s/S/

   Clients and servers implement the following messages for stateless
   DHCP service; the section numbers in this list refer to the DHCPv6
   specification:

==> many sections are missing the "the section ..." blurb.  It might make
sense to add something at the end of section 5, like, "In the following
subsections, the section numbers used refer to the DHCPv6 specification".

   Information-request: sent by a DHCP client to a server to request DNS
      configuration parameters (sections 18.1.5 and 18.2.5)
                                                                                                   
   Reply:               sent by a DHCP server to a client containing the
      DNS configuration parameters (sections 18.2.6 and 18.2.8)

==> s/DNS// (2 cases)

5.2 Options required for stateless DHCP service
                                                                                                   
==> s/r/R/, s/s/S/, s/service// (remove service for consistency with other
5.x)

5.3 Options used for configuration information
                                                                                                   
==> s/u/U/, s/c/C/, s/i/I/

5.4 Other options used in stateless DHCP
                                                                                                   
==> s/o/O/, s/u/U/, s/s/S/

   DHCP service; the section numbers in this list refer to the DHCPv6
   specification, RFC 3315>:

==> see above, but if keeping it here, make consistent with the rest

      22.2).  Clients are not required to send this option; servers send
      the option back if included in a message fro ma client
                                                                                              
==> s/fro ma/from a/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg