Subject: [dhcwg] Stateless DHCPv6 service

From: Ralph Droms <[email-masked]>
Date: Sun, 06 Apr 2003 09:06:41 -0400

Now that the DHCPv6 base specification is at PS, and the DNS and time configuration option specs have passed WG last call, I have published "A Guide to Implementing Stateless DHCPv6 Service" as a dhc WG document, draft-ietf-dhc-dhcpv6-stateless-00.txt.

This revision of the document has been reviewed by Pekka Savola and Christian Huitema, and includes changes based on their input.  Based on the interest in this specification, I would like to progress it quickly.  Unless there are objections, I will start a WG last call for the specification in a week or so.

- Ralph

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 8 Apr 2003 21:10:34 -0500

Ralph:

The document looks very good. Here are some corrections & nits for you:

In 1. Introduction, "through some other mechanism" ... other than what? [DHCP].

In 2. Terminology, add a "[1]" after "DHCP specification"?

In 5. Implementation of Stateless DHCP, 2nd paragraph, there is no such thing as
a "DUID Option". Replace with Client Identifier Option.

In 5.2 Options required for stateless DHCP service, add "Server Identifier" option
to the first list of options. The server always returns this in a Reply to identify
itself.

In 5.3 Options used for configuration information, add the references to the
documents. [3], [3], and [4] respectively.

In 5.4 Other options used in stateless DHCP, the Vendor-Specific Information can be
sent by clients to servers as well (it isn't just for server to client).

Also in this section, the Client DUID is Client Identifier. And, it is echoed back
by the server if the client supplied it (so the statement "servers never send this
option" is wrong - they send it if the client sent it).

And, perhaps a warning to implementators that other options may be sent by a server
which they may wish to ignore (such as Server Unicast and other configuration data
options).

In 7. Security Considerations, the 3rd paragraph is wrong. We don't allow a client
to send an Information-Request option with anything but its link-local address and
the destination is always a multicast.

This document is also silent with respect to Reconfigure. As no Reconfigure-Accept
is sent, Reconfigure will not be supported. However, clients MAY support this
feature if they wish. You probably chose to ignore this to keep it fairly simple.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Sunday, April 06, 2003 9:07 AM
To: [email-masked]
Subject: [dhcwg] Stateless DHCPv6 service

- Ralph

---

From: [email-masked]
Date: Mon, 14 Apr 2003 14:41:00 +0300

Hi, Ralph!

This document looks good, I personally support starting wglc for it.

By the way, are you going to mention other options than DNS and Time Configuration Options? I think this would also be useful:
http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-01.txt

Best Regards,
	          -Juha W.-

-----Original Message-----
From: ext Ralph Droms [mailto:[email-masked]]
Sent: 06 April, 2003 16:07
To: [email-masked]
Subject: [dhcwg] Stateless DHCPv6 service

- Ralph