Subject: Re: DHCP use of Node ID

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 1 Dec 1998 18:01:25 -0800

> -----Original Message-----
> From: Kenji Fujisawa [mailto:[email-masked]]
> Sent: Tuesday, December 01, 1998 5:12 PM
> To: [email-masked]
> Subject: Re: DHCP use of Node ID
>
>
> >This brings up another issue with the DHCP document, should it
> >include a discussion of what a server should do after a bus
> >reset when the server sits on the 1394 link?
>
> I don't see any issue unless the server holds nodeID in 'chaddr'
> field. I'd like to avoid 1394-specific action as far as I can,

Okay, makes sense.

> >Does this mean never use chaddr in 1394 networks?
>
> Yes.
>
> >Does this mean always use broadcast?
>
> No.
> It is descrived in RFC2131 which DHCP messages should be an unicast.
> For example,
>   DHCP messages between the relay agents and the DHCP server
>   DHCPINFORM and its response
>   DHCPOFFER/DHCPACK if 'ciaddr' in corresponding DHCP request
> is non-zero
>   DHCPREQUEST during RENEWING state
>   DHCPRELEASE
>   etc.
> In these case, ARP can/should be used to get the link-layer address.
>
> I don't wish to re-write the DHCP spec itself.

Me either. I'm not completely sure we are talking about the same thing. When I said always use broadcast, I was referring to the places in your below diagram where ???? exists. I think your response above is referring to the non-1394 link between the forwarding agent and the server. In the case of forwarding agent to server), of course we cannot always use broadcast.

Here is your previous text with the ????:
> All we have to consider is, the case when the server (or the
> relay agent) will wish to use the 'chaddr'.
>
>         Client ---(broadcast)--> Server
>                <---- ???? ------
>
>         Client ---(broadcast)--> Relay ---(unicast)---> Server
>                <---- ???? ------       <--(unicast)----
>
>                                 (Note: Relay and Server may exist
>                                                  on another 1394)
>
> My idea is,
>     DHCP client on the 1394 does not put its hardware address
>     in the DHCP request. 'hlen' equals zero.
>     Set BROADCAST flag to request the server (or the relay) to
>     send a broadcast reply.

-myron

---

From: Kenji Fujisawa <[email-masked]>
Date: Wed, 2 Dec 1998 13:27:47 +0900

>I think your response above is referring to the non-1394 link
>between the forwarding agent and the server.

No. The examples which I mentioned includes other scenario.

>>   DHCPOFFER/DHCPACK if 'ciaddr' in corresponding DHCP request

This DHCPOFFER or DHCPACK message is sent from the server to the
client as an unicast since the client already has an IP address.

>When I said always use broadcast, I was referring to the places
>in your below diagram where ???? exists.

My intent was, the server (or the relay) SHOULD send a broadcast
reply when the client wish to acquire an IP address.

So, I'd like to write more precisely again.

- 'chaddr' for 1394 DHCP clients is not used.
  'hlen' for 1394 DHCP clients MUST be 0.

- DHCP clients on 1394 SHOULD set BROADCAST flag in DHCPDISCOVER
  and DHCPREQUEST messages to request the server (or the relay
  agent) to send a broadcast reply if its 'ciaddr' is zero.

Kenji Fujisawa

---

From: Myron Hattig <[email-masked]>
Date: Wed, 2 Dec 1998 08:54:17 -0800

> reply when the client wish to acquire an IP address.

I think we are talking past each other some in the earlier
paragraphs, but in the last section I agree with but have some
questions below.

>   'hlen' for 1394 DHCP clients MUST be 0.

If we don't define chaddr, then how can its length
be zero. Maybe there is some DHCP nuance here that
I am unaware of.

>   agent) to send a broadcast reply if its 'ciaddr' is zero.

If ciaddr is zero and chaddr is never used for 1394 interfaces, true,
the response can be broadcasted, but how will the requestor know
the response is for it.

-myron

---

From: Kenji Fujisawa <[email-masked]>
Date: Thu, 3 Dec 1998 11:07:40 +0900

>be zero. Maybe there is some DHCP nuance here that

I defined 'chaddr' for 1394 clients as an NULL.

>the response can be broadcasted, but how will the requestor know

There is an 'xid' field in all DHCP messages.

RFC2131,
:   The 'xid' field is used by the client to match incoming DHCP messages
:   with pending requests.  A DHCP client MUST choose 'xid's in such a
:   way as to minimize the chance of using an 'xid' identical to one used
:   by another client.   [snip]

It is not 100% perfect, but it works.
DHCP recomends to detect a collision of an IP address.

:   The client SHOULD perform a final check on the
:   parameters (e.g., ARP for allocated network address),

Kenji Fujisawa