Subject: 1394 DHCP conclusion

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 2 Aug 1999 14:22:09 -0400 (EDT)

I think the conclusions are:
1) Don't use chaddr with 1394, if it is used the chaddr 
   len is equal to zero and chaddr value is null.
2) Use EUI-64 for client id.
3) Use IP broadcast for request and response.

Is anything missing?

-myron

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 2 Aug 1999 15:51:21 -0400 (EDT)

Myron--

I slightly disagree:  hlen MUST be zero AND htype MUST be set to the proper
value for IEEE-1394.

--Barr

> ----------
> From: 	Hattig, Myron[SMTP:[email-masked]]
> Sent: 	Monday, August 02, 1999 11:25 AM
> To: 	Multiple recipients of list
> Subject: 	1394 DHCP conclusion
> 
>

---

From: C J Considine <[email-masked]>
Date: Mon, 2 Aug 1999 17:01:48 -0400 (EDT)

EUI-64'ing both fields is the same as either alone.  Chaddr
alone leaves the option of DNS names in client identifier.
That logical addressing is why there are two fields.
You probably must EUI-64 one of them so as to pick your
response out of the DHCPOFFER's if the whole subnet reboots.

client_id alone would reject much of our experience and break
older software, you might want both fields to be useful and 
plausible.  The volatile id is irrelevant.  Many DHCP requests
will span bus resets, and most leases will as well.

chaddr alone would be more robust and not break older servers.
It would also much simplify debugging as every packet would
have a factory unique identifier, even when customers 
override client_id.  Why else would there be two fields?

---

From: [email-masked]
Date: Mon, 2 Aug 1999 21:36:49 -0400 (EDT)

>3) Use IP broadcast for request and response.

Since the expiration date of the previous draft was July 1999,
I submitted new draft, draft-ietf-ip1394-dhcp-02.txt, yesterday
adding two notes.

:         Note: In general, the use of a broadcast reply is discouraged,
:         but we consider the impact in a 1394 network is not an issue.

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

I'll gladly update the draft if necessary.

Best Regards,

Kenji Fujisawa

---

From: [email-masked]
Date: Mon, 2 Aug 1999 22:46:21 -0400 (EDT)

>I slightly disagree:  hlen MUST be zero AND htype MUST be set to the proper

Just a confirmation.
The draft says,
:   'htype' (hardware address type) MUST be 24 [ARPPARAM].
:   'hlen' (hardware address length) MUST be 0.

Do you disagree with this text?
Or, do you think it's okay?

Kenji Fujisawa

---

From: [email-masked]
Date: Tue, 3 Aug 1999 08:49:13 -0400 (EDT)

Unsubscribe me please.

William F. Buckalew, RCDD/LAN
General Manager
Summit Network Services
707 East Gay Street
West Chester, PA 19380
1-610-692-5042
1-888-332-3325 (toll-free)
1-610-429-9001 (fax)
www.summit-inc.com
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Aug 1999 09:52:09 -0400 (EDT)

Try sending mail to [email-masked] with the word "HELP" in the
body of the message.   Unfortunately, I _can't_ unsubscribe you, and
chances are that nobody else who read your message can either.   :'(

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Tue, 3 Aug 1999 10:32:25 -0400 (EDT)

>chances are that nobody else who read your message can either.   :'(

I've received several direct requests to be unsubscribed from the list
recently.  I have to enter those requests manually and it may be several
days before I get a chance to make those changes.  I'll follow up Ted's
suggestion and strongly recommend that anyone who wants to leave the
dhcp-v4 or dhcp-v6 lists first send mail to [email-masked] with the
message:

unsubscribe dhcp-v4

(and/or, as appropriate)

unsubscribe dhcp-v6

- Yr. obdt. (but very harried) mailing list manager
  Ralph

---

From: [email-masked]
Date: Tue, 3 Aug 1999 21:45:25 -0400 (EDT)

>response out of the DHCPOFFER's if the whole subnet reboots.

I couldn't understand your point, sorry.
My understanding is,
	client-ID	identification of the client
	chaddr		link address of the client

In the case of 1394, we don't have a consistent link address
within entire subnet, this is the reason for NULL chaddr.
EUI-64 is not a link address.

And, the use of EUI-64 is not mandatory. For example, the combination
of (client-ID = FQDN, chaddr = NULL) may be used for 1394 DHCP client
if desired.

Best Regards,

Kenji Fujisawa