Subject: chaddr len = 0

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 23 Jul 1999 17:05:46 -0400 (EDT)

Ted,

I'm told you're the person to ask about the best solution for chaddr on 
1394 networks. This relates to the "DHCP extensions for 1394" discussion
that took place at the Oslo IETF meeting last week. The options discussed 
were to have len = 0 or have len = 8 then use the EUI-64 ID as the value. 

We discussed using the 1394 16-bit node id but that is a bad idea. 1394 
node ids are the source and destination values in 1394 packets. 
Unfortunately 1394 node IDs change when a 1394 device is added or 
removed from the bus. This discounts node IDs as a candidate for the 
chaddr.

The EUI-64 is a globally unique number associated with each link/phy 
1394 interface (there is not one EUI-64 per port, just one EUI-64 per 
the link/phy chipset). The EUI-64 is not a link layer packet source or 
destination addrs.  Thus the normal function of EUI-64 is not equal to 
the normal function of a chaddr value (at least my understanding of 
a chaddr).

Looking at the function provided by chaddr and the numbers available 
from 1394, it seems chaddr for 1394 should be NULL with a length of
zero. Some say a chaddr of len 0 will break many DHCP implementations. 

The first question is: Will many implementations break with a chaddr 
len = 0?
If yes, then is it reasonable to expect people to fix their implementations
to support chaddr len = 0?
Is it a better option for 1394 devices to put the EUI-64 in the chaddr 
field? Will some implementations use this as a dst/src MAC address 
inappropriately?

Thanks,

-myron

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Thursday, July 15, 1999 6:09 AM
> To: Multiple recipients of list
> Subject: Re: UUID client ID 
> 
> 
> 
> > It seems that the global 802 MAC address and EUI-64 are also useful
> > for the authentication.
> 
> Do you mean as a global identifier, or as actual authentication?
> They're probably useful as a global identifier, although 48 bits is
> kind of small nowadays for a global identifier and will come to seem
> even smaller as time goes by.
> 
> 			       _MelloN_
>

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Fri, 23 Jul 1999 18:29:40 -0400 (EDT)

Myron--

I won't pretend to be an authority on other servers than the one I nurture
very carefully for our high-reliability environment, but in general, I don't
much like the idea of zero length chaddr's.

Having said that, I do understand the difficulty in transferring a mechanism
designed for a different medium to the IEEE-1394 environment, and don't want
to be too arbitrary about what packets my server will accept.  We go far
beyond the validation built into the ISC server -- we cross-check every
single BOOTP packet header field and discard any packet that does not
completely conform to published layouts.  Note that this is quite the
opposite of the old programmer's maxim, "Be liberal in what you accept, but
conservative in what you offer."

The major difference in philosophies comes from our business requirement to
provide nearly 100% availability of all operations support systems.  We
routinely reject vendor equipment as unsuitable for our environment because
it does not conform to these policies.

I suggest that a chaddr length of zero, while it wouldn't pass our current
packet filters, might not be a devastating thing to accept if there were
some way to clearly and unambiguously identify the sender as an IEEE-1394
interface.  If there is a unique hardware type octet that identifies an
IEEE-1394 interface, that would work well for me.  But if the only way to
distinguish an IEEE-1394 interface is to infer it from a missing chaddr, I
would tell you to go back to the drawing board and start over....  How could
I tell a broken client from a firewire client in that case?

In your note you mentioned that the node ID changes as devices are added or
dropped from a firewire interface, rendering it unusable for identifying the
source or destination of a packet.  However, you didn't really explain
enough about the EUI to know if it is an appropriate substitute.  So, how
does one uniquely identify the source and destination of data packets on a
firewire interface?  The answer to that question, it seems to me, is the
answer to the question "what to use in place of chaddr?"  As the current
version of the DHC RFC uses the hardware address as the final determinant of
client identity (it MUST be present if client-identifier is not), how could
a server do anything but discard a received packet having a null chaddr and
no client-identifier?

Also, what is the hardware type octet for IEEE-1394?  Does such a concept
exist?  Is there some way to absolutely identify a firewire interface that
would serve the same purpose?  [I realize that Kenji covered this some time
ago on the mailing list, but I want to be very certain that we have the same
understanding, so, I ask again....]

Finally, one has to consider who/what would have to change to have a null
chaddr.  You probably cannot change client behavior because there are too
many clients, which cannot be expected to change just because of a new
option.  That leaves DHCP servers.  If there is an unambiguous way to
determine the source and destination address of a packet, then the servers
will change to accommodate it -- but not if there isn't!

--Barr

> From: 	Hattig, Myron[SMTP:[email-masked]]
> Sent: 	Friday, July 23, 1999 2:07 PM
> Subject: 	chaddr len = 0

---

From: [email-masked]
Date: Sat, 24 Jul 1999 15:04:48 -0400 (EDT)

>IEEE-1394 interface, that would work well for me. 

'htype' for IEEE1394 node is 24.
http://www.isi.edu/in-notes/iana/assignments/arp-parameters
So, it will not be a problem.

>As the current

Our draft proposes as follows,
:  'client identifier' option MUST be used in DHCP messages from the
:  client to the server due to the lack of the 'chaddr'. 

If chaddr is null and there is no client-ID, it is an illegal packet.
I think such packet should be discarded.

>would serve the same purpose?

'htype' for IEEE1394 node is 24.

Best Regards,

Kenji Fujisawa

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Jul 1999 11:42:21 -0400 (EDT)

> The first question is: Will many implementations break with a chaddr 

I don't really know.  The ISC server will not behave optimally in this
situation, although I think it will work.  You would have to ask
Microsoft, Cisco, Sun, and all the other DHCP server vendors how their
servers would operate.

> to support chaddr len = 0?

