[rfc2462bis issue 277] M/O flags and DHCPv6
JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Fri, 27 February 2004 12:37 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28221 for <ipv6-archive@odin.ietf.org>; Fri, 27 Feb 2004 07:37:54 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwhF4-00072e-P0 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 07:37:25 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RCbMVc027048 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 07:37:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwhF4-00071v-2S for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 07:37:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28209 for <ipv6-web-archive@ietf.org>; Fri, 27 Feb 2004 07:37:20 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwhF3-0006Nc-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 07:37:21 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwhEG-0006IQ-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 07:36:33 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwhDW-0006Cg-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 07:35:46 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwhBp-0006U4-Vi; Fri, 27 Feb 2004 07:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwhB9-0006T7-49 for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 07:33:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28067 for <ipv6@ietf.org>; Fri, 27 Feb 2004 07:33:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwhB8-00060J-00 for ipv6@ietf.org; Fri, 27 Feb 2004 07:33:18 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwhAB-0005vc-00 for ipv6@ietf.org; Fri, 27 Feb 2004 07:32:21 -0500
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Awh9m-0005qr-00 for ipv6@ietf.org; Fri, 27 Feb 2004 07:31:54 -0500
Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3284E15214 for <ipv6@ietf.org>; Fri, 27 Feb 2004 21:31:47 +0900 (JST)
Date: Fri, 27 Feb 2004 21:31:57 +0900
Message-ID: <y7vwu68itz6.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: ipv6@ietf.org
Subject: [rfc2462bis issue 277] M/O flags and DHCPv6
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset="US-ASCII"
Sender: ipv6-admin@ietf.org
Errors-To: ipv6-admin@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Id: IP Version 6 Working Group (ipv6) <ipv6.ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
(note: this is a long message.) One major open issue of rfc2462bis is semantics of the M/O bit, what "stateful configuration" means, etc. Ralph Droms raised a set of questions in March 2003: a. the text needs to be updated to use RFC 2119 keywords b. which keywords? c. what is "the stateful configuration protocol"? d. if the answer to "c" is DHCPv6, should RFC 2462 more explicitly reference the configuration-only version of DHCPv6 in the description of the 'O'flag? I've been thinking about these questions, and I now have my personal answers. Since this message is lengthy, I'll first summarize the major (proposed) changes as follows: - clarify that the stateful protocol *is* DHCPv6. For example, say in Section 1 that: In this document, Stateful autoconfiguration for IPv6 means DHCPv6 [7]. - change the first part of Section 5.5.2 to: If a link has no routers, a host MAY attempt to use stateful autoconfiguration to obtain addresses and other configuration information. An implementation MAY provide a way to enable the invocation of stateful autoconfiguration in this case, but the default SHOULD be disabled. (i.e. change MUST in the first sentence to MAY, and modify the second sentence accordingly) - use "SHOULD" instead of "should" in some related sentences of Section 5.5.3. For example, we'll have the following sentence: If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host SHOULD invoke the stateful address autoconfiguration protocol, ... If you have time, and particularly if you have objections to some of the above changes, please look at the following discussions. *** regarding question c **** I'd first like to answer this question. RFC2462 currently says: Stateful autoconfiguration for IPv6 is the subject of future work [DHCPv6]. (Section 1) And, considering the latest standardization status, the current revision of rfc2462bis says: Stateful autoconfiguration for IPv6 is the subject of DHCPv6 [7]. However, I still don't think this is crystal clear. I believe we should first clarify whether "stateful autoconfiguration" *equals to* DHCPv6 (as specified in RFC3315), or whether we should still leave the possibility of (future) other stateful protocols. And then we should clarify this point in rfc2462bis more explicitly. Personally, I would prefer the first option (i.e., the "stateful protocol" equals to DHCPv6). Flexibility is in general a good thing, but in this case, I don't see a reasonable practical reason to leave other possibilities with ambiguous wording, particularly because the ambiguity has annoyed people and caused similar questions/discussions again and again. If we can agree on this, I'll change the above sentence like: In this document, Stateful autoconfiguration for IPv6 means DHCPv6 [7]. In the followings, I assume we adopt this interpretation (but it won't matter much even if we do not). *** regarding question a **** First, I think we can concentrate on Section 5 "PROTOCOL SPECIFICATION" (and its subsections). For example, someone pointed out that the following sentence in section 4 is "ambiguous": A "managed address configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain addresses. because it uses "should", not "SHOULD". But I don't think we should care about the wording in Section 4, since it's just an overview of the protocol, not the protocol specification itself. In fact, there are no RFC2119 keywords throughout Section 4. Of course, we may have to revisit the wording when we resolve question b ("which keyword?") though. Concentrating on Section 5, I've found the following candidates of RFC2119 keywords: ====================== start candidates ====================== 1. Section 5.2 ManagedFlag Copied from the M flag field (i.e., the ... The flag indicates whether or not addresses are to be configured using the stateful autoconfiguration mechanism. where "are to be" may need to be, e.g., "SHOULD be". 2. Section 5.2 OtherConfigFlag Copied from the O flag field (i.e., the "other ... The flag indicates whether or not information other than addresses is to be obtained using the stateful autoconfiguration mechanism. where "is to be" may need to be, e.g., "SHOULD be". 3. Section 5.5.3 ... If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address autoconfiguration protocol, ... where "the host should invoke" may need to be, e.g., "the host SHOULD invoke". 4. Section 5.5.3 ... If the value of the ManagedFlag changes from TRUE to FALSE, the host should continue running the stateful address autoconfiguration, ... where "the host should continue" may need to be, e.g., "the host SHOULD continue". 5. Section 5.5.3 ... If the value of OtherConfigFlag changes from FALSE to TRUE, the host should invoke the stateful autoconfiguration protocol, ... where "the host should invoke" may need to be, e.g., "the host SHOULD invoke". 6. Section 5.5.3 ... If the value of the OtherConfigFlag changes from TRUE to FALSE, the host should continue running the stateful address autoconfiguration protocol, ... where "the host should continue" may need to be, e.g., "the host SHOULD continue". ====================== end candidates ====================== In my current impression, we can leave 1 and 2 unchanged, but we'll need to use RFC2119 keywords for the rest. *** regarding question b **** In addition to the above candidates, the following parts already using RFC2119 keywords will need to be discussed here: 7. Section 5.5.2 If a link has no routers, a host MUST attempt to use stateful autoconfiguration to obtain addresses and other configuration information. 8. Section 5.5.2 An implementation MAY provide a way to disable the invocation of stateful autoconfiguration in this case, but the default SHOULD be enabled. 9. Section 5.5.3 In particular, a host MUST NOT reinvoke stateful address configuration if it is already participating in the stateful protocol as a result of an earlier advertisement. 10. Section 5.5.3 In particular, a host MUST NOT reinvoke stateful configuration if it is already participating in the stateful protocol as a result of an earlier advertisement. To choose appropriate keywords, I'd like to be synchronized with the node requirements draft (draft-ietf-ipv6-node-requirements-08.txt). It says in Section 4.5.5 that: Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- 3315] is the standard stateful address configuration protocol; see section 5.3 for DHCPv6 support. Nodes which do not support Stateful Address Autoconfiguration may be unable to obtain any IPv6 addresses aside from link-local addresses when it receives a router advertisement with the 'M' flag (Managed address configuration) set and which contains no prefixes advertised for Stateless Address Autoconfiguration (see section 4.5.2). ... That is (in my understanding), implementing DHCPv6 is basically optional with warnings about the case of not implementing it. I know this was a controversial issue, but I believe the node-requirements draft made a reasonable decision in terms of practical and realistic deployment path while honoring future flexibility. So, I'd like to propose changing candidate 7 to: If a link has no routers, a host MAY attempt to use stateful autoconfiguration to obtain addresses and other configuration information. Similarly, change candidate 8 to: An implementation MAY provide a way to enable the invocation of stateful autoconfiguration in this case, but the default SHOULD be disabled. Another reason for the change is because we can at least use link-local addresses within a single link without a router. For candidates 3 to 6, I think "SHOULD" is appropriate, since this only happens the network manager explicitly turns on the M or O flag and the effect of this setting is described in the node-requirements draft with warnings. I also think "MUST NOT"s in candidates 9 and 10 are okay for the same reason. *** regarding question d **** (I interpret "the configuration-only version of DHCPv6" as so called "stateless DHCPv6" described in draft-ietf-dhc-dhcpv6-stateless-04.txt.) This is not a strong opinion, but I'd currently say "no" for this question. The reasons are: - in my opinion, the stateless DHCPv6 service should be a "ubiquitous" service, and hosts that need autoconfiguration should try it by default (that is, without seeing an O flag set, which needs an explicit configuration in routers). - the O bit indicates a "stateful" mechanism for other configuration information than addresses. If the information actually includes some real "other" stateful resources (probably in a future extension), using the stateless version of DHCPv6 may result in an incomplete service. Even if we agree on my opinion, however, it might still be useful to note that the protocol invoked by the O bit should be the full-spec DHCPv6 instead of the stateless version. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- [rfc2462bis issue 277] M/O flags and DHCPv6 JINMEI Tatuya / 神明達哉
- RE: [rfc2462bis issue 277] M/O flags and DHCPv6 john.loughney
- [rfc2462bis] M/O flags and DHCPv6 JINMEI Tatuya / 神明達哉
- RE: [rfc2462bis] M/O flags and DHCPv6 Dave Thaler
- Re: [rfc2462bis] M/O flags and DHCPv6 Pekka Savola
- Re: [rfc2462bis] M/O flags and DHCPv6 JINMEI Tatuya / 神明達哉
- RE: [rfc2462bis] M/O flags and DHCPv6 Dave Thaler
- RE: [rfc2462bis] M/O flags and DHCPv6 john.loughney
- RE: [rfc2462bis] M/O flags and DHCPv6 john.loughney
- Re: [rfc2462bis] M/O flags and DHCPv6 JINMEI Tatuya / 神明達哉
- RE: [rfc2462bis] M/O flags and DHCPv6 john.loughney
- Re: [rfc2462bis] M/O flags and DHCPv6 JINMEI Tatuya / 神明達哉
- Re: [rfc2462bis] M/O flags and DHCPv6 Ralph Droms
- RE: [rfc2462bis] M/O flags and DHCPv6 john.loughney
- RE: [rfc2462bis] M/O flags and DHCPv6 Ralph Droms
- Re: [rfc2462bis issue 277] M/O flags and DHCPv6 Ralph Droms
- reference dependency (DS to PS) (Re: [rfc2462bis]… JINMEI Tatuya / 神明達哉
- Re: [rfc2462bis] M/O flags and DHCPv6 Ralph Droms
- Re: reference dependency (DS to PS) (Re: [rfc2462… Pekka Savola
- [rfc2462bis] Absence of Router Advertisements JINMEI Tatuya / 神明達哉