Broadcasts of DHCPNAK: To be or not to be...

Mark Sirota <msirota@isc.upenn.edu> Tue, 18 June 1996 19:29 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03096; 18 Jun 96 15:29 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03092; 18 Jun 96 15:29 EDT
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa18581; 18 Jun 96 15:29 EDT
Received: from localhost by reef.bucknell.edu with SMTP (5.65/IDA-1.2.8) id AA01061; Tue, 18 Jun 1996 15:22:19 -0400
Date: Tue, 18 Jun 1996 15:22:19 -0400
Message-Id: <31C70110.52BF@isc.upenn.edu>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
X-Orig-Sender: dhcp-v4@bucknell.edu
Precedence: bulk
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Sirota <msirota@isc.upenn.edu>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Broadcasts of DHCPNAK: To be or not to be...
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
Mime-Version: 1.0
X-Mailer: Mozilla 3.0b2 (X11; I; OSF1 V3.2 alpha)

I'm confused.  The specs seem to contradict themselves about whether a DHCPNAK
should be broadcast to the client or should be unicast.

The latest spec, draft-ietf-dhc-dhcp-07.txt, reads on Page 19:

	If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
	the same subnet as the server.  The server MUST
	broadcast the DHCPNAK message to the 0xffffffff broadcast address
	because the client may not have a correct network address or subnet
	mask, and the client may not be answering ARP requests.
	Otherwise, the server MUST send the DHCPNAK message to the IP
	address of the BOOTP relay agent, as recorded in 'giaddr'.  The
	relay agent will, in turn, forward the message directly to the
	client's hardware address, so that the DHCPNAK can be delivered even
	if the client has moved to a new network.

So, this says to me that if the two are on the same network, regardless of
the client's previous notion of its address, the client should expect a NAK
to be broadcast at both the link and IP layers.  If there is a router or
other BOOTP relay agent between them, then the client should expect NAKs to
be unicast to its hardware address (this doesn't say what it should see in
the IP destination address).

This is bewildering...  The client doesn't know anything about the topology
of the network, and in both cases, its notion of its IP address (and maybe
netmask, etc) are wrong.  Why would we send the NAK in two different ways?

On page 23, the spec says:

	In all cases, when 'giaddr' is zero, the server broadcasts any
	DHCPNAK messages to 0xffffffff.

Now this doesn't explicitly conflict with the section above from Page 19,
but if the server is to broadcast the NAK, shouldn't the BOOTP relay agent
also broadcast the NAK?  Yet the passage above from page 19 says no.  Note
also that this sentence is worded without the benefit of words like "SHOULD"
or "MUST"...

Just to confuse matters further, on Page 24:

	Normally, DHCP servers and BOOTP relay agents attempt to deliver
	DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
	unicast delivery.  The IP destination address (in the IP header) is
	set to the DHCP 'yiaddr' address and the link-layer destination
	address is set to the DHCP 'chaddr' address.

This is leading to a discussion of the broadcast bit, and is discussing the
scenario where the broadcast bit was not set by the client on the DISCOVER or
REQUEST.  However, it conflicts with the page 19 passage, which says "the
server MUST broadcast the DHCPNAK message..."

On page 31, we have a good summary of the situation:

	If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on the
	same subnet as the server.  The server MUST broadcast the DHCPNAK
	message to the 0xffffffff broadcast address because the client may
	not have a correct network address or subnet mask, and the client
	may not be answering ARP requests.

	If 'giaddr' is set in the DHCPREQUEST message, the client is on a
	different subnet.  The server MUST set the broadcast bit in the
	DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
	client, because the client may not have a correct network address
	or subnet mask, and the client may not be answering ARP requests.

The second paragraph there conflicts directly with the passages I quoted from
pages 19 and 24.

This has been rather long, so I will send a separate message indicating how
this relates to my situation.
-- 
Mark Sirota, Network Systems Engineer
University of Pennsylvania, Information Systems and Computing
msirota@isc.upenn.edu, 215/573-7214