JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]> writes:
> 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.
There is nothing wrong with the above case. But, I don't think we need
our specs need to say anything about them either. There are always
going to be lots of scenarios where a vendor may want to do things
differently than implement _only_ what the spec says _explicitely_.
Thus, I see no reason to go into a lot of detail in one our specs
supporting this particular scenario or "allowing" it to be "part of
the standard" so to speak.
That is, vendors always implement additional knobs/whistles as they
see fit. The IETF doesn't need to account for all of those.
What we our specs do need to support is not disallowing behavior that
it might make sense to allow for, and that doesn't negatively impact
interoperability and such.
The above should be perfectly consistent with our existing specs. Do
you (or others) feel otherwise? I.e., is the above not allowed by our
specs?
> 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.
I do not understand the concept of having a local policy that disables
invoking a service that one has not implemented. If you don't
implement it you don't implement it, and anywhere you might consider
invoking the service, well, you obviously just don't. That is not a
"local policy", that is just common sense. :-)
It has never been the case that if something is not in an IETF spec,
it is "disallowed" or "not compliant" with a spec. If we go down that
road, one ends up having to overspecify everything to make sure even
obvious things are allowed.
What our specs _do_ need to do is be very clear on what we expect all
implementations to do, in order to achieve interoberability (and to
prevent damaging behavior, as in, e.g., being congestion unfriendly).
> 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.
I agree that this should be allowed. Indeed, I'd expect that to be the default
behavior regardless of the M/O bits. It should be the default behavior
of anyone that implements DHC.
No where in our specs (AFAIK) is it claimed that you SHOULD/MUST NOT
invoke DHC if the M/O bits are clear. Right?
> 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).
Is there any wording in our specs that suggests a client is not
allowed to invoke DHC if either of the M or O bit is off? If not, why
do people feel that they are not allowed to invoke DHC?
> "_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)
The RA bits should have no bearing in answering that question. They
are advisory only.
I think folk have already made it clear that DHC on clients is not
"mandatory to implement as part of IPv6".
If that is the question you really have, this document is the wrong
way to ask/resolve it.
Another way of looking at things. Does the fact that someone can send
a node a TCP SYN packet require (in the MUST sense) that the client
respond to that SYN?
Likewise, if an RA says "DHC is available", that doesn't mandate that
it invoke DHC either. (but the node SHOULD do so...)
> 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)
That is why I suggested "SHOULD invoke DHC". Makes it clear you
should, but there are cases where you might not want to, so no, it is
not mandatory to _invoke_ (mandatory to implement is covered in the
previous question).
> 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)
should be, IMO. The bits do not mean "if 0, you MUST NOT use DHC ..."
> 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.)
On to off? nothing. Let DHC continue to be used. The DHC protocol will
do what it normally does if a DHC server goes away... I.e., if you've
gotten config information from DHC that still has a valide lifetime,
you wouldn't throw that information away...
> 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?
Should be legal, but this is an unfortunate situation, since we're not
trying getting into how to deal with misconfigurations...
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
