RE: [dhcwg] How to respond to Option 50 (requested address)

Chris Pearson <chris.pearson@infocus.com> Mon, 10 June 2002 19:55 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22473 for <dhcwg-archive@odin.ietf.org>; Mon, 10 Jun 2002 15:55:49 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25984 for dhcwg-archive@odin.ietf.org; Mon, 10 Jun 2002 15:56:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25784; Mon, 10 Jun 2002 15:53:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25759 for <dhcwg@ns.ietf.org>; Mon, 10 Jun 2002 15:53:30 -0400 (EDT)
Received: from manta.infocus.com (moray.infocus.com [209.84.97.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22275 for <dhcwg@ietf.org>; Mon, 10 Jun 2002 15:52:54 -0400 (EDT)
Received: by manta.infocus.com (Postfix, from userid 5) id 9AA9428B66; Mon, 10 Jun 2002 12:52:44 -0700 (PDT)
Received: from sonata.infocus.com(200.1.10.70), claiming to be "sonata.infocuscorp.com" via SMTP by manta.infocus.com, id smtpdAAAkj71F_; Mon Jun 10 12:52:36 2002
Received: by sonata with Internet Mail Service (5.5.2653.19) id <MVDR8Y6L>; Mon, 10 Jun 2002 12:48:58 -0700
Message-ID: <EEBC1981C362D311AA230008C7E627BA07D8EB18@toccata>
From: Chris Pearson <chris.pearson@infocus.com>
To: "'Jeremy Levy'" <jlevy@joltage.com>, dhcwg@ietf.org
Subject: RE: [dhcwg] How to respond to Option 50 (requested address)
Date: Mon, 10 Jun 2002 12:50:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

Sorry, I missed your point.  Section 4.3.1 is pretty clear though:

   When a server receives a DHCPDISCOVER message from a client, the
   server chooses a network address for the requesting client.  If no
   address is available, the server may choose to report the problem to
   the system administrator. If an address is available, the new address
   SHOULD be chosen as follows:

      o The client's current address as recorded in the client's current
        binding, ELSE

      o The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      o The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      o A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

Note that not only does the server *not* have to offer the requested
address, it is not even the first choice.  And if the first two conditions
are absent, your server only "SHOULD" (not "MUST") assign the requested
address, so the implementation does have discretion to ignore the requested
address even in that case.

Apparently your client mistakenly believes that it will get its way by
repeatedly asking the same question.  The client could eliminate the entire
discover/offer exchange by initially broadcasting DHCPREQUEST with desired
IP per section 3.2, but I imagine that changing the client is not in your
control.

- Chris

-----Original Message-----
From: Jeremy Levy [mailto:jlevy@joltage.com]
Sent: Sunday, June 09, 2002 11:37 AM
To: dhcwg@ietf.org
Subject: RE: [dhcwg] How to respond to Option 50 (requested address)


Even in a Discover? Maybe I am missing something but all I can find is
this:

"  If a server receives a DHCPREQUEST message with an invalid 'requested
   IP address', the server SHOULD respond to the client with a DHCPNAK
   message and may choose to report the problem to the system
   administrator.  The server may include an error message in the
   'message' option."

I don't see any information on how to handle this is in a discover if I
don't want to give the client its requested IP...

Jeremy

-----Original Message-----
From: Chris Pearson [mailto:chris.pearson@infocus.com] 
Sent: Friday, June 07, 2002 3:37 PM
To: Jeremy Levy; dhcwg@ietf.org
Subject: RE: [dhcwg] How to respond to Option 50 (requested address)


DHCPNAK.  Search RFC2131 for 'Requested IP Address' option for the
answer. HTH.

-- Chris

-----Original Message-----
From: Jeremy Levy [mailto:jlevy@joltage.com]
Sent: Thursday, June 06, 2002 9:47 AM
To: dhcwg@ietf.org
Subject: [dhcwg] How to respond to Option 50 (requested address)


I have written a DHCP server, however I can't find anything in the RFC
about how to handle Option 50, client requested IPAddress on a
DHCPDiscovery when I want to give the client a different address.  

Right now I just respond with a DHCPOffer with a different IP.  After 2
or 3 Discovers/Offers the client finally sends a request.  Am I handling
this
properly?   I would like to get rid of those 2 or 3 middle
Discover/Offers
and speed up the process a bit...


Thanks


Jeremy


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg