Hi Jinmei,
JINMEI Tatuya / ???? wrote:
On Fri, 13 Aug 2004 11:15:48 +0200, Stig Venaas <[EMAIL PROTECTED]> said:
Why? In this (i.e., the latter) scenario, does M=1/O=0 simply mean that (Solicit/Advertise/Request/Reply and)Rebind/Renew/Request is available but Information Request is not? Perhaps this is inconvenient, but I don't see why this combination is invalid.
I tried to say something about that in my previous mail. I think it should be invalid.
A DHCPv6 server should either be a server according to RFC 3315 in which case it must support all these messages, or it must support the subset listed in RFC 3736 (Information-Request/Reply). Is someone seriously suggesting the possibility of servers supporting only Solicit/Advertise/Request/Reply? I think that would be a bad idea. If server supports all of RFC 3315, it doesn't make sense to make clients only use part of the available functionality.
So, by saying "M=1 and O=0 is not a valid advertisement state" you would mean "*I think* it would be a bad idea".
Perhaps it does, but I'm amenable to new ideas.
Then I understand what you mean, but I'd not use the word "invalid" in such a case. I would use the word when, e.g., the combination causes a logical contradiction (like M=1 means the node MUST do X while O=0 means the nod MUST NOT do X), especially when I say that as if it were a fact like "It is invalid"...
Anyways. I can think of a "valid" case where an administrator wants to enables only Solicit/Advertise/Request/Reply exchanges. For example, the administrator may want to deploy strictly managed network where no host is allowed to perform any meaningful network operation unless it is assigned an IPv6 global address from a managed DHCPv6 server. In such a case, there is no reason for the network administrator to enable Information-request/Reply exchanges, and it would be convenient to tell the hosts (clients) about the policy, perhaps implicitly, by setting the O flag to zero.
I just showed a possible scenario though; this is not necessarily my preferred scenario. I'm sure I need to think more about implication of the M/O semantics.
Indeed, this may be an OK aim, although existing RFC 3315 DHCP hosts which don't make use of the M/O flags (as perhaps they should) will not be able to distinguish what's going on. They won't know they have to choose Renew/Request/Rebind instead of Information-Request. These hosts will fail in their information request on the network.
This may be your point though, and could be controlled by enforcing compilance with this document on a particular access link (although that may be something worth standardizing, rather than documenting in an Informational RFC).
Mind you, this is the same case if there are stateful (Request/Renew/Rebind) clients attempting to do DHCP when only a stateless 3736 server exists, if M=0,O=1.
If we decide that for X=0,Y=1 cases, we're not supporting devices which aren't aware of the flags' meaning, then that's probably OK.
I'd like to be sure that's what we're doing though, by explicitly stating that in the draft (or at least documenting behaviours in such a case).
If we're not supporting that restriction, then M=1,O=0 doesn't make sense.
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
