Re: DHCP clarification

On Wed, 7 May 2003, Kanoj Sarcar wrote:

> Vivek,
>
> Yes, I had noticed 2855, and knew that most of the material in
> that applies to IPoIB too. But I was not sure why 2855 went ahead and put that
> restriction (specifically since 2131 doesn't), and I was questioning whether
> it is really required.

I take the reasoning behind RFC2855 to be as follows:

RFC2131 states:

	"A client that cannot receive unicast IP datagrams until its protocol
	software has been configured with an IP address SHOULD set
	the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
	DHCPREQUEST messages that client sends.  The BROADCAST bit will
	provide a hint to the DHCP server and BOOTP relay agent to broadcast
    any messages to the client on the client's subnet.  A client that can
    receive unicast IP datagrams before its protocol software has been
	configured SHOULD clear the BROADCAST bit to 0.  "

Therefore:

	In the case of BOUND/RENEWING/REBINDING states the client stack
	has the IP address. Therefore, though the RFC doesn't say it
	explicitly (or at least I didn't find such a statement on a
	search), I still read the RFC as stating that the B flag is not
	to be set in these states.  RFC2131 does explicitly say that a
	client MUST include the 'ciaddr' value in these states.


Vivek

>
> In any case, I am okay if you want to keep the same restriction in ipoib/dhcp
> as in 2855.
>
> Thanks.
>
> Kanoj
>
> Vivek Kashyap wrote:
> >
> > Kanoj,
> >
> > The case where the B flag is  not being set are when the ciaddr
> > contains the IP address.
> >
> > RFC2855 states:
> >
> >       Note: As described in [RFC2131], 'ciaddr' MUST be filled in with
> >       client's IP address during BOUND, RENEWING or REBINDING state,
> >       therefore, the BROADCAST flag MUST NOT be set.  In these cases,
> >       the DHCP server unicasts DHCPACK message to the address in
> >       'ciaddr'. The link address will be resolved by 1394 ARP.
> >
> > The existing draft has:
> >
> >         Note: As described in [RFC2131], 'ciaddr' MUST be filled in with
> >         client's IP address during BOUND, RENEWING or REBINDING state,
> >         therefore, the BROADCAST flag MUST NOT be set. In these cases,
> >         the DHCP server unicasts DHCPACK message to the address in
> >         'ciaddr'. The link address will be resolved by IPoIB ARP.
> >
> > Maybe we should leave it like that.
> >
> > Vivek
> >
> > On Tue, 6 May 2003, Kanoj Sarcar wrote:
> >
> > > Vivek,
> > >
> > > The wording sounds fine; although I am uncomfortable with the "MUST NOT
> > > set BROADCAST flag", preferring the "SHOULD NOT" option. Why is the MUST
> > > NOT restriction required? RFC 2131 leaves the setting of this flag to the
> > > client (as far as I can tell; unless you can quote a specific section that
> > > implies otherwise). Are you worried about servers that might get confused
> > > with the BROADCAST bit in BOUND/RENEWING/REBINDING clients?
> > >
> > > Thanks.
> > >
> > > Kanoj
> > >
> > >
> > > Vivek Kashyap wrote:
> > > >
> > > > Kanoj,
> > > >
> > > > How about the following:
> > > >
> > > > 2.2 Use of the BROADCAST flag
> > > >
> > > >         A DHCP client on IPoIB MUST set the BROADCAST flag and set
> > > >         'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages
> > > >         when it is not in BOUND or RENEWING states. This ensures that
> > > >         the server (or the relay agent) broadcasts its reply to
> > > >         the client.
> > > >
> > > >         In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be
> > > >         filled in with the client's IP address [RFC2131]. The
> > > >         BROADCAST flag MUST NOT be set in these cases since the DHCP
> > > >         server, after resolving the 'ciaddr' address using ARP,
> > > >         unicasts the DHCPACK message to the client.
> > > >
> > > > Vivek
> > > >
> > > > > 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
> > > > > _______________________________________________
> > > > > IPoverIB mailing list
> > > > > [email protected]
> > > > > https://www1.ietf.org/mailman/listinfo/ipoverib
> > > > >
> > > > >
> > > >
> > > > __
> > > >
> > > > Vivek Kashyap
> > > > Linux Technology Center, IBM
> > > _______________________________________________
> > > IPoverIB mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/ipoverib
> > >
> > >
> >
> > __
> >
> > Vivek Kashyap
> > Linux Technology Center, IBM
> _______________________________________________
> IPoverIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipoverib
>
>

__

Vivek Kashyap
Linux Technology Center, IBM