Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg

Ted Lemon <ted.lemon@nominum.com> Sun, 02 February 2014 13:33 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8922A1A00D0 for <dhcwg@ietfa.amsl.com>; Sun, 2 Feb 2014 05:33:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSSa3pIdl3uy for <dhcwg@ietfa.amsl.com>; Sun, 2 Feb 2014 05:33:56 -0800 (PST)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 96CEF1A00CF for <dhcwg@ietf.org>; Sun, 2 Feb 2014 05:33:56 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUu5JQIDavA8F87IIBYXJmDzkeSLr33u1@postini.com; Sun, 02 Feb 2014 05:33:52 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 425451B8327 for <dhcwg@ietf.org>; Sun, 2 Feb 2014 05:33:52 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 16613190052; Sun, 2 Feb 2014 05:33:52 -0800 (PST)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 2 Feb 2014 05:33:51 -0800
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <52EBC3EA.1020104@innovationslab.net>
Date: Sun, 2 Feb 2014 08:33:49 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <CFA19E62-0F9A-4358-AB7C-E4A910BF4874@nominum.com>
References: <52EBC3EA.1020104@innovationslab.net>
To: Brian Haberman <brian@innovationslab.net>
X-Mailer: Apple Mail (2.1827)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>, draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org
Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 02 Feb 2014 13:33:58 -0000

On Jan 31, 2014, at 10:40 AM, Brian Haberman <brian@innovationslab.net> wrote:
>     I have done my AD Evaluation of draft-ietf-dhc-dhcpv6-unknown-msg
> (since Ted is listed as a co-author).  I only have a few points of
> discussion on this document before we move it along in the publication
> process.  I am by no means a DHCP expert, so let me know if I have gone
> off in the weeds...
> 
> 1. I would like to see a little more clarity in the purpose of this
> document.  It does a good job clarifying what a relay agent should do
> with existing messages, but I think it would be useful to spell out that
> is document is also dictating how future documents that define new DHCP
> messages should specify relay behavior.

This is a good suggestion (actually, these are all good suggestions!).   I think the right solution to this is twofold.   First, the following change should be made at the end of 4.1 (this also addresses your point 2):

OLD:
   In the case that a new type of message is sent by the server to a
   relay agent but the relay agent does not recognize it, the message is
   put into a Relay-forward message and sent to the server.
NEW:
   New DHCP message types may be defined in future that are intended to
   convey information from DHCP servers to relay agents.   Relay agents
   that do not implement these messages will not recognize that such
   messages are intended for them.   A relay agent that implements this
   specification will necessarily forward such messages to the DHCP
   servers to which it is configured to relay client messages.

   At this time, no messages of this variety have been specified.
   If such a message is specified in the future, the specification could
   include text something like the following:

      DHCP servers that send this new message type MAY, when they
      receive a relayed message of this type, mark the relay agent to
      which the message was sent as not implementing messages of this
      type.   In this case, the DHCP server MAY implement a strategy
      of probing the relay agent occasionally to see if it has been
      updated.

   However, this is not strictly necessary, since DHCP does not provide
   a signaling message for rejecting unexpected message types, and
   therefore DHCP servers are not expected to respond to such messages.

   Documents specifying new message types should use different types for
   communicating *to* relay agents than are used for communicating *from*
   relay agents, so that no confusion can occur where a message sent to
   a relay agent is sent back to the DHCP server, which then tries to
   process it as if it came from a relay agent.

In addition to this change, I'd propose the following change to the abstract:

OLD:
   DHCPv6 is not specific about handling messages with unknown types.
   This memo describes the problems and defines how a DHCPv6 server,
   client or relay agent should behave when receiving unknown DHCPv6
   messages.  This document updates RFC3315.

NEW:
   DHCPv6 is not specific about handling messages with unknown types.
   This memo describes the problems and defines how a DHCPv6 server,
   client or relay agent should behave when receiving unknown DHCPv6
   messages.  This document also provides advice for authors of future
   documents defining new messages sent from DHCP servers to DHCP relay
   agents, and should be read by potential authors of such documents.
   This document updates RFC3315.

> 2. In section 4.1, the text talks about targeting a message based on its
> message type.  To me, that suggests that a relay must know about all
> DHCP message types.  I thought (feel free to correct me) that relay
> agents were mostly stateless and would forward all messages not
> addressed to them to the configured DHCP server.  This assumes that all
> Relay-Reply messages are addressed to the relay directly.

That is the general effect of 4.1, but I hope the text above makes clearer what the issues are, both to you and to other future readers of the document.

> 3. After having an exchange with Ralph Droms, I want to ask about
> messages from servers to clients.  If those messages are *not* in a
> Relay-Reply message, but are received by a relay, should those messages
> be dropped?  If a server->client message is forwarded to a server by the
> relay, should it be dropped by the server?

If this happens, it's an implementation bug: the DHCP server is not in conformance with RFC3315.   I therefore think that we don't need to address it, although it would certainly break things if an implementation were to erroneously do that.   I think such an implementation would never make it to the field, because it simply wouldn't work.

> 4. Is there a need to specifically discuss the behavior of single
> devices that have both a relay agent and a client running at the same time?

Hm.   We generally treat these as two separate implementations that happen to be running on the same hardware.   Also I think usually it's a client and a server, not a relay agent and a server.   We could add text addressing this, but I don't really see this coming up in practice.   There isn't similar text in RFC3315, for instance, and we haven't seen evidence of implementors getting this wrong.

> 5. Also from Ralph... Could section 5 simply be written as "A client or
> server MUST silently discard any received DHCPv6 message with an unknown
> message type."?

Yes, I think this is a good edit.   Qi, do you have time to do these edits?