Comments in line... On Fri, 2005-04-22 at 16:30 +0300, Pekka Savola wrote: > 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.
I think it's perfectly reasonable to assume that a configuration mismatch is admin error and leave it at that - in this case, the RAs are configured incorrectly, promising that a non-existent address assignment service is available. > > 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). As was pointed out in a followup, I don't think there is anything in RFC 3315 that precludes a client from initiating an Information- request/Reply message exchange in parallel with or subsequent to a Solicit/Advertise/Request/Reply message exchange. > > 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 [email protected] Adminiistrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
