Forwarded to include dhc WG in conversation about M/O flags. - Ralph
-------- Forwarded Message -------- > From: JINMEI Tatuya / çæéå <[EMAIL PROTECTED]> > To: Pekka Savola <[EMAIL PROTECTED]> > Cc: IPv6 WG <ipv6@ietf.org> > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt > Date: Tue, 26 Apr 2005 17:18:24 +0900 > >>>>> On Fri, 22 Apr 2005 16:30:02 +0300 (EEST), > >>>>> Pekka Savola <[EMAIL PROTECTED]> said: > > >> 2. allow a host to fall-back to Information Configuration Behaviour in > >> such a case. This is not 100% compliant with the DHCPv6 > >> specification, though. > >> > >> 3. make small updates on the DHCPv6 specifications (RFC3315 and > >> RFC3736) to help mitigate or avoid the problematic scenario. > > [...] > >> Ideally, I think resolution 3 is the way to go and should be included > >> in this document (we'll then need to DHCPv6 updates at the dhc wg, of > >> course). But if it's too tough, resolution 2 can be a workaround with > >> careful wording. > > > I think the DHC WG should be part of the resolution of this issue > > whether it's 2 or 3. In particular, we should get their permission to > > say that implementations can do 2) if they want to, and can then maybe > > just refer to DHC WG (or some initial document) for 3). > > I agree in that we should make consensus on this with dhc folks. > (Should we continue this discussion copying the dhc list?) > > Meanwhile, after re-reading the DHCPv6 specification, I thought I had > not 100% correct about compliance with the DHCPv6 spec. As far as I > understand it, RFC3315 does not prohibit the client from performing > Information-request/Reply exchanges in parallel with > Solicit/Advertise/Request/Reply/... exchanges. So, for example, the > following behavior should be valid in terms of RFC3315: > > - the client starts Host Configuration Behaviour > (Solicit/Advertise/... exchanges) > - unfortunately, it does not get any responses for a while > - the client then starts Information Configuration Behaviour *in > parallel with* Host Configuration Behaviour > - if there is a DHCPv6 server that only implements/enables the > RFC3736 subset (i.e., Information Configuration Behaviour), the > client will at least get other configuration information > > However, this approach will cause additional issues: > > + this approach may break the sense of RFC2462 (not bis), since it > does not seem to expect Host/Information Configuration Behaviour > can take place simultaneously. For example, it says in Section > 5.5.3: > > If the value of OtherConfigFlag changes from FALSE to TRUE, the > host should invoke the stateful autoconfiguration protocol, > requesting information (excluding addresses if ManagedFlag is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > set to FALSE). > ^^^^^^^^^^^^ > I personally think we can accept the change in the sense as a part > of clarification with the reality of concrete protocol > specifications. > > + if, for example, full-service DHCPv6 servers are just temporarily > down when the client starts Host Configuration Behaviour, the > client will eventually get configuration information from both > Host Configuration Behaviour and Information Configuration > Behaviour and will face the issue about how to integrate or > prioritize the two sets of information (there may even be > inconsistency between those). > > I personally think this is not a big issue in this context, > though: this is actually a general issue of what the client should > do when it has multiple configuration sources (e.g., when a client > tries to run DHCP on multiple interfaces or over different > protocols (IPv4 and IPv6)). So, I think it is acceptable for the > mo-flags document just to mention this issue as one form of the > general issue and should be handled in the context of DHCP > standardization (likely at the dhc wg). > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
