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

[Brian Haberman <[e-mail]>]

On 2/2/14 8:33 AM, Ted Lemon 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.
> 

Hmm... The text above talks about messages from servers to relays.
Would these messages be coming from servers *not* identified in the
relay's configuration?  That is, do you envision relays seeing messages
from servers that the relay is not configured to use for received client
messages?  If not, shouldn't the guidance be that relays should silently
drop them?  If they can receive messages from servers they don't know
about, the relays will forward these messages to *other* servers and
they should drop them.

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

Almost sounds like DHCP needs a capabilities negotiation between servers
and relays. :)

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

Ok.

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

Once my follow-up question is answered, I will have a better grasp on
the clarity.

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

Ok.

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

If the pairing of a client and relay agent is not expected, this may not
be an issue.

Regards,
Brian