Subject: [dhcwg] draft-dhankins-dhcpinform-clarify-00.txt

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Nov 2008 00:11:30 -0600

In section 2, the draft talks about confusion as to were the DHCP  
server should get the MAC address of the client when sending its  
response.   There should be no confusion aboutthis.   DHCPINFORM is  
meant to be implemented over IPv4 unicast, and it would be incorrect  
to use the MAC address in the DHCP packet as a destination for the  
response.   The DHCP server shouldn't even need to know the client's  
MAC address.

In section 3, the draft says to set chaddr, htype and hlen; in  
practice this may be difficult for some clients to do.   Is there a  
clear reason for wanting to do this?   It seems to me that this and  
the following bullet point, which talks about setting the BROADCAST  
flag, are only germane to clients that do not have IPv4 addresses.    
DHCPINFORM was never intended to be used by such clients.   Is it the  
intention of the authors to extend DHCPINFORM to support clients that  
don't have IPv4 addresses?

Section 4 talks about what to do if the ciaddr option is zero.   The  
ciaddr option should never be zero.   It also talks about what to do  
if giaddr is nonzero.   Giaddr should never be nonzero.   Using the IP  
source address is problematic, since this places an additional burden  
on the DHCP server that wasn't previously present - it is now required  
to capture the source address of the UDP packet.   Item 6 is invalid -  
since DHCPINFORM is unicast, subnet selection cannot be done based on  
the subnet address or addresses configured on the interface on which  
the DHCPINFORM packet is received.

In the section on the response generated by the server, the draft  
specifies that file and sname must be all zero.   This is incorrect -  
both file and sname can be used for option overloading.   I don't  
understand the motivation for specifying what file and sname should  
contain - it seems to me that RFC2131 and RFC2131 already specify this  
adequately.

Again with the IP address to which the reply will be sent, the draft  
allows for DHCPINFORMs to be sent to unconfigured clients.   This  
doesn't make sense.

There's quite a bit more language about what to do if ciaddr isn't  
set.   I think that if ciaddr isn't set, the DHCP server should simply  
drop the packet.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 21 Nov 2008 13:48:54 -0800

First, thanks for such extensive review Ted, and to everyone at the
DHC WG meeting who said they'd read the draft and are willing to work
forward on this.

As a preface, this draft was intended to clarify, not to extend.  To
those ends, and understanding that our knowledge is not universal to
all DHCP software implementations (hence needing to err on the side
of specification permissiveness), I tried to limit myself to at least
what I understood RFC 2131 to define in terms of normative
requirements.  This hopefully gets a "starting point" where we don't
remove anything the protocol currently extends.

I think that anything we "peel back" from RFC 2131's permissive
language should have well-reasoned arguments, and therefore some
discussion.

Getting on with it;

On Thu, Nov 20, 2008 at 12:11:30AM -0600, Ted Lemon wrote:
> In section 2, the draft talks about confusion as to were the DHCP server 
> should get the MAC address of the client when sending its response.   There 
> should be no confusion aboutthis.   DHCPINFORM is meant to be implemented 
> over IPv4 unicast, and it would be incorrect to use the MAC address in the 
> DHCP packet as a destination for the response.   The DHCP server shouldn't 
> even need to know the client's MAC address.

You're quoting the Introduction, which is describing the questions
that have been raised.  Maybe I've overanalyzed the question a bit
in the Introduction.  It is certainly the goal of this draft to
remove any confusion.  Note that the conclusions haven't been
written yet (section 4 trails off at that point kinda), so I'll take
this as input for what I should write there.

> In section 3, the draft says to set chaddr, htype and hlen; in practice 
> this may be difficult for some clients to do.   Is there a clear reason for 
> wanting to do this?

From the standpoint of only clarifying RFC 2131, and not extending it,
I have used as a guide RFC 2131 Table 5, bits quoted for brevity;

Field      DHCPDISCOVER          DHCPREQUEST           DHCPDECLINE,
           DHCPINFORM                                  DHCPRELEASE
-----      ------------          -----------           -----------
'htype'    (From "Assigned Numbers" RFC)
'hlen'     (Hardware address length in octets)
'chaddr'   client's hardware     client's hardware     client's hardware
           address               address               address

Unlike other rows in this table, which specify specific behaviour
for DHCPDISCOVER -or- DHCPINFORM otherwise, there is no 'or' syntax
here.

I think Table 5 is not normative, but I have frequently heard in
discussions in DHC WG that RFC 2131 tables are considered normative,
despite having no normative tie-ins.  Clients that do not implement
according to the tables are often referred to as non-conforming.

