(Cleaning the Cc list a bit)
>>>>> On Wed, 18 May 2005 12:29:20 -0400,
>>>>> Thomas Narten <[EMAIL PROTECTED]> said:
> There are really only two behaviors a client should be doing. If a
> client doesn't implement DHC, well, then it obviously shouldn't/can't
> invoke DHC. End of story. If it does implement DHC, well, it should
> use it. Moreover, it shold never really be a "client" choice whether
> to invoke use DHC or not. If the sys admin has stuff available via
> DHC, the client should (in the SHOULD sense) be getting it and using
> it. Why on earth would we want to disable that via a configuration
> knob?
One possible case would be a server host which manually configures
itself with an IPv6 address, but seeks to get default router addresses
via an RA and possibly other configuration information such as
recursive DNS server addresses via DHCPv6 (Information-request/Reply).
Such a host would receive (and use) RAs but not invoke DHCPv6 for
address allocation even if the M flag is set in the RAs.
I personally also expect a host that does not implement address
allocation via DHCPv6 would have an implicit local policy that
"disables" the behavior (regardless of the value of the M flag). But
I admit the current mo-flags document does not clearly indicate that
even if my expectation is reasonable.
On the other hand, I'd also like to allow a client to use DHCPv6
(either full 3315 or the 3736 subset) even if the corresponding M or O
flag is not set. In particular, I'd reserve the possibility for a
host to try the RFC3736 behavior even if the O flag is off, so that
the host can get configuration information even when the RA flags and
available DHCPv6 are inconsistent (due to misconfiguration of routers,
etc).
> So, these bits should just provide clients with a stronger indication
> that they should be using DHC to get the information that is
> available.
In general, I agree (while I'd say "...that they can be using DHC
...").
> Is more than something like the above _really_ needed? If so, why?
"_really_" sounds subjective, and opinions may vary, but I personally
don't think "the above" is enough in practice. In my understanding,
many people have been confused about the relationship between the M/O
flags and the "stateful" configuration protocol (we now know the
protocol is DHCPv6). At least I, as an implementor, have been always
confused about these points. For example,
1. whether the specification about the M flag indicates address
allocation via DHCPv6 is a mandatory feature to be implemented in
hosts. (this point may now be clear by the "IPv6 Node
Requirements" document and recent clarification of 2462bis)
2. whether it's valid for a host to not invoke DHCPv6 (either full
RFC3315 or the RFC3736 subset) even if the corresponding M/O flag
is set. (see above)
3. whether it's valid for a host to do invoke DHCPv6 (either full
RFC3315 or the RFC3736 subset) even if the corresponding M/O flag
is not set. (see also above)
4. what should the host do if the M or O flag is reset from ON to OFF.
(while I pernsoally believe RFC2462 is pretty clear on this, many
people, including a DHCPv6 specialist, have still misunderstood
that.)
5. what if the M flag is set but the host does not get any DHCPv6
Advertise in the initial exchange? Is it okay to fall back to the
RFC3736 subset? Or is it even okay to run both full RFC3315 and
the RFC3736 subset concurrently from the beginning?
If all we have is "the above" you suggested or the current 2461bis
wording, I'd still continue getting confused. So I personally want to
clarify these points somewhere, either in an existing document or a
separate document like the ra-mo-flags draft. As for the latter, I
don't stick to the current content. Perhaps sections 6 and 7 are
overspecification, and I'll be happy as long as we can clarify the
points that have confused many people so far.
According to the others' opinions, however, all or some of the above
points seem to be so trivial to some people that they don't bother to
"clarify" those. If I've been simply dull and things are so clear for
others, I don't mind killing the new clarification document (it would
reduce my responsibility:-).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
