Subject: [dhcwg] [Fwd: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt]

From: Ralph Droms <[email-masked]>
Date: Tue, 26 Apr 2005 11:16:40 -0400

Forwarded to include dhc WG in conversation about M/O flags.

- Ralph

-------- Forwarded Message --------
> From: JINMEI Tatuya / 神明達哉 <[email-masked]>
> To: Pekka Savola <[email-masked]>
> Cc: IPv6 WG <[email-masked]>
> 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-masked]> 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-masked]
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg