>>>>> 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".
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.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
