Subject: [dhcwg] Question about RFC2131

From: Amy <[email-masked]>
Date: Wed, 21 Jun 2006 09:35:54 +0800

Hi, all
      
     I read the RFC2131 yesterday, and I have some questions about
DHCPREQUEST

     In Section4.4.4 Use of broadcast and unicast
	"The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
   messages, unless the client knows the address of a DHCP server."

     And In Section 3.1 Client-server interaction - allocating a network
address
     	"3.........The client broadcasts a DHCPREQUEST message
     that MUST include the 'server identifier' option to indicate which
     server it has selected, and that MAY include other options
     specifying desired configuration values. ..........."

    My questions are:
    The client can extracts the server address from the 'server identifier'
option in the DHCPOFFER message , can I say that the client knows the
address of the DHCP Server? 
    According to Section 4.4.4, the DHCP client unicasts the DHCPREQUEST.
But according to Section 3.1，the DHCP client broadcasts the DHCPREQUEST.
And which is correct， unicast ?  or broadcast ?  

   Is there a contradiction between Section 4.4 and Section 3.1?

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

---

From: Pavan Kurapati <[email-masked]>
Date: Wed, 21 Jun 2006 08:13:55 +0530

Hi Amy,

Client broadcasts DHCP REQUEST so that all other servers who sent OFFER
can know which server was selected by the client. This will be done
whenever the client broadcasts the DISCOVER packet. What section 4.4.4
says is that if client knows the server IP address before hand then it
can directly unicast the DISCOVER/REQUEST to the server (instead of
broadcasting DISCOVER). Even in this case, it will revert to broadcast
model if there is no response from the server.

Regards,
Pavan

>   Is there a contradiction between Section 4.4 and Section 3.1?

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 21 Jun 2006 03:09:15 +0000

> address of the DHCP Server? 

That's correct, although even that language is a bit misleading.

Wether or not the client chooses to unicast or broadcast has more to
do with wether or not it is configured enough to be able to do so
than what state or protocol message it's dealing with.

Basically, if you have an ip address and have good reason to believe
it's correct, you unicast.  If not, you broadcast.

> But according to Section 3.1??the DHCP client broadcasts the DHCPREQUEST.
> And which is correct?? unicast ?  or broadcast ?  

It depends.

If the client is in RENEWING, you can count on it using unicast.

Any other state, broadcast, as far as my memory goes.  See the table
in 4.3.6 (this is a subset of all the client states, but for example
INIT state for DISCOVER is covered in another section of the RFC - it
obviously has to be broadcast).

>    Is there a contradiction between Section 4.4 and Section 3.1?

Not really.  Section 3.1 is focusing on 'acquiring an address', so
it doesn't really talk about RENEWING leases.  When the client does
not yet have an address, all it can do is broadcast.

Section 4.4.4 mentions as you quote that the client 'knows the address
of the DHCP Server', and allows unicast in that case...this is a
reference to RENEWING state and similar.

It could have been clearer...

-- 
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

---

From: Amy <[email-masked]>
Date: Thu, 22 Jun 2006 17:29:05 +0800

Thank for your answer.

If the client broadcast the DISCOVER, then it broadcast the subsequent
REQUEST in SELECTING state. And If the client unicast the DISCOVER, then it
unicast the subsequent REQUEST in SELECTING state. 

Do I catch your mean? 

> -----Original Message-----
> From: Pavan Kurapati [mailto:[email-masked]] 
> Sent: Wednesday, June 21, 2006 10:44 AM
> To: Amy
> Cc: [email-masked]
> Subject: Re: [dhcwg] Question about RFC2131
> 
> 
> Hi Amy,
> 
> Client broadcasts DHCP REQUEST so that all other servers who 
> sent OFFER can know which server was selected by the client. 
> This will be done whenever the client broadcasts the DISCOVER 
> packet. What section 4.4.4 says is that if client knows the 
> server IP address before hand then it can directly unicast 
> the DISCOVER/REQUEST to the server (instead of broadcasting 
> DISCOVER). Even in this case, it will revert to broadcast 
> >     And In Section 3.1 Client-server interaction - allocating a 
> >network address
> **************** CAUTION - Disclaimer ***************** This 
> e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION 
> intended solely for the use of the addressee(s). If you are 
> not the intended recipient, please notify the sender by 
> e-mail and delete the original message. Further, you are not 
> to copy, disclose, or distribute this e-mail or its contents 
> to any other person and any such actions are unlawful. This 
> e-mail may contain viruses. Infosys has taken every 
> reasonable precaution to minimize this risk, but is not 
> liable for any damage you may sustain as a result of any 
> virus in this e-mail. You should carry out your own virus 
> checks before opening the e-mail or attachment. Infosys 
> reserves the right to monitor and review the content of all 
> messages sent to or from this e-mail address. Messages sent 
> to or from this e-mail address may be stored on the Infosys 
> e-mail system.

---

From: Pavan Kurapati <[email-masked]>
Date: Fri, 23 Jun 2006 12:12:16 +0530

Amy,
Yes. You are right. If client knows the server and has a capability of
unicasting, it will unicast the message(Discover/Request). Incase it is
renewal it will send a REQUEST directly to the server.

Thanks,
Pavan

Amy wrote:

>>>	"The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST 
>>>      
>>>
>>and DHCPINFORM
>>    
>>
>>>    that MUST include the 'server identifier' option to 
>>>      
>>>
>>indicate which
>>    
>>
>>>   The client can extracts the server address from the 
>>>      
>>>
>>'server identifier'
>>    
>>
>>>option in the DHCPOFFER message , can I say that the client 
>>>      
>>>
>>knows the 
>>    
>>
>>>   According to Section 4.4.4, the DHCP client unicasts the 
>>>      
>>>
>>DHCPREQUEST.
>>    
>>
>>>But according to Section 3.1，the DHCP client broadcasts the 
>>>      
>>>
>>DHCPREQUEST.
>>    
>>