>>>>> 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
--------------------------------------------------------------------
