From owner-freebsd-hackers  Fri Jan 17 17:39:22 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id RAA13235
          for hackers-outgoing; Fri, 17 Jan 1997 17:39:22 -0800 (PST)
Received: from dynamite.Stanford.EDU (root@dynamite.Stanford.EDU [171.64.65.12])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA13221
          for <hackers@freebsd.org>; Fri, 17 Jan 1997 17:38:42 -0800 (PST)
Received: from mosquitonet.Stanford.EDU (tomy@localhost [127.0.0.1]) by dynamite.Stanford.EDU (8.7.3/8.7.3) with ESMTP id RAA11768; Fri, 17 Jan 1997 17:38:33 -0800
Message-Id: <199701180138.RAA11768@dynamite.Stanford.EDU>
To: dhcp-v4@cs.bucknell.edu
Cc: brian@awfulhak.demon.co.uk, hackers@freebsd.org,
        tomy@dynamite.Stanford.EDU
Subject: Q about draft-ietf-dhc-dhcp-09.txt
X-Mailer: Mew version 1.54 on Emacs 19.28.1, Mule 2.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri, 17 Jan 1997 17:38:32 -0800
From: Akihiro Tominaga <tomy@gunpowder.Stanford.EDU>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

I want to discuss about the following paragraph (on pg 32);

   o DHCPREQUEST generated during INIT-REBOOT state:

        <omit>

     If the network is correct, then the DHCP server should check if the
     client's notion of its IP address is correct. If not, then the
     server SHOULD send a DHCPNAK message to the client. If the DHCP
     server has no record of this client, then it MUST remain silent,
     and MAY output a warning to the network administrator. This
     behavior is necessary for peaceful coexistence of non-communicating
     DHCP servers on the same wire.


Please think about the following situation.

  A client requests address 'A'.
  There is a server 'X' which has the binding that points address 'B'.
     'B' is already expired.
  There is another server 'Y' which has the binding that points address 'A'.
     'A' is valid.

This is not illegal situation.  And if 'X' sends NAK and 'Y' sends
ACK, there is no guarantee which packet arrives first.  So the behavior
of the most client depends on arrivals of packets.

IMHO, the server should send back NAK only if the DHCPREQUEST is
directly sent to the specific unicast IP address of the server.  And
in this situation, the server shouldn't send NAK.

Any comment?

--
Visiting Researcher of Stanford Univ.
Mosquito Net Project.
Keio Univ.
WIDE Project.
			Akihiro Tominaga (tomy@mosquitonet.stanford.edu)