Hi Jinmei,
JINMEI Tatuya / ???? wrote:
On Thu, 12 Aug 2004 15:23:23 +1000, Greg Daley <[EMAIL PROTECTED]> said:
It's important to relize though that a host doesn't invoke RFC 3736 procedures though. The host only cares that it wants to do an Information-Request. 3736 is an implementation hint for DHCPv6 servers and relays, not hosts.
(snip)
Sorry, it doesn't clearly answer my question. So can I rephrase your statement to "3736 is an implementation hint for DHCPv6 servers and relays, not clients."?
Oh, sorry for the confusion.
Yes I believe so.
Okay, thanks.
Then my next quick question for clarification is: what led you to that impression? In my understanding, RFC3736 is a hint for both clients and servers on the "stateless" subset service of DHCPv6. (Also for relays, but this case is relatively minor since relays are originally independent from the notion of "stateful" or "stateless").
In fact, all subsections of RFC3736 Section 5 begin with a phrase like: "Clients and servers implement the following messages for stateless DHCP service".
Additionally, a previous discussion in rfc2462bis seems to support my understanding (i.e., RFC3736 provides a hint for clients as well as for servers): http://www1.ietf.org/mail-archive/web/ipv6/current/msg02494.html http://www1.ietf.org/mail-archive/web/ipv6/current/msg02495.html
Note that Ralph (the main editor of RFC3315 and the author of RFC3736) agreed on my understanding.
I understand what you (and Ralph) are saying
The protocol features embodied by the 'stateless' RFC are what is required for this case.
We have a requriement to only send Information-Requests though if M=0,O=1 independent of which class of host (client) is configuring (full RFC 3315 capable or RFC3736 only capable).
Calling the procedures 'stateless' or 'stateful' is correct, but the description in 3736 is of implemented subsets of DHCPv6.
Therefore, the operation of M=0,O=1, should be described in terms of operations to be undertaken by the host, not
It's obvious that RFC3736 provides a good summary of the minimal implementation of these capabilities, but it's an implementation guideline, not a protocol:
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg02856.html
If we're coming to the point where RFC3736 is being described as a protocol, perhaps we're at a point where use of the terms 'stateless' and 'stateful' in this case will lead to confusion amongst people who haven't been following standardization as closely.
JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED]
p.s. this may not be the substantial point of you in this thread. But you seem to emphasize this point, so I think it might worth clarifying (whether my understanding is correct or not).
Indeed, I see your point.
The main issue with stateless RFC 3736 is that there is no state kept on the server (thus the name).
The host portion is covered, but the inability of the server to provide Renew/Request/Rebind dictates the capabilities of the clients, not the other way around.
Greg.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