In this case I've elected to side partially with that view, directing
this behaviour as a SHOULD, because I believe we should adopt these
non-chaddr-setting client behaviours, for the reason you've stated;
not all can fetch this information.  At the same time, if you have it,
you really SHOULD fill it in.

Because there is no normative tie-in in RFC 2131 to Table 5, if WG
consensus wanted to make a different indication (MUST/MUST NOT), I
think we could still call that a clarification.  Any normative
direction at all here is clarification, and I'm open to WG consensus
of course.

> It seems to me that this and the following bullet 
> point, which talks about setting the BROADCAST flag, are only germane to 
> clients that do not have IPv4 addresses.   DHCPINFORM was never intended to 
> be used by such clients.   Is it the intention of the authors to extend 
> DHCPINFORM to support clients that don't have IPv4 addresses?

No, the inclusion of the discussion of the BROADCAST flag was to
explicitly spell out under what circumstances a client would be
reasonable in setting the broadcast flag (the motivation is quite
honestly Windows Vista; although I think it does not set the broadcast
flag on DHCPINFORM, the intent is to discourage clients that wish to
set the flag despite being able to receive unicasts (IMO, this could
also use separate clarification as I believe the Vista behaviour
should be non-conforming)).

Again, this is explicitly clarifying Table 5's direction for the
flags field for DHCPINFORM (there is no 'or else for DHCPINFORM
it is zero' text);

Field      DHCPDISCOVER          DHCPREQUEST           DHCPDECLINE,
           DHCPINFORM                                  DHCPRELEASE
-----      ------------          -----------           -----------
'flags'    Set 'BROADCAST'       Set 'BROADCAST'       0
           flag if client        flag if client
           requires broadcast    requires broadcast
           reply                 reply

I think MUST/MUST NOT is appropriate direction, and I would suggest
that we could even clarify that in general for all DHCP client
messages, not not just specifically for DHCPINFORM (but not in this
draft).

Again, any normative direction is a clarification.

> Section 4 talks about what to do if the ciaddr option is zero.   The ciaddr 
> option should never be zero.

RFC 2131 currently says you 'SHOULD' unicast to ciaddr, and gives no
indication for otherwise.

There exist, as I have documented, DHCPINFORM clients that do not
follow Table 5 nor the non-normative language in section 4.4.3 (read:
they zero ciaddr, as well as htype, hlen, and chaddr), but are also
compatible with servers that do conform to RFC 2131's direction that
they SHOULD unicast to 'ciaddr'.  They still conform to this direction
by replying otherwise.

So this is a "asymmetric conformance" case, and I'm trying to figure
out what WG consensus is/will-be.  This is where I wound up.

I think that if we forbade servers from replying other than to ciaddr,
then that would be an extension of RFC 2131, not a clarification, and
I know of at least two well-deployed server implementations (possibly
3) which would not conform today.

I would want to hear a covenant from all these server implementers
that they would conform to a new RFC outlawing this behaviour before
I would choose to (not speaking for my employer who might be convinced
otherwise for all I know, just for my own lattitude to operate), so I
am suggesting that retaining the DHCPv4 server lattitudes in this case
is most expeditious.

This also means documenting as fact the lattitudes the clients have
taken despite non-normative text to the contrary, which may be
uncomfortably ugly.

>  It also talks about what to do if giaddr is 
> nonzero.   Giaddr should never be nonzero.

Giaddr is often nonzero, and rightly from RFC 2131 section 4.4.3;

   The client then unicasts the DHCPINFORM to the DHCP server if it
   knows the server's address, otherwise it broadcasts the message to
   the limited (all 1s) broadcast address.  DHCPINFORM messages MUST be
   directed to the 'DHCP server' UDP port.

If a DHCPINFORM packet is broadcast, then either the server is
directly attached, or giaddr will be set by a BOOTP relay that
forwards it on.

giaddr is often nonzero in the field, the real question is whether a
server rightly should inspect it (there is no RFC 2131 language
suggesting it, and no normative language outlawing it).

On this issue even I am not convinced, but in the draft I've taken a
position that it should be considered in some unsavory fallback cases.

>  Using the IP source address is 
> problematic, since this places an additional burden on the DHCP server that 
> wasn't previously present - it is now required to capture the source 
> address of the UDP packet.

I agree.  A server will be required to perform this function in order
to be consistently compatible with other servers.  In that sense, it
is already implicitly required, if not explicitly through reference.

So I think not documenting this requirement is also problematic; it
is false, to my mind, to suggest that a server implementer need not
concern themselves.

I also think this requirement is not onerous.  Most UDP port reception
APIs have a mechanism to record the IPv4 source address along with the
UDP packet contents, without having to transfer IPv4 headers in their
entirety, or resort to raw packets, or similar.

>  Item 6 is invalid - since DHCPINFORM is 
> unicast, subnet selection cannot be done based on the subnet address or 
> addresses configured on the interface on which the DHCPINFORM packet is 
> received.

Item 6 is the last resort following the trail of non-conforming (?)
clients; the client has not set ciaddr, the giaddr is not set, there
are no link selection options, and the IPv4 source address is even
zero (something we do not see today on the Internet).  In this case,
our last presumption is that the client is some strange, non-
conforming (?) beast, on the local wire.

The truth is that unless the specification says "at this last resort,
the server MUST drop it", some implementation would follow a more
liberal last resort like this one, and then all would have to when
or if the first client appears that capitalizes on it.

To be clear; this list was the result of my looking at how we would
code subnet configuration selection, and realizing that there was
still a potential gap in my if/else chain that RFC 2131's SHOULD
allows me to fill.  Given that allowance, I will tend to do so.

If WG consensus is otherwise; you MUST drop this packet, log, do
something else...that's fine with me (I can rename this an extension
or correction, as this does change RFC 2131 normative language).  I
was just taking a stab here at what I thought was the most liberal
interpretation providing a clarification of the existing normative,
but vague, standard.

