DHCP clarification

Kanoj Sarcar <[email protected]>
Newsgroups gmane.ietf.ipoib
Message-ID <[email protected]>
Hi,

While going over section 2 of ipoib/dhcp draft, I realized that it
can be cleaned up somewhat (in my opinion, ie; to others, it might
be quite clear already). Accordingly, I came up with the following
verbiage. If there are some improvements in here, it should be used 
to reword the section.

2.2 Use of the BROADCAST flag

        A DHCP client on IPoIB MUST set the BROADCAST flag (and
        set 'ciaddr' to zero) in DHCPREQUEST messages and 
        DHCPDISCOVER messages sent when it is not in the BOUND 
        or RENEWING states (ie it is in INIT-REBOOT or SELECTING 
        states).

        For other cases, the client SHOULD NOT set the BROADCAST 
        flag if it can receive the server's unicast responses.
        As described in [RFC2131], 'ciaddr' MUST be filled in
        with client's IP address during BOUND, RENEWING or 
        REBINDING states. In these cases, 
        the DHCP server attempts to unicast DHCP responses to 
        the address filled in by the client in 'ciaddr' by using
        IPoIB ARP to resolve the link address. 

The reason I think this is clearer is because:
1. It makes it clear that the BROADCAST flag has to be set in
DHCPDISCOVER.
2. It makes it clear that the BROADCAST flag needs to be set
for DHCPREQUEST only in INIT-REBOOT/SELECTING states.
3. It allows that servers might broadcast responses
(allowed per 2131, see last paragraph section 4.1).
4. It allows that servers might respond with DHCPNAK.
5. It allows that there might be other reasons for clients to
set BROADCAST bit (specifically for INFORM, see 2131 table 5).
6. It does not make it illegal for clients to set BROADCAST bit
for whatever other reason. Unless there is a good reason (other 
than known issues) to make it illegal, I am not sure if this 
was intended. I could not find any MUST NOT reference wrt BROADCAST 
bit in 2131.

Thanks.

Kanoj
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.