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

From: Ralph Droms <[email-masked]>
Date: Tue, 26 Apr 2005 13:58:32 -0400

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-masked] Adminiistrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Apr 2005 21:17:33 +0300 (EEST)

> configured incorrectly, promising that a non-existent address assignment

That would be consistent if the presence of M-flag would only trigger 
DHCPv6 for address assignment, but DHCPv6 would not be used to 
configure anything else at all unless O-flag was also appropriately 
set.

Then the DHCPv6 and DHCPv6-lite would function in a similar fashion 
from the network administrator's perspective.

So, IMHO, either we must require O flag always for Information 
Configuration (whether DHCPv6 full or lite) or support the 
administrators who can't make out the subtle difference about the 
appropriate configuration of the flags.  For that, guidance for full 
DHCPv6 implementers to also try emulating DHCPv6 lite would probably 
be sufficient.