Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt

From: Ralph Droms <[email-masked]>
Date: Fri, 11 Apr 2003 11:31:33 -0400

This message announces a WG last call on "A Guide to Implementing
Stateless DHCPv6 Service" <draft-ietf-dhc-dhcpv6-stateless-00.txt>.
The last call will conclude on Friday, April 25.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  One review of this document
has been published,
http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01990.html,
and will be considered as part of the WG response to this last call.

draft-ietf-dhc-dhcpv6-stateless-00.txt is a guide to the protocol
messages and options that must be implemented to provide stateless
DHCPv6 service.  Stateless DHCPv6 service is used by nodes that have
obtained IPv6 addresses through some other mechanism to obtain
configuration information such as the addresses of DNS recursive name
servers that does not require the maintenance of any dynamic state for
individual clients.  This document is being considered for Proposed
Standard, and is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-00.txt

- Ralph Droms

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 15 Apr 2003 00:10:46 +0900

>>>>> On Fri, 11 Apr 2003 11:31:33 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> and will be considered as part of the WG response to this last call.

I basically support the document, but I have several general
comments.  They are not directly related to the content of the draft,
but may require a revise of it.

1. address selection of Information-request/Reply exchanges

According to the DHCPv6 base spec, the client should send Information
Request messages to the All_DHCP_Relay_Agents_and_Servers multicast
address (FF02::1:2).  However, doesn't it make much sense to allow the
client to send the requests to the All_DHCP_Servers multicast address
FF05::1:3?  Since the stateless usage assumes the client has obtained
its IPv6 addresses through some other mechanism, I don't see a reason
that the client cannot do so.  If we allow this, the client can access
an off-link server without relying on a relay agent, which would help
the deployment.

2. how to invalidate stale configuration parameters

The stateless usage does not have the notion of Renew or Rebind.  So,
how the client can purge configuration parameters (e.g. DNS addresses)
when they become invalidated?  I guess we need a some kind of
"timeout" parameter, which suggests to the client that it refresh the
parameters in a certain period.

3. how to restart the stateless procedure

It would be useful if we had a guideline where the client should
restart the Information-request/Reply exchanges, particularly when the
client is a nomadic host moving link to link.  Section 18.1.2 of the
base specification can be a good example of this.

4. interaction/consistency with RFC 246[12]

How the stateless usage is related to the "Other stateful
configuration" of router advertisements defined in RFC 2461 and 2462?
Is the client (host) expected to start the stateless DHCPv6 when it
receives a router advertisement with the "Other stateful
configuration" flag being set?  If so, how can we interpret the
"inconsistency" between the "stateless" DHCPv6 usage and the
"stateful" router advertisement flag?  Perhaps this is just a matter
of wording.  But, if RFC 2461 really intended a "stateful" protocol
(i.e., where a server maintains lease state for the other
configuration parameters), we may need to consider the gap as a
fundamental architecture issue.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Tue, 15 Apr 2003 14:52:38 +0900 (JST)

> parameters in a certain period.

or the server "advertises" when the parameters change?

--
SHIRASAKI Yasuhiro @ NTT Communications
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg