On Fri, 22 Apr 2005, JINMEI Tatuya / [ISO-2022-JP] ¿ÀÌÀãºÈ wrote:
[...]
 then the host will try the "Host Configuration Behaviour"
 (Solicit/Advertise/Request/Reply exchanges), but the server does not
 respond to the Solicits.  According to the DHCPv6 specification, the
 host will send Solicits eternally, and won't even get other
 configuration information such as recursive DNS server addresses.

Thanks for bringing up this issue. I agree we must figure out how to fix this.


I can think of several possible resolutions:

1. just say that it's host/network administrator's responsibility to
  provide consistent parameters/configurations.  In this sense, the
  combination of a) and b) above is just a configuration error.
  This would be the most lightweight resolution for the authors:-),
  but I personally think it's irresponsible.

I agree as well. This is not good enough.

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


In any case, the solution or workaround should be so that it does not depend on updating the DHCPv6 server (so that just updating the client, e.g., to fall back is sufficient).

COMMENT 2:

I believe we should also make consensus on the open issue described in
Section 11 (default policy values) before publication.

Agreed.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to