Subject: Re: Relayed lease extension

From: Ted Lemon <[email-masked]>
Date: Mon, 01 May 2000 11:44:42 -0400

If the client acts like it's in the REBINDING state, the DHCP server
*must* honor giaddr.   The only time that the server's expected
behaviour is not defined for giaddr is when the client is acting like
it's in the RENEWING state.   So if you want consistent behaviour, you
shouldn't have the client fill in giaddr when it's acting like it's in
the RENEWING state.

I will freely admit that this isn't entirely optimal - it would be
nice if the standard said that the server MUST honor giaddr in favor
of ciaddr, but it doesn't, so you're stuck.   :'}

			       _MelloN_

---

From: Tylor Allison <[email-masked]>
Date: Mon, 1 May 2000 14:12:13 -0500 (CDT)

> of ciaddr, but it doesn't, so you're stuck.   :'}

Even using the giaddr field does not solve all implementation
scenarios.  The scenario I've been wrestling with is having a DHCP
client (similar to the BixBox described previously) hosted on the same
machine as a DHCP server.  In this scenario the client cannot use the
giaddr field (to act as a DHCP relay agent) because the DHCP server port
is already bound to the local DHCP server.

Any ideas on how this can be accomplished using the current DHCP
standards?  Does it make sense to support this scenario at all?

---
Tylor Allison         [email-masked]
Secure Computing Corporation

---

From: David Babbitt <[email-masked]>
Date: Mon, 01 May 2000 14:29:03 -0500

> standards?  Does it make sense to support this scenario at all?

It's a hack, but you could make the client use REBIND instead of RENEW, 
and you may have to always set the broadcast bit (depends on how your 
server learns of your hwaddr.)  Like the rest of the discussion in this
thread, this might also depend on how lenient the server is.

The second question is probably more philosophical :)  I guess it
makes sense if you want to use DHCP as a client for some interfaces
on which the server won't receive requests from clients, but I'd 
have to lean to the "no" answer for anything else.

Dave
-- 
David Babbitt
AIX TCP/IP Development
IBM Austin

---

From: Wim Janssen <[email-masked]>
Date: Mon, 01 May 2000 13:59:27 -0700

> For renewals, how are they handled? The renewl is sent by BigBox with
> the client's IP address. If the response is send back to the cleint's
> IP address, then either:
> a) BigBox must take steps to prevent it from going to the client and
> intercept it.

I'm not really in favor of snooping all DHCP packets, which would be
the only solution if the DHCPACK is returned to the PPP user.
AnyBox would loose a lot of its performance in doing so.
 
> shouldn't have the client fill in giaddr when it's acting like it's in

Would it be a valid scenario, if the client immediately went to 
REBINDING state (and doesn't fill in ciaddr), when T2 expires 
(and didn't do anything when T1 expires)?
I suppose the server doesn't know that this client is skipping
the RENEWING state. 

Of course, this would be a temporary solution, as long as there 
is no definite answer.

>  The scenario I've been wrestling with is having a DHCP

That's a similar problem BigBox has, when it wants to relay *real* dhcp
clients. If it can only listen for a single DHCP server port, it has to
make its decisions based on its knowledge of client leases it owns, and
decide whether it needs to relay the request to a real dhcp client or not.

Wim

---

From: Ted Lemon <[email-masked]>
Date: Mon, 01 May 2000 19:01:33 -0400

> standards?  Does it make sense to support this scenario at all?

Criminy, man!   I think the answer in this case is currently that
you're SOL.   Sorry about that.   I do a lot of DHCP development on my
laptop, and the only way I've found to work around this issue is to
assign more than one IP address to the DHCP client/server machine and
bind to specific addresses.   In combination with BPF, this gives me
the behaviour I want, but I wouldn't want to have to tell a customer
how to do it!

			       _MelloN_

---

From: Wim Janssen <[email-masked]>
Date: Mon, 01 May 2000 22:18:23 -0700

> (and didn't do anything when T1 expires)?

I myself can answer this ;-)  
Apparently not: 'ciaddr' is supposed to be filled in all the 
time, even when REBINDING.

The reason behind the idea was that it still didn't work when I went
to REBINDING state, and 'ciaddr' & 'giaddr' were filled in.

Is this then a problem in the server?

Wim

---

From: Ted Lemon <[email-masked]>
Date: Tue, 02 May 2000 14:18:19 -0400

Here's the table from the standard:

   ---------------------------------------------------------------------
   |              |INIT-REBOOT  |SELECTING    |RENEWING     |REBINDING |
   ---------------------------------------------------------------------
   |broad/unicast |broadcast    |broadcast    |unicast      |broadcast |
   |server-ip     |MUST NOT     |MUST         |MUST NOT     |MUST NOT  |
   |requested-ip  |MUST         |MUST         |MUST NOT     |MUST NOT  |
   |ciaddr        |zero         |zero         |IP address   |IP address|
   ---------------------------------------------------------------------

It looks like the DHCPREQUEST in RENEWING and REBINDING states is the
same, so you don't get any benefit from mimicking the REBINDING state
when you really want the RENEWING state - they should both look the
same to the server.   RFC2131 says, in section 4.1 (constructing and
sending DHCP messages):

   If the 'giaddr' field in a DHCP message from a client is non-zero,
   the server sends any return messages to the 'DHCP server' port on the
   BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
   field is zero and the 'ciaddr' field is nonzero, then the server
   unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
   If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
   set, then the server broadcasts DHCPOFFER and DHCPACK messages to
   0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
   'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
   messages to the client's hardware address and 'yiaddr' address.  In
   all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
   messages to 0xffffffff.

So if you set giaddr and the response comes back to ciaddr, the DHCP
server is in violation of the protocol.

I'm sorry for not having read the specification before responding
earlier - in fact, the specification says what needs to be said quite
clearly, and if you are experiencing different behaviour from a DHCP
server, you should contact the server vendor and request an update.
Sigh.

			       _MelloN_

---

From: Wim Janssen <[email-masked]>
Date: Tue, 02 May 2000 16:30:31 -0700

> same to the server.   RFC2131 says, in section 4.1 (constructing and

With all due respect - & with apologies if I look too persistent - I 
must say the rfc actually assumes that a DHCPREQUEST won't contain 
'giaddr' when generated during RENEWING state. 
On the other hand, it doesn't mention 'giaddr' when the client is in 
REBINDING state.

Section 4.3.2 (DHCPREQUEST message):

   Clients send DHCPREQUEST messages as follows:

   o DHCPREQUEST generated during RENEWING state:

      'server identifier' MUST NOT be filled in, 'requested IP address'
      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
      client's IP address. In this situation, the client is completely
      configured, and is trying to extend its lease. This message will
      be unicast, so no relay agents will be involved in its      
      transmission.  Because 'giaddr' is therefore not filled in, the
      DHCP server will trust the value in 'ciaddr', and use it when
      replying to the client.

So your initial remark, stating that 'giaddr' can be filled in & needs
to be addressed when responding during REBINDING state is perfectly
valid - which is what I will do (for now).

> server, you should contact the server vendor and request an update.

I just did. 

Wim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 03 May 2000 01:33:17 -0400

> valid - which is what I will do (for now).

The section of the RFC that I quoted applies to _all_ DHCP messages
originating from the DHCP server, not just to certain ones.   If
giaddr is set, the server is very clearly required to send the message
to giaddr, *not* to the client.   The state the client is in is
irrelevant.   The fact that the giaddr-specific behaviour is not
reiterated in the section you quoted is immaterial.

			       _MelloN_