I think it's reasonable to ask.   Whether or not they will do it, I
don't know.   While you're asking them the first question, you can put
the second to them if they answer no to the first... :')   We at the
ISC are very definitely willing to make the changes required to the
server to make this work well.

Of course, you haven't asked the question, "will vendor's DHCP servers
work at all with firewire, as they are."   This is a question worth
asking.   I don't have any equipment with which to try this, myself,
so I don't know.

> field?

I don't think it is.   If you don't have a valid link-layer address to
put in chaddr, I think it makes perfect sense to put nothing there,
and I think it makes no sense at all to put something there that will
not work as a link-layer address.

> Will some implementations use this as a dst/src MAC address 
> inappropriately?

Possibly.   I don't know.

What does firewire use as a link-layer address itself?   Are all
packets broadcast, and the IP destination address used as a
discriminator?

			       _MelloN_

---

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 26 Jul 1999 12:45:36 -0400 (EDT)

> not work as a link-layer address.

Thanks, that is the answer that makes the most sense to me.
 
> packets broadcast, and the IP destination address used as a

1394 uses a 16 bit node id. 10 bits identify the bus. 6 bits identify the
node.
The node id is ephemeral. It changes any time there is a bus reset. A bus 
reset occurs when a device is plugged into the bus or removed from the bus.
Also, the software on a host can force a bus reset for error conditions 
or in some awful cases as a part of the initialization of a protocol or 
application.

These comments and my simple-minded understanding of chaddr lead me to 
think the value of chaddr for 1394 nodes should be null. Maybe a less 
controversial  way to say this is "don't use chaddr to identify a client".

Then in addition say "only use client id". According to the rules described
to
me, servers only look at chaddr if client id is not used, thus this rule
should 
work. Before flaming me for this comment, realize I'm not a DHCP expert.

-myron

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Jul 1999 12:47:07 -0400 (EDT)

> controversial  way to say this is "don't use chaddr to identify a client".

Right.

> Then in addition say "only use client id". According to the rules
> described to me, servers only look at chaddr if client id is not
> used, thus this rule should work. Before flaming me for this
> comment, realize I'm not a DHCP expert.

This sounds fine.

One observation that I would have, though, is that if it's possible
for IP to use the ephemeral link-layer address, it should also be
possible for DHCP to use it - just not as an identifier.   Whether or
not this is important, I don't know - it'd be neater and cleaner to
eliminate the broadcasts, but I'm not sure how much difference it
would make in practice.

The DHCP protocol already says the DHCP server is supposed to prefer
the client identifier to the hardware address as an identifier, so as
long as you require that all firewire DHCP clients send a DHCP client
identifier, it would be legitimate to include the ephemeral id in
chaddr and use it to unicast responses.

			       _MelloN_

---

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 26 Jul 1999 13:39:37 -0400 (EDT)

> it would be legitimate to include the ephemeral id in

The problem is if the node ID changes after the 
host sends a chaddr to the server, then the server
may be unicasting back to the wrong host. This may
occur because values for the 6 bit phy portion of 
the 16 bit  node id are always contiguous from 0 to
the number of 1394 devices on the bus. Since there
is no guarantee that a host retains the value it 
previously had before the bus reset, the DHCP 
server could be unicasting back to the wrong
host.

If DHCP servers only use chaddr for unicast 
responses or as a client identifiers, then it sounds 
like 1394 nodes should never use chaddr. And, 
client id should be the only client identifier. Well,
I've convinced myself at least. ;-)

-myron

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Jul 1999 13:40:34 -0400 (EDT)

> may be unicasting back to the wrong host.

So how does TCP/IP over firewire deal with this problem?

			       _MelloN_

---

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 26 Jul 1999 13:40:56 -0400 (EDT)

> So how does TCP/IP over firewire deal with this problem?

Flush ARP cache after bus reset. Flush queued send/rcv
packets after bus rest. 

Bus resets are not so common that a large part of the 
bandwidth is consumed with ARP, but they are common 
enough (specially during initialization; as when DHCP 
will most likely be used) that node IDs should not 
be used as persistent values.

-myron

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Jul 1999 15:42:36 -0400 (EDT)

> be used as persistent values.

Hm.   I guess.   The thing is that DHCP already has a process for
dealing with lossage of this sort - we retry.   So if a bus reset
occurred after a DHCPDISCOVER or DHCPREQUEST was sent but before the
response came back, the retry would take care of it.   Whether this is
better than just broadcasting, I don't know - I don't see a clear
advantage to either method, really.

			       _MelloN_

---

From: [email-masked]
Date: Mon, 26 Jul 1999 21:19:33 -0400 (EDT)

>advantage to either method, really.

There is another issue related 1394 nodeID.
As I wrote before, 

: 1394 bus bridge WILL do some node_ID (busID+phyID) mapping, it means
: that link address of node-A may be different for node-B and node-C.
: 
:         -+-------+-----Bridge------+--------
:          A       B                 C

To solve this problem, in the case of ARP over 1394, we have chosen
to use nodeID IN THE 1394 HEADER. There is no nodeID in the ARP payload.

But for DHCP, DHCP relay can not send link header information to the
DHCP server, and vice versa.

This is another reason to use broadcast reply for DHCP/1394.

Best Regards,

Kenji Fujisawa

---

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 27 Jul 1999 11:27:27 -0400 (EDT)

> This is another reason to use broadcast reply for DHCP/1394.

Based on what I've heard so far, I agree with Kenji - use DHCP broadcast.

There are too many corner cases with unicasting via 1394 node id.

-myron

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Jul 1999 13:14:20 -0400 (EDT)

> There are too many corner cases with unicasting via 1394 node id.

Okay, you all have talked me into it... :')

			       _MelloN_