Subject: Re: [Ipoverib] DHCP clarification

From: Vivek Kashyap <[email-masked]>
Date: Tue, 6 May 2003 16:19:33 -0700 (Pacific Daylight Time)

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-masked]
> https://www1.ietf.org/mailman/listinfo/ipoverib
>
>

__

Vivek Kashyap
Linux Technology Center, IBM

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

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 6 May 2003 16:19:33 -0700 (Pacific Daylight Time)

Kanoj,

How about the following:

Vivek

__

Vivek Kashyap

---

From: Kanoj Sarcar <[email-masked]>
Date: Tue, 06 May 2003 17:48:09 -0700

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

---

From: Kanoj Sarcar <[email-masked]>
Date: Tue, 06 May 2003 17:48:09 -0700

Vivek,

Thanks.

Kanoj

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 7 May 2003 10:48:55 -0700 (Pacific Daylight Time)

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

__

Vivek Kashyap

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 7 May 2003 10:48:55 -0700 (Pacific Daylight Time)

Kanoj,

RFC2855 states:

The existing draft has:

Vivek

__

Vivek Kashyap

---

From: Kanoj Sarcar <[email-masked]>
Date: Wed, 07 May 2003 12:18:55 -0700

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

---

From: Kanoj Sarcar <[email-masked]>
Date: Wed, 07 May 2003 12:18:55 -0700

Vivek,

Thanks.

Kanoj

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 7 May 2003 15:34:13 -0700 (Pacific Daylight Time)

> restriction (specifically since 2131 doesn't), and I was questioning whether

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

__

Vivek Kashyap

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 7 May 2003 15:34:13 -0700 (Pacific Daylight Time)

RFC2131 states:

Therefore:

Vivek

__

Vivek Kashyap

---

From: Vivek Kashyap <[email-masked]>
Date: Fri, 9 May 2003 13:36:22 -0700 (Pacific Daylight Time)

Kanoj,

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

Vivek

__

Vivek Kashyap

---

From: Vivek Kashyap <[email-masked]>
Date: Fri, 9 May 2003 13:36:22 -0700 (Pacific Daylight Time)

Kanoj,

Vivek

__

Vivek Kashyap