> In the section on the response generated by the server, the draft specifies 
> that file and sname must be all zero.   This is incorrect - both file and 
> sname can be used for option overloading.   I don't understand the 
> motivation for specifying what file and sname should contain - it seems to 
> me that RFC2131 and RFC2131 already specify this adequately.

This actually was a guess on my part, aiming this time towards the
most conservative view, since all the text describing the use of the
file and sname fields appears to be specific to the stateful client
replies (in context of DHCPREQUEST).

As an example, from Table 3;

Field      DHCPOFFER            DHCPACK             DHCPNAK
-----      ---------            -------             -------
'xid'      'xid' from client    'xid' from client   'xid' from client
           DHCPDISCOVER         DHCPREQUEST         DHCPREQUEST
           message              message             message
'sname'    Server host name     Server host name    (unused)
           or options           or options
'file'     Client boot file     Client boot file    (unused)
           name or options      name or options

It seems strange to me that a DHCPINFORM->DHCPACK reply would carry
the xid from any DHCPREQUEST message from the same client (and what if
there wasn't one)?

So it seems to me that Table 3 is documenting only what to do in the
stateful case, and there is no direction for the stateless case (you
cannot reasonably expect a "or in the case of DHCPINFORM, this
alternate behaviour" in the DHCPACK column).  So I set out to provide
the most conservative (minimal) directions, since the other sections
on server DHCPINFORM behaviour were mum on this.

The idea is, wherever my conservative list is wrong, we can trim them
back.

In this case I clearly need to reword that.  I'm thinking it should
say that file/sname may be used by option overloading, but would not
be used otherwise (does not carry a servername or filename config),
similarly to how Table 5 words these fields for client packets.

Should clients reasonably expect servername or filename to carry a
real configuration value on a DHCPINFORM?

> Again with the IP address to which the reply will be sent, the draft allows 
> for DHCPINFORMs to be sent to unconfigured clients.   This doesn't make 
> sense.

This is another case along the lines of Item 6 above; this is the
fully liberal interpretation, filling in RFC 2131's SHOULD to the
best of my ability.  If WG consensus is for a more conservative MUST
somewhere along that line, or even a more liberal MAY, I will record
it.

> There's quite a bit more language about what to do if ciaddr isn't set.   I 
> think that if ciaddr isn't set, the DHCP server should simply drop the 
> packet.

As I've said, I don't think that would be a clarification of RFC 2131,
I believe this revokes normative permission granted to servers, and so
is a reverse-extension (untension? detension? unextension?  ahhh...
_retraction_).

But I'm willing to encode that kind of RFC (whatever you call it) if
it's the WG's consensus.

It is my opinion that we should not encode that in RFC, because I do
not believe it will have any effect on the implementions, client nor
(consequently) server.

The truth is that clients exist that do not set ciaddr, and multiple
independent servers exist which compatibly reply as default behaviour
(one of which was written by Ted Lemon, but had bugs (would send
DHCPACKs to 0.0.0.0 if got via relay agent), modified by me, but had
bugs (would always send to giaddr instead of preferring ciaddr when
good clients set it), and again modified...with no reports of problem
so far but also no peer review of its algorithm).

If you are writing DHCPv4 server software, you want to feature replace
these servers, or you will be called on this.  So the omission of this
algorithm from standards creates an instant support cost for anyone
who wants to build DHCP servers (everyone has to develop it
independently).  In my opinion this omission shouldn't be tolerated by
the community.

But my opinion isn't always in line with WG consensus.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg