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

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

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

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

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.
					[e-mail]
_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg