Re: DHCP clarification

Kanoj,

I think we can leave the draft as is
(draft-ietf-ipoib-dhcp-over-infiniband-05.txt).

Vivek


On Wed, 7 May 2003, Vivek Kashyap wrote:

> 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
>
> _______________________________________________
> IPoverIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipoverib
>
>

__

Vivek Kashyap
Linux Technology Center, IBM