Subject: Re: DHCP use of Node ID

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 30 Nov 1998 12:53:47 -0800

I was thinking all DHCP packets should avoid unicast, but that may be too
restrictive. In general unicast should be avoided whenever there is a
chance of the node ID changing before the response is sent on the 1394
link back to the requestor.

For example, when a DHCP server not on a 1394 link receives a request from a

forwarding agent, the DHCP server (not on the 1394 link) should definitely
not send a unicast DHCP response because the node ID may have changed by the

time the DHCP server responds.

If the server is on the 1394 link and is aware of bus resets, then the
response may use unicast.

A DHCP request could be unicast as long as a DHCP forwarding agent
doesn't extract the 1394 source to be used later as the destination.

Does this help?

-myron

> -----Original Message-----
> From: Randy Turner [mailto:[email-masked]]
> Sent: Monday, November 30, 1998 11:57 AM
> To: Hattig, Myron
> Cc: [email-masked]
> Subject: Re: DHCP use of Node ID
>
>
>
> Are you saying that DHCP "requests" should NOT be unicast? Or
> ALL DHCP packets (requests and responses) should NOT be unicast? It's
> not clear to me from (1) and (2) below which type of packet
> you are referencing.
>
> Randy
>
>
>
> Randy Turner
> Sharp Laboratories of America
> [email-masked]
>
>
> "Hattig, Myron" wrote:
>
> > Kenji,
> >
> > In light of recent bridging discussions you may want to
> > consider the following points:
> >
> > 1) All DHCP packets sent over 1394 should use NETWORK_CHANNEL
> > (aka IP broadcast mechanism).  This includes packets sent
> > by DHCP forwarding agents.
> > 2) Unicasting DHCP packets over 1394 should not be done
> > because of the transient nature of Node id. If DHCP packets
> > are unicasted, the DHCP forwarding agent should not use
> > source information from that packet's 1394 header to return
> > DHCP responses.
> > 3) Add warnings and notes related to the transient
> > nature of the embedded node Id in the chaddr data.
> >
> > Are there other comments on this DHCP proposal?
> >
> > Remember our WG's goal is to submit a 1394/DHCP spec to the
> > appropriate IETF DHCP wG so they can incorporate the 1394/DHCP
> > spec into whatever documents they see fit.
> >
> > -myron
>

---

From: Randy Turner <[email-masked]>
Date: Mon, 30 Nov 1998 14:33:57 -0800

Yes, this helps.

There is language in the DHCP specs that (I believe) talks about what types of requests and responses SHOULD or MUST be implemented,
and I was concerned that we might be going against the official DHCP RFC, with regards to what is broadcast or unicast. I was just
considering the case of official "compliance" with the core DHCP specification.

Thanks!

Randy