[dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt
JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Sat, 14 May 2005 08:34 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWs6l-0005bF-W9; Sat, 14 May 2005 04:34:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWs6k-0005b3-31; Sat, 14 May 2005 04:34:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14145; Sat, 14 May 2005 04:34:47 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWsMp-0004tJ-SS; Sat, 14 May 2005 04:51:28 -0400
Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 209B715210; Sat, 14 May 2005 17:36:43 +0900 (JST)
Date: Sat, 14 May 2005 17:35:37 +0900
Message-ID: <y7v64xmp5ly.wl%jinmei@isl.rdc.toshiba.co.jp>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: Pekka Savola <pekkas@netcore.fi>
In-Reply-To: <Pine.LNX.4.61.0504262111110.28111@netcore.fi>
References: <caab0e1b8f9a111b72c4a53df125c31a@innovationslab.net> <y7vhdhzjb8p.wl@ocean.jinmei.org> <Pine.LNX.4.61.0504221622100.14579@netcore.fi> <1114538312.6886.17.camel@localhost.localdomain> <Pine.LNX.4.61.0504262111110.28111@netcore.fi>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: dhcwg@ietf.org, IPv6 WG <ipv6@ietf.org>, Ralph Droms <rdroms@cisco.com>
Subject: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
>>>>> On Tue, 26 Apr 2005 21:17:33 +0300 (EEST), >>>>> Pekka Savola <pekkas@netcore.fi> said: >>>> 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. > 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. I've been thinking about this issue for a while, and I now feel it may require a more profound discussion than I originally thought... Here are some background points: - In original RFC2462, if ManagedFlag (host's variable corresponding to the M flag of RA) is TRUE, it implicitly means OtherConfigFlag is also TRUE (Section 5.2). It would mean if we receive an RA with M=on (whether O=on or off), the receiving host would start the "stateful" protocol (which we now know is DHCPv6) for address configuration *and* the "stateful" protocol for configuration information excluding addresses (Section 5.5.3). - In the past discussion about the M/O flag document, we clarified that the notion of "M" and "O" is quite independent. That is, "M" means the "Host Configuration Behavior", which, more specifically, means DHCPv6 Solicit/Advertise/Request/Reply/... exchanges; "O" means the "Information Configuration Behavior", which means DHCPv6 an Information-request/Reply exchange. Unlike RFC2462, there is no implicit dependency between "O-Flag" (renamed from OtherConfigFlag to avoid confusion) and the M flag in this document. So, for example, the host does not invoke the "Information Configuration Behavior" just because the M flag in an RA is ON. I guess the slightly different sense led us to the current confusion (or problem). If we respect both the original sense of RFC2462 and our consensus about the semantics separation of the M/O flags, I believe the right solution is the following: - allow (or even require) running the Host Configuration Behavior and the Information Configuration Behavior concurrently. (note: this is a significant change from the current M/O document) - note that the same type of configuration information (e.g., recursive DNS server addresses) can be obtained with those two behaviors, and that how to deal with possible inconsistency is beyond the scope of the M/O document. - also note that the network administrator should by default provide the Information Configuration Behavior when they provide the Host Configuration Behavior, in which case both the M and O flags should be set to ON in router advertisements. With the last notice, I'm fine with the position of saying "it's administrator's responsibility to ensure service consistency". JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] [Fwd: IPv6 WG Last Call:draft-ietf-ipv6-r… Ralph Droms
- [dhcwg] [Fwd: Re: IPv6 WG Last Call:draft-ietf-ip… Ralph Droms
- [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-… Ralph Droms
- [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-… Pekka Savola
- [dhcwg] [Resolving Issues]IPv6 WG Last Call:draft… Soohong Daniel Park@SAMSUNG.COM
- [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-… JINMEI Tatuya / 神明達哉
- RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Bernie Volz (volz)
- RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Bernie Volz (volz)
- Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Stig Venaas
- RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Bernie Volz (volz)
- RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Pekka Savola
- RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Bernie Volz (volz)
- RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Bernie Volz (volz)
- RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Bernie Volz (volz)
- Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… JINMEI Tatuya / 神明達哉
- Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Thomas Narten
- Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Bob Hinden
- Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… JINMEI Tatuya / 神明達哉
- Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Syam Madanapalli
- Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Ralph Droms
- Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Ralph Droms
- Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Thomas Narten
- RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Bernie Volz (volz)
- Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… JINMEI Tatuya / 神明達哉
- RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… timothy enos
- RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… timothy enos
- [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-… Bob Hinden
- [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-… Pekka Savola
- [dhcwg] RE: IPv6 WG Last Call:draft-ietf-ipv6-ra-… john.loughney
- [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-… Bob Hinden
- [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-… Tim Hartrick
- Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6… Ralph Droms
- [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-… Ralph Droms
- [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-… Ralph Droms
- [dhcwg] RE: IPv6 WG Last Call:draft-ietf-ipv6-ra-… Soliman, Hesham
- [dhcwg] RE: IPv6 WG Last Call:draft-ietf-ipv6-ra-… Bound, Jim
- [dhcwg] RE: IPv6 WG Last Call:draft-ietf-ipv6-ra-… Bound, Jim
- [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-… JINMEI Tatuya / 神明達哉
- [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-… Tim Hartrick
- Re: [dhcwg] dhc wg last call on "DHCP Relay Agent… Thomas Narten