Comments in line...
- Ralph
On Fri, 2005-05-20 at 16:19 +0900, JINMEI Tatuya / çæéå wrote:
> (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.
There's no particular reason why a host with an otherwise configured
address might not also use DHCP for other assigned addresses. But, I
agree with you that use of DHCP in a host is a matter of local policy,
perhaps guided by the M/O bits.
> 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.
This local policy seems to be a crucial issue. Do we try to describe
host behavior explicitly or do we specify the network behavior (M/O
bits; retransmit behavior for ND and DHCP; HCB/ICB (Host Configuration
Behavior [RFC 3315]/Information Configuration Behavior [RFC 3736]
information returned from DHCP server) and leave the host to implement
its own policy and behavior?
> 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).
I don't see a reason to prohibit explicitly use of DHCP is M/O bits are
not set. Other standards bodies or host implementors may choose to make
such prohibitions if appropriate; e.g., in a network environment with
limited bandwidth where any spurious traffic is avoided.
> > 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)
I agree that the requirement for DHCP has never been entirely clear nor
well-documented.
> 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)
If there is confusion about these points, then we need clarification,
once we agree on the desired behavior and definition.
> 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.)
RFC 2462 is pretty clear; however, I must admit I have been confused by
the lengthy discussion clarifying the meaning of the bits and I seem to
remember that there was a proposal to change the meaning of the bits at
some point in the discussion.
> 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?
There is another possibility - a DHCP server that will not assign
addresses can respond to a Solicit message with an appropriate status
code. Thus, a host that tries to use HCB first can get an immediate
indication that HCB is not available and revert to ICB immediately.
Deployment of such behavior may require some clarification in the DHCP
RFCs, because the existence of two separate RFCs has led to confusion
about the "separation" of two "different" protocols for HCB and ICB.
There is no *prohibition* against a DHCP server that intends to
participate only in ICB from responding to a Solicit message with the
"will not assign addresses" ("NoAddrsAvail")._DOa.
Additionally, a small, backward-compatible extension to RFC 3315 would
simplify the situation even further. At present, RFC 3315 specifies
that a server return the NoAddrsAvail status code and no other
information. If the server were allowed to return NoAddrsAvail *and*
ICB options, the host could use the ICB options with a simple 2-message
exchange. This extension would also require a clarification to RFC 3736
explicitly allowing this behavior (Note that RFC 3736 is intended as
*minimum* function and does not *prohibit* implementation of other DHCP
features).
> 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]
In my opinion, we need a simple clarification of M/O bits as "advisory"
and that there is no explicit *restriction* on hosts' use of DHCP. We
might also consider a couple of clarifications and minor extensions to
the DHCP spec to optimize host-server interaction.
- Ralph
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
