Subject: [dhcwg] Use of chaddr in response to DHCPINFORM message

From: Ralph Droms <[email-masked]>
Date: Mon, 3 Dec 2007 02:47:02 -0500

I'm paraphrasing a question I received about how a response to a  
DHCPINFORM message - should the sender use the MAC address from the  
chaddr field in the header or the device's MAC address as determined  
from the DHCPINFORM message or through ARP.

Microsoft CE thin-clients are sending DHCP-INFORM requests and some of  
them use the fixed hardware address (chaddr) of 3000.3000.3a00 instead  
of the actual hardware address of the device. At least one  
organization deploying these thin-clients claims the response DHCP- 
ACKs should be be sent using the the actual hardware address (MAC) in  
the received Ethernet packet instead of the (artificial) hardware  
address in chaddr.

Of course, a relay agent must use chaddr because it no longer has  
access to the MAC address in the original DHCPINFORM message.  There  
is an argument that the relay agent could use ARP for the DHCPACK, if  
the relay agent has some indication that the DHCP client already has  
an address and will respond to ARP.

The RFC-2131 does not state explicitly, as it does for DHCPOFFER and  
DHCPACK, how a DHCPINFORM message should be returned to a client.  Do  
we need to write a short clarification to be published as an errata  
for RFC 2131?

- Ralph

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Dec 2007 10:12:57 -0500

> we need to write a short clarification to be published as an errata

If it doesn't say, we probably do.   I've always assumed that for  
unicasts to devices with addresses you just send it using the usual IP  
methods - you definitely don't use chaddr even if the device is on the  
server's link, because in this case RFC2131 doesn't call upon you to  
decide whether or not the IP address is on the server's link.   But if  
someone got it wrong, then clearly the RFC needs to specify it more  
explicitly...  :'}

---

From: Ralph Droms <[email-masked]>
Date: Mon, 3 Dec 2007 10:25:09 -0500

Ted - sending to unicast using "usual IP methods" makes sense.  How  
does the server or relay know when the client has an IP address?   
There are specific cases when the server might know, but I haven't  
thought through the relay agent case; can the relay agent  
differentiate these DHCPACKs:

* initial assignment
* lease extension
* response to DHCPINFORM

- Ralph

On Dec 3, 2007, at Dec 3, 2007,10:12 AM, Ted Lemon wrote:

> unicasts to devices with addresses you just send it using the usual  
> IP methods - you definitely don't use chaddr even if the device is  
> on the server's link, because in this case RFC2131 doesn't call upon  
> you to decide whether or not the IP address is on the server's  
> link.   But if someone got it wrong, then clearly the RFC needs to  
> specify it more explicitly...  :'}

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Dec 2007 11:02:50 -0500

> differentiate these DHCPACKs:

There are ways to differentiate.   I would have to sit down and think  
about it to get the details right, but the ISC server has been doing a  
version of this for a long time, and DCS does a nicer version of it.

> * response to DHCPINFORM

This one is easy.   If you sent a DHCPINFORM, you have an IP address.

---

From: "Andre Kostur" <[email-masked]>
Date: Mon, 3 Dec 2007 08:44:09 -0800

Offhand, I think RFC 2131 does say enough on the subject.

Section 4.3.5:

   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.

