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

[Ralph Droms <[e-mail]>]

On Feb 2, 2014, at 8:33 AM 2/2/14, Ted Lemon <[e-mail]> wrote:

> On Jan 31, 2014, at 10:40 AM, Brian Haberman <[e-mail]> 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.

This proposed text generally looks ok.  I see the conversation has picked up a few messages later in the thread, so I'll jump ahead to that discussion in another response.

> 
>> 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.

OK.

> 
>> 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.

Looking ahead to 4, seems to me we should consider the case in which a client and relay agent are multiplexing inbound DHCPv6 messages on the same port.

> 
>> 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.

I'm imagining a scenario in which a device is doing DHCP-PD and has a DHCPv6 client for local configuration.  Don't underestimate implementors; jsut because they haven't gotten it wrong in the past doesn't mean we shouldn't consider the case.

I'm assuming this entire document will be absorbed into RFC3315bis at some point?  Idle thought - is it worth publishing this document now when it will likely be superseded by RFC3315bis?

> 
>> 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?
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg