Re: DHCP clarification

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.

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