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

From: Brian Haberman <[email-masked]>
Date: Wed, 13 Apr 2005 10:09:12 -0400

This starts a 2 week IPv6 WG Last Call for advancing:

	Title		: Considerations on M and O Flags of IPv6 Router Advertisement
	Author(s)	: S. Park, et al.
	Filename	: draft-ietf-ipv6-ra-mo-flags-01.txt
	Pages	: 13
	Date		: 2005-3-30
	
as a Proposed Standard.  Substantive comments should be directed
to the mailing list.  Editorial comments can be sent to the document
editor.  This Last Call will end on April 27, 2005.

Regards,
Bob & Brian
IPv6 WG co-chairs

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 22 Apr 2005 20:34:46 +0900

>>>>> On Wed, 13 Apr 2005 10:09:12 -0400, 
>>>>> Brian Haberman <[email-masked]> said:

> editor.  This Last Call will end on April 27, 2005.

Although I'm listed in this document as a co-author, this time I'm
commenting as an ordinary reader (I could not find time to make
comments on this version at the intra-author review period.  It was
just my bad).

I don't think this document is ready for publication (or being
submitted to the IESG) yet.

COMMENT 1: (the biggest concern)

I believe we should address the first comment on a prior version of
this document from Pekka:
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg03808.html

That is, with the current specification (of the mo-flags document or
of ND/autoconf/DHCPv6), we'll see troubles like this:

  Consider the following settings:
  a) the M flag is on in RAs
  b) all available DHCPv6 servers support the RFC3736 subset
  c) host's M-Policy is set to 2 (invoke DHCPv6 when M-Flag changes
     from False to True)

  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.

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.

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.

I showed some concrete ideas of 2 and 3 before:
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg03862.html

But at that time we did not have detailed discussions much.

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.

COMMENT 2:

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

COMMENT 3: (miscellaneous minor issues, mostly editorial)

  - In the last sentence of Section 12
       s/is different form/is different from/
  - SEND is now published as an RFC (RFC3971)
  - if we need an update version of this document (I believe we do),
    we'll need to use the new IPR boilerplate (e.g., with version 1.29
    of xml2rfc)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Apr 2005 16:30:02 +0300 (EEST)

On Fri, 22 Apr 2005, JINMEI Tatuya / [ISO-2022-JP] ¿ÀÌÀÃ£ºÈ wrote:
[...]
>  configuration information such as recursive DNS server addresses.

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

>   but I personally think it's irresponsible.

I agree as well.  This is not good enough.

>   RFC3736) to help mitigate or avoid the problematic scenario.
[...]
> course).  But if it's too tough, resolution 2 can be a workaround with

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

> 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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 26 Apr 2005 17:18:24 +0900

>>>>> On Fri, 22 Apr 2005 16:30:02 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

> 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

---

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

Comments in line...

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

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

> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email-masked] Adminiistrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------

---

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.