Also, the table on page 37 dictates that the CIADDR is filled with the
client's IP address.  So the server is expected to either unicast it
back to the client directly (by IP), or unicast it to the relay agent
(if there's a GIADDR).  I'd expect all of the normal ARP requests to
resolve the IP address, and thus I'd expect the packet to be sent to the
actual MAC address of the device.

(Arguably the thin-client is broken in that it's not reporting the
client's hardware address in the chaddr, but that's a different issue)

(I hope everybody's having fun at the IETF in my city :) )

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 3 Dec 2007 08:49:16 -0800

> This one is easy.   If you sent a DHCPINFORM, you have an IP address.

Operationally, this is not precisely true.  There are DHCPINFORMing
clients in the wild now that send an all-zero chaddr, zero htype, and
zero ciaddr.  Since the client does not know the DHCPv4 server's
address, it broadcasts the packet locally, involving relays.

By the time it reaches the server, there is no way to divine an
address for the client.

Ralph, I am overexcited to hear of an interest in clarifying
DHCPINFORM behaviour.  The 2131 specification diverges from the
operational practice.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
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://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Andre Kostur" <[email-masked]>
Date: Mon, 3 Dec 2007 09:06:13 -0800

Which clients aren't sending CIADDR?  That seems to be a violation of
DHCPINFORM.  Sure, it makes sense that the client broadcasts the INFORM
since it doesn't know where the DHCP server is, but the client is
supposed to already have an IP address through some out-of-band
mechanism (or potentially a previous DHCP sequence).

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Monday, December 03, 2007 8:49 AM
To: DHC WG
Subject: Re: [dhcwg] Use of chaddr in response to DHCPINFORM message

By the time it reaches the server, there is no way to divine an address
for the client.

Ralph, I am overexcited to hear of an interest in clarifying DHCPINFORM
behaviour.  The 2131 specification diverges from the operational
practice.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Dec 2007 12:07:23 -0500

On Dec 3, 2007, at 11:44 AM, Andre Kostur wrote:

> (if there's a GIADDR).

Actually, if you go by the text you just quoted, the server never  
sends the reply to giaddr.   I believe that this is in fact the  
correct behavior.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Dec 2007 12:09:57 -0500

> address, it broadcasts the packet locally, involving relays.

In the case you've described, a server conforming to RFC2131 would  
unicast its response to 0.0.0.0, which would obviously not work.   But  
that's okay, because the client isn't compliant with RFC2131.   If you  
would like to describe what the correct behavior is in this case, that  
would be fine, but it is not the case that RFC2131 doesn't say what to  
do in this case - it most definitely does.

Back when I was working on the ISC server, it actually looked for the  
client's IP address in the IP header if it wasn't available in the  
ciaddr field, but that's a quirk workaround, not what the protocol  
says to do.

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 3 Dec 2007 09:14:15 -0800

> ciaddr field, but that's a quirk workaround, not what the protocol  

Yes, precisely.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Dec 2007 12:23:13 -0500

On Dec 3, 2007, at 12:14 PM, David W. Hankins wrote:
>> but that's a quirk workaround, not what the protocol
>> says to do.
>
> Yes, precisely.

So just to disambiguate, the point is that when a device sends a  
nonsense value in a critical protocol field, the fix is for the vendor  
of that device to update its firmware.    If the protocol  
specification is unclear, then a document clarifying the specification  
is in order.   However, the clarification should not simply  
grandfather the broken device's behavior.

And of course, we should not delude ourselves into thinking that the  
offending vendor is going to ever read the new document.   :'}

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 3 Dec 2007 09:22:10 -0800

On Mon, Dec 03, 2007 at 09:06:13AM -0800, Andre Kostur wrote:
> Which clients aren't sending CIADDR?

Specifically, we discovered this via 'Macromedia Flash Proxy
Auto-Detection'.

Generally, my understanding based upon the discussion we had with
folks dealing with this is that Macromedia was using a service
extended to them by Microsoft .Net.

So it may be that a class of DHCP clients do not have the ability to
sense, or at least provide, their IP and MAC addresses.  They may not
even know what interface the packet will be transmitted on.

They seem to use DHCP anyway, and it seems to be working.

> That seems to be a violation of
> DHCPINFORM.

Not just seems, it absolutely is.  So are the workarounds that server
software today uses to interoperate.

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 3 Dec 2007 08:55:17 -0800

> actual MAC address of the device.

Where ciaddr is nonzero, the giaddr should be ignored, according to
2131.  So although it may come to the server through a relay, it need
not return to the client via a relay.

Where ciaddr is (incorrectly) zeroed, it gets interesting, but
specifically in the case where a relay agent is involved, at least one
implementation will reply to the giaddr with the broadcast flag set
explicitly true in this case.

This means that the relay agent will receive the DHCPACK, and will
pass it along.  I think most relay agents are not built to investigate
what DHCP message is passing through them; they are always governed by
the broadcast flag, and chaddr contents.

> client's hardware address in the chaddr, but that's a different issue)

I don't think there is any possibility of argument here.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Dec 2007 21:47:19 -0500

Wrapping up this discussion, David Hankins has volunteered to lead a  
review of the text in RFC 2131 related to sending DHCPINFORM to  
determine if the WG should publish a clarification.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Dec 2007 21:49:55 -0500

There is also text about how a server sends a DHCPINFORM here:

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.

This text implies that the host has an IP address before sending a  
DHCPINFORM and that the server uses unicast back to 'ciaddr'.

So, I guess my summary is that, in fact, the value in the chaddr field  
is irrelevant and ciaddr has the return address.

- Ralph