Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpinform-clarify-02.txt

From: [email-masked]
Date: Thu, 26 Feb 2009 12:00:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title           : Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications
	Author(s)       : D. Hankins
	Filename        : draft-ietf-dhc-dhcpinform-clarify-02.txt
	Pages           : 11
	Date            : 2009-02-26

The DHCPINFORM message within the DHCPv4 protocol has in operation
diverged incompatibly from the current defined standard.  This
document seeks to provide clarification of actual behaviour and
guidance for some situations that were previously omitted.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpinform-clarify-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 27 Feb 2009 13:48:32 -0500

Dave:

In section 4, the order of priority is wrong, I think. Also, you should
reference RFC 3527 regarding the relay agent link selection sub-option.

In RFC 3527 is written:

   In the event that a DHCP server receives a packet that contains both
   a subnet-selection option [RFC 3011], as well as a link-selection
   sub-option, the information contained in the link-selection sub-
   option MUST be used to control the allocation of an IP address in
   preference to the information contained in the subnet-selection
   option.

Thus, priority 3 and 1 should be switched. I also question whether
ciaddr should really be the top priority since that is the address the
client already has? So, your 1, 2, 3 order should be 2, 3, 1, I think.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, February 26, 2009 3:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpinform-clarify-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Dynamic Host Configuration Working
Group of the IETF.

	Title           : Dynamic Host Configuration Protocol DHCPINFORM
Message Clarifications
	Author(s)       : D. Hankins
	Filename        : draft-ietf-dhc-dhcpinform-clarify-02.txt
	Pages           : 11
	Date            : 2009-02-26

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpinform-clarify-02
.txt

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 27 Feb 2009 12:34:11 -0800

> client already has? So, your 1, 2, 3 order should be 2, 3, 1, I think.

I'm concerned if we did that, then clients that actually rely on
subnet selection would have to zero ciaddr to get to that order of
priority.  That's why I bumped it over ciaddr.

So it's kind of like I was pairing subnet selection with ciaddr and
link selection with giaddr, like they were tied together in pairs if
the order was changed (subnet selection disambiguates the ciaddr
config/locator, in the same way link selection disambiguates giaddr).
In just DHCPINFORM's point of view, that is...

I'm pretty sure you're right on the order, but I'm trying to figure
out if I should just omit subnet selection entirely?

On another note;

As I look at this list again, I wonder if this text;

   3.  The Relay Agent Link Selection Sub-Option [RFC3046], if it is
       present in a Relay Agent Information Option [RFC3046] in the
       DHCPINFORM packet (never cached from a previous exchange).

Can be simplified by ending the sentence earlier, while fixing the
first mis-reference;

   3.  The Relay Agent Link Selection Sub-Option [RFC3527], if it is
       present in a Relay Agent Information Option [RFC3046].

If 'ciaddr' is zero, which is the only way to get this low on the
list, then the server has no key to lookup a cached copy of relay
agent options from a previous exchange.  So this is a direction not to
do the impossible.  Unless anyone objects, I'll use this simplified
text.

Thank you Bernie.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 27 Feb 2009 16:35:29 -0500

>out if I should just omit subnet selection entirely? 

Yes, this is best. And, in fact, I think the client is really
responsible for providing its address in ciaddr. I think our server
drops the packet if ciaddr is not valid.

Is there a reason why you want to allow a client not to supply ciaddr?
(I guess one could allow ciaddr = 0 and use the source address of the
packet (provided giaddr = 0) if one wanted to support really stupid
clients.)

RFC 2131 is fairly explicit that DHCPINFORM is only when a client
already has a usable address:

   DHCPINFORM   -  Client to server, asking only for local configuration
                   parameters; client already has externally configured
                   network address.

3.4 Obtaining parameters with externally configured network address

   If a client has obtained a network address through some other means
   (e.g., manual configuration), it may use a DHCPINFORM request message
   to obtain other local configuration parameters.  Servers receiving a
   DHCPINFORM message construct a DHCPACK message with any local
   configuration parameters appropriate for the client without:
   allocating a new address, checking for an existing binding, filling
   in 'yiaddr' or including lease time parameters.  The servers SHOULD
   unicast the DHCPACK reply to the address given in the 'ciaddr' field
   of the DHCPINFORM message.

4.3.5 DHCPINFORM message

   The server responds to a DHCPINFORM message by sending a DHCPACK
   message directly to the address given in the 'ciaddr' field of the
   DHCPINFORM message.  The server MUST NOT send a lease expiration time
   to the client and SHOULD NOT fill in 'yiaddr'.  The server includes
   other parameters in the DHCPACK message as defined in section 4.3.1.

I really don't understand why we would want to loosen this up any.

If clients are broken, they need to be fixed.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David W. Hankins
Sent: Friday, February 27, 2009 3:34 PM
To: DHC WG
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpinform-clarify-02.txt

On another note;

Thank you Bernie.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 27 Feb 2009 15:27:33 -0800

> Is there a reason why you want to allow a client not to supply ciaddr?

I have two motivations,

1) I don't want to break existing deployments of "Microsoft .Net" DHCP
   agents, or similar.  The first I saw was the Flash Media Proxy
   Autodetection widget, I don't know how many others...we only get
   reports when things are broken.  :(

2) I want to document what our software actually has been doing since
   at least the 6th of May, 1999, and get peer review of our solution
   ("what it should have been doing") as well as documenting this for
   other implementers that need to feature replace our server.

> If clients are broken, they need to be fixed.

Back when Barr Hibbs was writing an RFC 2131 updates draft, I said the
same thing, to add a bit to clarify the case for these clients that
they need to be fixed.  Years later, the clients still exist, they are
just interoperating with more servers now than before, and I don't
have nearly as much righteous indignation as I did then.

For all I know, these clients can't work any other way.  So even if we
call that broken, I don't actually know if they can do any better, or
that we'd ever stop answering them the way we do today.  Would the old
broken clients disappear?  Would our customers stop needing it to
work?

So I'm with you in spirit on the RFC 2131 analysis, I think these
clients had an obligation to write an RFC before extending DHCP.  It
is a little hypocritical of me to say that when my software package
answers these clients - extending DHCP - without having written an
RFC explaining why or how.  So, I'm here to do that second piece.

There are other ways we can organize that message tho; we could make
the server extensions at that level optional to implement (which lets
this document be a good measure of DHCP as-deployed, a server might or
might not answer such clients today...).