Subject: Re: DHCP use of Node ID

From: Kenji Fujisawa <[email-masked]>
Date: Tue, 1 Dec 1998 14:16:02 +0900

I'll respond out of order.

>Are there other comments on this DHCP proposal?

Not yet.

>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.

In this case, the server sends an unicast DHCP response to the 'giaddr',
the IP address of the relay agent. It will typically be a link-layer
unicast.

And then, the relay agent forwards it to the DHCP client.
This packet is the issue.

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

Even if the server is aware of bus resets, the server can not know
the new nodeID since the server can not use ARP yet.

>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.

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.

This will eliminate the burden of handlling a link header at
the DHCP server or the relay agent, and this does not break the
DHCP(RFC2131) context.

What do you think of?

Kenji Fujisawa

---

From: "Wooten, David" <[email-masked]>
Date: Wed, 2 Dec 1998 08:35:29 -0600

Comment below.

David Wooten

> -----Original Message-----
> From: Hattig, Myron [mailto:[email-masked]]
> Sent: Tuesday, December 01, 1998 8:01 PM
> To: [email-masked]
> Subject: Re: DHCP use of Node ID
>
>
> > -----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.

Still going to have to have a discussion about what happens after a 1394
reset.  If for no other reason than to make sure that the are not any 1394
specific issues that need to be covered in the spec.  Need to discuss at
least one implementation that works and doesn't require 1394 specific
behavior to be described in the spec.

>
> > >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 ????:
> -myron