From exim@www1.ietf.org Sat May 1 13:37:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04748 for ; Sat, 1 May 2004 13:37:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJy1Y-0008VK-HG for ipv6-archive@odin.ietf.org; Sat, 01 May 2004 13:11:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41HBagm032690 for ipv6-archive@odin.ietf.org; Sat, 1 May 2004 13:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxx1-0003Vv-NI for ipv6-web-archive@optimus.ietf.org; Sat, 01 May 2004 13:06:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02748 for ; Sat, 1 May 2004 13:06:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJxwz-0000ll-TY for ipv6-web-archive@ietf.org; Sat, 01 May 2004 13:06:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJxuy-0007Wu-00 for ipv6-web-archive@ietf.org; Sat, 01 May 2004 13:04:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJxpW-00050k-00 for ipv6-web-archive@ietf.org; Sat, 01 May 2004 12:59:10 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJxpX-0004b8-Fm for ipv6-web-archive@ietf.org; Sat, 01 May 2004 12:59:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxRC-0003O8-0W; Sat, 01 May 2004 12:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJvig-00081H-3l for ipv6@optimus.ietf.org; Sat, 01 May 2004 10:43:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21910 for ; Sat, 1 May 2004 10:43:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJvid-0002nI-Lf for ipv6@ietf.org; Sat, 01 May 2004 10:43:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJvhe-0002Zk-00 for ipv6@ietf.org; Sat, 01 May 2004 10:42:55 -0400 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1BJvgc-0002ES-00 for ipv6@ietf.org; Sat, 01 May 2004 10:41:50 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel13.hp.com (Postfix) with ESMTP id 779F01C0254D; Sat, 1 May 2004 07:41:48 -0700 (PDT) Received: from india.hp.com (nt231152.india.hp.com [15.42.231.152]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i41Eamj09631; Sat, 1 May 2004 20:06:48 +0530 (IST) Message-ID: <4093B705.9000100@india.hp.com> Date: Sat, 01 May 2004 20:11:09 +0530 From: Arun Thulasi Reply-To: arunt@india.hp.com User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Cc: shankar_r@hp.com Subject: Requesting Comments & Suggestions - ID on Prefix Delegation using ICMPv6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello All, We've submitted a draft that describes a mechanism for Prefix Delegation using ICMPv6 by satisfying the requirements mentioned in Requirements for IPv6 prefix delegation (draft-ietf-ipv6-prefix-delegation-requirement-04.txt) .. Do let us know your comments and suggestions on the draft .. We would also like to request the Working Group and the Chairs to consider draft-arunt-prefix-delegation-using-icmpv6-00.txt as a Working Group item. Thanks, Arun T Shankar R Internet-Drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Prefix Delegation Using ICMPv6 Author(s) : S. Raman, A. Thulasi Filename : draft-arunt-prefix-delegation-using-icmpv6-00.txt Pages : 34 Date : 2004-4-29 This document describes a Prefix Delegation Mechanism which delegates IPv6 prefixes to a subscriber's network (or "site") by an Internet Service Provider (ISP). It uses ICMPv6 messages to handle Prefix Delegation between the Delegating Router and the Requesting Router. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arunt-prefix-delegation-using-icmpv6-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-arunt-prefix-delegation-using-icmpv6-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-arunt-prefix-delegation-using-icmpv6-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun May 2 01:14:05 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12429 for ; Sun, 2 May 2004 01:14:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK9Dd-00054e-A3 for ipv6-archive@odin.ietf.org; Sun, 02 May 2004 01:08:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4258nIO019489 for ipv6-archive@odin.ietf.org; Sun, 2 May 2004 01:08:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK9Bi-0003aa-Kx for ipv6-web-archive@optimus.ietf.org; Sun, 02 May 2004 01:06:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10732 for ; Sun, 2 May 2004 00:20:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK8So-00020z-OV for ipv6-web-archive@ietf.org; Sun, 02 May 2004 00:20:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK8Rq-0001ne-00 for ipv6-web-archive@ietf.org; Sun, 02 May 2004 00:19:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BK8Qq-0001WB-00 for ipv6-web-archive@ietf.org; Sun, 02 May 2004 00:18:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK8Es-0007et-2M; Sun, 02 May 2004 00:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK8E0-00071O-1k for ipv6@optimus.ietf.org; Sun, 02 May 2004 00:05:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10278 for ; Sun, 2 May 2004 00:05:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK8Dx-0006MD-OP for ipv6@ietf.org; Sun, 02 May 2004 00:05:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK8C8-0005yC-00 for ipv6@ietf.org; Sun, 02 May 2004 00:03:13 -0400 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1BK89j-0005PN-00 for ipv6@ietf.org; Sun, 02 May 2004 00:00:43 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id E9C3020B for ; Sun, 2 May 2004 00:00:11 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 02 May 2004 00:00:11 -0400 Message-Id: <20040502040011.E9C3020B@cyteen.hactrn.net> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.2 required=5.0 tests=AWL autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.29% | 12 | 14.49% | 65418 | alain.durand@sun.com 11.90% | 10 | 15.12% | 68287 | jinmei@kame.net 7.14% | 6 | 8.20% | 37031 | jim.bound@hp.com 7.14% | 6 | 6.72% | 30350 | jinmei@isl.rdc.toshiba.co.jp 4.76% | 4 | 7.36% | 33230 | iljitsch@muada.com 5.95% | 5 | 5.74% | 25926 | rdroms@cisco.com 5.95% | 5 | 5.34% | 24109 | ipng@uni-muenster.de 4.76% | 4 | 4.89% | 22062 | h.soliman@flarion.com 4.76% | 4 | 4.54% | 20513 | tjc@ecs.soton.ac.uk 4.76% | 4 | 3.31% | 14927 | subramoniap@ctd.hcltech.com 3.57% | 3 | 3.33% | 15044 | brian@innovationslab.net 3.57% | 3 | 3.27% | 14771 | huitema@windows.microsoft.com 2.38% | 2 | 2.38% | 10749 | internet-drafts@ietf.org 2.38% | 2 | 1.94% | 8766 | pekkas@netcore.fi 2.38% | 2 | 1.90% | 8586 | john.loughney@nokia.com 2.38% | 2 | 1.76% | 7936 | ot@cisco.com 1.19% | 1 | 1.34% | 6052 | ftemplin@iprg.nokia.com 1.19% | 1 | 1.30% | 5880 | arunt@india.hp.com 1.19% | 1 | 1.11% | 4992 | tim@mentat.com 1.19% | 1 | 0.94% | 4261 | soohong.park@samsung.com 1.19% | 1 | 0.91% | 4127 | sra+ipng@hactrn.net 1.19% | 1 | 0.88% | 3967 | boodhooa@mx.uom.ac.mu 1.19% | 1 | 0.82% | 3720 | msa@burp.tkv.asdf.org 1.19% | 1 | 0.82% | 3696 | bob.hinden@nokia.com 1.19% | 1 | 0.81% | 3662 | itojun@itojun.org 1.19% | 1 | 0.77% | 3467 | mailman-owner@www1.ietf.org --------+------+--------+----------+------------------------ 100.00% | 84 |100.00% | 451529 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 3 09:41:27 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28755 for ; Mon, 3 May 2004 09:41:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKd4y-0006oz-R5 for ipv6-archive@odin.ietf.org; Mon, 03 May 2004 09:01:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43D1qWi026221 for ipv6-archive@odin.ietf.org; Mon, 3 May 2004 09:01:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcw1-0001TS-15 for ipv6-web-archive@optimus.ietf.org; Mon, 03 May 2004 08:52:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25790 for ; Mon, 3 May 2004 08:52:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKcvz-0006Z6-Mg for ipv6-web-archive@ietf.org; Mon, 03 May 2004 08:52:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKcpU-0005di-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 08:45:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKcjn-0004mu-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 08:39:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcRY-0007Jj-Lb; Mon, 03 May 2004 08:21:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcHd-0002AE-CQ for ipv6@optimus.ietf.org; Mon, 03 May 2004 08:10:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22973 for ; Mon, 3 May 2004 08:10:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKcHa-0000J7-DK for ipv6@ietf.org; Mon, 03 May 2004 08:10:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKcDI-0007Lz-00 for ipv6@ietf.org; Mon, 03 May 2004 08:06:25 -0400 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1BKc8g-0006ZQ-00 for ipv6@ietf.org; Mon, 03 May 2004 08:01:38 -0400 Received: from [128.176.184.156] (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.11/8.12.9) with ESMTP id i43C1J3l013177 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 3 May 2004 14:01:20 +0200 (CEST) Subject: Re: Requesting Comments & Suggestions - ID on Prefix Delegation using ICMPv6 From: "Christian Strauf (JOIN)" To: arunt@india.hp.com Cc: ipv6@ietf.org, shankar_r@hp.com In-Reply-To: <4093B705.9000100@india.hp.com> References: <4093B705.9000100@india.hp.com> Content-Type: text/plain Organization: JOIN-Team, WWU-Muenster Message-Id: <1083585674.6263.150.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 03 May 2004 14:01:14 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Arun, before I write up a few comments I'd like to remark that I don't like the idea of delegating prefixes using ICMPv6 because I don't see how this offers different/better/more versatile features compared to DHCPv6-PD. Especially since you need a state machinery or cache for this mechanism to maintain tables of allocated and free prefixes. You basically try to provide functionality with ICMPv6 that is already provided by DHCPv6-PD. > Do let us know your comments and suggestions on the draft .. Here are my initial comments after the first pass of reading the document: Para 2.1: - Here you say that RRs make requests to the CPE. Later paragraphs (e.g. 3.1) suggest that the RR and the CPE are the same entity (which makes sense). You should clarify this. Same goes for the PE and the DR -- they appear to be the same in later paragraphs but it's not clear. Para 4.1: - Assuming that RRs and DRs aren't necessarily connected via P-t-P connection (if they were you could try and use some link-scoped multicast address), how is the "Destination Address" of the DR determined by the RR? Does it have to be specified manually? I don't recall that you specify this in the document. Would the default router's address be the "Destination Address"? Para 5.1: - The "Free Prefix Cache" section is too unspecific in my eyes. You should clarify what you actually mean by "list of available prefixes". Let's say that you have 2001:638:500::/48 in that cache. Does this mean that RRs may request several /64 prefixes from the /48? Or does it mean that you can only request the whole /48? (The latter obviously makes more sense but it should be made clear in this paragraph what is possible and what isn't.) - What do you mean by "details of acceptable IP addresses for this prefix"? Is this a list of IPv6 addresses of RRs that may request this prefix? Is this mandatory? In what form can you specify these IP addresses (e.g. also as prefixes)? - It is not clear from looking at the "Free Prefix Cache" if or if not prefixes are actually pre-assigned. Maybe a "Reserved" state that is practically the same as the "Free" state in Para 5.2 would clarify this with the addition that it may only be assigned to an RR with a specific Identifier. Para 9.: - A very important security issue I see is that the ICMPv6 messages are not limited to a link. I don't see why it wouldn't be possible for any host with a global IPv6 address to act as an RR and contact a DR with to request a prefix. This can only be countered with filtering the ICMPv6 messages on the appropriate routers. The I-D does not specifically limit the Prefix Delegation exchanges to a P-t-P link -- e.g. Figure 2 in Para 2.1 doesn't suggest it does. - Since prefixes can be freely requested by RRs in some scenarios, routing adjustments have to be made automatically by PEs based on the prefix delegations. This potentially makes the mechanism vulnerable to denial of service attacks. Especially since the administrational realm of the ISP does not include the CPEs. Again, I think that we shouldn't try to use ICMPv6 for providing a functionality that is already provided by DHCPv6-PD. Additionally, the issue of pre-assigned prefixes for CPEs is not that clear to me in your document, even though this will most likely be the most common scenario for prefix delegation in my eyes. Can you clarify how pre-assignment is done specifically? Do you use a pre-shared Identifier that has to be put on RR and DR? Cheers, Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 3 10:24:57 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04701 for ; Mon, 3 May 2004 10:24:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeMF-0001JX-Uu for ipv6-archive@odin.ietf.org; Mon, 03 May 2004 10:23:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43ENlMB005041 for ipv6-archive@odin.ietf.org; Mon, 3 May 2004 10:23:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeEn-0006Jy-R8 for ipv6-web-archive@optimus.ietf.org; Mon, 03 May 2004 10:16:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03059 for ; Mon, 3 May 2004 10:16:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKeEl-0003bG-J9 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 10:16:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKe7k-0002Pr-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 10:08:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKdxF-0000xM-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 09:57:57 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKdxF-0003ut-GS for ipv6-web-archive@ietf.org; Mon, 03 May 2004 09:57:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKdjs-00080C-I4; Mon, 03 May 2004 09:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKdAk-0007wS-Lj for ipv6@optimus.ietf.org; Mon, 03 May 2004 09:07:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26941 for ; Mon, 3 May 2004 09:07:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKdAj-00017H-4z for ipv6@ietf.org; Mon, 03 May 2004 09:07:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKd7N-0000W0-00 for ipv6@ietf.org; Mon, 03 May 2004 09:04:22 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BKd3j-0007dq-00 for ipv6@ietf.org; Mon, 03 May 2004 09:00:35 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 May 2004 05:14:09 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i43D01Su016173; Mon, 3 May 2004 06:00:02 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-37.cisco.com [10.86.242.37]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIC33912; Mon, 3 May 2004 09:00:00 -0400 (EDT) From: "Bernie Volz" To: "'Alain Durand'" , "'IETF IPv6 Mailing List'" Subject: RE: [rfc2462bis] whether we need the M/O flags Date: Mon, 3 May 2004 08:59:59 -0400 Organization: Cisco Message-ID: <000001c4310e$8a912e10$6801a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Alain: And, if hosts just run DHCPv6 anyway, it makes the job of the rogue = server user even easier - since it need not even bother to generate RAs. So, security is no better or worse. It may even be slightly better if they = need to generate the RAs since a) it is more work (especially if SEND is = used) and b) there's a chance that this fact can be discovered if a network is monitoring RAs to make sure only "legal" ones are generated. >Why is is not good for IPv6? Why have hosts needless generate periodic DHCP traffic when there is no = DHCP server present? True that in DHCPv6 the impact is much more minor as multicasting is used (in DHCPv4 all hosts on the network receive the = packets because they are broadcast), but it still seems better to me to avoid unnecessary traffic. You can certainly have hosts that always run DHCPv6, or at least policy settings that would allow it on a host. - Bernie > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On=20 > Behalf Of Soliman Hesham > Sent: Monday, April 26, 2004 9:55 PM > To: Alain Durand; IETF IPv6 Mailing List; JINMEI Tatuya / ???? > Subject: RE: [rfc2462bis] whether we need the M/O flags >=20 >=20 > Alain >=20 > Your point about security is valid but is relevant to=20 > securing RAs in general, and is not specific to the M/O bits.=20 > If you want to be sure they're=20 > secure just use SEND.=20 >=20 > Hesham >=20 >=20 > > -----Original Message----- > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On=20 > > Behalf Of Alain Durand > > Sent: Monday, April 26, 2004 1:14 PM > > To: IETF IPv6 Mailing List; JINMEI Tatuya / ???? > > Subject: Re: [rfc2462bis] whether we need the M/O flags > >=20 > >=20 > > Let me try to explain why I, as an implementor, do not=20 > like the M/O=20 > > bits very much. > >=20 > > It is not that DHCPv6 cannot be made secure, it is that the=20 > > M/O bits are > > an automatic and insecure way to trigger an external configuration=20 > > mechanism. > >=20 > > The are security implication for the hosts in implementing=20 > > those bits. > > They are received in RA, which are mostly insecure (anyone=20 > > can send a=20 > > "valid" RA) > > The current text says a host should turn stateful autoconf when=20 > > receiving those bits. > > So one could mount an attack fairly easily by introducing a=20 > > rogue DHCPv6 > > server on a network that had no DHCPv6 so far and send a=20 > fake RA with > the M/O bits on. The host will then configure=20 > itself using=20 > > data coming > > from the new rogue DHCPv6 server. > >=20 > > 2462 says "host should invoke the stateful address=20 > autoconfiguration=20 > > protocol" > > and not "MUST invoke", so there are already provision for=20 > not obeying > the M/O bits. But if those bits are not mandatory to=20 > > execute, why are=20 > > they here in > > the first place? To give a hint that DHCPv6 is present? > > Host should not blindly believe this unless the RA are=20 > secured. > Also, there are no such bits in IPv4, and host=20 > implementations that=20 > > chose to turn > > DHCPv4 on simply try it. Why is is not good for IPv6? > >=20 > > - Alain. > >=20 > >=20 > >=20 > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests:=20 > https://www1.ietf.org/mailman/listinfo/ipv6 > >=20 > -------------------------------------------------------------------- > >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > This email may contain confidential and privileged material=20 > for the sole use of the intended recipient. Any review or=20 > distribution by others is=20 > strictly prohibited. If you are not the intended recipient=20 > please contact the sender and delete all copies.=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 3 10:31:52 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05188 for ; Mon, 3 May 2004 10:31:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeMc-0001RD-OH for ipv6-archive@odin.ietf.org; Mon, 03 May 2004 10:24:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43EOA4v005517 for ipv6-archive@odin.ietf.org; Mon, 3 May 2004 10:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeIv-0008Ea-Tf for ipv6-web-archive@optimus.ietf.org; Mon, 03 May 2004 10:20:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03800 for ; Mon, 3 May 2004 10:20:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKeIt-0004Hw-GB for ipv6-web-archive@ietf.org; Mon, 03 May 2004 10:20:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKeFE-0003dv-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 10:16:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKe8T-0002V7-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 10:09:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKdqZ-00023U-Dy; Mon, 03 May 2004 09:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKdZc-00022y-HR for ipv6@optimus.ietf.org; Mon, 03 May 2004 09:33:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27915 for ; Mon, 3 May 2004 09:33:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKdZa-0004rt-8p for ipv6@ietf.org; Mon, 03 May 2004 09:33:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKdTg-00044x-00 for ipv6@ietf.org; Mon, 03 May 2004 09:27:25 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BKdPK-0003O7-00 for ipv6@ietf.org; Mon, 03 May 2004 09:22:55 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) with ESMTP id i43DMril028826 for ; Mon, 3 May 2004 16:22:53 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) id i43DMrot028823; Mon, 3 May 2004 16:22:53 +0300 Date: Mon, 3 May 2004 16:22:53 +0300 Message-Id: <200405031322.i43DMrot028823@burp.tkv.asdf.org> From: Markku Savela To: ipv6@ietf.org Subject: draft-jeong-dnsop-ipv6-dns-discovery-01.txt 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 I would like to implement the above, but it is somewhat hard when there is no assigned type code from IANA. What does it require for IANA to assign a type code? (same goes with the preferred route option). In my view the router solicitation could be viewed as "service solicitation", and in addition to normal routers answering with prefixes, some other "services" could send their own replies with their own options (like the DNS address), but without prefix information. Of course, single router box can do all answering, if desired. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 3 11:10:08 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07240 for ; Mon, 3 May 2004 11:10:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKf2X-0005Wg-8L for ipv6-archive@odin.ietf.org; Mon, 03 May 2004 11:07:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43F7To1021238 for ipv6-archive@odin.ietf.org; Mon, 3 May 2004 11:07:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKev6-0003az-MV for ipv6-web-archive@optimus.ietf.org; Mon, 03 May 2004 10:59:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06651 for ; Mon, 3 May 2004 10:59:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKev4-0006oz-6n for ipv6-web-archive@ietf.org; Mon, 03 May 2004 10:59:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKeuE-0006mH-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 10:58:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKeti-0006im-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 10:58:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKejh-0007ij-SN; Mon, 03 May 2004 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeeU-0006MB-9H for ipv6@optimus.ietf.org; Mon, 03 May 2004 10:42:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05721 for ; Mon, 3 May 2004 10:42:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKeeR-0005lF-Nt for ipv6@ietf.org; Mon, 03 May 2004 10:42:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKedU-0005hu-00 for ipv6@ietf.org; Mon, 03 May 2004 10:41:36 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1BKecU-0005df-00 for ipv6@ietf.org; Mon, 03 May 2004 10:40:34 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 977A64D4E; Mon, 3 May 2004 10:40:33 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 10:40:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rfc2462bis] whether we need the M/O flags Date: Mon, 3 May 2004 10:40:27 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B765@tayexc13.americas.cpqcorp.net> Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQxFpTJGfgrICmyS6qgIC6Ng2kUigABUB0w From: "Bound, Jim" To: "Bernie Volz" , "Alain Durand" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 03 May 2004 14:40:33.0305 (UTC) FILETIME=[96DBD090:01C4311C] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Why have hosts needless generate periodic DHCP traffic when=20 > there is no DHCP server present? True that in DHCPv6 the=20 > impact is much more minor as multicasting is used (in DHCPv4=20 > all hosts on the network receive the packets because they are=20 > broadcast), but it still seems better to me to avoid=20 > unnecessary traffic. This is excellent operational reason to keep both the M and O bits. All implementations support the M and O bits being received today it is not a problem and has not caused a problem. DHCPv6 is being deployed as we speak. DHCPv6 or DHCP6 lite can provide prefix delegations. DHCPv6 lite is so we can build lighterweight DHCPv6 not replace DHCPv6. All users I speak with will not turn on stateless in the Enterprise except for wireless and mobility. DHCPv6 permits control by the Enterprise administration and that is the process they know and understand and with all the IPv6 transition items to do they are glad DHCPv6 exists now and that several vendors are shipping products or planning to ship DHCPv6 server products. We should definitely not remove the M and O bits at all in 2461 or 2462, or try to identify use of DHCPv6 or DHCPv6 lite. /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 3 13:53:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16577 for ; Mon, 3 May 2004 13:53:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhT1-0007nB-BM for ipv6-archive@odin.ietf.org; Mon, 03 May 2004 13:42:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43Hgx6m029953 for ipv6-archive@odin.ietf.org; Mon, 3 May 2004 13:42:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhMI-0005hl-NA for ipv6-web-archive@optimus.ietf.org; Mon, 03 May 2004 13:36:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15595 for ; Mon, 3 May 2004 13:36:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhMG-0004qt-La for ipv6-web-archive@ietf.org; Mon, 03 May 2004 13:36:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhLP-0004io-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 13:35:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKhKR-0004b5-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 13:34:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKh2y-0001ML-NU; Mon, 03 May 2004 13:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgxq-0007wG-T5 for ipv6@optimus.ietf.org; Mon, 03 May 2004 13:10:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14445 for ; Mon, 3 May 2004 13:10:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKgxo-0002So-SJ for ipv6@ietf.org; Mon, 03 May 2004 13:10:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgwr-0002Nf-00 for ipv6@ietf.org; Mon, 03 May 2004 13:09:46 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1BKgw2-0002JR-00 for ipv6@ietf.org; Mon, 03 May 2004 13:08:54 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i43H8sMu011988 for ; Mon, 3 May 2004 11:08:54 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HX5003GSEAT3I@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 03 May 2004 11:08:54 -0600 (MDT) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HX500K6AEAS3N@mail.sun.net> for ipv6@ietf.org; Mon, 03 May 2004 11:08:53 -0600 (MDT) Date: Mon, 03 May 2004 10:08:52 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: <000001c4310e$8a912e10$6801a8c0@amer.cisco.com> To: Bernie Volz Cc: "'IETF IPv6 Mailing List'" Message-id: <8D50081C-9D24-11D8-AFDE-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <000001c4310e$8a912e10$6801a8c0@amer.cisco.com> Content-Transfer-Encoding: 7BIT 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On May 3, 2004, at 5:59 AM, Bernie Volz wrote: > You can certainly have hosts that always run DHCPv6, or at least policy > settings that would allow it on a host. Or the opposite... That is, hosts that have a policy to not turn DHCPv6 on even when receiving O or M. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 3 17:39:04 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04616 for ; Mon, 3 May 2004 17:39:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKl0I-0000dj-CF for ipv6-archive@odin.ietf.org; Mon, 03 May 2004 17:29:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43LTYs2002361 for ipv6-archive@odin.ietf.org; Mon, 3 May 2004 17:29:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKkQJ-00074q-WC for ipv6-web-archive@optimus.ietf.org; Mon, 03 May 2004 16:52:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29993 for ; Mon, 3 May 2004 16:52:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKkQI-0006Wt-2U for ipv6-web-archive@ietf.org; Mon, 03 May 2004 16:52:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKkO8-00065Z-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 16:50:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKkMt-0005lz-01 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 16:48:51 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKkI1-0000Zt-Uz for ipv6-web-archive@ietf.org; Mon, 03 May 2004 16:43:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjb1-000649-2k; Mon, 03 May 2004 15:59:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjWK-0004uT-BL for ipv6@optimus.ietf.org; Mon, 03 May 2004 15:54:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25657; Mon, 3 May 2004 15:54:29 -0400 (EDT) Message-Id: <200405031954.PAA25657@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipv6@ietf.org, rtgwg@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-perlman-rbridge-00.txt Date: Mon, 03 May 2004 15:54:29 -0400 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RBridges: Transparent Routing Author(s) : R. Perlman, et al. Filename : draft-perlman-rbridge-00.txt Pages : 0 Date : 2004-5-3 This design provides the ability to have an entire campus, with multiple physical links, look to IP like a single subnet. This allows zero configuration of the switches within the campus, and allows nodes to move around within the campus without changing IP addresses. This capability is often provided today with bridges. Bridges do accomplish this goal. However, bridges have disadvantages: routing is confined to a spanning tree (precluding pair-wise shortest paths), the header on which the spanning tree forwards has no hop count, spanning tree forwarding in the presence of temporary loops spawns exponential copies of packets, nodes can have only a single point of attachment, and the spanning tree, in order to avoid temporary loops, is slow to start forwarding on new ports. The design in this paper avoids these disadvantages of bridges while maintaining the advantages. This design works for both IPv4 and IPv6. This document is a work in progress; we invite you to participate on the rbridge mailing list at http://www.postel.org/rbridge A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perlman-rbridge-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-perlman-rbridge-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-perlman-rbridge-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-3161505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-perlman-rbridge-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-perlman-rbridge-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-3161505.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 3 20:04:41 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12641 for ; Mon, 3 May 2004 20:04:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKnPf-00068b-4V for ipv6-archive@odin.ietf.org; Mon, 03 May 2004 20:03:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4403t7u023593 for ipv6-archive@odin.ietf.org; Mon, 3 May 2004 20:03:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKnOr-0005tP-3C for ipv6-web-archive@optimus.ietf.org; Mon, 03 May 2004 20:03:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12587 for ; Mon, 3 May 2004 20:03:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKnOp-0002Nr-6b for ipv6-web-archive@ietf.org; Mon, 03 May 2004 20:03:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKnNv-0002GF-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 20:02:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKnNA-00028u-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 20:01:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKnH4-0003p0-HC; Mon, 03 May 2004 19:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKnAI-0002Nk-CT for ipv6@optimus.ietf.org; Mon, 03 May 2004 19:48:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12247 for ; Mon, 3 May 2004 19:48:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKnAG-0000b9-Fu for ipv6@ietf.org; Mon, 03 May 2004 19:48:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKn9K-0000To-00 for ipv6@ietf.org; Mon, 03 May 2004 19:47:03 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BKn8O-0000G5-00 for ipv6@ietf.org; Mon, 03 May 2004 19:46:04 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HX500A04WNXKE@mailout1.samsung.com> for ipv6@ietf.org; Tue, 04 May 2004 08:45:33 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HX5003ZHWNWC8@mailout1.samsung.com> for ipv6@ietf.org; Tue, 04 May 2004 08:45:33 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HX500G1HWNW6L@mmp2.samsung.com> for ipv6@ietf.org; Tue, 04 May 2004 08:45:32 +0900 (KST) Date: Tue, 04 May 2004 08:46:02 +0900 From: "S. Daniel Park" Subject: RE: draft-jeong-dnsop-ipv6-dns-discovery-01.txt In-reply-to: <200405031322.i43DMrot028823@burp.tkv.asdf.org> To: "'Markku Savela'" , ipv6@ietf.org Cc: "'S. Daniel Park'" Message-id: <00a401c43168$cb068b20$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > I would like to implement the above, but it is somewhat hard when > there is no assigned type code from IANA. What does it require for > IANA to assign a type code? (same goes with the preferred route > option). AFAIC, RFC-Editor is responsible for the IANA assignment, thus this draft must be accepted as working group draft in the IETF in advance. You can assign your temporary number to implement it in your lab or somewhere, of course it does not have interoperability. Unfortunately, I (and somebody) am doing the same way as temporary Type of this option. > In my view the router solicitation could be viewed as "service > solicitation", and in addition to normal routers answering with > prefixes, some other "services" could send their own replies with > their own options (like the DNS address), but without prefix > information. > > Of course, single router box can do all answering, if desired. > Yep. Thanks your interesting in this work as co-author of this draft. - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 3 22:00:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16489 for ; Mon, 3 May 2004 22:00:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKpCG-0002p3-UX for ipv6-archive@odin.ietf.org; Mon, 03 May 2004 21:58:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i441wCsB010849 for ipv6-archive@odin.ietf.org; Mon, 3 May 2004 21:58:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKpBI-0002cj-8r for ipv6-web-archive@optimus.ietf.org; Mon, 03 May 2004 21:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16396 for ; Mon, 3 May 2004 21:57:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKpBF-0001Od-EP for ipv6-web-archive@ietf.org; Mon, 03 May 2004 21:57:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKpAH-0001Gw-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 21:56:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKp9a-00019P-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 21:55:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKp3O-000102-MO; Mon, 03 May 2004 21:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKp1b-0000ll-NZ for ipv6@optimus.ietf.org; Mon, 03 May 2004 21:47:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16065 for ; Mon, 3 May 2004 21:47:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKp1Y-00006T-PJ for ipv6@ietf.org; Mon, 03 May 2004 21:47:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKp0f-0007mV-00 for ipv6@ietf.org; Mon, 03 May 2004 21:46:14 -0400 Received: from pec.etri.re.kr ([129.254.114.50]) by ietf-mx with esmtp (Exim 4.12) id 1BKp0M-0007eJ-00 for ipv6@ietf.org; Mon, 03 May 2004 21:45:54 -0400 Received: from paul3 (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.12.10/8.12.10) with SMTP id i4422Xof018136; Tue, 4 May 2004 11:02:33 +0900 (KST) Message-ID: <015801c43179$6fe99780$c470fe81@etri.re.kr> From: "Jaehoon Paul Jeong" To: "Markku Savela" Cc: References: <200405031322.i43DMrot028823@burp.tkv.asdf.org> Subject: Re: draft-jeong-dnsop-ipv6-dns-discovery-01.txt Date: Tue, 4 May 2004 10:45:11 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL,MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Rmlyc3Qgb2YgYWxsLCB0aGFua3MgZm9yIHlvdXIgaW50ZXJlc3QuDQoNClJlY2VudGx5LCBETlNP UCB3b3JraW5nIGdyb3VwIGRlY2lkZWQgdG8gd3JpdGUgYW4gSW5mb3JtYXRpb24gUkZDDQpkZXNj cmliaW5nICJJUHY2IEhvc3QgQ29uZmlndXJhdGlvbiBvZiBETlMgU2VydmVyIEluZm9ybWF0aW9u IEFwcHJvYWNoZXMiOw0KYSkgUkEgb3B0aW9uLCBiKSBESENQdjYgb3B0aW9uLCBhbmQgYykgV2Vs bC1rbm93biBhbnljYXN0IGFkZHJlc3Nlcy4NCg0KQWZ0ZXIgdGhpcyBSRkMgaXMgcHVibGlzaGVk LCBJIGhvcGUgdGhhdCBvdXIgUkEgb3B0aW9uIGRyYWZ0IHdpbGwgYmUgZGlzY3Vzc2VkIGluIERO U09QDQpvciBJUHY2IHdvcmtpbmcgZ3JvdXAuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCkZyb206ICJNYXJra3UgU2F2ZWxhIiA8bXNhQGJ1cnAudGt2LmFzZGYub3JnPg0KVG86 IDxpcHY2QGlldGYub3JnPg0KU2VudDogTW9uZGF5LCBNYXkgMDMsIDIwMDQgMTA6MjIgUE0NClN1 YmplY3Q6IGRyYWZ0LWplb25nLWRuc29wLWlwdjYtZG5zLWRpc2NvdmVyeS0wMS50eHQNCg0KDQo+ IA0KPiBJIHdvdWxkIGxpa2UgdG8gaW1wbGVtZW50IHRoZSBhYm92ZSwgYnV0IGl0IGlzIHNvbWV3 aGF0IGhhcmQgd2hlbg0KPiB0aGVyZSBpcyBubyBhc3NpZ25lZCB0eXBlIGNvZGUgZnJvbSBJQU5B LiBXaGF0IGRvZXMgaXQgcmVxdWlyZSBmb3INCj4gSUFOQSB0byBhc3NpZ24gYSB0eXBlIGNvZGU/ IChzYW1lIGdvZXMgd2l0aCB0aGUgcHJlZmVycmVkIHJvdXRlDQo+IG9wdGlvbikuDQo+IA0KDQpJ IGFncmVlIHdpdGggRGFuaWVsJ3Mgb3BpbmlvbiB0aGF0IHlvdSBjYW4gdXNlIGEgdGVtcG9yYXJ5 IHZhbHVlLg0KDQo+IEluIG15IHZpZXcgdGhlIHJvdXRlciBzb2xpY2l0YXRpb24gY291bGQgYmUg dmlld2VkIGFzICJzZXJ2aWNlDQo+IHNvbGljaXRhdGlvbiIsIGFuZCBpbiBhZGRpdGlvbiB0byBu b3JtYWwgcm91dGVycyBhbnN3ZXJpbmcgd2l0aA0KPiBwcmVmaXhlcywgc29tZSBvdGhlciAic2Vy dmljZXMiIGNvdWxkIHNlbmQgdGhlaXIgb3duIHJlcGxpZXMgd2l0aA0KPiB0aGVpciBvd24gb3B0 aW9ucyAobGlrZSB0aGUgRE5TIGFkZHJlc3MpLCBidXQgd2l0aG91dCBwcmVmaXgNCj4gaW5mb3Jt YXRpb24uDQoNCkkgYWdyZWUgd2l0aCB5b3UuIEhvd2V2ZXIsIEkgdGhpbmsgdGhhdCBSQSBvcHRp b24gb2YgRE5TIHNlcnZlciBhZGRyZXNzIHNob3VsZCBiZQ0KYWxvbmcgd2l0aCBwcmVmaXggaW5m b3JtYXRpb24gb3B0aW9uIGF0IHRoZSBzYW1lIHBlcmlvZC4gT3RoZXJ3aXNlLCB3ZSBuZWVkIGEg d2F5DQp0byBpbmRpY2F0ZSB0aGUgd2FudGVkIG9wdGlvbiBpbiBSUyBtZXNzYWdlLCBlLmcuLCB0 aHJvdWdoIGEgbmV3IGZsYWcgaW4gdGhlIHJlc2VydmVkIGZpZWxkLg0KSSBhbSBub3Qgc3VyZSB0 aGF0IElQdjYgd2cgYWdyZWVzIHdpdGggdGhpcy4NCg0KVGhhbmtzLg0KDQpQYXVsDQoNCj4gDQo+ IE9mIGNvdXJzZSwgc2luZ2xlIHJvdXRlciBib3ggY2FuIGRvIGFsbCBhbnN3ZXJpbmcsIGlmIGRl c2lyZWQuDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAg bWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6 IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4g -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 3 23:38:32 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20898 for ; Mon, 3 May 2004 23:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqiE-0004V1-EL for ipv6-archive@odin.ietf.org; Mon, 03 May 2004 23:35:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i443ZIxq017293 for ipv6-archive@odin.ietf.org; Mon, 3 May 2004 23:35:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqhO-00048g-Pu for ipv6-web-archive@optimus.ietf.org; Mon, 03 May 2004 23:34:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20682 for ; Mon, 3 May 2004 23:34:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKqhM-0007JR-RG for ipv6-web-archive@ietf.org; Mon, 03 May 2004 23:34:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKqgZ-00079s-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 23:33:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKqg1-0006zC-00 for ipv6-web-archive@ietf.org; Mon, 03 May 2004 23:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqZJ-000219-8P; Mon, 03 May 2004 23:26:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqVU-00010R-KI for ipv6@optimus.ietf.org; Mon, 03 May 2004 23:22:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19899 for ; Mon, 3 May 2004 23:22:05 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKqVS-0005KV-Jg for ipv6@ietf.org; Mon, 03 May 2004 23:22:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKqUT-0005Am-00 for ipv6@ietf.org; Mon, 03 May 2004 23:21:06 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BKqTU-0004vD-00 for ipv6@ietf.org; Mon, 03 May 2004 23:20:04 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i443Jxv14238; Tue, 4 May 2004 06:19:59 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 06:19:57 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i443Jv91030895; Tue, 4 May 2004 06:19:57 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00Le0PPW; Tue, 04 May 2004 06:19:56 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i443JrH26036; Tue, 4 May 2004 06:19:53 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 06:19:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-jeong-dnsop-ipv6-dns-discovery-01.txt Date: Tue, 4 May 2004 06:19:51 +0300 Message-ID: Thread-Topic: draft-jeong-dnsop-ipv6-dns-discovery-01.txt Thread-Index: AcQxGFT4MDvLZerdSZ6L3ly0pzWbSAAbje9w To: , X-OriginalArrivalTime: 04 May 2004 03:19:53.0476 (UTC) FILETIME=[AAD63440:01C43186] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Markku, > I would like to implement the above, but it is somewhat hard when > there is no assigned type code from IANA. What does it require for > IANA to assign a type code? (same goes with the preferred route > option). There's a proposal for early IANA assignment, see: Title : Early IANA Allocation of Standards Track Codepoints Author(s) : K. Kompella, A. Zinin Filename : draft-kompella-zinin-early-allocation-01.txt Pages : 7 Date : 2004-5-3 =09 This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the 'Standards Action' IANA policy for protocols where, by the IETF process, implementation and deployment experience is desired or required prior to publication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation= -01.txt However, this should be discussed elsewhere, I suppose. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 4 20:39:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10877 for ; Tue, 4 May 2004 20:39:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLAMb-0007Wn-3r for ipv6-archive@odin.ietf.org; Tue, 04 May 2004 20:34:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i450YHfV028937 for ipv6-archive@odin.ietf.org; Tue, 4 May 2004 20:34:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLAJW-0006fJ-Fh for ipv6-web-archive@optimus.ietf.org; Tue, 04 May 2004 20:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10398 for ; Tue, 4 May 2004 20:31:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLAJU-0001le-B2 for ipv6-web-archive@ietf.org; Tue, 04 May 2004 20:31:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLAIZ-0001ep-00 for ipv6-web-archive@ietf.org; Tue, 04 May 2004 20:30:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLAI7-0001XK-00 for ipv6-web-archive@ietf.org; Tue, 04 May 2004 20:29:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLA9m-0004Dc-EE; Tue, 04 May 2004 20:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLA6r-0003Xu-IE for ipv6@optimus.ietf.org; Tue, 04 May 2004 20:18:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09853 for ; Tue, 4 May 2004 20:17:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLA6p-00008R-FK for ipv6@ietf.org; Tue, 04 May 2004 20:17:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLA5x-00001M-00 for ipv6@ietf.org; Tue, 04 May 2004 20:17:06 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BLA5P-0007h2-00 for ipv6@ietf.org; Tue, 04 May 2004 20:16:31 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i450G0C20712 for ; Tue, 4 May 2004 17:16:00 -0700 X-mProtect: <200405050016> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdf9mry8; Tue, 04 May 2004 17:15:51 PDT Message-Id: <4.3.2.7.2.20040504171024.01ba5700@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 17:13:44 -0700 To: ipv6@ietf.org From: Bob Hinden Subject: IPv6 Work Group Last Call for "Default Router Preferences and More-Specific Routes" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 This is a IPv6 working group last call for comments on advancing the following document as an Proposed Standard: Title : Default Router Preferences and More-Specific Routes Author(s) : R. Draves, D. Thaler Filename : draft-ietf-ipv6-router-selection-03.txt Pages : 13 Date : 2003-12-18 This is a two week working group last call that will end on May 18, 2004. Please direct substantive comments to the IPv6 mailing list. Editorial comments can be sent directly to the authors. Regards, Bob & Brian IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 5 10:36:22 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16612 for ; Wed, 5 May 2004 10:36:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNK4-0003CT-LE for ipv6-archive@odin.ietf.org; Wed, 05 May 2004 10:24:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45EOWfw012299 for ipv6-archive@odin.ietf.org; Wed, 5 May 2004 10:24:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNGN-0002EY-TE for ipv6-web-archive@optimus.ietf.org; Wed, 05 May 2004 10:20:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15652 for ; Wed, 5 May 2004 10:20:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNGL-0005YT-Iw for ipv6-web-archive@ietf.org; Wed, 05 May 2004 10:20:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNFU-0005KQ-00 for ipv6-web-archive@ietf.org; Wed, 05 May 2004 10:19:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLNEs-00056Z-00 for ipv6-web-archive@ietf.org; Wed, 05 May 2004 10:19:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLN62-0005k7-W1; Wed, 05 May 2004 10:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLN3U-0003wr-33 for ipv6@optimus.ietf.org; Wed, 05 May 2004 10:07:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14163; Wed, 5 May 2004 10:07:13 -0400 (EDT) Message-Id: <200405051407.KAA14163@ietf.org> From: The IESG To: IETF-Announce: ; Cc: ipv6@ietf.org, Robert Hinden , Brian Haberman Subject: WG Action: RECHARTER: IP Version 6 Working Group (ipv6) Date: Wed, 05 May 2004 10:07:13 -0400 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.2 required=5.0 tests=AWL autolearn=no version=2.60 The charter of the IP Version 6 Working Group (ipv6) in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. IP Version 6 Working Group (ipv6) ---------------------------------- Current Status: Active Working Group Chairs: Robert Hinden Brian Haberman Internet Area Director(s): Thomas Narten Margaret Wasserman Internet Area Advisor: Margaret Wasserman Mailing Lists: General Discussion: ipv6@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ipv6 In Body: subscribe Archive: http://www1.ietf.org/mail-archive/working-groups/ipv6/current/ Description of Working Group: The IPv6 working group is responsible for the specification and standardization of the Internet Protocol version 6 (IPv6). IPv6 provides a much larger global addresses space than its predecessor IPv4. This enables global end-to-end communication and restores valuable properties of the IP architecture that have been lost in the IPv4 Internet. The core IPv6 standards are widely implemented and are starting to see global deployment. The IPv6 working group was originally chartered by the IESG as the IP Next Generation (IPng) working group to implement the recommendations of the IPng Area Directors as outlined at the July 1994 IETF meeting and in "The Recommendation for the IP Next Generation Protocol," RFC1752, January 1995. The primary focus of the IPv6 w.g. is to complete the standardization of the IPv6 protocols, and to review and update the IPv6 specifications based on implementation and deployment experience, and advancing them on the standardization track as appropriate. The working group's work items are as follows: o Complete Prefix Delegation requirements and publish. Related remaining work is: - Develop Proxy Neighbor Discovery solution for prefix delegation and publish. This enables a simple site border router to re-advertise downstream a prefix it hears on its upstream link. o Complete revision of IPv6 MIBs (combined IPv4/IPv6 versions) and publish. o Complete "Default Router Preferences, More-Specific Routes, and "Load Sharing" and publish. o Update to ICMPv6 (RFC2463) and publish. o Complete "Node Information Queries" and publish. o Update Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) and publish. o Investigate approaches to optimize or eliminate Duplicate Address Detection (DAD) to make reduce the delays incurred by DAD when there is a change of network attachment points. Publish a document defining DAD optimizations. o Update "Privacy Extensions for Stateless Autoconfiguration" document (RFC3041) and publish. o Complete work on IPv6 Node Requirements and publish. o Complete work stemming from the working group decision to deprecate site-local addressing. This includes: - Publish document deprecating the usage of Site-Local addressing. - Publish revision of the IPv6 Address Architecture that includes the deprecation of site-local addressing. - Publish a replacement for site-local addresses that removes the major limitations and allows for local allocations. o Update the IPv6 Address Architecture to resolve the issues raised in the IAB response to the Robert Elz appeal and publish as a Draft Standard. o Complete work on Scoped Addressing Architecture and publish. o Update IPv6 over PPP (RFC2472) and publish. o Complete work on "Link Scoped IPv6 Multicast Addresses" and publish. All new work items not listed above require the approval of the working group and IESG before they will be taken on by the working group. Goals and Milestones: Apr 04 Submit Link Scoped IPv6 Multicast Addresses to IESG for Proposed Standard. Apr 04 Submit IPv6 Scoped Addressing Architecture to IESG for Proposed Standard. Apr 04 Submit TCP MIB to IESG for Proposed Standard. Apr 04 Submit Site-Local Deprecation document to IESG for Informational. Apr 04 Submit Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard. May 04 Submit update to ICMPv6 (RFC2463) to be republished at Draft Standard. May 04 Submit Router Preferences, More-Specific Routes, and Load Sharing to IESG for Proposed Standard. Jun 04 Resubmit Node Information Queries to IESG for Proposed Standard. Jun 04 Submit updates to Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) to be republished at Draft Standard. Jun 04 Submit Proxy ND to IESG for Informational. Jun 04 Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard. Jun 04 Submit update to IPv6 Address Architecture to the IESG for Draft Standard. Aug 04 Submit Update to Privacy Extensions for Stateless Autoconfiguration document (RFC3041) to the IESG for Draft Standard. Dec 04 Submit document defining DAD optimizations to the IESG for Proposed Standard. Jan 05 Re-charter or close working group. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 5 16:57:03 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11295 for ; Wed, 5 May 2004 16:57:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLTQh-0000ly-4r for ipv6-archive@odin.ietf.org; Wed, 05 May 2004 16:55:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45KtlIT002971 for ipv6-archive@odin.ietf.org; Wed, 5 May 2004 16:55:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLTOt-00009e-4d for ipv6-web-archive@optimus.ietf.org; Wed, 05 May 2004 16:53:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11215 for ; Wed, 5 May 2004 16:53:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLTOr-0006Uv-50 for ipv6-web-archive@ietf.org; Wed, 05 May 2004 16:53:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLTNs-0006EN-00 for ipv6-web-archive@ietf.org; Wed, 05 May 2004 16:52:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLTMu-0005yC-00 for ipv6-web-archive@ietf.org; Wed, 05 May 2004 16:51:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLTFJ-0004fJ-SB; Wed, 05 May 2004 16:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLT8S-0000w1-9k for ipv6@optimus.ietf.org; Wed, 05 May 2004 16:36:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10689 for ; Wed, 5 May 2004 16:36:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLT8Q-0001j4-DM for ipv6@ietf.org; Wed, 05 May 2004 16:36:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLT7W-0001SK-00 for ipv6@ietf.org; Wed, 05 May 2004 16:35:58 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BLT6e-0000un-00 for ipv6@ietf.org; Wed, 05 May 2004 16:35:04 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i45KYXh14375; Wed, 5 May 2004 13:34:33 -0700 X-mProtect: <200405052034> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNWgeck; Wed, 05 May 2004 13:34:31 PDT Message-ID: <40994FE0.1070406@iprg.nokia.com> Date: Wed, 05 May 2004 13:34:40 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org CC: h.soliman@flarion.com Subject: RFC2461(bis) Issue - LLAO's for NS/NA References: <72479c729d88.729d8872479c@mail1.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In RFC 2461, section 7.2.2, the first sentence of the third paragraph reads: "If the solicitation is being sent to a solicited-node multicast address, the sender MUST include its link-layer address (if it has one) as a Source Link-Layer Address option." I believe this specification is correct, and I interpret the phrase "(if it has one)" to mean that the SLLAO may be omitted (or, may contain don't-care values) if the sender does not have a link-layer address. However, the text of section 7.2.4 ("Sending Solicited Neighbor Advertisements") does not account for the case in which the responder does not have a link-layer address. Suggested fix is to change the 4th sentence of the first paragraph of section 7.2.4 to: "If the solicitation's IP Destination Address is a multicast address, the node MUST include its link-layer address (if it has one) as a Target Link-Layer Address option in the advertisement." Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 6 13:27:57 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04662 for ; Thu, 6 May 2004 13:27:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmPD-0004CJ-2g for ipv6-archive@odin.ietf.org; Thu, 06 May 2004 13:11:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HBVwP016130 for ipv6-archive@odin.ietf.org; Thu, 6 May 2004 13:11:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlp3-0005kS-3y for ipv6-web-archive@optimus.ietf.org; Thu, 06 May 2004 12:34:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27524 for ; Thu, 6 May 2004 12:33:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLlov-0006qC-L5 for ipv6-web-archive@ietf.org; Thu, 06 May 2004 12:34:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLlkp-0005Ve-00 for ipv6-web-archive@ietf.org; Thu, 06 May 2004 12:29:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLlhp-0004Jw-00 for ipv6-web-archive@ietf.org; Thu, 06 May 2004 12:26:41 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLlhq-0001VU-Fe for ipv6-web-archive@ietf.org; Thu, 06 May 2004 12:26:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkvM-0008JY-CK; Thu, 06 May 2004 11:36:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLknx-0004Op-Ob for ipv6@optimus.ietf.org; Thu, 06 May 2004 11:28:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20166; Thu, 6 May 2004 11:28:55 -0400 (EDT) Message-Id: <200405061528.LAA20166@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-host-load-sharing-02.txt Date: Thu, 06 May 2004 11:28:55 -0400 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Host to Router Load Sharing Author(s) : R. Hinden, D. Thaler Filename : draft-ietf-ipv6-host-load-sharing-02.txt Pages : 6 Date : 2004-5-5 The original IPv6 conceptual sending algorithm does not do load- sharing among equivalent IPv6 routers, and suggests schemes which can be problematic in practice. This document updates the conceptual sending algorithm so that traffic to different destinations can be distributed among routers in an efficient fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-host-load-sharing-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-host-load-sharing-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-host-load-sharing-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-6113437.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-host-load-sharing-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-host-load-sharing-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-6113437.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 6 14:36:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09989 for ; Thu, 6 May 2004 14:36:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnc6-0003Eq-Bm for ipv6-archive@odin.ietf.org; Thu, 06 May 2004 14:28:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46ISsGq012433 for ipv6-archive@odin.ietf.org; Thu, 6 May 2004 14:28:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnUO-0008UP-4a for ipv6-web-archive@optimus.ietf.org; Thu, 06 May 2004 14:20:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08925 for ; Thu, 6 May 2004 14:20:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLnUL-0006zI-MX for ipv6-web-archive@ietf.org; Thu, 06 May 2004 14:20:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLnTL-0006ZA-00 for ipv6-web-archive@ietf.org; Thu, 06 May 2004 14:19:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLnSG-0005s6-00 for ipv6-web-archive@ietf.org; Thu, 06 May 2004 14:18:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnFz-0002Nw-Gy; Thu, 06 May 2004 14:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlOn-0000F4-Rd for ipv6@optimus.ietf.org; Thu, 06 May 2004 12:07:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23825 for ; Thu, 6 May 2004 12:06:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLlOm-0003iV-Gp for ipv6@ietf.org; Thu, 06 May 2004 12:07:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLlLL-0002SE-00 for ipv6@ietf.org; Thu, 06 May 2004 12:03:28 -0400 Received: from web8302.mail.in.yahoo.com ([203.199.122.32]) by ietf-mx with smtp (Exim 4.12) id 1BLlHs-0000wA-00 for ipv6@ietf.org; Thu, 06 May 2004 11:59:52 -0400 Message-ID: <20040506155920.78473.qmail@web8302.mail.in.yahoo.com> Received: from [61.95.177.131] by web8302.mail.in.yahoo.com via HTTP; Thu, 06 May 2004 16:59:20 BST Date: Thu, 6 May 2004 16:59:20 +0100 (BST) From: =?iso-8859-1?q?Girish=20Kamath?= Subject: Scope Issue To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1884751663-1083859160=:78127" Content-Transfer-Encoding: 8bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_20_30, HTML_MESSAGE autolearn=no version=2.60 --0-1884751663-1083859160=:78127 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, For Neighbor Discovery messages, is it mandatory that the scope of the source and destination address should match? If i have just a link-local unicast address on a node A connected to another node B which has global unicast addresses configured, can i form a ND message with source address as link-local unicast address and destination address as global unicast address when sending a ND packet from A to B. -- Girish Yahoo! India Matrimony: Find your partner online. --0-1884751663-1083859160=:78127 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello,
      For Neighbor Discovery messages, is it mandatory that the scope of the source and destination address should match?
If i have just a link-local unicast address on a node A connected to another node B which has global unicast addresses configured, can i form a ND message with source address as link-local unicast address and destination address as global unicast address when sending a ND packet from A to B.
 
-- Girish

Yahoo! India Matrimony: Find your partner online. --0-1884751663-1083859160=:78127-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 6 19:43:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28053 for ; Thu, 6 May 2004 19:43:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLsSy-0004t3-IQ for ipv6-archive@odin.ietf.org; Thu, 06 May 2004 19:39:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46NdmXE018783 for ipv6-archive@odin.ietf.org; Thu, 6 May 2004 19:39:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLsPY-0002y5-HY for ipv6-web-archive@optimus.ietf.org; Thu, 06 May 2004 19:36:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27593 for ; Thu, 6 May 2004 19:36:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLsPW-000729-U3 for ipv6-web-archive@ietf.org; Thu, 06 May 2004 19:36:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLsOd-0006au-00 for ipv6-web-archive@ietf.org; Thu, 06 May 2004 19:35:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLsNi-0006Aq-00 for ipv6-web-archive@ietf.org; Thu, 06 May 2004 19:34:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLsGf-0000RF-Tw; Thu, 06 May 2004 19:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLsEt-00081x-M8 for ipv6@optimus.ietf.org; Thu, 06 May 2004 19:25:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26830 for ; Thu, 6 May 2004 19:25:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLsEs-0002Hr-2n for ipv6@ietf.org; Thu, 06 May 2004 19:25:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLsDk-0001kv-00 for ipv6@ietf.org; Thu, 06 May 2004 19:24:05 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BLsCc-0000ry-00 for ipv6@ietf.org; Thu, 06 May 2004 19:22:54 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 6 May 2004 16:23:06 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 May 2004 16:22:19 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 May 2004 16:22:23 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 May 2004 16:22:08 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 6 May 2004 16:22:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-ietf-ipv6-host-load-sharing-02.txt Date: Thu, 6 May 2004 16:22:22 -0700 Message-ID: Thread-Topic: I-D ACTION:draft-ietf-ipv6-host-load-sharing-02.txt Thread-Index: AcQzhpP+Jd8pvNEQRVWslizpAmb4WwAOdd0g From: "Dave Thaler" To: X-OriginalArrivalTime: 06 May 2004 23:22:23.0148 (UTC) FILETIME=[FC37F6C0:01C433C0] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I have now updated the load sharing doc in response to the discussion on the list so far, and would like to=20 request a WG last call. Responses to Pekka's email below (others that commented=20 said similar things). Pekka Savola wrote: > I have major, fundamental objection to the premises on which this=20 > draft is based on. However, I think we should be able to find=20 > consensus on the way forward. >=20 > Fundamental objection > --------------------- >=20 > The document assumes that it is always desirable to do load-sharing=20 > with the equivalent routers. I don't agree with this assumption. >=20 > If the router's capacity is sufficient so that it can forward all the=20 > traffic sent by its nodes, there is actually very little need for load > sharing. On the contrary -- sharing load between routers produces=20 > difficult-to-debug scenarios when some destinations (which are=20 > distributed to some routers) fail in mysterious ways while others work just fine. >=20 > Due to that, I, as an operator, would not wish to enable load-sharing=20 > on hosts except when I specifically require that kind of functionality. >=20 > So, I'd propose that this document does not describe that the hosts=20 > MUST share the load, but rather describes how the hosts MUST behave if > they wish to share the load To summarize the other discussion on the list on this topic: A number of other folks (Changming Liu, Tim Chown, and Suresh Satapati) also argued on the list against the MUST, while others (such as Bob Hinden) have argued for it on and off the list. In draft-02, I have changed the MUST to a SHOULD as a result. > -- and if turned on by default, require that there MUST be a way to=20 > toggle load balancing off. A difficult issue to settle might be=20 > whether to recommend (and if so, how strongly) to enable load-sharing=20 > by default. I am not particularly eager to add any MUSTs at this point, as there seems to be lack of consensus on any MUST. For example, if you have an embedded device designed for a very specific application, "MUST be a way to toggle" seems too much to argue for. I agree it would be difficult enough to come to consensus on any text discussing defaults and toggling configuration, and as a result, draft-02 is silent on this issue.. The relevant paragraph in draft-02 is now: | When a host chooses from multiple equivalent routers, it SHOULD=20 | support choosing using some method which distributes load for=20 | different destinations among the equivalent routers rather than always | choosing the same router (e.g., the first in the list). Furthermore,=20 | a host that does attempt to distribute load among routers SHOULD use a | hash-based scheme, such as those described in [MULTIPATH], which takes | the destination IP address into account. > substantial > ----------- >=20 > [ND] does not require any particular behavior in this respect. It=20 > specifies that an implementation may always choose the same router=20 > (e.g., the first in the list) or may cycle through the routers in a=20 > round-robin manner. Both of these suggestions are problematic. >=20 > Clearly, always choosing the same router does not provide load=20 > sharing. Some problems with naive tie-breaking techniques such as=20 > round-robin and random are discussed in [MULTIPATH]. While the=20 > destination cache provides some stability since the determination is=20 > not per-packet, cache evictions or timeouts can still result in=20 > unstable or unpredictable paths over time, lowering the performance=20 > and making it harder to diagnose problems. Round- robin selection may > also result in synchronization issues among hosts, where in the worst=20 > case the load is concentrated on one router at a time. >=20 > =3D=3D> I don't think this document clearly described both of the = above=20 > suggestion (1st paragraph): but rather how round-robin and random have > issues. That is, it does not cleatly describe why choosing the same=20 > router is undesirable. Clarfied by changing second sentence to | Some problems with load sharing using naive tie-breaking techniques=20 | such as round-robin and random are discussed in [MULTIPATH]. > As mentioned in [MULTIPATH], when next-hop selection is predictable,=20 > an application can synthesize traffic that will all hash the same,=20 > making it possible to launch a denial-of-service attack against the=20 > load sharing algorithm, and overload a particular router. A special=20 > case of this is when the same > (single) next-hop is always selected, such as in the algorithm allowed > by [ND]. Introducing hashing can make such an attack more difficult;=20 > the more unpredictable the hash is, the harder it becomes to conduct a > denial-of-service attack against any single router. >=20 > =3D=3D> these threats appear to have no clear threat model. What's = the=20 > point of such an attack, as you're already on-link, and can already=20 > DoS the routers there using a number of means? Not quite true. A remote attacker can conduct such an attack too, as long as he has the ability to spoof/use a bunch of different source addresses. Added the sentence: + This can even be done by a remote application that can cause a host to + respond to a given destination address. However, you are correct in that there's not really much of a threat there, since there are other ways of doing the same thing. But it seems better than claiming there's no security issues whatsoever. > Introducing hashing doesn't help much here > -- > you're making an assumption that the attacker is a "friendly" node. A > maliscious node will just a) send the packets through raw sockets,=20 > DoSing the routers directly, or b) overload both of the routers :). =20 > It seems the security considerations needs a rewrite... With the above clarification, I think the text is sufficient. If you feel otherwise, please submit proposed text. > editorial > --------- >=20 > =3D=3D> all the empty lines in the document appear to have been = duplicated > for some reason. I don't see this. Perhaps a CR/LF issue? > Abstract >=20 > The original IPv6 conceptual sending algorithm does not require=20 > load-sharing among equivalent IPv6 routers, and suggests schemes >=20 > =3D=3D> s/IPv6/IPv6 Neighbor Discovery/ Disagree. Although it's in the ND spec, the relevant part of the algorithm here is not specific to links which actually run full ND. Hence I find it less confusing the way it is. It's a trivial point in any case. > Subsequent traffic to the same > destination address continues to use the same router unless there is=20 > some reason to change to a different router (e.g., a redirect message=20 > is received, or a router is found to be unreachable). >=20 > =3D=3D> s/a router/the router/ Done. > 9. Full Copyright Statement >=20 > =3D=3D> IPR boilerplate prior to this document would not hurt. Done. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 6 20:42:50 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00735 for ; Thu, 6 May 2004 20:42:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLtPM-0006Wc-GQ for ipv6-archive@odin.ietf.org; Thu, 06 May 2004 20:40:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i470e83U025078 for ipv6-archive@odin.ietf.org; Thu, 6 May 2004 20:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLtKh-0004qN-Lz for ipv6-web-archive@optimus.ietf.org; Thu, 06 May 2004 20:35:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00369 for ; Thu, 6 May 2004 20:35:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLtKf-0000UP-Aj for ipv6-web-archive@ietf.org; Thu, 06 May 2004 20:35:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLtJh-00005E-00 for ipv6-web-archive@ietf.org; Thu, 06 May 2004 20:34:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLtJH-0007TX-00 for ipv6-web-archive@ietf.org; Thu, 06 May 2004 20:33:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLtBi-00021m-06; Thu, 06 May 2004 20:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLt82-000109-9C for ipv6@optimus.ietf.org; Thu, 06 May 2004 20:22:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29669 for ; Thu, 6 May 2004 20:22:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLt80-0002sN-65 for ipv6@ietf.org; Thu, 06 May 2004 20:22:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLt70-0002SZ-00 for ipv6@ietf.org; Thu, 06 May 2004 20:21:11 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BLt69-0001fX-00 for ipv6@ietf.org; Thu, 06 May 2004 20:20:17 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HXB00B6DI8SDO@mailout1.samsung.com> for ipv6@ietf.org; Fri, 07 May 2004 09:19:40 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HXB00HRLI74FN@mailout1.samsung.com> for ipv6@ietf.org; Fri, 07 May 2004 09:18:40 +0900 (KST) Received: from Alperyegin ([105.253.155.8]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HXB00F7II70HP@mmp2.samsung.com> for ipv6@ietf.org; Fri, 07 May 2004 09:18:39 +0900 (KST) Date: Thu, 06 May 2004 17:18:35 -0700 From: Alper Yegin Subject: RE: ND-proxy applicability and loop-prevention In-reply-to: To: "'Margaret Wasserman'" , "'Jari Arkko'" , "'Pekka Savola'" Cc: "'Erik Nordmark'" , ipv6@ietf.org Message-id: <017b01c433c8$d84a4bc0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > There was some discussion of this general concept (zero-configuration > routing and/or layer 3 bridging) in the Zerouter BOF and on the > zerouter mailing list... Does anyone know if that effort is still > active? http://www.ietf.org/internet-drafts/draft-perlman-rbridge-00.txt >From abstract: This document is a work in progress; we invite you to participate on the rbridge mailing list at http://www.postel.org/rbridge Alper -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 7 01:13:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11782 for ; Fri, 7 May 2004 01:13:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxeH-0004lF-6z for ipv6-archive@odin.ietf.org; Fri, 07 May 2004 01:11:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i475Bnr7018297 for ipv6-archive@odin.ietf.org; Fri, 7 May 2004 01:11:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxdu-0004XV-0K for ipv6-web-archive@optimus.ietf.org; Fri, 07 May 2004 01:11:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11755 for ; Fri, 7 May 2004 01:11:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLxdr-0004G1-5T for ipv6-web-archive@ietf.org; Fri, 07 May 2004 01:11:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLxcw-0003rk-00 for ipv6-web-archive@ietf.org; Fri, 07 May 2004 01:10:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLxcZ-0003Sz-00 for ipv6-web-archive@ietf.org; Fri, 07 May 2004 01:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxTq-0001D6-JX; Fri, 07 May 2004 01:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxSF-0000g0-Qa for ipv6@optimus.ietf.org; Fri, 07 May 2004 00:59:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11251 for ; Fri, 7 May 2004 00:59:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLxSD-000747-1z for ipv6@ietf.org; Fri, 07 May 2004 00:59:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLxRE-0006fL-00 for ipv6@ietf.org; Fri, 07 May 2004 00:58:20 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BLxQF-0005s5-00 for ipv6@ietf.org; Fri, 07 May 2004 00:57:19 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 May 2004 21:01:51 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i474ulSu022392 for ; Thu, 6 May 2004 21:56:48 -0700 (PDT) Received: from tgleesonw2k02 (dhcp-shinjuku-8f-64-104-8-107.cisco.com [64.104.8.107]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id VAA20929 for ; Thu, 6 May 2004 21:56:47 -0700 (PDT) Reply-To: From: "Timothy Gleeson \(tgleeson\)" To: Subject: RE: IPv6 Work Group Last Call for "Default Router Preferences and More-Specific Routes" Date: Fri, 7 May 2004 13:56:46 +0900 Message-ID: <00e301c433ef$b38cdc90$6b086840@apac.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <4.3.2.7.2.20040504171024.01ba5700@mailhost.iprg.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rich, Dave, Quick comment/question on the router selection spec. When a parameter is changed (e.g. the operator changes the default router preference or adds a route option) what should the router do? I guess it's implicit it should do the same as [RFC2461,6.2.4,last para] i.e. as for "becoming an advertising interface". If so, could this be made explicit? When a router interface is going down: [RFC2461,6.2.5] currently says (roughly) "SHOULD transmit one or more RAs with Router Lifetime zero". I'm uncertain if this would clear a ::/0 route in a type C host - the text currently says "updates a ::/0 route ... based on the Router Advertisement message header". Does "update" encompass "delete"? Also, such a final RA wouldn't clear any more specific routes. Does the latter case need some more text e.g. "SHOULD send all more specific routes with lifetime zero" or somesuch? Thanks. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 7 02:51:16 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00528 for ; Fri, 7 May 2004 02:51:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLz4r-0007v4-Hf for ipv6-archive@odin.ietf.org; Fri, 07 May 2004 02:43:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i476hL41030440 for ipv6-archive@odin.ietf.org; Fri, 7 May 2004 02:43:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLz43-0007Qv-5Q for ipv6-web-archive@optimus.ietf.org; Fri, 07 May 2004 02:42:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00146 for ; Fri, 7 May 2004 02:42:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLz3z-0003h1-Gi for ipv6-web-archive@ietf.org; Fri, 07 May 2004 02:42:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLz32-0003IL-00 for ipv6-web-archive@ietf.org; Fri, 07 May 2004 02:41:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLz2Q-0002tx-00 for ipv6-web-archive@ietf.org; Fri, 07 May 2004 02:40:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLyry-0000mr-Bh; Fri, 07 May 2004 02:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLymY-0006xv-Gr for ipv6@optimus.ietf.org; Fri, 07 May 2004 02:24:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29259 for ; Fri, 7 May 2004 02:24:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLymU-00045X-T2 for ipv6@ietf.org; Fri, 07 May 2004 02:24:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLylV-0003f6-00 for ipv6@ietf.org; Fri, 07 May 2004 02:23:21 -0400 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1BLykS-0002ri-00 for ipv6@ietf.org; Fri, 07 May 2004 02:22:17 -0400 Received: by anchovy.zoic.org (Postfix, from userid 1000) id E771270A3E7; Fri, 7 May 2004 16:22:03 +1000 (EST) Date: Fri, 7 May 2004 16:22:03 +1000 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Subject: RECHARTER / DAD Optimization Message-ID: <20040507062203.GC4134@zoic.org> Mail-Followup-To: ipv6@ietf.org References: <200405051407.KAA14163@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200405051407.KAA14163@ietf.org> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.3 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-05-05, The IESG wrote: > > The working group's work items are as follows: [...] > > o Investigate approaches to optimize or eliminate Duplicate Address > Detection (DAD) to make reduce the delays incurred by DAD when > there is a change of network attachment points. Publish a > document defining DAD optimizations. > [...] > Dec 04 Submit document defining DAD optimizations to the IESG for > Proposed Standard. Hi everyone, I'm interested in getting reviews and comments on draft-ietf-ipv6-optimistic-dad-00 -- it's been through a few rounds already, but I'd like to take an issues list to San Diego and, hopefully, a Last Call to Washington. cheers, -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 7 11:06:15 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29467 for ; Fri, 7 May 2004 11:06:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6aV-0004tV-5o for ipv6-archive@odin.ietf.org; Fri, 07 May 2004 10:44:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47EiVlY018813 for ipv6-archive@odin.ietf.org; Fri, 7 May 2004 10:44:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6Jb-0006Nb-Dn for ipv6-web-archive@optimus.ietf.org; Fri, 07 May 2004 10:27:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25593 for ; Fri, 7 May 2004 10:26:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM6JZ-0004ZW-7d for ipv6-web-archive@ietf.org; Fri, 07 May 2004 10:27:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6IV-00045f-00 for ipv6-web-archive@ietf.org; Fri, 07 May 2004 10:25:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM6HR-0003bq-00 for ipv6-web-archive@ietf.org; Fri, 07 May 2004 10:24:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5vP-0000jW-4s; Fri, 07 May 2004 10:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM31D-0000HZ-Lt for ipv6@optimus.ietf.org; Fri, 07 May 2004 06:55:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15149 for ; Fri, 7 May 2004 06:55:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM319-0007dh-ED for ipv6@ietf.org; Fri, 07 May 2004 06:55:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM304-0007Du-00 for ipv6@ietf.org; Fri, 07 May 2004 06:54:41 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1BM2zQ-0006eb-00 for ipv6@ietf.org; Fri, 07 May 2004 06:54:00 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i47ArUL30170 for ; Fri, 7 May 2004 03:53:30 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i47BAf4J027301 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 7 May 2004 04:10:48 -0700 Message-ID: <409B6A9B.9080505@innovationslab.net> Date: Fri, 07 May 2004 06:53:15 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: IPv6 Work Group Last Call for "IPv6 Host to Router Load Sharing" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This starts an IPv6 WG Last Call for advancing the following draft as a Proposed Standard Title : IPv6 Host to Router Load Sharing Author(s) : R. Hinden, D. Thaler Filename : draft-ietf-ipv6-host-load-sharing-02.txt Pages : 6 Date : 2004-5-5 This is a two week Last Call that will end on Friday May 21st, 2004. Substantive comments should be directed to the mailing list. Editorial comments can be sent to the authors. Regards, Brian & Bob IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat May 8 10:55:05 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06894 for ; Sat, 8 May 2004 10:55:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMTCk-0000YU-R1 for ipv6-archive@odin.ietf.org; Sat, 08 May 2004 10:53:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i48ErUpl002134 for ipv6-archive@odin.ietf.org; Sat, 8 May 2004 10:53:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMT8J-00009F-WE for ipv6-web-archive@optimus.ietf.org; Sat, 08 May 2004 10:48:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06647 for ; Sat, 8 May 2004 10:48:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMT8H-0005KO-IF for ipv6-web-archive@ietf.org; Sat, 08 May 2004 10:48:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMT7O-0004xs-00 for ipv6-web-archive@ietf.org; Sat, 08 May 2004 10:47:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMT6P-0004an-00 for ipv6-web-archive@ietf.org; Sat, 08 May 2004 10:46:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMT1d-0007ea-Dx; Sat, 08 May 2004 10:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMT0U-0007X1-O8 for ipv6@optimus.ietf.org; Sat, 08 May 2004 10:40:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06310 for ; Sat, 8 May 2004 10:40:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMT0S-0002Rv-Ak for ipv6@ietf.org; Sat, 08 May 2004 10:40:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMSzf-00026G-00 for ipv6@ietf.org; Sat, 08 May 2004 10:39:59 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BMSyy-0001kg-00 for ipv6@ietf.org; Sat, 08 May 2004 10:39:17 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:9921:cf9:ba50:24c1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 95A521525D; Sat, 8 May 2004 23:39:08 +0900 (JST) Date: Sat, 08 May 2004 23:39:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: ipv6@ietf.org Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) In-Reply-To: <4.3.2.7.2.20040428120350.02ae0f10@flask.cisco.com> References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> <20040428122811.GB7397@login.ecs.soton.ac.uk> <4.3.2.7.2.20040428120350.02ae0f10@flask.cisco.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Wed, 28 Apr 2004 12:16:15 -0400, >>>>> Ralph Droms said: > I think the O flag (if we keep it!) should simply specify DHCPv6, with no > implication about the way in which DHCPv6 is used. > "Stateless DHCPv6" is simply a way to use some of the messages from the full > specification in RFC 3315. RFC 3376 is a guideline to the implementation of > DHCPv6 that uses just Information-request/Reply messages. A client can > choose to use the Request/Reply or the Information-request/Reply message > exchange to obtain other configuration information without address assignment. Before going to further details, please let me clarify one thing about RFC3736 (you should have meant RFC3736 by "RFC 3376" BTW). In my understanding, RFC3736 defines a certain class of implementation that is a subset of RFC3315, even though RFC3736 is basically a "guideline". Specifically, RFC3736 defines the implementation class in its Section 5. So, there can be four types of servers and clients: A. servers that conform to RFC3315. (These servers also conform to RFC3736) B. clients that conform to RFC3315 (These servers also conform to RFC3736) C. servers that only conform to RFC3736 (and do not implement the rest of RFC3315) D. clients that only conform to RFC3736 (and do not implement the rest of RFC3315) Is the above understanding correct? 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 -------------------------------------------------------------------- From exim@www1.ietf.org Sun May 9 00:33:44 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15271 for ; Sun, 9 May 2004 00:33:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMfxG-0004WA-2g for ipv6-archive@odin.ietf.org; Sun, 09 May 2004 00:30:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i494UMav017362 for ipv6-archive@odin.ietf.org; Sun, 9 May 2004 00:30:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMfwS-0004Oo-Qr for ipv6-web-archive@optimus.ietf.org; Sun, 09 May 2004 00:29:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15162 for ; Sun, 9 May 2004 00:29:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMfwQ-0001Br-A7 for ipv6-web-archive@ietf.org; Sun, 09 May 2004 00:29:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMfvd-0000ni-00 for ipv6-web-archive@ietf.org; Sun, 09 May 2004 00:28:42 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BMfuX-0007n3-00 for ipv6-web-archive@ietf.org; Sun, 09 May 2004 00:27:35 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BMffM-00027D-1i for ipv6-web-archive@ietf.org; Sun, 09 May 2004 00:11:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMfag-0006j2-K6; Sun, 09 May 2004 00:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMfZG-0006X4-US for ipv6@optimus.ietf.org; Sun, 09 May 2004 00:05:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14037 for ; Sun, 9 May 2004 00:05:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMfZE-0007In-Ll for ipv6@ietf.org; Sun, 09 May 2004 00:05:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMfXT-0006bQ-00 for ipv6@ietf.org; Sun, 09 May 2004 00:03:44 -0400 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1BMfUa-0005lg-00 for ipv6@ietf.org; Sun, 09 May 2004 00:00:44 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 420482B6 for ; Sun, 9 May 2004 00:00:14 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 09 May 2004 00:00:14 -0400 Message-Id: <20040509040014.420482B6@cyteen.hactrn.net> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.7 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 9.52% | 2 | 10.42% | 11341 | internet-drafts@ietf.org 4.76% | 1 | 9.88% | 10750 | dthaler@windows.microsoft.com 4.76% | 1 | 7.21% | 7850 | volz@cisco.com 4.76% | 1 | 7.12% | 7755 | iesg-secretary@ietf.org 4.76% | 1 | 6.14% | 6680 | ipng@uni-muenster.de 4.76% | 1 | 5.06% | 5505 | paul@etri.re.kr 4.76% | 1 | 4.57% | 4980 | jinmei@isl.rdc.toshiba.co.jp 4.76% | 1 | 4.57% | 4977 | soohong.park@samsung.com 4.76% | 1 | 4.33% | 4718 | john.loughney@nokia.com 4.76% | 1 | 4.32% | 4708 | sra+ipng@hactrn.net 4.76% | 1 | 4.18% | 4552 | jim.bound@hp.com 4.76% | 1 | 4.00% | 4355 | tgleeson@cisco.com 4.76% | 1 | 3.98% | 4335 | girishnk75@yahoo.co.in 4.76% | 1 | 3.81% | 4144 | alper.yegin@samsung.com 4.76% | 1 | 3.76% | 4089 | ftemplin@iprg.nokia.com 4.76% | 1 | 3.43% | 3729 | alain.durand@sun.com 4.76% | 1 | 3.39% | 3692 | brian@innovationslab.net 4.76% | 1 | 3.34% | 3636 | sharkey@zoic.org 4.76% | 1 | 3.34% | 3633 | bob.hinden@nokia.com 4.76% | 1 | 3.15% | 3429 | msa@burp.tkv.asdf.org --------+------+--------+----------+------------------------ 100.00% | 21 |100.00% | 108858 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 10 03:03:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13924 for ; Mon, 10 May 2004 03:03:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN4mf-0007OE-EF for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 03:01:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4A715kJ028400 for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 03:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN4hF-0006zb-Oi for ipv6-web-archive@optimus.ietf.org; Mon, 10 May 2004 02:55:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13602 for ; Mon, 10 May 2004 02:55:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN4hB-0003BP-Uh for ipv6-web-archive@ietf.org; Mon, 10 May 2004 02:55:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN4gC-0002t6-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 02:54:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN4fE-0002b6-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 02:53:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN4XF-0005Ts-CB; Mon, 10 May 2004 02:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN4Rl-0004xD-Rz for ipv6@optimus.ietf.org; Mon, 10 May 2004 02:39:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13003 for ; Mon, 10 May 2004 02:39:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN4Rh-0006JC-A9 for ipv6@ietf.org; Mon, 10 May 2004 02:39:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN4Qh-00061T-00 for ipv6@ietf.org; Mon, 10 May 2004 02:38:24 -0400 Received: from coconut.itojun.org ([221.249.121.227]) by ietf-mx with esmtp (Exim 4.12) id 1BN4Pm-0005kC-00 for ipv6@ietf.org; Mon, 10 May 2004 02:37:26 -0400 Received: by coconut.itojun.org (Postfix, from userid 1001) id F06D83C; Mon, 10 May 2004 15:37:24 +0900 (JST) To: brian@innovationslab.net Cc: ipv6@ietf.org Subject: Re: IPv6 Work Group Last Call for "IPv6 Host to Router Load Sharing" In-Reply-To: Your message of "Fri, 07 May 2004 06:53:15 -0400" <409B6A9B.9080505@innovationslab.net> References: <409B6A9B.9080505@innovationslab.net> X-Mailer: Cue version 0.8 (040507-1428/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040510063724.F06D83C@coconut.itojun.org> Date: Mon, 10 May 2004 15:37:24 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 i have problem understanding the intent of first paragraph of section 2. >When a host chooses from multiple equivalent routers, it SHOULD >support choosing using some method which distributes load for >different destinations among the equivalent routers rather than >always choosing the same router (e.g., the first in the list). >Furthermore, a host that does attempt to distribute load among >routers SHOULD use a hash-based scheme, such as those described in >[MULTIPATH], which takes the destination IP address into account. "SHOULD" on the first line seems way too strong to me, if this text is targetted to random hosts around. the subject of the sentence is not restricted ("a host"), so it seems to me that it includes memory/cpu/whatever-restricted hosts too. i would like to suggest either of the following: - change SHOULD to MAY - clearly state that this text/document applies only for hosts that intentionally support router load balancing/sharing itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 10 12:01:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13010 for ; Mon, 10 May 2004 12:01:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BND6u-0000pE-Cn for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 11:54:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AFsWiw003173 for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 11:54:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCyc-0008Ck-Ow for ipv6-web-archive@optimus.ietf.org; Mon, 10 May 2004 11:45:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12110 for ; Mon, 10 May 2004 11:45:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNCyb-0002BU-NN for ipv6-web-archive@ietf.org; Mon, 10 May 2004 11:45:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNCxf-0001rU-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 11:44:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNCwk-0001YN-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 11:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNChM-0004RD-Sd; Mon, 10 May 2004 11:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCcF-00034k-Fl for ipv6@optimus.ietf.org; Mon, 10 May 2004 11:22:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10890 for ; Mon, 10 May 2004 11:22:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNCcE-0002F6-Bf for ipv6@ietf.org; Mon, 10 May 2004 11:22:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNCbD-0001uR-00 for ipv6@ietf.org; Mon, 10 May 2004 11:21:47 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BNCa9-0001Mr-00 for ipv6@ietf.org; Mon, 10 May 2004 11:20:41 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4AFKe7s007473 for ; Mon, 10 May 2004 16:20:40 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA26884 for ; Mon, 10 May 2004 16:20:39 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4AFKdu25581 for ipv6@ietf.org; Mon, 10 May 2004 16:20:39 +0100 Date: Mon, 10 May 2004 16:20:39 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 Work Group Last Call for "IPv6 Host to Router Load Sharing" Message-ID: <20040510152039.GJ22998@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <409B6A9B.9080505@innovationslab.net> <20040510063724.F06D83C@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040510063724.F06D83C@coconut.itojun.org> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 I agree. This point has been made in previous discussions of the draft... Tim On Mon, May 10, 2004 at 03:37:24PM +0900, Jun-ichiro itojun Hagino wrote: > i have problem understanding the intent of first paragraph of section 2. > > >When a host chooses from multiple equivalent routers, it SHOULD > >support choosing using some method which distributes load for > >different destinations among the equivalent routers rather than > >always choosing the same router (e.g., the first in the list). > >Furthermore, a host that does attempt to distribute load among > >routers SHOULD use a hash-based scheme, such as those described in > >[MULTIPATH], which takes the destination IP address into account. > > "SHOULD" on the first line seems way too strong to me, if this text > is targetted to random hosts around. the subject of the sentence is > not restricted ("a host"), so it seems to me that it includes > memory/cpu/whatever-restricted hosts too. > > i would like to suggest either of the following: > - change SHOULD to MAY > - clearly state that this text/document applies only for hosts that > intentionally support router load balancing/sharing > > itojun > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 10 12:24:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14652 for ; Mon, 10 May 2004 12:24:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNDX8-0007l9-V3 for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 12:21:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AGLcM5029825 for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 12:21:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNDMh-0004df-Ry for ipv6-web-archive@optimus.ietf.org; Mon, 10 May 2004 12:10:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13881 for ; Mon, 10 May 2004 12:10:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNDMg-0002qS-JI for ipv6-web-archive@ietf.org; Mon, 10 May 2004 12:10:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNDLj-0002Xm-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 12:09:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNDKl-0002Ej-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 12:08:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BND7S-00018D-Uy; Mon, 10 May 2004 11:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCwZ-0007uq-7s for ipv6@optimus.ietf.org; Mon, 10 May 2004 11:43:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12036 for ; Mon, 10 May 2004 11:43:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNCwY-0001Wa-52 for ipv6@ietf.org; Mon, 10 May 2004 11:43:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNCvh-0001EC-00 for ipv6@ietf.org; Mon, 10 May 2004 11:42:57 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BNCuv-0000vU-00 for ipv6@ietf.org; Mon, 10 May 2004 11:42:09 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:e50f:5695:7154:69d4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7A34B1525D; Tue, 11 May 2004 00:42:06 +0900 (JST) Date: Tue, 11 May 2004 00:42:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: ipv6@ietf.org Subject: the protocol for the O flag In-Reply-To: References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> <20040428122811.GB7397@login.ecs.soton.ac.uk> <4.3.2.7.2.20040428120350.02ae0f10@flask.cisco.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 (changing the subject) >>>>> On Sat, 08 May 2004 23:39:20 +0900, >>>>> JINMEI Tatuya said: >> I think the O flag (if we keep it!) should simply specify DHCPv6, with no >> implication about the way in which DHCPv6 is used. >> "Stateless DHCPv6" is simply a way to use some of the messages from the full >> specification in RFC 3315. RFC 3376 is a guideline to the implementation of >> DHCPv6 that uses just Information-request/Reply messages. A client can >> choose to use the Request/Reply or the Information-request/Reply message >> exchange to obtain other configuration information without address assignment. > Before going to further details, please let me clarify one thing about > RFC3736 (you should have meant RFC3736 by "RFC 3376" BTW). > In my understanding, RFC3736 defines a certain class of implementation > that is a subset of RFC3315, even though RFC3736 is basically a > "guideline". Specifically, RFC3736 defines the implementation class > in its Section 5. > So, there can be four types of servers and clients: > A. servers that conform to RFC3315. (These servers also conform to > RFC3736) > B. clients that conform to RFC3315 (These servers also conform to ^^^^^^^should be "clients" > RFC3736) > C. servers that only conform to RFC3736 (and do not implement the rest > of RFC3315) > D. clients that only conform to RFC3736 (and do not implement the rest > of RFC3315) > Is the above understanding correct? No responses...so, assuming the understanding is correct, I believe the best protocol for the O flag is the subset of RFC3315 as defined in RFC3736 (aka "stateless DHCPv6"). The rationale is as follows: As long as we need to care about type D clients (which do not support full RFC3315), servers must be configured to enable RFC3736, whether they can also support full RFC3315 or not. But then, I don't see the reason for leaving flexibility by specifying a larger set (i.e., RFC3315) as the protocol for the O flag. If we specify RFC3736 as the protocol, - type A servers will be configured to act as RFC3736 servers (they may also act as full RFC3315 servers, but that doesn't matter here). - type B clients will perform RFC3736 to get the "other" configuration information, as a subset of their full ability. - type C servers will simply act as RFC3736 servers - type D clients will simply act as RFC3736 clients On the other hand, if we just specify RFC3315 as the protocol, we'll be bothered about combination issues. In the following discussion, I'll call other configuration by request/reply exchanges "stateful other configuration". - type A servers will at least need to be configured to enable RFC3736, as explained above. They may or may not enable the rest of RFC3315. - type B clients may perform RFC3736 only, stateful other configuration only, or both. + if the client only tries RFC3736, it will be happy, since type A servers should act as RFC3736 servers (type C servers can of course serve for the client). + if the client only tries stateful other configuration, the configuration will fail when type A servers do not enable stateful other configuration or there are only type C servers. + if the client tries both RFC3736 and stateful other configuration, what happens depends on the ordering. If it first tries RFC3736 or performs both concurrently, it will be happy. If it first tries stateful other configuration, the client can see a long delay before the configuration completes when type A servers do not enable stateful other configuration or there are only type C servers. - type C servers will simply act as RFC3736 servers. If there are type B clients that do not try RFC3736, the servers cannot serve for the clients. - type D clients will simply act as RFC3736 clients. The clients will be happy, since type A servers should act as RFC3736 servers (type C servers can of course serve for the client). As shown above, a type B client can easily get stuck unless it is very carefully configured; to be able to configure itself in all the possible scenarios, the client will need to perform RFC3736 only, tries RFC3736 first (which should succeed), or tries both RFC3736 and stateful other configuration concurrently (at least the former should succeed). Then, why can't we simply specify RFC3736 as the protocol? Meanwhile, leaving the flexibility may make sense if it has a clear advantage comparing to specify RFC3736 clearly. Regarding other configuration information, however, I don't see such an advantage that outweighs the complexity shown above. Comments? 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 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 10 13:17:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17979 for ; Mon, 10 May 2004 13:17:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEHq-0007oy-Of for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 13:09:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AH9sfx030052 for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 13:09:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNECA-0006QJ-4o for ipv6-web-archive@optimus.ietf.org; Mon, 10 May 2004 13:04:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17208 for ; Mon, 10 May 2004 13:03:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNEC8-00064w-Ce for ipv6-web-archive@ietf.org; Mon, 10 May 2004 13:04:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEB8-0005kY-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 13:02:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNEAK-0005Qv-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 13:02:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNE1W-0004h1-FJ; Mon, 10 May 2004 12:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNDqy-00038C-Vu for ipv6@optimus.ietf.org; Mon, 10 May 2004 12:42:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16177 for ; Mon, 10 May 2004 12:42:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNDqx-0006Xp-Cs for ipv6@ietf.org; Mon, 10 May 2004 12:42:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNDpz-0006D2-00 for ipv6@ietf.org; Mon, 10 May 2004 12:41:08 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BNDpR-0005pr-00 for ipv6@ietf.org; Mon, 10 May 2004 12:40:33 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 10 May 2004 08:44:07 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4AGduSw024441; Mon, 10 May 2004 09:40:01 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIG77442; Mon, 10 May 2004 12:39:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20040510122602.02ec1e40@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 May 2004 12:39:53 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: the protocol for the O flag Cc: ipv6@ietf.org In-Reply-To: References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> <20040428122811.GB7397@login.ecs.soton.ac.uk> <4.3.2.7.2.20040428120350.02ae0f10@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Yes, your original analysis is correct... Seems like the protocol associated with the 'O' bit should be RFC 3736; there is no particular advantage to using the 4 message exchange of RFC 3315 for "other configuration information". The only potential advantage would be if there is ever a need for "other configuration information" that needs atateful assignment; we've never found a need for such assignment in DHCPv4. Although exactly where prefix delegation falls is a little unclear... - Ralph At 12:42 AM 5/11/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >(changing the subject) > > >>>>> On Sat, 08 May 2004 23:39:20 +0900, > >>>>> JINMEI Tatuya said: > > >> I think the O flag (if we keep it!) should simply specify DHCPv6, with no > >> implication about the way in which DHCPv6 is used. > > >> "Stateless DHCPv6" is simply a way to use some of the messages from > the full > >> specification in RFC 3315. RFC 3376 is a guideline to the > implementation of > >> DHCPv6 that uses just Information-request/Reply messages. A client can > >> choose to use the Request/Reply or the Information-request/Reply message > >> exchange to obtain other configuration information without address > assignment. > > > Before going to further details, please let me clarify one thing about > > RFC3736 (you should have meant RFC3736 by "RFC 3376" BTW). > > > In my understanding, RFC3736 defines a certain class of implementation > > that is a subset of RFC3315, even though RFC3736 is basically a > > "guideline". Specifically, RFC3736 defines the implementation class > > in its Section 5. > > > So, there can be four types of servers and clients: > > > A. servers that conform to RFC3315. (These servers also conform to > > RFC3736) > > B. clients that conform to RFC3315 (These servers also conform to > ^^^^^^^should be "clients" > > RFC3736) > > C. servers that only conform to RFC3736 (and do not implement the rest > > of RFC3315) > > D. clients that only conform to RFC3736 (and do not implement the rest > > of RFC3315) > > > Is the above understanding correct? > >No responses...so, assuming the understanding is correct, I believe >the best protocol for the O flag is the subset of RFC3315 as defined in >RFC3736 (aka "stateless DHCPv6"). The rationale is as follows: > >As long as we need to care about type D clients (which do not support >full RFC3315), servers must be configured to enable RFC3736, whether >they can also support full RFC3315 or not. > >But then, I don't see the reason for leaving flexibility by specifying >a larger set (i.e., RFC3315) as the protocol for the O flag. > >If we specify RFC3736 as the protocol, > >- type A servers will be configured to act as RFC3736 servers (they > may also act as full RFC3315 servers, but that doesn't matter here). >- type B clients will perform RFC3736 to get the "other" configuration > information, as a subset of their full ability. >- type C servers will simply act as RFC3736 servers >- type D clients will simply act as RFC3736 clients > >On the other hand, if we just specify RFC3315 as the protocol, we'll >be bothered about combination issues. In the following discussion, >I'll call other configuration by request/reply exchanges "stateful >other configuration". > >- type A servers will at least need to be configured to enable > RFC3736, as explained above. They may or may not enable the rest of > RFC3315. >- type B clients may perform RFC3736 only, stateful other > configuration only, or both. > + if the client only tries RFC3736, it will be happy, since type A > servers should act as RFC3736 servers (type C servers can of > course serve for the client). > + if the client only tries stateful other configuration, the > configuration will fail when type A servers do not enable stateful > other configuration or there are only type C servers. > + if the client tries both RFC3736 and stateful other configuration, > what happens depends on the ordering. If it first tries RFC3736 > or performs both concurrently, it will be happy. If it first > tries stateful other configuration, the client can see a long > delay before the configuration completes when type A servers do > not enable stateful other configuration or there are only type C > servers. >- type C servers will simply act as RFC3736 servers. If there are > type B clients that do not try RFC3736, the servers cannot serve for > the clients. >- type D clients will simply act as RFC3736 clients. The clients will > be happy, since type A servers should act as RFC3736 servers (type C > servers can of course serve for the client). > >As shown above, a type B client can easily get stuck unless it is very >carefully configured; to be able to configure itself in all the >possible scenarios, the client will need to perform RFC3736 only, >tries RFC3736 first (which should succeed), or tries both RFC3736 and >stateful other configuration concurrently (at least the former should >succeed). Then, why can't we simply specify RFC3736 as the protocol? > >Meanwhile, leaving the flexibility may make sense if it has a clear >advantage comparing to specify RFC3736 clearly. Regarding other >configuration information, however, I don't see such an advantage that >outweighs the complexity shown above. > >Comments? > > 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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 10 13:20:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18145 for ; Mon, 10 May 2004 13:20:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEP5-0000SY-R0 for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 13:17:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AHHN1n001761 for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 13:17:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEHs-0007pf-Ep for ipv6-web-archive@optimus.ietf.org; Mon, 10 May 2004 13:09:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17490 for ; Mon, 10 May 2004 13:09:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNEHq-0000Fw-K0 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 13:09:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEGq-0007hV-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 13:08:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNEFz-0007N8-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 13:07:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNE4Q-00053K-JW; Mon, 10 May 2004 12:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNDwd-0003k4-81 for ipv6@optimus.ietf.org; Mon, 10 May 2004 12:47:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16427 for ; Mon, 10 May 2004 12:47:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNDwb-0000iS-Jg for ipv6@ietf.org; Mon, 10 May 2004 12:47:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNDve-0000O1-00 for ipv6@ietf.org; Mon, 10 May 2004 12:46:59 -0400 Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx with esmtp (Exim 4.12) id 1BNDui-0007XO-00 for ipv6@ietf.org; Mon, 10 May 2004 12:46:01 -0400 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id i4AGkMt02789; Mon, 10 May 2004 09:46:22 -0700 (PDT) Received: from feller (feller [192.88.122.144]) by leo.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id i4AGkMX18086; Mon, 10 May 2004 09:46:22 -0700 (PDT) Subject: Re: IPv6 Work Group Last Call for "IPv6 Host to Router Load Sharing" From: Tim Hartrick Reply-To: tim@mentat.com To: Tim Chown Cc: ipv6@ietf.org In-Reply-To: <20040510152039.GJ22998@login.ecs.soton.ac.uk> References: <409B6A9B.9080505@innovationslab.net> <20040510063724.F06D83C@coconut.itojun.org> <20040510152039.GJ22998@login.ecs.soton.ac.uk> Content-Type: text/plain Organization: Mentat Inc. Message-Id: <1084211153.4005.4.camel@feller> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 10 May 2004 10:45:53 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2004-05-10 at 08:20, Tim Chown wrote: > I agree. This point has been made in previous discussions of the draft... I agree as well. There are environments where load balancing is desirable and environments where is is not desirable. MAY is the right word for this circumstance. tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 10 13:39:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19224 for ; Mon, 10 May 2004 13:39:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEjL-0003bM-ON for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 13:38:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AHcJMn013837 for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 13:38:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEhQ-00032c-Kx for ipv6-web-archive@optimus.ietf.org; Mon, 10 May 2004 13:36:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19052 for ; Mon, 10 May 2004 13:36:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNEhO-0001Ua-Hf for ipv6-web-archive@ietf.org; Mon, 10 May 2004 13:36:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEgf-000190-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 13:35:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNEfX-0000lP-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 13:34:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEaM-0001q9-Lb; Mon, 10 May 2004 13:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNETW-00018c-4j for ipv6@optimus.ietf.org; Mon, 10 May 2004 13:21:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18302 for ; Mon, 10 May 2004 13:21:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNETU-0004NI-2u for ipv6@ietf.org; Mon, 10 May 2004 13:21:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEST-000428-00 for ipv6@ietf.org; Mon, 10 May 2004 13:20:54 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BNERW-0003No-00 for ipv6@ietf.org; Mon, 10 May 2004 13:19:54 -0400 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 10 May 2004 10:19:10 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 10 May 2004 10:19:26 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 May 2004 10:19:22 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 10 May 2004 10:19:19 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 10 May 2004 10:19:21 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 10 May 2004 10:19:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: the protocol for the O flag Date: Mon, 10 May 2004 10:19:20 -0700 Message-ID: Thread-Topic: the protocol for the O flag Thread-Index: AcQ2sH12EMYM81UuQVW9Tt/QmDNd0QAAiSiQ From: "Christian Huitema" To: "Ralph Droms" , =?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Cc: X-OriginalArrivalTime: 10 May 2004 17:19:54.0919 (UTC) FILETIME=[02EA9370:01C436B3] Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Prefix delegation is a somewhat different animal than your average DHCP lookup. It only makes sense in routers, not hosts. In fact, it is unclear whether the DHCP server for prefix delegation should be the same as the DHCP server for DNS configuration. I think we should leave prefix delegation out of this discussion. > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Ralph > Droms > Sent: Monday, May 10, 2004 9:40 AM > To: JINMEI Tatuya / $B?@L@C#:H(J > Cc: ipv6@ietf.org > Subject: Re: the protocol for the O flag > > Yes, your original analysis is correct... > > Seems like the protocol associated with the 'O' bit should be RFC 3736; > there is no particular advantage to using the 4 message exchange of RFC > 3315 > for "other configuration information". The only potential advantage would > be if there is ever a need for "other configuration information" that > needs > atateful assignment; we've never found a need for such assignment in > DHCPv4. > > Although exactly where prefix delegation falls is a little unclear... > > - Ralph > > At 12:42 AM 5/11/2004 +0900, JINMEI Tatuya / > =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >(changing the subject) > > > > >>>>> On Sat, 08 May 2004 23:39:20 +0900, > > >>>>> JINMEI Tatuya said: > > > > >> I think the O flag (if we keep it!) should simply specify DHCPv6, > with no > > >> implication about the way in which DHCPv6 is used. > > > > >> "Stateless DHCPv6" is simply a way to use some of the messages from > > the full > > >> specification in RFC 3315. RFC 3376 is a guideline to the > > implementation of > > >> DHCPv6 that uses just Information-request/Reply messages. A client > can > > >> choose to use the Request/Reply or the Information-request/Reply > message > > >> exchange to obtain other configuration information without address > > assignment. > > > > > Before going to further details, please let me clarify one thing about > > > RFC3736 (you should have meant RFC3736 by "RFC 3376" BTW). > > > > > In my understanding, RFC3736 defines a certain class of implementation > > > that is a subset of RFC3315, even though RFC3736 is basically a > > > "guideline". Specifically, RFC3736 defines the implementation class > > > in its Section 5. > > > > > So, there can be four types of servers and clients: > > > > > A. servers that conform to RFC3315. (These servers also conform to > > > RFC3736) > > > B. clients that conform to RFC3315 (These servers also conform to > > ^^^^^^^should be "clients" > > > RFC3736) > > > C. servers that only conform to RFC3736 (and do not implement the rest > > > of RFC3315) > > > D. clients that only conform to RFC3736 (and do not implement the rest > > > of RFC3315) > > > > > Is the above understanding correct? > > > >No responses...so, assuming the understanding is correct, I believe > >the best protocol for the O flag is the subset of RFC3315 as defined in > >RFC3736 (aka "stateless DHCPv6"). The rationale is as follows: > > > >As long as we need to care about type D clients (which do not support > >full RFC3315), servers must be configured to enable RFC3736, whether > >they can also support full RFC3315 or not. > > > >But then, I don't see the reason for leaving flexibility by specifying > >a larger set (i.e., RFC3315) as the protocol for the O flag. > > > >If we specify RFC3736 as the protocol, > > > >- type A servers will be configured to act as RFC3736 servers (they > > may also act as full RFC3315 servers, but that doesn't matter here). > >- type B clients will perform RFC3736 to get the "other" configuration > > information, as a subset of their full ability. > >- type C servers will simply act as RFC3736 servers > >- type D clients will simply act as RFC3736 clients > > > >On the other hand, if we just specify RFC3315 as the protocol, we'll > >be bothered about combination issues. In the following discussion, > >I'll call other configuration by request/reply exchanges "stateful > >other configuration". > > > >- type A servers will at least need to be configured to enable > > RFC3736, as explained above. They may or may not enable the rest of > > RFC3315. > >- type B clients may perform RFC3736 only, stateful other > > configuration only, or both. > > + if the client only tries RFC3736, it will be happy, since type A > > servers should act as RFC3736 servers (type C servers can of > > course serve for the client). > > + if the client only tries stateful other configuration, the > > configuration will fail when type A servers do not enable stateful > > other configuration or there are only type C servers. > > + if the client tries both RFC3736 and stateful other configuration, > > what happens depends on the ordering. If it first tries RFC3736 > > or performs both concurrently, it will be happy. If it first > > tries stateful other configuration, the client can see a long > > delay before the configuration completes when type A servers do > > not enable stateful other configuration or there are only type C > > servers. > >- type C servers will simply act as RFC3736 servers. If there are > > type B clients that do not try RFC3736, the servers cannot serve for > > the clients. > >- type D clients will simply act as RFC3736 clients. The clients will > > be happy, since type A servers should act as RFC3736 servers (type C > > servers can of course serve for the client). > > > >As shown above, a type B client can easily get stuck unless it is very > >carefully configured; to be able to configure itself in all the > >possible scenarios, the client will need to perform RFC3736 only, > >tries RFC3736 first (which should succeed), or tries both RFC3736 and > >stateful other configuration concurrently (at least the former should > >succeed). Then, why can't we simply specify RFC3736 as the protocol? > > > >Meanwhile, leaving the flexibility may make sense if it has a clear > >advantage comparing to specify RFC3736 clearly. Regarding other > >configuration information, however, I don't see such an advantage that > >outweighs the complexity shown above. > > > >Comments? > > > > 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 > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 10 16:06:52 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00307 for ; Mon, 10 May 2004 16:06:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNH1D-0000IQ-NS for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 16:04:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AK4tNi001138 for ipv6-archive@odin.ietf.org; Mon, 10 May 2004 16:04:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNGsl-0006pb-48 for ipv6-web-archive@optimus.ietf.org; Mon, 10 May 2004 15:56:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29701 for ; Mon, 10 May 2004 15:56:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNGsj-0003zp-Jf for ipv6-web-archive@ietf.org; Mon, 10 May 2004 15:56:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNGrp-0003fl-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 15:55:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNGrN-0003L9-00 for ipv6-web-archive@ietf.org; Mon, 10 May 2004 15:54:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNGmo-0005dB-C4; Mon, 10 May 2004 15:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNGeC-0004DQ-9x for ipv6@optimus.ietf.org; Mon, 10 May 2004 15:41:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28524 for ; Mon, 10 May 2004 15:41:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNGeA-0006K8-Sh for ipv6@ietf.org; Mon, 10 May 2004 15:41:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNGd9-0005ws-00 for ipv6@ietf.org; Mon, 10 May 2004 15:40:04 -0400 Received: from evrtwa1-ar11-4.14.89.229.evrtwa1.dsl-verizon.net ([4.14.89.229] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1BNGc9-0005Wa-00 for ipv6@ietf.org; Mon, 10 May 2004 15:39:01 -0400 Received: from eaglet (127.0.0.1:3504) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Mon, 10 May 2004 12:38:57 -0700 From: "Tony Hain" To: "'Christian Huitema'" , "'Ralph Droms'" , "'JINMEI Tatuya / ????'" Cc: Subject: RE: the protocol for the O flag Date: Mon, 10 May 2004 12:38:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQ2sH12EMYM81UuQVW9Tt/QmDNd0QAAiSiQAASyTVA= Message-Id: Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Actually there is an operational simplicity case to be made for hosts doing PD. In the scenario where the ISP wants to provide a 1:1 mapping between customer & prefix, but the customer hasn't acquired a router yet. This can be done with discrete RAs when customers are on independent interfaces, but on shared media (HFC) there would need to be a hack to RAs to unicast them, or host based PD. Tony > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of > Christian Huitema > Sent: Monday, May 10, 2004 10:19 AM > To: Ralph Droms; JINMEI Tatuya / ???? > Cc: ipv6@ietf.org > Subject: RE: the protocol for the O flag > > Prefix delegation is a somewhat different animal than your average DHCP > lookup. It only makes sense in routers, not hosts. In fact, it is unclear > whether the DHCP server for prefix delegation should be the same as the > DHCP server for DNS configuration. I think we should leave prefix > delegation out of this discussion. > > > -----Original Message----- > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of > Ralph > > Droms > > Sent: Monday, May 10, 2004 9:40 AM > > To: JINMEI Tatuya / $B?@L@C#:H(B > > Cc: ipv6@ietf.org > > Subject: Re: the protocol for the O flag > > > > Yes, your original analysis is correct... > > > > Seems like the protocol associated with the 'O' bit should be RFC 3736; > > there is no particular advantage to using the 4 message exchange of RFC > > 3315 > > for "other configuration information". The only potential advantage > would > > be if there is ever a need for "other configuration information" that > > needs > > atateful assignment; we've never found a need for such assignment in > > DHCPv4. > > > > Although exactly where prefix delegation falls is a little unclear... > > > > - Ralph > > > > At 12:42 AM 5/11/2004 +0900, JINMEI Tatuya / > > =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > > >(changing the subject) > > > > > > >>>>> On Sat, 08 May 2004 23:39:20 +0900, > > > >>>>> JINMEI Tatuya said: > > > > > > >> I think the O flag (if we keep it!) should simply specify DHCPv6, > > with no > > > >> implication about the way in which DHCPv6 is used. > > > > > > >> "Stateless DHCPv6" is simply a way to use some of the messages from > > > the full > > > >> specification in RFC 3315. RFC 3376 is a guideline to the > > > implementation of > > > >> DHCPv6 that uses just Information-request/Reply messages. A client > > can > > > >> choose to use the Request/Reply or the Information-request/Reply > > message > > > >> exchange to obtain other configuration information without address > > > assignment. > > > > > > > Before going to further details, please let me clarify one thing > about > > > > RFC3736 (you should have meant RFC3736 by "RFC 3376" BTW). > > > > > > > In my understanding, RFC3736 defines a certain class of > implementation > > > > that is a subset of RFC3315, even though RFC3736 is basically a > > > > "guideline". Specifically, RFC3736 defines the implementation class > > > > in its Section 5. > > > > > > > So, there can be four types of servers and clients: > > > > > > > A. servers that conform to RFC3315. (These servers also conform to > > > > RFC3736) > > > > B. clients that conform to RFC3315 (These servers also conform to > > > ^^^^^^^should be > "clients" > > > > RFC3736) > > > > C. servers that only conform to RFC3736 (and do not implement the > rest > > > > of RFC3315) > > > > D. clients that only conform to RFC3736 (and do not implement the > rest > > > > of RFC3315) > > > > > > > Is the above understanding correct? > > > > > >No responses...so, assuming the understanding is correct, I believe > > >the best protocol for the O flag is the subset of RFC3315 as defined in > > >RFC3736 (aka "stateless DHCPv6"). The rationale is as follows: > > > > > >As long as we need to care about type D clients (which do not support > > >full RFC3315), servers must be configured to enable RFC3736, whether > > >they can also support full RFC3315 or not. > > > > > >But then, I don't see the reason for leaving flexibility by specifying > > >a larger set (i.e., RFC3315) as the protocol for the O flag. > > > > > >If we specify RFC3736 as the protocol, > > > > > >- type A servers will be configured to act as RFC3736 servers (they > > > may also act as full RFC3315 servers, but that doesn't matter here). > > >- type B clients will perform RFC3736 to get the "other" configuration > > > information, as a subset of their full ability. > > >- type C servers will simply act as RFC3736 servers > > >- type D clients will simply act as RFC3736 clients > > > > > >On the other hand, if we just specify RFC3315 as the protocol, we'll > > >be bothered about combination issues. In the following discussion, > > >I'll call other configuration by request/reply exchanges "stateful > > >other configuration". > > > > > >- type A servers will at least need to be configured to enable > > > RFC3736, as explained above. They may or may not enable the rest of > > > RFC3315. > > >- type B clients may perform RFC3736 only, stateful other > > > configuration only, or both. > > > + if the client only tries RFC3736, it will be happy, since type A > > > servers should act as RFC3736 servers (type C servers can of > > > course serve for the client). > > > + if the client only tries stateful other configuration, the > > > configuration will fail when type A servers do not enable stateful > > > other configuration or there are only type C servers. > > > + if the client tries both RFC3736 and stateful other configuration, > > > what happens depends on the ordering. If it first tries RFC3736 > > > or performs both concurrently, it will be happy. If it first > > > tries stateful other configuration, the client can see a long > > > delay before the configuration completes when type A servers do > > > not enable stateful other configuration or there are only type C > > > servers. > > >- type C servers will simply act as RFC3736 servers. If there are > > > type B clients that do not try RFC3736, the servers cannot serve for > > > the clients. > > >- type D clients will simply act as RFC3736 clients. The clients will > > > be happy, since type A servers should act as RFC3736 servers (type C > > > servers can of course serve for the client). > > > > > >As shown above, a type B client can easily get stuck unless it is very > > >carefully configured; to be able to configure itself in all the > > >possible scenarios, the client will need to perform RFC3736 only, > > >tries RFC3736 first (which should succeed), or tries both RFC3736 and > > >stateful other configuration concurrently (at least the former should > > >succeed). Then, why can't we simply specify RFC3736 as the protocol? > > > > > >Meanwhile, leaving the flexibility may make sense if it has a clear > > >advantage comparing to specify RFC3736 clearly. Regarding other > > >configuration information, however, I don't see such an advantage that > > >outweighs the complexity shown above. > > > > > >Comments? > > > > > > 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 > > >-------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 11 04:31:04 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11729 for ; Tue, 11 May 2004 04:31:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNSNh-0007hl-7u for ipv6-archive@odin.ietf.org; Tue, 11 May 2004 04:12:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B8CrSY029618 for ipv6-archive@odin.ietf.org; Tue, 11 May 2004 04:12:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNSLX-0006cm-Kz for ipv6-web-archive@optimus.ietf.org; Tue, 11 May 2004 04:10:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10434 for ; Tue, 11 May 2004 04:10:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNSLU-0007X9-TY for ipv6-web-archive@ietf.org; Tue, 11 May 2004 04:10:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNSKl-0007Ac-00 for ipv6-web-archive@ietf.org; Tue, 11 May 2004 04:09:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNSK6-0006n7-00 for ipv6-web-archive@ietf.org; Tue, 11 May 2004 04:09:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNS0q-0001Bu-65; Tue, 11 May 2004 03:49:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNRvL-00083N-UE for ipv6@optimus.ietf.org; Tue, 11 May 2004 03:43:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09059 for ; Tue, 11 May 2004 03:43:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNRvI-00051q-Pw for ipv6@ietf.org; Tue, 11 May 2004 03:43:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNRuI-0004f2-00 for ipv6@ietf.org; Tue, 11 May 2004 03:42:31 -0400 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1BNRtJ-0003wh-00 for ipv6@ietf.org; Tue, 11 May 2004 03:41:29 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i4B7eko8017968; Tue, 11 May 2004 09:40:46 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i4B7ejZn013795; Tue, 11 May 2004 09:40:45 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 11 May 2004 09:40:45 +0200 From: Stig Venaas To: Ralph Droms Cc: "JINMEI Tatuya / ?$B?@L@C#:H" , ipv6@ietf.org Subject: Re: the protocol for the O flag Message-ID: <20040511074045.GB13755@sverresborg.uninett.no> References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> <20040428122811.GB7397@login.ecs.soton.ac.uk> <4.3.2.7.2.20040428120350.02ae0f10@flask.cisco.com> <4.3.2.7.2.20040510122602.02ec1e40@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20040510122602.02ec1e40@flask.cisco.com> User-Agent: Mutt/1.4.1i 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 On Mon, May 10, 2004 at 12:39:53PM -0400, Ralph Droms wrote: > Yes, your original analysis is correct... > > Seems like the protocol associated with the 'O' bit should be RFC 3736; > there is no particular advantage to using the 4 message exchange of RFC 3315 > for "other configuration information". The only potential advantage would > be if there is ever a need for "other configuration information" that needs > atateful assignment; we've never found a need for such assignment in DHCPv4. I wouldn't rule this out completely. I think normally RFC 3736 will be the reasonable thing to do. But if client for some reason wants some stateful info it could still try to use RFC 3315 I think. Just as examples, you could imagine client using RFC 3315 to get an IPv4 address or IPv6 multicast address. Or it could be none-address resources. Note that I don't really want to discuss the need for IPv4 or multicast address assignment here. But I'm not sure one should say that client always must stick to the RFC 3736 subset. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 11 05:20:00 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14043 for ; Tue, 11 May 2004 05:19:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNTFJ-00043j-Ve for ipv6-archive@odin.ietf.org; Tue, 11 May 2004 05:08:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B98HWt015566 for ipv6-archive@odin.ietf.org; Tue, 11 May 2004 05:08:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNT3A-000120-9r for ipv6-web-archive@optimus.ietf.org; Tue, 11 May 2004 04:55:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13015 for ; Tue, 11 May 2004 04:55:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNT37-0001Ah-7j for ipv6-web-archive@ietf.org; Tue, 11 May 2004 04:55:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNT27-0000lm-00 for ipv6-web-archive@ietf.org; Tue, 11 May 2004 04:54:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNT19-0000M4-00 for ipv6-web-archive@ietf.org; Tue, 11 May 2004 04:53:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNSmA-00055N-Dg; Tue, 11 May 2004 04:38:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNSTK-0001HW-Ni for ipv6@optimus.ietf.org; Tue, 11 May 2004 04:18:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10831 for ; Tue, 11 May 2004 04:18:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNSTI-0002pG-03 for ipv6@ietf.org; Tue, 11 May 2004 04:18:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNSSK-0002S4-00 for ipv6@ietf.org; Tue, 11 May 2004 04:17:41 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx with esmtp (Exim 4.12) id 1BNSRg-00021w-00 for ipv6@ietf.org; Tue, 11 May 2004 04:17:00 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4B8GTYO149244; Tue, 11 May 2004 08:16:29 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4B8GSTo155028; Tue, 11 May 2004 10:16:29 +0200 Received: from zurich.ibm.com (sig-9-145-228-8.de.ibm.com [9.145.228.8]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA41230; Tue, 11 May 2004 10:16:25 +0200 Message-ID: <40A08BE2.1000806@zurich.ibm.com> Date: Tue, 11 May 2004 10:16:34 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Alper Yegin CC: ipv6@ietf.org Subject: Re: ND-proxy applicability and loop-prevention References: <017b01c433c8$d84a4bc0$991d9069@sisa.samsung.com> In-Reply-To: <017b01c433c8$d84a4bc0$991d9069@sisa.samsung.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alper Yegin wrote: >>There was some discussion of this general concept (zero-configuration >>routing and/or layer 3 bridging) in the Zerouter BOF and on the >>zerouter mailing list... Does anyone know if that effort is still >>active? > > > http://www.ietf.org/internet-drafts/draft-perlman-rbridge-00.txt > >>From abstract: > > This document is a work in progress; we invite you to participate on > the rbridge mailing list at http://www.postel.org/rbridge > > Alper On the other hand, > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026 except that the right to > produce derivative works is not granted. So the IETF can't really do much with it. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 11 05:20:26 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14082 for ; Tue, 11 May 2004 05:20:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNTFY-0004EY-TB for ipv6-archive@odin.ietf.org; Tue, 11 May 2004 05:08:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B98ULa016177 for ipv6-archive@odin.ietf.org; Tue, 11 May 2004 05:08:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNT8C-00023I-Dj for ipv6-web-archive@optimus.ietf.org; Tue, 11 May 2004 05:00:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13298 for ; Tue, 11 May 2004 05:00:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNT7z-00036E-0E for ipv6-web-archive@ietf.org; Tue, 11 May 2004 05:00:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNT76-0002iz-00 for ipv6-web-archive@ietf.org; Tue, 11 May 2004 04:59:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNT6C-0002Lt-00 for ipv6-web-archive@ietf.org; Tue, 11 May 2004 04:58:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNSn5-0005Wl-GK; Tue, 11 May 2004 04:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNSaw-0002XZ-8j for ipv6@optimus.ietf.org; Tue, 11 May 2004 04:26:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11543 for ; Tue, 11 May 2004 04:26:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNSat-00060q-Eb for ipv6@ietf.org; Tue, 11 May 2004 04:26:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNSZw-0005dj-00 for ipv6@ietf.org; Tue, 11 May 2004 04:25:32 -0400 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1BNSYz-0005GY-00 for ipv6@ietf.org; Tue, 11 May 2004 04:24:33 -0400 Received: from [IPv6:2001:638:500:200:20a:95ff:feb3:dd4] ([IPv6:2001:638:500:200:20a:95ff:feb3:dd4]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.11/8.12.9) with ESMTP id i4B8ONSZ023097 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 11 May 2004 10:24:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <20040511074045.GB13755@sverresborg.uninett.no> References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> <20040428122811.GB7397@login.ecs.soton.ac.uk> <4.3.2.7.2.20040428120350.02ae0f10@flask.cisco.com> <4.3.2.7.2.20040510122602.02ec1e40@flask.cisco.com> <20040511074045.GB13755@sverresborg.uninett.no> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Christian Strauf Subject: Re: the protocol for the O flag Date: Tue, 11 May 2004 10:24:57 +0200 To: ipv6@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I wouldn't rule this out completely. I think normally RFC 3736 will be > the reasonable thing to do. But if client for some reason wants some > stateful info it could still try to use RFC 3315 I think. The problem is that if a clients tries stateful DHCPv6 by sending an IA option with the request while the server doesn't accept stateful DHCPv6 (NoAddrsAvail), the exchange will fail and not even information options will be sent -- see parallel thread. In that case, the client MUST fall back to stateless exchanges if it wants to request information options. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 11 06:12:22 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16520 for ; Tue, 11 May 2004 06:12:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNU4Q-0006ch-LQ for ipv6-archive@odin.ietf.org; Tue, 11 May 2004 06:01:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BA16GI025457 for ipv6-archive@odin.ietf.org; Tue, 11 May 2004 06:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNU1M-0005cM-Po for ipv6-web-archive@optimus.ietf.org; Tue, 11 May 2004 05:57:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15668 for ; Tue, 11 May 2004 05:57:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNU1J-0000LF-6n for ipv6-web-archive@ietf.org; Tue, 11 May 2004 05:57:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNU0H-0007kr-00 for ipv6-web-archive@ietf.org; Tue, 11 May 2004 05:56:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNTzQ-0007Nj-00 for ipv6-web-archive@ietf.org; Tue, 11 May 2004 05:55:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNTm5-000307-2d; Tue, 11 May 2004 05:42:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNTii-0001j2-3G for ipv6@optimus.ietf.org; Tue, 11 May 2004 05:38:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14905 for ; Tue, 11 May 2004 05:38:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNTie-0001eh-Fb for ipv6@ietf.org; Tue, 11 May 2004 05:38:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNThe-0001IA-00 for ipv6@ietf.org; Tue, 11 May 2004 05:37:35 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BNTgc-0000as-00 for ipv6@ietf.org; Tue, 11 May 2004 05:36:31 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4B9Zxb18344; Tue, 11 May 2004 12:35:59 +0300 Date: Tue, 11 May 2004 12:35:59 +0300 (EEST) From: Pekka Savola To: Dave Thaler cc: ipv6@ietf.org Subject: RE: I-D ACTION:draft-ietf-ipv6-host-load-sharing-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Coming back to the old thread, sorry for not responding earlier.. Also comments regarding the SHOULD/MUST/MAY debate below. I think we should be first clearer to _what_ we're putting on these keywords. On Thu, 6 May 2004, Dave Thaler wrote: > Pekka Savola wrote: > > So, I'd propose that this document does not describe that the hosts > > MUST share the load, but rather describes how the hosts MUST behave if > > they wish to share the load > > To summarize the other discussion on the list on this topic: > A number of other folks (Changming Liu, Tim Chown, and Suresh Satapati) > also argued on the list against the MUST, while others (such as Bob > Hinden) have argued for it on and off the list. > > In draft-02, I have changed the MUST to a SHOULD as a result. I'm still having the difficulty in understanding the paragraph: ========= When a host chooses from multiple equivalent routers, it SHOULD support choosing using some method which distributes load for different destinations among the equivalent routers rather than always choosing the same router (e.g., the first in the list). Furthermore, a host that does attempt to distribute load among routers SHOULD use a hash-based scheme, such as those described in [MULTIPATH], which takes the destination IP address into account. ========= .. this seems to say, in essence: 1) "you SHOULD implement host load sharing, whether you turn it on is out of scope", and 2) "even if you choose not to share the load, you SHOULD use a hash-based scheme". 2.b) ".. and the hash-based scheme should take dest IP into account" If the intent if 1) is that and not "you SHOULD turn on load sharing", it's fine but could maybe be clarified by adding e.g. the following after the first sentence: This memo takes no stance on whether the support for load sharing should be turned on or off by default. As for 2), it took a while to figure out _where_ to use hash-based scheme would be used. I think it would be better to add a note about a tie-breaker this to e.g.: Furthermore, a host that does attempt to distribute load among routers SHOULD use a hash-based scheme for choosing a single router to be used, [...] As for 2.b), it seems if you take destination IP address into account and require hash-based mechanism, you're just creating the same kind of load sharing. For tie-breaking purposes, it's unnecessary to consider the destination address, right? So, I'd suggest removing the ", which .." -part from the end of the last sentence. > > substantial > > ----------- > > > > [ND] does not require any particular behavior in this respect. It > > specifies that an implementation may always choose the same router > > (e.g., the first in the list) or may cycle through the routers in a > > round-robin manner. Both of these suggestions are problematic. > > > > Clearly, always choosing the same router does not provide load > > sharing. Some problems with naive tie-breaking techniques such as > > round-robin and random are discussed in [MULTIPATH]. While the > > destination cache provides some stability since the determination is > > not per-packet, cache evictions or timeouts can still result in > > unstable or unpredictable paths over time, lowering the performance > > and making it harder to diagnose problems. Round- robin selection may > > also result in synchronization issues among hosts, where in the worst > > case the load is concentrated on one router at a time. > > > > ==> I don't think this document clearly described both of the above > > suggestion (1st paragraph): but rather how round-robin and random have > > issues. That is, it does not cleatly describe why choosing the same > > router is undesirable. > > Clarfied by changing second sentence to > | Some problems with load sharing using naive tie-breaking techniques > | such as round-robin and random are discussed in [MULTIPATH]. This only addresses one part of my comment (sorry, should have been clearer). It still does not state why exactly the load-sharing is desirable in the first place, and what are the reasons why it might not be desirable. Suggestion: reword: It is typically desirable when there is more than one equivalent router that hosts distribute their outgoing traffic among these routers. This shares the load among multiple routers and provides better performance for the host's traffic. to something like: It is typically desirable when there is more than one equivalent router that hosts distribute their outgoing traffic among these routers. This shares the load among multiple routers and provides better performance for the host's traffic. On the other hand, the load sharing can be undesirable in the situations where sufficient capacity is available through a single router and the traffic patterns could be more predictable by using a single router; in particular, this helps to diagnose connectivity problems upstream from the first-hop routers. .. this gives a more balanced view of the need for load sharing. > > As mentioned in [MULTIPATH], when next-hop selection is predictable, > > an application can synthesize traffic that will all hash the same, > > making it possible to launch a denial-of-service attack against the > > load sharing algorithm, and overload a particular router. A special > > case of this is when the same > > (single) next-hop is always selected, such as in the algorithm allowed > > by [ND]. Introducing hashing can make such an attack more difficult; > > the more unpredictable the hash is, the harder it becomes to conduct a > > denial-of-service attack against any single router. > > > > ==> these threats appear to have no clear threat model. What's the > > point of such an attack, as you're already on-link, and can already > > DoS the routers there using a number of means? > > Not quite true. A remote attacker can conduct such an attack too, as > long as he has the ability to spoof/use a bunch of different source > addresses. > Added the sentence: > + This can even be done by a remote application that can cause a host to > + respond to a given destination address. > > However, you are correct in that there's not really much of a threat > there, since there are other ways of doing the same thing. But it seems > better than claiming there's no security issues whatsoever. Yes, it's better to say something than nothing at all, but I do not think the current text says enough.. below.. > > Introducing hashing doesn't help much here -- > > you're making an assumption that the attacker is a "friendly" node. A > > > maliscious node will just a) send the packets through raw sockets, > > DoSing the routers directly, or b) overload both of the routers :). > > It seems the security considerations needs a rewrite... > > With the above clarification, I think the text is sufficient. If you > feel otherwise, please submit proposed text. Yes, I don't think the text says enough. Add a paragraph: The added protection of load sharing is not significant: hosts can overload the routers on directly especially if they're on-link; if on-link, hosts can circumvent the sending algorithm by using "raw sockets"; if the host is capable of taking down one router, the load sharing only requires double the capability, and as a consequence, both routers can be taken down simultaneously by a denial-of-service attack. > > editorial > > --------- > > > > ==> all the empty lines in the document appear to have been duplicated > > for some reason. > > I don't see this. Perhaps a CR/LF issue? Probably, possibly by the secretariat as the current document has CR/LF's, but not duplicated empty lines. > > Abstract > > > > The original IPv6 conceptual sending algorithm does not require > > load-sharing among equivalent IPv6 routers, and suggests schemes > > > > ==> s/IPv6/IPv6 Neighbor Discovery/ > > Disagree. Although it's in the ND spec, the relevant part of the > algorithm here is not specific to links which actually run full ND. > Hence I find it less confusing the way it is. It's a trivial point in > any case. I'm fine with this in the abstract. -- 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 11 06:19:26 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16812 for ; Tue, 11 May 2004 06:19:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNUFP-000196-5L for ipv6-archive@odin.ietf.org; Tue, 11 May 2004 06:12:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BACRXK004398 for ipv6-archive@odin.ietf.org; Tue, 11 May 2004 06:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNU9v-0007kh-Ub for ipv6-web-archive@optimus.ietf.org; Tue, 11 May 2004 06:06:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16171 for ; Tue, 11 May 2004 06:06:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNU9s-0003qo-7r for ipv6-web-archive@ietf.org; Tue, 11 May 2004 06:06:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNU8x-0003Tu-00 for ipv6-web-archive@ietf.org; Tue, 11 May 2004 06:05:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNU8B-00036s-00 for ipv6-web-archive@ietf.org; Tue, 11 May 2004 06:04:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNU1T-0005kA-Ot; Tue, 11 May 2004 05:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNTpQ-0003m4-OH for ipv6@optimus.ietf.org; Tue, 11 May 2004 05:45:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15168 for ; Tue, 11 May 2004 05:45:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNTpN-0003SX-7w for ipv6@ietf.org; Tue, 11 May 2004 05:45:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNTnR-0002p4-00 for ipv6@ietf.org; Tue, 11 May 2004 05:43:33 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BNTlO-00023p-00 for ipv6@ietf.org; Tue, 11 May 2004 05:41:27 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4B9etX18428; Tue, 11 May 2004 12:40:56 +0300 Date: Tue, 11 May 2004 12:40:55 +0300 (EEST) From: Pekka Savola To: Bob Hinden cc: ipv6@ietf.org Subject: Re: IPv6 Work Group Last Call for "Default Router Preferences and More-Specific Routes" In-Reply-To: <4.3.2.7.2.20040504171024.01ba5700@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 On Tue, 4 May 2004, Bob Hinden wrote: > This is a IPv6 working group last call for comments on advancing the > following document as an Proposed Standard: > > Title : Default Router Preferences and More-Specific Routes > Author(s) : R. Draves, D. Thaler > Filename : draft-ietf-ipv6-router-selection-03.txt > Pages : 13 > Date : 2003-12-18 > > This is a two week working group last call that will end on May 18, 2004. > > Please direct substantive comments to the IPv6 mailing list. Editorial > comments can be sent directly to the authors. My comments from Feb 29th still apply. (I don't recall there was response.) The link to the archives is below: http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01829.html -- 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 12 00:22:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19362 for ; Wed, 12 May 2004 00:22:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNlEE-0003uX-DQ for ipv6-archive@odin.ietf.org; Wed, 12 May 2004 00:20:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C4KMBf015033 for ipv6-archive@odin.ietf.org; Wed, 12 May 2004 00:20:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNl8q-0002gG-JR for ipv6-web-archive@optimus.ietf.org; Wed, 12 May 2004 00:14:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19046 for ; Wed, 12 May 2004 00:14:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNl8o-0007F1-9z for ipv6-web-archive@ietf.org; Wed, 12 May 2004 00:14:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNl7l-0006n8-00 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 00:13:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNl74-0006Lx-00 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 00:12:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNkwU-00088Q-0j; Wed, 12 May 2004 00:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNkt1-0007IU-7s for ipv6@optimus.ietf.org; Tue, 11 May 2004 23:58:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18144 for ; Tue, 11 May 2004 23:58:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNksy-000054-T5 for ipv6@ietf.org; Tue, 11 May 2004 23:58:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNks0-0007SN-00 for ipv6@ietf.org; Tue, 11 May 2004 23:57:25 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BNkr2-0006cI-00 for ipv6@ietf.org; Tue, 11 May 2004 23:56:24 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4C3tqLc020135; Tue, 11 May 2004 22:55:52 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 11 May 2004 22:55:30 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRFNHFFN; Tue, 11 May 2004 23:55:50 -0400 Date: Tue, 11 May 2004 23:55:11 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: ipv6@ietf.org cc: Bob Hinden Subject: Last call on default router preferences In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830D8F6D2D@eammlex037.lmc.ericsson.se> Message-ID: <7B2A7784F4B7F0409947481F3F3FEF83103BCE9F-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi Folks, I have a couple of comments on this draft Section 2.3 Route Information Option * The length can be more tightly specified. For example if the prefix length is 0 the draft allows the length to be 1,2 or 3 while it is sufficient to specify 1 as the only valid value for the length. Is there a reason for this? * Since the preference is in the middle of the octet (between the reserved fields) the host needs to do an arithmetic shift for this to be used. Is this necessary? * The following statement "If a host processes a Router Advertisement carrying multiple Router Information Options with the same Prefix and Prefix Length, it MUST process one of the options (unspecified which one) and it MUST effectively ignore the rest." implies that the host needs to keep state about the previously encountered route information options in the message. Does this need to be specified? Section 3.5 Router Reachability Probing When the better router becomes available again(say due to a system restart) it will send a new RA message which can trigger the switchover to the better router. Why is the probing needed at all? Section 2.2 Changes to RA message: This draft assumes the presence of the H bit in the RA message. The MIPv6 spec which defines this is still a draft. Assuming that it becomes a standard this draft still needs to mention MIPv6 as a normative reference. Section 5.2: Router X and router Y are mixed up in paragraph 1 and 3. para 1 mentions "a multi-homed host is connected to the 6bone/internet via router X on one link and to an isolated network via router Y on another link" para 3 mentions "For example, router X on the isolated network should advertise a Route Information Option for the isolated network prefix." Section 6: In the security considerations, the draft mentions that this draft is no worse than status quo. But it may not be so. With 2461 a router advertisement expires after a maximum of 18 hrs. But with this draft we can send a route information option with an infinite lifetime. Thus the effect of a misconfigured/malicious router can linger around for longer. Regards Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 12 01:20:57 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21675 for ; Wed, 12 May 2004 01:20:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNm9J-00070J-6W for ipv6-archive@odin.ietf.org; Wed, 12 May 2004 01:19:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C5JLSv026918 for ipv6-archive@odin.ietf.org; Wed, 12 May 2004 01:19:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNlq7-0002QS-67 for ipv6-web-archive@optimus.ietf.org; Wed, 12 May 2004 00:59:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20548 for ; Wed, 12 May 2004 00:59:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNlq4-0003DF-E8 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 00:59:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNlp4-0002mf-00 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 00:58:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNlnv-0001zZ-00 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 00:57:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNlf0-0000Pr-1z; Wed, 12 May 2004 00:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNlbe-00086B-Bo for ipv6@optimus.ietf.org; Wed, 12 May 2004 00:44:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20151 for ; Wed, 12 May 2004 00:44:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNlbb-0004ay-La for ipv6@ietf.org; Wed, 12 May 2004 00:44:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNlad-0004BD-00 for ipv6@ietf.org; Wed, 12 May 2004 00:43:32 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BNla5-0003lW-00 for ipv6@ietf.org; Wed, 12 May 2004 00:42:57 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:9117:4ca0:7d7b:e392]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3C8EC15263; Wed, 12 May 2004 13:42:56 +0900 (JST) Date: Wed, 12 May 2004 13:43:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: ipv6@ietf.org Subject: Re: the protocol for the O flag In-Reply-To: <4.3.2.7.2.20040510122602.02ec1e40@flask.cisco.com> References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> <20040428122811.GB7397@login.ecs.soton.ac.uk> <4.3.2.7.2.20040428120350.02ae0f10@flask.cisco.com> <4.3.2.7.2.20040510122602.02ec1e40@flask.cisco.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Mon, 10 May 2004 12:39:53 -0400, >>>>> Ralph Droms said: > Yes, your original analysis is correct... > Seems like the protocol associated with the 'O' bit should be RFC 3736; > there is no particular advantage to using the 4 message exchange of RFC 3315 > for "other configuration information". The only potential advantage would > be if there is ever a need for "other configuration information" that needs > atateful assignment; we've never found a need for such assignment in DHCPv4. Okay. > Although exactly where prefix delegation falls is a little unclear... I think prefix delegation is a kind of "managed address configuration" (corresponding to the M flag), rather than "other configuration information". If a PD requesting router wants to get some "other" configuration information like DNS recursive server addresses as well, it can do that in the normal request/reply exchanges for prefix delegation. Note that only getting the "other" information does not make much sense in this case, because the delegated site will almost not be able to do anything meaningful without a global prefix. And, in any event, I believe we can separate the PD case from this particular issue for rfc2462bis since PD is not expected to be invoked via RA. 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 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 12 01:34:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22449 for ; Wed, 12 May 2004 01:34:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNmLE-00013V-5G for ipv6-archive@odin.ietf.org; Wed, 12 May 2004 01:31:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C5VeVi004057 for ipv6-archive@odin.ietf.org; Wed, 12 May 2004 01:31:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNmKP-0000py-Di for ipv6-web-archive@optimus.ietf.org; Wed, 12 May 2004 01:30:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22243 for ; Wed, 12 May 2004 01:30:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNmKM-0001ZY-Fr for ipv6-web-archive@ietf.org; Wed, 12 May 2004 01:30:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNmJK-000175-00 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 01:29:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNmIc-0000fk-00 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 01:28:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNmAD-0007Gu-AX; Wed, 12 May 2004 01:20:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNlr5-0002bW-C1 for ipv6@optimus.ietf.org; Wed, 12 May 2004 01:00:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20600 for ; Wed, 12 May 2004 01:00:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNlr2-0003dd-Gr for ipv6@ietf.org; Wed, 12 May 2004 01:00:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNlq8-0003Dk-00 for ipv6@ietf.org; Wed, 12 May 2004 00:59:33 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BNlpC-0002ni-00 for ipv6@ietf.org; Wed, 12 May 2004 00:58:34 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:9117:4ca0:7d7b:e392]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 6A0A01525D; Wed, 12 May 2004 13:58:34 +0900 (JST) Date: Wed, 12 May 2004 13:58:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig Venaas Cc: Ralph Droms , ipv6@ietf.org Subject: Re: the protocol for the O flag In-Reply-To: <20040511074045.GB13755@sverresborg.uninett.no> References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> <20040428122811.GB7397@login.ecs.soton.ac.uk> <4.3.2.7.2.20040428120350.02ae0f10@flask.cisco.com> <4.3.2.7.2.20040510122602.02ec1e40@flask.cisco.com> <20040511074045.GB13755@sverresborg.uninett.no> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Tue, 11 May 2004 09:40:45 +0200, >>>>> Stig Venaas said: >> Yes, your original analysis is correct... >> >> Seems like the protocol associated with the 'O' bit should be RFC 3736; >> there is no particular advantage to using the 4 message exchange of RFC 3315 >> for "other configuration information". The only potential advantage would >> be if there is ever a need for "other configuration information" that needs >> atateful assignment; we've never found a need for such assignment in DHCPv4. > I wouldn't rule this out completely. I think normally RFC 3736 will be > the reasonable thing to do. But if client for some reason wants some > stateful info it could still try to use RFC 3315 I think. > Just as examples, you could imagine client using RFC 3315 to get an IPv4 > address or IPv6 multicast address. Or it could be none-address resources. I would say this kind of configuration information is out of scope of the discussion for the O flag. IMO, such information is rather "managed" one corresponding to the M flag (of course, opinions on this may vary because the meaning of the "other" configuration is not very clear in RFC2462). > Note that I don't really want to discuss the need for IPv4 or multicast > address assignment here. But I'm not sure one should say that client always > must stick to the RFC 3736 subset. We can always imagine any possibility. Considering reality, however, I would leave it for future extensions instead of including it in the scope of the O flag. First, as Ralph said, this is the reality from experiences of DHCPv4. Secondly, the combination mess I explained in an earlier message would be very likely to happen (even though it's just a "theoretical analysis" right now:) whereas the possibility you raised is an imaginary one at the moment as you yourself noticed. 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 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 12 03:02:22 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11680 for ; Wed, 12 May 2004 03:02:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNngw-0000s1-MM for ipv6-archive@odin.ietf.org; Wed, 12 May 2004 02:58:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C6wAQY003341 for ipv6-archive@odin.ietf.org; Wed, 12 May 2004 02:58:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnNK-0004Ah-54 for ipv6-web-archive@optimus.ietf.org; Wed, 12 May 2004 02:37:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09515 for ; Wed, 12 May 2004 02:37:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNnNG-0000sp-B4 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 02:37:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNnMJ-0000PP-00 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 02:36:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNnL8-0007Wj-00 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 02:35:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNn72-0006s5-Vg; Wed, 12 May 2004 02:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNn2n-0005Lj-8L for ipv6@optimus.ietf.org; Wed, 12 May 2004 02:16:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10954 for ; Wed, 12 May 2004 02:16:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNn2j-0006SO-Bh for ipv6@ietf.org; Wed, 12 May 2004 02:16:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNn1q-000625-00 for ipv6@ietf.org; Wed, 12 May 2004 02:15:42 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BNn0v-0005b6-00 for ipv6@ietf.org; Wed, 12 May 2004 02:14:46 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:5d32:a69e:2168:71ec]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5CA0D1525D; Wed, 12 May 2004 15:14:45 +0900 (JST) Date: Wed, 12 May 2004 15:14:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden Cc: ipv6@ietf.org Subject: Re: IPv6 Work Group Last Call: IPv6 Scoped Address Architecture In-Reply-To: <4.3.2.7.2.20040429163229.030f6af0@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20040429163229.030f6af0@mailhost.iprg.nokia.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Thu, 29 Apr 2004 16:40:12 -0700, >>>>> Bob Hinden said: > This is a IPv6 working group last call for comments on advancing the > following document as an Proposed Standard: > Title : IPv6 Scoped Address Architecture > Author(s) : S. Deering, et. al. > Filename : draft-ietf-ipv6-scoping-arch-01.txt > Pages : 23 > Date : 2004-2-13 > This is a one week working group last call that will end on May 6, > 2004. This is to insure that comments from the previous two week working > group last have been address in the current draft. (Just checking) I've not seen any responses for this last call, and I interpreted this as an agreement on submitting the document to the IESG. (If I misunderstood the procedure, please let me know). 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 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 12 09:12:38 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00439 for ; Wed, 12 May 2004 09:12:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtQF-0004MJ-U1 for ipv6-archive@odin.ietf.org; Wed, 12 May 2004 09:05:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CD5Jvj016751 for ipv6-archive@odin.ietf.org; Wed, 12 May 2004 09:05:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtJP-0003Dr-Sl for ipv6-web-archive@optimus.ietf.org; Wed, 12 May 2004 08:58:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29358 for ; Wed, 12 May 2004 08:58:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNtJO-00076L-C6 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 08:58:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNtIL-0006YQ-00 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 08:57:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNtHQ-00060n-00 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 08:56:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNt8Z-0001DE-Ej; Wed, 12 May 2004 08:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNt0v-00080J-AG for ipv6@optimus.ietf.org; Wed, 12 May 2004 08:39:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28370 for ; Wed, 12 May 2004 08:39:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNt0t-0004y0-SX for ipv6@ietf.org; Wed, 12 May 2004 08:39:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNt01-0004SH-00 for ipv6@ietf.org; Wed, 12 May 2004 08:38:14 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1BNsz6-0003Pu-00 for ipv6@ietf.org; Wed, 12 May 2004 08:37:17 -0400 Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i4CCajEP002382 for ; Wed, 12 May 2004 14:36:45 +0200 Received: from vies141a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i4CCaioC015546 for ; Wed, 12 May 2004 14:36:45 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Wed, 12 May 2004 14:37:01 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AB8A@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IPV6 IETF (E-mail)" Subject: IPv6 Router discovery for IPsec/IKev2 VPN tunnel Date: Wed, 12 May 2004 14:33:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I wonder how an IPv6 RAC-node gets to know any router, if it is connected in an IPv6/Ipsec/Ikev2 VPN scenario. IKEv2 configuration payload only assigns an address+ netmask and gives DHCPv6 server address, but DHCPv6 does not=20 have any options for publishing routers. Therefore to get to know routers, Router-solicitation/advertisement is needed. The RAC host is allowed to send its Router solicitation to with its source IPv6 address assigned by IKEv2 Configuration = payload, destination address however has to be link-scope all routers multicast. -> first link local address. The router answers by sending a router advertisement, which again has a link-local source address. But having a selector for link-scope all routers multicast in SPD/SAD is not a good idea, if the scope of this SPD entry is not bound to a virtual interface representing the VPN tunnel (which is possible by RFC2401 and 2401bis)-> router solicitations on other interfaces of = host shall not be sent through tunnel but at link of that inferface. Without that mechanism the funny situation would arise, that no routers are known for the VPN, allthough the RAC should be=20 virtually connected to it. But it is clear that all packets intented = for VPN=B4s address range have to be sent accross VPN-tunnel anyway, and = the prefixes served are the INTERNAL_IP_SUBNETS from IKEv2 configuration payload. Any comments ? Best regards Peter -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 12 21:00:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23427 for ; Wed, 12 May 2004 21:00:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO4VG-0001iH-6z for ipv6-archive@odin.ietf.org; Wed, 12 May 2004 20:55:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D0tEJh006583 for ipv6-archive@odin.ietf.org; Wed, 12 May 2004 20:55:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO4PR-0000N6-S3 for ipv6-web-archive@optimus.ietf.org; Wed, 12 May 2004 20:49:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22794 for ; Wed, 12 May 2004 20:49:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO4PP-0001Vr-Iw for ipv6-web-archive@ietf.org; Wed, 12 May 2004 20:49:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO4OA-0000td-00 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 20:47:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO4Mt-0007it-00 for ipv6-web-archive@ietf.org; Wed, 12 May 2004 20:46:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO450-0002BP-9Q; Wed, 12 May 2004 20:28:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO3xj-00011S-PF for ipv6@optimus.ietf.org; Wed, 12 May 2004 20:20:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20976 for ; Wed, 12 May 2004 20:20:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO3xh-0002KW-MQ for ipv6@ietf.org; Wed, 12 May 2004 20:20:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO3wk-0001pS-00 for ipv6@ietf.org; Wed, 12 May 2004 20:19:35 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx with esmtp (Exim 4.12) id 1BO3w6-0001JA-00 for ipv6@ietf.org; Wed, 12 May 2004 20:18:54 -0400 Received: from consulintel02 ([80.25.193.196]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.0.1.R) with ESMTP id md50000088852.msg for ; Thu, 13 May 2004 02:19:14 +0200 Message-ID: <0b1801c4387f$be7335c0$7000000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: RIRs and IPv6 Date: Thu, 13 May 2004 02:17:56 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 13 May 2004 02:19:14 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 80.25.193.196 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-MDAV-Processed: consulintel.es, Thu, 13 May 2004 02:19:18 +0200 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable FYI Regional Internet Registries, IPv6 Task Forces and IPv6 Forum Pledge Cooperative Support of Global IPv6 Deployment http://www.ist-ipv6.org/modules.php?op=3Dmodload&name=3DNews&file=3Darticle&sid=3D547 TeliaSonera receives /20, the bigger IPv6 block up to now http://www.ist-ipv6.org/modules.php?op=3Dmodload&name=3DNews&file=3Darticle&sid=3D546 Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 13 03:15:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23649 for ; Thu, 13 May 2004 03:15:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOAPX-0006Hn-S2 for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 03:13:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D7Dh8s024164 for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 03:13:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOALn-0005Pj-5O for ipv6-web-archive@optimus.ietf.org; Thu, 13 May 2004 03:09:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23474 for ; Thu, 13 May 2004 03:09:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOALj-00032o-83 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 03:09:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOAKj-0002Yq-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 03:08:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOAJw-000255-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 03:07:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOA9P-0003DY-8Q; Thu, 13 May 2004 02:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOA8H-00031o-MQ for ipv6@optimus.ietf.org; Thu, 13 May 2004 02:55:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22822 for ; Thu, 13 May 2004 02:55:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOA8D-0003lw-Qm for ipv6@ietf.org; Thu, 13 May 2004 02:55:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOA73-0003EP-00 for ipv6@ietf.org; Thu, 13 May 2004 02:54:38 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BOA5z-0002XV-00 for ipv6@ietf.org; Thu, 13 May 2004 02:53:31 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:2598:2abe:16d5:cd5e]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 131191525D for ; Thu, 13 May 2004 15:53:28 +0900 (JST) Date: Thu, 13 May 2004 15:53:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis] relationship between M/O flags and related protocols User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. In-Reply-To: MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Thu_May_13_15:53:42_2004-1" 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 --Multipart_Thu_May_13_15:53:42_2004-1 Content-Type: text/plain; charset=US-ASCII Now I'd like to (re)start a bigger discussion about the M/O flags: how we should describe the relationship between the M/O flags and the related protocols. So far, many people seem to have (somehow) agreed on what Christian said (attached below): the M/O flags should just be hints of availability of the corresponding services (or protocols) rather than a trigger to invoke the protocols under a certain level of requirement. While some part of his interpretation (i.e., "do DHCP, and only if it fails do auto-config") was not really accurate according to the specification as others already pointed out, I still think he made important points, in that RFC2462 has "supposedly mandatory nature" with ambiguity on details. An example of the "mandatory nature" is the following sentence of Section 5.5.3: If the value of ManagedFlag changes from FALSE to TRUE, ..., the host should invoke the stateful address autoconfiguration protocol, ... The "ambiguity" includes: - the level of requirements (e.g., should the above "should" be actually SHOULD?, etc) - what is the protocol to be invoked by this statement (we are now trying to clarify this point) - what hosts should do if the M/O flags keep being cleared; e.g., does this mean the hosts should not invoke the protocols? - what if the hosts do not implement the stateful protocol? (recall that in the node requirements document it is basically optional to implement DHCPv6 for the stateful address configuration) I interpreted Christian's suggestion as one that tries to remove the "mandatory nature" considering the current deployment/implementation status, and in that sense, I tend to agree. The suggestion won't fully solve the ambiguity issues, but it will make the document well-balanced based on the current status. Although his suggestion was apparently supported by several key players in this group, I'm afraid details on actual changes for rfc2462bis may still vary. So I'll soon throw concrete idea of the changes based on my own interpretation of his suggestion in a separate message. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Thu_May_13_15:53:42_2004-1 Content-Type: message/rfc822 Return-Path: Return-Path: X-Original-To: jinmei@kame.net Delivered-To: jinmei@kame.net Received: from orange.kame.net [203.178.141.194] by localhost with POP3 (fetchmail-6.2.4) for jinmei@localhost (single-drop); Thu, 29 Apr 2004 11:21:40 +0900 (JST) Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by orange.kame.net (Postfix) with ESMTP id A4B3735681F; Thu, 29 Apr 2004 01:53:59 +0900 (JST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsBD-00055t-MP; Wed, 28 Apr 2004 12:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIryX-0002KT-Bd for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 12:31:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26842 for ; Wed, 28 Apr 2004 12:31:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIryU-0005G0-HI for ipv6@ietf.org; Wed, 28 Apr 2004 12:31:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrxV-0005Ah-00 for ipv6@ietf.org; Wed, 28 Apr 2004 12:30:54 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BIrwZ-00052P-00 for ipv6@ietf.org; Wed, 28 Apr 2004 12:29:56 -0400 Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 28 Apr 2004 09:29:42 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 28 Apr 2004 09:29:26 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 28 Apr 2004 09:29:25 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Apr 2004 09:30:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 28 Apr 2004 09:29:25 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 28 Apr 2004 09:29:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Subject: RE: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Date: Wed, 28 Apr 2004 09:29:23 -0700 Message-ID: Thread-Topic: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Thread-Index: AcQtOhw8CIb55GwuTZm1PA7KcX1SBAAAZKdA From: "Christian Huitema" To: =?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , "Tim Chown" Cc: X-OriginalArrivalTime: 28 Apr 2004 16:29:28.0473 (UTC) FILETIME=[FA0E9090:01C42D3D] 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-UIDL: ?Z8!!22!#!Q8B!!m*g!! X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on ocean.jinmei.org X-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL autolearn=no version=2.61 Content-Transfer-Encoding: 7bit I think a whole lot of the issue has to do with the supposedly mandatory nature of the M flag, which leads to phrases like "do DHCP, and only if it fails do auto-config." It would be much simpler to simply define the flags as "announcing an available service", as in: 1) The "M" flag is set to indicate that a DHCPv6 address configuration service is available on this link, as specified in RFC3315. 2) The "O" flag is set to indicate that a DHCPv6 information service is available on this link, as specified in RFC3736. We should then leave it at that, and leave it to nodes to decide whether they want to use these services or not. For example, a server with a configured address will never use DHCPv6 address configuration; an appliance that never has to resolve DNS names will never use the information service. By setting the flags to indicate service availability, we will reduce the amount of useless chatter on the link when the services are not in fact available. We should note that, from a protocol point of view, there is no need to use the M bit to control stateless address configuration. This function is already achieved by the "Autonomous flag" in the prefix information option. If the flag is not set, the hosts will not configure information from the prefix. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --Multipart_Thu_May_13_15:53:42_2004-1-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 13 07:22:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05493 for ; Thu, 13 May 2004 07:22:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOEH4-00034f-No for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 07:21:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DBLEDS011818 for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 07:21:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOEFk-0002t4-3E for ipv6-web-archive@optimus.ietf.org; Thu, 13 May 2004 07:19:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05337 for ; Thu, 13 May 2004 07:19:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOEFj-0003Wu-MN for ipv6-web-archive@ietf.org; Thu, 13 May 2004 07:19:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOEEk-0002yt-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 07:18:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOEDn-0002NZ-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 07:17:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOE2N-0008Po-An; Thu, 13 May 2004 07:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BODyi-0007r5-3t for ipv6@optimus.ietf.org; Thu, 13 May 2004 07:02:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04656 for ; Thu, 13 May 2004 07:02:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BODyd-0001oN-Sy for ipv6@ietf.org; Thu, 13 May 2004 07:02:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BODxf-0001EB-00 for ipv6@ietf.org; Thu, 13 May 2004 07:01:11 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BODwe-0000d0-00 for ipv6@ietf.org; Thu, 13 May 2004 07:00:08 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:2598:2abe:16d5:cd5e]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7F60115272 for ; Thu, 13 May 2004 20:00:00 +0900 (JST) Date: Thu, 13 May 2004 20:00:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols In-Reply-To: References: 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Thu, 13 May 2004 15:53:42 +0900, >>>>> JINMEI Tatuya said: > Although his suggestion was apparently supported by several key > players in this group, I'm afraid details on actual changes for > rfc2462bis may still vary. So I'll soon throw concrete idea of the > changes based on my own interpretation of his suggestion in a separate > message. And here are the proposed changes. The basic idea is: 1. clarify (change) the meaning of the M/O flags; they are just hints of availability of the corresponding services, not triggers for invoking the protocols under a certain level of requirement 2. remove "requirements" regarding these flags according to the above change 3. (optionally) make a separate document (standard or BCP) on how to interact the protocols with these flags (In the followings, I'm assuming we have agreed that - we should clearly specify the corresponding protocols for the M/O flags - the protocol for the M flag is DHCPv6 (RFC3315) - the protocol for the O flag is the "stateless" subset of DHCPv6 (RFC3736) but these details are not the essential part of the proposal.) The followings are some concrete examples of how I'd revise the document based on the idea. For 1, I'd revise the following sentence of RFC2462 Section 4 (page 9): A "managed address configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain addresses. to: A "managed address configuration" flag indicates whether DHCPv6 is available for hosts to obtain addresses. For 2, - remove the notion of the ManagedFlag and OtherConfigFlag (conceptual) variables defined in Section 5.2, since these flags will become meaningless if we do not mandate invoking particular protocols by the RA M/O flags. - remove "requirement" sentences like the following one 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, requesting both address information and other information. (Section 5.5.3 of RFC2462) - remove Section 5.5.2 of RFC2462 (that mandates performing the "stateful" protocol when no RAs) Hopefully, these are not so different from what others imagined by Christian's suggestion. But I'm not that optimistic, and expect objections. Please make comments on the idea shown above, particularly if you have an objection. Thanks, 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 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 13 11:53:11 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19938 for ; Thu, 13 May 2004 11:53:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOIQx-0004f3-C2 for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 11:47:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DFlhbr017913 for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 11:47:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOIKE-0003Zd-W2 for ipv6-web-archive@optimus.ietf.org; Thu, 13 May 2004 11:40:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19243 for ; Thu, 13 May 2004 11:40:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOIKD-0002qE-Uq for ipv6-web-archive@ietf.org; Thu, 13 May 2004 11:40:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOIJ3-0002Ej-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 11:39:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BOIHV-00017Q-02 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 11:37:57 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BOI2e-0004RX-RL for ipv6-web-archive@ietf.org; Thu, 13 May 2004 11:22:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHwK-00067W-TS; Thu, 13 May 2004 11:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHqn-0004iW-5Z for ipv6@optimus.ietf.org; Thu, 13 May 2004 11:10:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17943 for ; Thu, 13 May 2004 11:10:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOHqk-0002rd-GS for ipv6@ietf.org; Thu, 13 May 2004 11:10:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOHpq-0002KJ-00 for ipv6@ietf.org; Thu, 13 May 2004 11:09:22 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BOHpA-0001lA-00 for ipv6@ietf.org; Thu, 13 May 2004 11:08:40 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 May 2004 11:08:04 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols Date: Thu, 13 May 2004 11:08:04 -0400 Message-ID: Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols Thread-Index: AcQ4uOG/S3HBkhSIS6aFU2U+yfN0ygAIeemA From: "Soliman Hesham" To: "JINMEI Tatuya / ????" , X-OriginalArrivalTime: 13 May 2004 15:08:04.0684 (UTC) FILETIME=[1749C0C0:01C438FC] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Some answers below. > So far, many people seem to have (somehow) agreed on what Christian > said (attached below): the M/O flags should just be hints of > availability of the corresponding services (or protocols) rather than > a trigger to invoke the protocols under a certain level of=20 > requirement. >=20 > While some part of his interpretation (i.e., "do DHCP, and only if it > fails do auto-config") was not really accurate according to the > specification as others already pointed out, I still think he made > important points, in that RFC2462 has "supposedly mandatory nature" > with ambiguity on details. =3D> Before I attempt to answer the questions below I'd like to clarify that we already have a Node requirements doc which states what RFCs, and to some extent functions within RFCs, should be supported and the level of such support. >=20 > An example of the "mandatory nature" is the following sentence of > Section 5.5.3: >=20 > If the value of ManagedFlag changes from FALSE to > TRUE, ..., the host should invoke the stateful > address autoconfiguration protocol, ... >=20 > The "ambiguity" includes: > - the level of requirements (e.g., should the above "should" be > actually SHOULD?, etc) =3D> I don't know if it's a requirement to have upper case. RFC2460 has = no upper cases and several other IPv6 RFCs (especially those edited by Steve = Deering) have no upper cases at all. > - what is the protocol to be invoked by this statement (we are now > trying to clarify this point) =3D> Right. > - what hosts should do if the M/O flags keep being cleared; e.g., > does this mean the hosts should not invoke the protocols? =3D> Stateless is a MUST according to the Node requirements. Now, if an implementation decided to use DHCP when the flags are set, then there are two cases to consider: a. No DHCP server. This will be discovered pretty soon. b. DHCP exists and address is allocated c. DHCP exists but since admin doesn't want it to be used for address allocation it won't allocate an address.=20 All of those cases will render a definite outcome so there is no need to = tell the=20 host what to do in this case. I.e. no interop issues. > - what if the hosts do not implement the stateful protocol? (recall > that in the node requirements document it is basically=20 > optional to > implement DHCPv6 for the stateful address configuration) =3D> It doesn't work! It only gets a link local address. Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 13 12:04:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20498 for ; Thu, 13 May 2004 12:04:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOIaC-0006QG-Pg for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 11:57:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DFvGaw024683 for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 11:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOIWB-0005s3-Md for ipv6-web-archive@optimus.ietf.org; Thu, 13 May 2004 11:53:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19922 for ; Thu, 13 May 2004 11:53:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOIWA-00025R-IS for ipv6-web-archive@ietf.org; Thu, 13 May 2004 11:53:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOIV9-0001Z0-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 11:52:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOITw-0000eG-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 11:50:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOILS-0003iz-0m; Thu, 13 May 2004 11:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOIEh-0002CB-SW for ipv6@optimus.ietf.org; Thu, 13 May 2004 11:35:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18923 for ; Thu, 13 May 2004 11:35:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOIEg-00000L-OS for ipv6@ietf.org; Thu, 13 May 2004 11:35:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOIDj-0007I3-00 for ipv6@ietf.org; Thu, 13 May 2004 11:34:04 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BOID1-0006QM-00 for ipv6@ietf.org; Thu, 13 May 2004 11:33:20 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:2598:2abe:16d5:cd5e]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AA5AA1525D; Fri, 14 May 2004 00:32:47 +0900 (JST) Date: Fri, 14 May 2004 00:32:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman Hesham" Cc: Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols In-Reply-To: References: 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Quick checks: >>>>> On Thu, 13 May 2004 11:08:04 -0400, >>>>> "Soliman Hesham" said: >> - what hosts should do if the M/O flags keep being cleared; e.g., >> does this mean the hosts should not invoke the protocols? > => Stateless is a MUST according to the Node requirements. Now, if an > implementation > decided to use DHCP when the flags are set, then there are two cases to > consider: do you mean the case when the flags are NOT set? (I talked about the case where the flags are "cleared"). And you actually meant "three" cases to consider instead of "two":-) > a. No DHCP server. This will be discovered pretty soon. > b. DHCP exists and address is allocated > c. DHCP exists but since admin doesn't want it to be used for address > allocation > it won't allocate an address. > All of those cases will render a definite outcome so there is no need to tell > the > host what to do in this case. I.e. no interop issues. Not sure about your intention, but a few additional clarifications: Detecting non existence of DHCPv6 servers is a quite time-consuming process rather than "pretty soon", at least protocol-wise. In fact, according to RFC3315, we can never "detect" the non existence since MRC and MRT are both 0 for DHCPv6 solicit and information request messages, which means we should try to find servers forever. Also, when we are talking about the O flag, we should note that it is not directly relevant to address allocation. 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 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 13 12:28:59 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21510 for ; Thu, 13 May 2004 12:28:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOIwC-0004gQ-Dc for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 12:20:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DGK0TG018000 for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 12:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOIii-0000EC-Lk for ipv6-web-archive@optimus.ietf.org; Thu, 13 May 2004 12:06:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20592 for ; Thu, 13 May 2004 12:06:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOIih-0001BK-FF for ipv6-web-archive@ietf.org; Thu, 13 May 2004 12:06:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOIhh-0000eE-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 12:05:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOIgY-0007Yg-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 12:03:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOIX3-0005w7-R5; Thu, 13 May 2004 11:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOISN-0004zh-Tj for ipv6@optimus.ietf.org; Thu, 13 May 2004 11:49:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19757 for ; Thu, 13 May 2004 11:49:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOISM-0007mr-Ok for ipv6@ietf.org; Thu, 13 May 2004 11:49:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOIRP-0007Db-00 for ipv6@ietf.org; Thu, 13 May 2004 11:48:12 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BOIQJ-00069Y-00 for ipv6@ietf.org; Thu, 13 May 2004 11:47:03 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 May 2004 11:46:33 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols Date: Thu, 13 May 2004 11:46:33 -0400 Message-ID: Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols Thread-Index: AcQ4/4yTLllN/e88QZ+9r64mp2Is4QAAAtgA From: "Soliman Hesham" To: "JINMEI Tatuya / ????" CC: X-OriginalArrivalTime: 13 May 2004 15:46:33.0980 (UTC) FILETIME=[77BC5BC0:01C43901] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > =3D> Stateless is a MUST according to the Node requirements.=20 > Now, if an > > implementation > > decided to use DHCP when the flags are set, then there are=20 > two cases to > > consider: >=20 > do you mean the case when the flags are NOT set? (I talked about the > case where the flags are "cleared"). =3D> Yes, sorry. >=20 > And you actually meant "three" cases to consider instead of "two":-) =3D> Yes ;) > > a. No DHCP server. This will be discovered pretty soon. > > b. DHCP exists and address is allocated > > c. DHCP exists but since admin doesn't want it to be used=20 > for address > > allocation > > it won't allocate an address.=20 >=20 > > All of those cases will render a definite outcome so there=20 > is no need to tell > > the=20 > > host what to do in this case. I.e. no interop issues. >=20 > Not sure about your intention, but a few additional clarifications: >=20 > Detecting non existence of DHCPv6 servers is a quite time-consuming > process rather than "pretty soon", at least protocol-wise. In fact, > according to RFC3315, we can never "detect" the non existence since > MRC and MRT are both 0 for DHCPv6 solicit and information request > messages, which means we should try to find servers forever. >=20 =3D> Ok but if a host desicdes to waste time despite the network's recommendation to use stateless, what can we do? Clearing the flags clearly suggests = the use of stateless. If a host goes against that then there is no guarantees = that anything will work. > Also, when we are talking about the O flag, we should note that it > is not directly relevant to address allocation. =3D> Sure, but currently there is no standard alternative to DHCP for = the O flag. Hesham >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 13 12:55:52 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23191 for ; Thu, 13 May 2004 12:55:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJSD-0003Gq-RI for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 12:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DGr5TR012565 for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 12:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJOw-0002Jb-Lw for ipv6-web-archive@optimus.ietf.org; Thu, 13 May 2004 12:49:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22632 for ; Thu, 13 May 2004 12:49:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOJOu-0000Y1-W7 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 12:49:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOJNW-0007Gm-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 12:48:14 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BOJLg-0006Xz-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 12:46:20 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BOJ7Q-0005X8-Bf for ipv6-web-archive@ietf.org; Thu, 13 May 2004 12:31:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOIxD-0004t6-KU; Thu, 13 May 2004 12:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOIlg-00013J-Co for ipv6@optimus.ietf.org; Thu, 13 May 2004 12:09:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20717 for ; Thu, 13 May 2004 12:09:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOIlf-0002ki-0r for ipv6@ietf.org; Thu, 13 May 2004 12:09:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOIkn-0002FJ-00 for ipv6@ietf.org; Thu, 13 May 2004 12:08:13 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BOIjw-0001KP-00 for ipv6@ietf.org; Thu, 13 May 2004 12:07:21 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 May 2004 09:06:49 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Thu, 13 May 2004 09:06:47 -0700 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 May 2004 09:06:49 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 May 2004 09:06:29 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 May 2004 09:06:49 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 13 May 2004 09:07:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols Date: Thu, 13 May 2004 09:05:33 -0700 Message-ID: Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols thread-index: AcQ42+tUB5OtnalETRysLk5Md68wIQAJ6vAw From: "Christian Huitema" To: =?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , X-OriginalArrivalTime: 13 May 2004 16:07:12.0314 (UTC) FILETIME=[59D721A0:01C43904] Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > (In the followings, I'm assuming we have agreed that > > - we should clearly specify the corresponding protocols for the M/O > flags > - the protocol for the M flag is DHCPv6 (RFC3315) > - the protocol for the O flag is the "stateless" subset of DHCPv6 > (RFC3736) >From an operational point of view, it makes a lot of sense to use "M" to say that stateful DHCPv6 is available, and "O" to say that the stateless subset is available. This gives a good hint to the host: they should not attempt to use stateful DHCPv6 to obtain addresses or other parameters if the M flag is not set; they may attempt to use stateless DHCPv6 to obtain other parameters if the O flag is set. Doing otherwise leads to interoperability issues, e.g. a host attempting to use stateful DHCPv6 to obtain a configuration parameter when the local network only supports stateless operation. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 13 17:30:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16510 for ; Thu, 13 May 2004 17:30:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONhB-0001uL-AU for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 17:24:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DLOnqi007334 for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 17:24:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONIr-0002fZ-HS for ipv6-web-archive@optimus.ietf.org; Thu, 13 May 2004 16:59:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13464 for ; Thu, 13 May 2004 16:59:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BONIp-0002iP-BJ for ipv6-web-archive@ietf.org; Thu, 13 May 2004 16:59:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BONH2-0001hM-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 16:57:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BONEx-0000dW-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 16:55:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOMl2-00056l-Db; Thu, 13 May 2004 16:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOM9p-0004nC-M1 for ipv6@optimus.ietf.org; Thu, 13 May 2004 15:46:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09270 for ; Thu, 13 May 2004 15:46:15 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOM9o-0001aL-1s for ipv6@ietf.org; Thu, 13 May 2004 15:46:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOM8W-0000Y6-00 for ipv6@ietf.org; Thu, 13 May 2004 15:44:57 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BOM7W-0007mV-00 for ipv6@ietf.org; Thu, 13 May 2004 15:43:54 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4DJhrv01101 for ; Thu, 13 May 2004 22:43:53 +0300 (EET DST) X-Scanned: Thu, 13 May 2004 22:43:51 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4DJhpUZ021285 for ; Thu, 13 May 2004 22:43:51 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00mHPjq6; Thu, 13 May 2004 22:43:50 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4DJhnH18491 for ; Thu, 13 May 2004 22:43:49 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 13 May 2004 14:43:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: ICMPv3: Message Source Address Determination.. Date: Thu, 13 May 2004 14:43:44 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79A35@daebe009.americas.nokia.com> Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols Thread-Index: AcQ42+tUB5OtnalETRysLk5Md68wIQAJ6vAwAAdYioA= To: X-OriginalArrivalTime: 13 May 2004 19:43:45.0528 (UTC) FILETIME=[9A663F80:01C43922] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All, [Please express your opinion. It is needed to make the informed decision.] Pekka raised a concern about the usability of one of the methods (section 2.2 (c)) to select the source address=20 of the ICMPv3 packet. I want to know if anyone has=20 implemented it ? or how useful and practical this=20 method is in your opinion ? The decision that I want to make is to whether we should keep it in the draft or remove it. Here is the text for quick reference. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D (c) If the message is a response to a message sent to=20 an address that does not belong to the node, the=20 Source Address should be that unicast address=20 belonging to the node that will be most helpful=20 in diagnosing the error. For example, if the message is a response to a packet forwarding action that=20 cannot complete successfully, the Source Address=20 should be a unicast address belonging to the=20 interface on which the packet forwarding failed. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D and here is the link to the current draft for quick=20 reference. http://ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-03.txt Comments would be highly appreciated. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 13 17:39:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17952 for ; Thu, 13 May 2004 17:39:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONm7-0004th-1o for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 17:29:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DLTtMi018813 for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 17:29:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONgh-0001YM-Jv for ipv6-web-archive@optimus.ietf.org; Thu, 13 May 2004 17:24:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15925 for ; Thu, 13 May 2004 17:24:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BONgf-0001JH-AI for ipv6-web-archive@ietf.org; Thu, 13 May 2004 17:24:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BONdq-0007nM-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 17:21:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BONcQ-00076P-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 17:19:54 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BONUE-0000s8-4m for ipv6-web-archive@ietf.org; Thu, 13 May 2004 17:11:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOMlP-0005CL-Cb; Thu, 13 May 2004 16:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOMKR-0007Wk-UM for ipv6@optimus.ietf.org; Thu, 13 May 2004 15:57:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09767 for ; Thu, 13 May 2004 15:57:13 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOMKQ-0007W3-Bs for ipv6@ietf.org; Thu, 13 May 2004 15:57:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOMJU-0006yL-00 for ipv6@ietf.org; Thu, 13 May 2004 15:56:17 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BOMIQ-0006OT-00 for ipv6@ietf.org; Thu, 13 May 2004 15:55:10 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4DJtAB11477 for ; Thu, 13 May 2004 22:55:10 +0300 (EET DST) X-Scanned: Thu, 13 May 2004 22:55:07 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4DJt7t4017870 for ; Thu, 13 May 2004 22:55:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00I6lPDp; Thu, 13 May 2004 22:55:05 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4DJsxH26476 for ; Thu, 13 May 2004 22:54:59 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 13 May 2004 14:54:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: ICMPv3: Message Source Address Determination.. Date: Thu, 13 May 2004 14:54:23 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79A35@daebe009.americas.nokia.com> Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols Thread-Index: AcQ42+tUB5OtnalETRysLk5Md68wIQAJ6vAwAAdYioA= To: X-OriginalArrivalTime: 13 May 2004 19:54:24.0083 (UTC) FILETIME=[17020230:01C43924] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All, [Please express your opinion. It is needed to make the informed decision.] Pekka raised a concern about the usability of one of the methods (section 2.2 (c)) to select the source address=20 of the ICMPv3 packet. I want to know if anyone has=20 implemented it ? or how useful and practical this=20 method is in your opinion ? The decision that I want to make is to whether we should keep it in the draft or remove it. Here is the text for quick reference. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D (c) If the message is a response to a message sent to=20 an address that does not belong to the node, the=20 Source Address should be that unicast address=20 belonging to the node that will be most helpful=20 in diagnosing the error. For example, if the message is a response to a packet forwarding action that=20 cannot complete successfully, the Source Address=20 should be a unicast address belonging to the=20 interface on which the packet forwarding failed. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D and here is the link to the current draft for quick=20 reference. http://ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-03.txt Comments would be highly appreciated. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 13 20:29:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27418 for ; Thu, 13 May 2004 20:29:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQY8-00029h-Dv for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 20:27:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E0Rews008281 for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 20:27:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQWI-0001XX-6l for ipv6-web-archive@optimus.ietf.org; Thu, 13 May 2004 20:25:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27222 for ; Thu, 13 May 2004 20:25:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOQWG-0002PY-36 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 20:25:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOQVC-0001qS-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 20:24:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOQTs-00017D-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 20:23:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQOn-0007Mx-W1; Thu, 13 May 2004 20:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQJW-00063v-1F for ipv6@optimus.ietf.org; Thu, 13 May 2004 20:12:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26735 for ; Thu, 13 May 2004 20:12:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOQJS-0003H8-Jb for ipv6@ietf.org; Thu, 13 May 2004 20:12:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOQIT-0002lY-00 for ipv6@ietf.org; Thu, 13 May 2004 20:11:29 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BOQI5-0002GJ-00; Thu, 13 May 2004 20:11:05 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4E0AG730656; Thu, 13 May 2004 17:10:16 -0700 X-mProtect: <200405140010> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdEa8r5s; Thu, 13 May 2004 17:10:12 PDT Message-Id: <4.3.2.7.2.20040513163937.035c2e28@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 May 2004 17:07:38 -0700 To: Margaret Wasserman , Thomas Narten From: Bob Hinden Subject: Request to Advance "IPv6 Scoped Address Architecture" Cc: ipv6@ietf.org, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Margaret, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : IPv6 Scoped Address Architecture Author(s) : S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill Filename : draft-ietf-ipv6-scoping-arch-01.txt Pages : 23 Date : 2004-2-13 A working group last call for this document was completed on May 6, 2004. This draft resolves issues raised during the previous working group last call. No issues were raised during this last call. Bob Hinden / Brian Haberman IPv6 Working Group Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 13 20:32:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27720 for ; Thu, 13 May 2004 20:32:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQb5-0002un-0e for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 20:30:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E0UgLo011199 for ipv6-archive@odin.ietf.org; Thu, 13 May 2004 20:30:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQZJ-0002Q5-Iu for ipv6-web-archive@optimus.ietf.org; Thu, 13 May 2004 20:28:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27390 for ; Thu, 13 May 2004 20:28:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOQZH-00044Y-Er for ipv6-web-archive@ietf.org; Thu, 13 May 2004 20:28:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOQYJ-0003Vv-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 20:27:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOQXK-0002xo-00 for ipv6-web-archive@ietf.org; Thu, 13 May 2004 20:26:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQPn-0007n2-C5; Thu, 13 May 2004 20:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQNK-0006tl-9Q for ipv6@optimus.ietf.org; Thu, 13 May 2004 20:16:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26882 for ; Thu, 13 May 2004 20:16:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOQNI-0005Mj-3y for ipv6@ietf.org; Thu, 13 May 2004 20:16:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOQMU-0004rF-00 for ipv6@ietf.org; Thu, 13 May 2004 20:15:38 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BOQLg-0004Ax-00; Thu, 13 May 2004 20:14:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4E0DRT01729; Thu, 13 May 2004 17:13:27 -0700 X-mProtect: <200405140013> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdsojnsk; Thu, 13 May 2004 17:13:25 PDT Message-Id: <4.3.2.7.2.20040513171009.01bc76c8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 May 2004 17:11:07 -0700 To: Margaret Wasserman , Thomas Narten From: Bob Hinden Subject: Request to Advance "IPv6 Scoped Address Architecture" (resend) Cc: ipv6@ietf.org, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Margaret, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : IPv6 Scoped Address Architecture Author(s) : S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill Filename : draft-ietf-ipv6-scoping-arch-01.txt Pages : 23 Date : 2004-2-13 A working group last call for this document was completed on May 6, 2004. This draft resolves issues raised during the previous working group last call. No issues were raised during this last call. Bob Hinden / Brian Haberman IPv6 Working Group Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 14 02:31:36 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29466 for ; Fri, 14 May 2004 02:31:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOWBh-00053a-L0 for ipv6-archive@odin.ietf.org; Fri, 14 May 2004 02:28:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E6Sroq019422 for ipv6-archive@odin.ietf.org; Fri, 14 May 2004 02:28:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOW3s-0001q5-Ds for ipv6-web-archive@optimus.ietf.org; Fri, 14 May 2004 02:20:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28842 for ; Fri, 14 May 2004 02:20:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOW3o-0002Bf-OB for ipv6-web-archive@ietf.org; Fri, 14 May 2004 02:20:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOW2j-0001eG-00 for ipv6-web-archive@ietf.org; Fri, 14 May 2004 02:19:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOW1b-0000ly-00 for ipv6-web-archive@ietf.org; Fri, 14 May 2004 02:18:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOVtV-0004sj-1O; Fri, 14 May 2004 02:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOVrC-0003fw-UJ for ipv6@optimus.ietf.org; Fri, 14 May 2004 02:07:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22574 for ; Fri, 14 May 2004 02:07:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOVr9-0002oy-AR for ipv6@ietf.org; Fri, 14 May 2004 02:07:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOVq8-0002Hy-00 for ipv6@ietf.org; Fri, 14 May 2004 02:06:37 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BOVp2-0001FI-00 for ipv6@ietf.org; Fri, 14 May 2004 02:05:28 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:96f:69a3:96a3:6369]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5FB011525D; Fri, 14 May 2004 15:05:21 +0900 (JST) Date: Fri, 14 May 2004 15:05:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Christian Huitema" Cc: Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols In-Reply-To: References: 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Thu, 13 May 2004 09:05:33 -0700, >>>>> "Christian Huitema" said: >> (In the followings, I'm assuming we have agreed that >> >> - we should clearly specify the corresponding protocols for the M/O >> flags >> - the protocol for the M flag is DHCPv6 (RFC3315) >> - the protocol for the O flag is the "stateless" subset of DHCPv6 >> (RFC3736) >> From an operational point of view, it makes a lot of sense to use "M" to say that stateful DHCPv6 is available, and "O" to say that the stateless subset is available. This gives a good hint to the host: they should not attempt to use stateful DHCPv6 to obtain addresses or other parameters if the M flag is not set; they may attempt to use stateless DHCPv6 to obtain other parameters if the O flag is set. > Doing otherwise leads to interoperability issues, e.g. a host attempting to use stateful DHCPv6 to obtain a configuration parameter when the local network only supports stateless operation. Apparently this comment should apply to a separate thread entitled "the protocol for the O flag". BTW: do you have any comments on the other parts of my proposal (for which I'm mainly waiting in this thread)? Thanks, 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 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 14 10:30:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25478 for ; Fri, 14 May 2004 10:30:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOdg3-0005n2-6E for ipv6-archive@odin.ietf.org; Fri, 14 May 2004 10:28:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EEShvk022253 for ipv6-archive@odin.ietf.org; Fri, 14 May 2004 10:28:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOdef-0005SD-6O for ipv6-web-archive@optimus.ietf.org; Fri, 14 May 2004 10:27:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25336 for ; Fri, 14 May 2004 10:27:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOdec-0003wy-Re for ipv6-web-archive@ietf.org; Fri, 14 May 2004 10:27:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOddS-0003Rh-00 for ipv6-web-archive@ietf.org; Fri, 14 May 2004 10:26:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOdcU-0002ps-00 for ipv6-web-archive@ietf.org; Fri, 14 May 2004 10:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOdXh-0003hO-Uf; Fri, 14 May 2004 10:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOdWl-0003Tc-3Y for ipv6@optimus.ietf.org; Fri, 14 May 2004 10:19:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25017 for ; Fri, 14 May 2004 10:19:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOdWi-0007jX-R6 for ipv6@ietf.org; Fri, 14 May 2004 10:19:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOdVj-0007EV-00 for ipv6@ietf.org; Fri, 14 May 2004 10:18:03 -0400 Received: from coconut.itojun.org ([221.249.121.227]) by ietf-mx with esmtp (Exim 4.12) id 1BOdUg-0006eg-00 for ipv6@ietf.org; Fri, 14 May 2004 10:16:59 -0400 Received: by coconut.itojun.org (Postfix, from userid 1001) id B3DDC50; Fri, 14 May 2004 23:16:54 +0900 (JST) To: ipv6@ietf.org Subject: draft-itojun-ipv6-getnameinfo-multiproto-01.txt X-Mailer: Cue version 0.8 (040507-1428/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040514141654.B3DDC50@coconut.itojun.org> Date: Fri, 14 May 2004 23:16:54 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 a couple of questions from the author of the document. - are people satisfied with it? - if so, i would like to submit it to rfc-editor as individual/ informational, and then contact POSIX guys. does it sound right? itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 14 11:26:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27615 for ; Fri, 14 May 2004 11:26:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeUL-000770-0K for ipv6-archive@odin.ietf.org; Fri, 14 May 2004 11:20:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EFKesv027339 for ipv6-archive@odin.ietf.org; Fri, 14 May 2004 11:20:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeO3-0005no-6u for ipv6-web-archive@optimus.ietf.org; Fri, 14 May 2004 11:14:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27202 for ; Fri, 14 May 2004 11:14:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOeO2-0003i2-Dv for ipv6-web-archive@ietf.org; Fri, 14 May 2004 11:14:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOeN9-0003E5-00 for ipv6-web-archive@ietf.org; Fri, 14 May 2004 11:13:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOeMX-0002js-00 for ipv6-web-archive@ietf.org; Fri, 14 May 2004 11:12:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeI5-0004TB-I2; Fri, 14 May 2004 11:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeGJ-00041Y-C2 for ipv6@optimus.ietf.org; Fri, 14 May 2004 11:06:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26893 for ; Fri, 14 May 2004 11:06:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOeGG-0007Yx-Ly for ipv6@ietf.org; Fri, 14 May 2004 11:06:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOeFI-00074H-00 for ipv6@ietf.org; Fri, 14 May 2004 11:05:08 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1BOeEI-00067F-00 for ipv6@ietf.org; Fri, 14 May 2004 11:04:06 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i4EF3ZL06288; Fri, 14 May 2004 08:03:35 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i4EFLL4J013992 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 14 May 2004 08:21:24 -0700 Message-ID: <40A4DFAD.3050905@innovationslab.net> Date: Fri, 14 May 2004 11:03:09 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: ipv6@ietf.org Subject: Re: draft-itojun-ipv6-getnameinfo-multiproto-01.txt References: <20040514141654.B3DDC50@coconut.itojun.org> In-Reply-To: <20040514141654.B3DDC50@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Itojun, I would suggest talking to the POSIX group prior to submitting it to the RFC editor. That way changes can be incorporated during the I-D edit time rather than RFC edit time. Regards, Brian Jun-ichiro itojun Hagino wrote: > a couple of questions from the author of the document. > - are people satisfied with it? > - if so, i would like to submit it to rfc-editor as individual/ > informational, and then contact POSIX guys. does it sound right? > > > itojun > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 14 11:32:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27927 for ; Fri, 14 May 2004 11:32:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeaJ-00087b-PT for ipv6-archive@odin.ietf.org; Fri, 14 May 2004 11:26:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EFQpgr031214 for ipv6-archive@odin.ietf.org; Fri, 14 May 2004 11:26:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeUx-000794-9O for ipv6-web-archive@optimus.ietf.org; Fri, 14 May 2004 11:21:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27477 for ; Fri, 14 May 2004 11:21:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOeUw-0007BE-Ab for ipv6-web-archive@ietf.org; Fri, 14 May 2004 11:21:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOeU3-0006gR-00 for ipv6-web-archive@ietf.org; Fri, 14 May 2004 11:20:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOeTL-0006BB-00 for ipv6-web-archive@ietf.org; Fri, 14 May 2004 11:19:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeIA-0004U4-P7; Fri, 14 May 2004 11:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeHE-00044i-43 for ipv6@optimus.ietf.org; Fri, 14 May 2004 11:07:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26929 for ; Fri, 14 May 2004 11:07:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOeHB-0000FB-EU for ipv6@ietf.org; Fri, 14 May 2004 11:07:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOeG8-0007Xz-00 for ipv6@ietf.org; Fri, 14 May 2004 11:06:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BOeEy-0006af-00 for ipv6@ietf.org; Fri, 14 May 2004 11:04:48 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 14 May 2004 08:04:22 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4EF45Z0027228; Fri, 14 May 2004 11:04:09 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIL96587; Fri, 14 May 2004 11:04:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20040514100704.029c82a0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 May 2004 11:04:07 -0400 To: arunt@india.hp.com From: Ralph Droms Subject: Re: Requesting Comments & Suggestions - ID on Prefix Delegation using ICMPv6 Cc: ipv6@ietf.org, shankar_r@hp.com In-Reply-To: <4093B705.9000100@india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 draft-arunt-prefix-delegation-using-icmpv6-00.txt is an interesting approach to prefix delegation. Looking at it objectively, it appears to me that this protocol largely duplicates the prefix delegation functions in RFC 3633, at an approximately equivalent cost in message exchanges and implementation complexity. Further, I believe there are several issues in prefix delegation that are addressed in RFC 3633, but are not addressed as well or at all in draft-arunt-prefix-delegation-using-icmpv6-00.txt: As I understand the protocol, there is a four message exchange between the RR and the DR for prefix delegation, which is equivalent to the message exchange in RFC 3633. In draft-arunt-prefix-delegation-using-icmpv6-00.txt, the RR must be configured with the address of the DR, while RFC 3633 uses a multicast discovery mechanism. The mechanism for CPE identification seems inadequate, especially as compared to RFC 3633. How is the uniqueness of the 32-bit identifier draft-arunt-prefix-delegation-using-icmpv6-00.txt ensured? In RFC 3633, there are several ways in which a DUID for a device can be formed, with guarantees of uniqueness among all devices. Is there a way in draft-arunt-prefix-delegation-using-icmpv6-00.txt for the DR to communicate a preferred lifetime to the RR? How does draft-arunt-prefix-delegation-using-icmpv6-00.txt address the security issues raised in section 9? There is also a security exposure in prefix revocation (section 7.2), where an attacker spoofing the identity of the DR can cause an RR to stop using previously delegated prefixes. I think RFC 3633 meets the requirements from the prefix delegation requirements document and includes the features needed for deployment of prefix delegation service. We have multiple implementations and have demonstrated interoperability, and RFC 3633 prefix delegation is already in commercial deployment, so I don't see the need at this time to pursue an alternative prefix delegation protocol. - Ralph At 08:11 PM 5/1/2004 +0530, Arun Thulasi wrote: >Hello All, > >We've submitted a draft that describes a mechanism for Prefix Delegation >using ICMPv6 by satisfying the requirements mentioned in Requirements for >IPv6 prefix delegation >(draft-ietf-ipv6-prefix-delegation-requirement-04.txt) .. > >Do let us know your comments and suggestions on the draft .. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 14 17:28:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29060 for ; Fri, 14 May 2004 17:28:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOk6P-0007pL-G0 for ipv6-archive@odin.ietf.org; Fri, 14 May 2004 17:20:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ELKLJ3030088 for ipv6-archive@odin.ietf.org; Fri, 14 May 2004 17:20:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOjwm-0005DC-Bh for ipv6-web-archive@optimus.ietf.org; Fri, 14 May 2004 17:10:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27364 for ; Fri, 14 May 2004 17:10:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOjwk-0002lE-5e for ipv6-web-archive@ietf.org; Fri, 14 May 2004 17:10:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOjtc-0001SZ-00 for ipv6-web-archive@ietf.org; Fri, 14 May 2004 17:07:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOjrO-0000ao-00 for ipv6-web-archive@ietf.org; Fri, 14 May 2004 17:04:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOjbH-0004PU-WD; Fri, 14 May 2004 16:48:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOixa-0003KK-5V for ipv6@optimus.ietf.org; Fri, 14 May 2004 16:07:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20072 for ; Fri, 14 May 2004 16:07:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOixY-0007Wd-E4 for ipv6@ietf.org; Fri, 14 May 2004 16:07:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOiwC-0006rK-00 for ipv6@ietf.org; Fri, 14 May 2004 16:05:44 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1BOiv6-0005vv-00 for ipv6@ietf.org; Fri, 14 May 2004 16:04:36 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i4EK44L09037; Fri, 14 May 2004 13:04:04 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i4EKLo4J015079 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 14 May 2004 13:21:55 -0700 Message-ID: <40A52615.8010801@innovationslab.net> Date: Fri, 14 May 2004 16:03:33 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF Mailing List , mboned@lists.uoregon.edu Subject: Re: Request to Advance "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address" References: <20040507152456.GA12704@1-4-5.net> In-Reply-To: <20040507152456.GA12704@1-4-5.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit IPv6 WG, Please note the advancement of the above draft to the IESG. Anyone having comments can refer them to the mboned mailing list or comment during the IETF Last Call. Regards, Brian & Bob IPv6 WG co-chairs David Meyer wrote: > David and Bert, > > On behalf of the MBONED WG, I would like to request that the > following document be published as a RFC in the Proposed > Standard category: > > Embedding the Rendezvous Point (RP) Address in an IPv6 > Multicast Address > > http://www.ietf.org/internet-drafts/draft-ietf-mboned-embeddedrp-04.txt > > A second Working Group Last Call (WGLC) for this document > was completed on 06 May 2004 with no substantive comment. > > Thank you for your time and consideration, > > Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun May 16 00:32:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28384 for ; Sun, 16 May 2004 00:32:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPDIw-0007lq-71 for ipv6-archive@odin.ietf.org; Sun, 16 May 2004 00:31:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4G4VEIc029866 for ipv6-archive@odin.ietf.org; Sun, 16 May 2004 00:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPDBh-000767-7A for ipv6-web-archive@optimus.ietf.org; Sun, 16 May 2004 00:23:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28011 for ; Sun, 16 May 2004 00:23:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPDBe-000468-Qw for ipv6-web-archive@ietf.org; Sun, 16 May 2004 00:23:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPDAe-0003g6-00 for ipv6-web-archive@ietf.org; Sun, 16 May 2004 00:22:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPDA0-0003IC-00 for ipv6-web-archive@ietf.org; Sun, 16 May 2004 00:22:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPCyT-00048T-Hm; Sun, 16 May 2004 00:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPCvL-0003EA-Jv for ipv6@optimus.ietf.org; Sun, 16 May 2004 00:06:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27255 for ; Sun, 16 May 2004 00:06:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPCvJ-000527-66 for ipv6@ietf.org; Sun, 16 May 2004 00:06:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPCtO-0004Rl-00 for ipv6@ietf.org; Sun, 16 May 2004 00:04:51 -0400 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1BPCpO-0003GL-00 for ipv6@ietf.org; Sun, 16 May 2004 00:00:42 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id CA7252FE for ; Sun, 16 May 2004 00:00:12 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 16 May 2004 00:00:12 -0400 Message-Id: <20040516040012.CA7252FE@cyteen.hactrn.net> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.2 required=5.0 tests=AWL autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 24.24% | 8 | 26.28% | 49256 | jinmei@isl.rdc.toshiba.co.jp 6.06% | 2 | 8.61% | 16136 | huitema@windows.microsoft.com 6.06% | 2 | 8.19% | 15362 | rdroms@cisco.com 6.06% | 2 | 8.01% | 15009 | pekkas@netcore.fi 6.06% | 2 | 6.39% | 11977 | h.soliman@flarion.com 6.06% | 2 | 4.38% | 8204 | brian@innovationslab.net 6.06% | 2 | 4.04% | 7571 | bob.hinden@nokia.com 6.06% | 2 | 3.67% | 6884 | itojun@itojun.org 3.03% | 1 | 6.17% | 11564 | alh-ietf@tndh.net 3.03% | 1 | 2.93% | 5492 | suresh.krishnan@ericsson.ca 3.03% | 1 | 2.86% | 5365 | mukesh.gupta@nokia.com 3.03% | 1 | 2.63% | 4939 | tjc@ecs.soton.ac.uk 3.03% | 1 | 2.49% | 4666 | stig.venaas@uninett.no 3.03% | 1 | 2.45% | 4601 | peter.grubmair@siemens.com 3.03% | 1 | 2.33% | 4366 | sra+ipng@hactrn.net 3.03% | 1 | 2.28% | 4272 | jordi.palet@consulintel.es 3.03% | 1 | 2.23% | 4178 | brc@zurich.ibm.com 3.03% | 1 | 2.17% | 4075 | ipng@uni-muenster.de 3.03% | 1 | 1.89% | 3539 | tim@mentat.com --------+------+--------+----------+------------------------ 100.00% | 33 |100.00% | 187456 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun May 16 10:02:39 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02391 for ; Sun, 16 May 2004 10:02:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPM9y-0002R1-3s for ipv6-archive@odin.ietf.org; Sun, 16 May 2004 09:58:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4GDwYUw009357 for ipv6-archive@odin.ietf.org; Sun, 16 May 2004 09:58:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPM4o-0001wz-AV for ipv6-web-archive@optimus.ietf.org; Sun, 16 May 2004 09:53:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02076 for ; Sun, 16 May 2004 09:53:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPM4m-0005Jx-Hh for ipv6-web-archive@ietf.org; Sun, 16 May 2004 09:53:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPM3e-0004yQ-00 for ipv6-web-archive@ietf.org; Sun, 16 May 2004 09:52:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPM2z-0004dv-00 for ipv6-web-archive@ietf.org; Sun, 16 May 2004 09:51:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPLws-0000gW-Kt; Sun, 16 May 2004 09:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP2NS-0006US-Hm for ipv6@optimus.ietf.org; Sat, 15 May 2004 12:51:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29858 for ; Sat, 15 May 2004 12:51:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP2NQ-0004Lc-Nr for ipv6@ietf.org; Sat, 15 May 2004 12:51:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP2Mc-0003xt-00 for ipv6@ietf.org; Sat, 15 May 2004 12:50:18 -0400 Received: from web8311.mail.in.yahoo.com ([203.199.122.11]) by ietf-mx with smtp (Exim 4.12) id 1BP2Ld-0003CE-00 for ipv6@ietf.org; Sat, 15 May 2004 12:49:18 -0400 Message-ID: <20040515164845.71519.qmail@web8311.mail.in.yahoo.com> Received: from [210.210.35.149] by web8311.mail.in.yahoo.com via HTTP; Sat, 15 May 2004 17:48:45 BST Date: Sat, 15 May 2004 17:48:45 +0100 (BST) From: =?iso-8859-1?q?Girish=20Kamath?= Subject: RE: Scope Issue To: "sasson, shuki" Cc: ipv6@ietf.org In-Reply-To: <33CE6457C7003A478381BCD0B584DEC502741712@srmoon.eng.emc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-687868871-1084639725=:60705" Content-Transfer-Encoding: 8bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_40_50, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 --0-687868871-1084639725=:60705 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello Shuki, ND messages are always sent with a hop-limit of 255. So a router is not supposed to forward a ND packet recieved.Thus ND messages are restricted over a single link.So i can't see a scenario when a ND message will be forwarded by a gateway. You said that NS message always uses a link-local address as a source address. Is it true even when a node is configured with global unicast addresses. Taking our example if we have node A which is configured with both link-local and global unicast address can node A form a NS message with link-local as source address and destination as global unicast address to refresh its neighbor cache. "sasson, shuki" wrote: Hi Girish, you probably refer to Neighbor Solicitation message which is always using link locals as a source address. That would be possible. However pay attention to the following fact. When you send a message using a link local address as a source address this message cannot pass a gateway. For that you will need a global unicast address. Shuki -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Girish Kamath Sent: Thursday, May 06, 2004 11:59 AM To: ipv6@ietf.org Subject: Scope Issue Hello, For Neighbor Discovery messages, is it mandatory that the scope of the source and destination address should match? If i have just a link-local unicast address on a node A connected to another node B which has global unicast addresses configured, can i form a ND message with source address as link-local unicast address and destination address as global unicast address when sending a ND packet from A to B. -- Girish Yahoo! India Matrimony: Find your partner online. Yahoo! India Matrimony: Find your partner online. --0-687868871-1084639725=:60705 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hello Shuki,
   ND messages are always sent with a hop-limit of 255. So a router is not supposed to forward a ND packet recieved.Thus ND messages are restricted over a single link.So i can't see a scenario when a ND message will be forwarded by a gateway.
  You said that NS message always uses a link-local address as a source address. Is it true even when a node is configured with global unicast addresses. Taking our example if we have node A which is configured with both link-local and global unicast address can node A form a NS message with  link-local as source address and destination as global unicast address to refresh its neighbor cache.


"sasson, shuki" <sasson_shuki@emc.com> wrote:

Hi Girish,  you probably refer to Neighbor Solicitation message which is always using link locals as a source address. That would be possible. However pay attention to the following fact.

When you send a message using a link local address as a source address this message cannot pass a gateway. For that you will need a global unicast address.

 

Shuki

 

-----Original Message-----
From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Girish Kamath
Sent: Thursday, May 06, 2004 11:59 AM
To: ipv6@ietf.org
Subject: Scope Issue

 

Hello,
      For Neighbor Discovery messages, is it mandatory that the scope of the source and destination address should match?
If i have just a link-local unicast address on a node A connected to another node B which has global unicast addresses configured, can i form a ND message with source address as link-local unicast address and destination address as global unicast address when sending a ND packet from A to B.

 

-- Girish

Yahoo! India Matrimony: Find your partner online.

Yahoo! India Matrimony: Find your partner online. --0-687868871-1084639725=:60705-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun May 16 18:24:24 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25642 for ; Sun, 16 May 2004 18:24:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPU2Q-0007zx-RG for ipv6-archive@odin.ietf.org; Sun, 16 May 2004 18:23:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4GMNIW8030738 for ipv6-archive@odin.ietf.org; Sun, 16 May 2004 18:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPU0i-0007mA-GB for ipv6-web-archive@optimus.ietf.org; Sun, 16 May 2004 18:21:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25465 for ; Sun, 16 May 2004 18:21:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPU0f-0002tY-KK for ipv6-web-archive@ietf.org; Sun, 16 May 2004 18:21:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPTyn-0002LD-00 for ipv6-web-archive@ietf.org; Sun, 16 May 2004 18:19:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPTwu-0001t8-00 for ipv6-web-archive@ietf.org; Sun, 16 May 2004 18:17:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPTmf-0001dC-HG; Sun, 16 May 2004 18:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPTk7-0000hX-Hi for ipv6@optimus.ietf.org; Sun, 16 May 2004 18:04:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23984 for ; Sun, 16 May 2004 18:04:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPTk4-0005qg-Ok for ipv6@ietf.org; Sun, 16 May 2004 18:04:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPTjD-0005YX-00 for ipv6@ietf.org; Sun, 16 May 2004 18:03:28 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BPTij-0005Fy-00 for ipv6@ietf.org; Sun, 16 May 2004 18:02:57 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) with ESMTP id i4GM2ouK003714; Mon, 17 May 2004 01:02:50 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) id i4GM2oHA003711; Mon, 17 May 2004 01:02:50 +0300 Date: Mon, 17 May 2004 01:02:50 +0300 Message-Id: <200405162202.i4GM2oHA003711@burp.tkv.asdf.org> From: Markku Savela To: Mukesh.Gupta@nokia.com CC: ipv6@ietf.org In-reply-to: <8D260779A766FB4A9C1739A476F84FA401F79A35@daebe009.americas.nokia.com> (Mukesh.Gupta@nokia.com) Subject: Re: ICMPv3: Message Source Address Determination.. References: <8D260779A766FB4A9C1739A476F84FA401F79A35@daebe009.americas.nokia.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 > From: Mukesh.Gupta@nokia.com > [Please express your opinion. It is needed to make > the informed decision.] > > Pekka raised a concern about the usability of one of the > methods (section 2.2 (c)) to select the source address > of the ICMPv3 packet. I want to know if anyone has > implemented it ? or how useful and practical this > method is in your opinion ? > > The decision that I want to make is to whether we should > keep it in the draft or remove it. > > Here is the text for quick reference. > ==================================================== > (c) If the message is a response to a message sent to > an address that does not belong to the node, the > Source Address should be that unicast address > belonging to the node that will be most helpful > in diagnosing the error. For example, if the message > is a response to a packet forwarding action that > cannot complete successfully, the Source Address > should be a unicast address belonging to the > interface on which the packet forwarding failed. > ==================================================== > > and here is the link to the current draft for quick > reference. > http://ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-03.txt Currently I have following simple logic a) src address is the destination address of the packet to which ICMP is related. b) if the address of step (a) is not a valid address on the interface to which the ICMP is destined, the new valid source address is selected. I don't think it is good for *any* RFC to require a stack to send packets with wrong source address. Thus, if the ICMP draft seems to require such illegal thing, I think the draft needs revision. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 00:55:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14451 for ; Mon, 17 May 2004 00:55:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPa4l-00042U-J3 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 00:50:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H4o7I9015522 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 00:50:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPa1K-0003Xu-Rj for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 00:46:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13997 for ; Mon, 17 May 2004 00:46:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPa1I-0000lS-A8 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 00:46:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPa0J-0000TW-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 00:45:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPZzK-00006G-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 00:44:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPZqA-0001t1-HE; Mon, 17 May 2004 00:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPZl9-0001P3-IF for ipv6@optimus.ietf.org; Mon, 17 May 2004 00:29:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13067 for ; Mon, 17 May 2004 00:29:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPZl6-0003Rl-On for ipv6@ietf.org; Mon, 17 May 2004 00:29:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPZj7-0002fF-00 for ipv6@ietf.org; Mon, 17 May 2004 00:27:47 -0400 Received: from web8304.mail.in.yahoo.com ([203.199.122.34]) by ietf-mx with smtp (Exim 4.12) id 1BPZgV-0001rh-00 for ipv6@ietf.org; Mon, 17 May 2004 00:25:04 -0400 Message-ID: <20040517042433.10792.qmail@web8304.mail.in.yahoo.com> Received: from [61.95.177.131] by web8304.mail.in.yahoo.com via HTTP; Mon, 17 May 2004 05:24:33 BST Date: Mon, 17 May 2004 05:24:33 +0100 (BST) From: =?iso-8859-1?q?Girish=20Kamath?= Subject: RE: Scope Issue To: "sasson, shuki" Cc: ipv6@ietf.org In-Reply-To: <33CE6457C7003A478381BCD0B584DEC502741712@srmoon.eng.emc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2114109530-1084767873=:8763" Content-Transfer-Encoding: 8bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_40_50,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 --0-2114109530-1084767873=:8763 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello Shuki, ND messages are always sent with a hop-limit of 255. So a router is not supposed to forward a ND packet recieved.Thus ND messages are restricted over a single link.So i can't see a scenario when a ND message will be forwarded by a gateway. You said that NS message always uses a link-local address as a source address. Is it true even when a node is configured with global unicast addresses. Taking our example if we have node A which is configured with both link-local and global unicast address can node A form a NS message with link-local as source address and destination as global unicast address(B's address) to refresh its neighbor cache? Thanks -----Girish "sasson, shuki" wrote: Hi Girish, you probably refer to Neighbor Solicitation message which is always using link locals as a source address. That would be possible. However pay attention to the following fact. When you send a message using a link local address as a source address this message cannot pass a gateway. For that you will need a global unicast address. Shuki -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Girish Kamath Sent: Thursday, May 06, 2004 11:59 AM To: ipv6@ietf.org Subject: Scope Issue Hello, For Neighbor Discovery messages, is it mandatory that the scope of the source and destination address should match? If i have just a link-local unicast address on a node A connected to another node B which has global unicast addresses configured, can i form a ND message with source address as link-local unicast address and destination address as global unicast address when sending a ND packet from A to B. -- Girish Yahoo! India Matrimony: Find your partner online. Yahoo! India Matrimony: Find your partner online. --0-2114109530-1084767873=:8763 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hello Shuki,
   ND messages are always sent with a hop-limit of 255. So a router is not supposed to forward a ND packet recieved.Thus ND messages are restricted over a single link.So i can't see a scenario when a ND message will be forwarded by a gateway.
  You said that NS message always uses a link-local address as a source address. Is it true even when a node is configured with global unicast addresses. Taking our example if we have node A which is configured with both link-local and global unicast address can node A form a NS message with  link-local as source address and destination as global unicast address(B's address) to refresh its neighbor cache?
Thanks
 
-----Girish

"sasson, shuki" <sasson_shuki@emc.com> wrote:

Hi Girish,  you probably refer to Neighbor Solicitation message which is always using link locals as a source address. That would be possible. However pay attention to the following fact.

When you send a message using a link local address as a source address this message cannot pass a gateway. For that you will need a global unicast address.

 

Shuki

 

-----Original Message-----
From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Girish Kamath
Sent: Thursday, May 06, 2004 11:59 AM
To: ipv6@ietf.org
Subject: Scope Issue

 

Hello,
      For Neighbor Discovery messages, is it mandatory that the scope of the source and destination address should match?
If i have just a link-local unicast address on a node A connected to another node B which has global unicast addresses configured, can i form a ND message with source address as link-local unicast address and destination address as global unicast address when sending a ND packet from A to B.

 

-- Girish

Yahoo! India Matrimony: Find your partner online.

Yahoo! India Matrimony: Find your partner online. --0-2114109530-1084767873=:8763-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 01:58:02 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16519 for ; Mon, 17 May 2004 01:58:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPb4d-0003W2-Fb for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 01:54:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H5s3gR013514 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 01:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPaue-0002PY-Kq for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 01:43:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16011 for ; Mon, 17 May 2004 01:43:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPaub-0001yR-Ga for ipv6-web-archive@ietf.org; Mon, 17 May 2004 01:43:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPatj-0001ga-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 01:42:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPasn-0001OM-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 01:41:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPaoA-0001Lo-27; Mon, 17 May 2004 01:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPamv-00016n-3A for ipv6@optimus.ietf.org; Mon, 17 May 2004 01:35:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15728 for ; Mon, 17 May 2004 01:35:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPamr-0007Nu-S7 for ipv6@ietf.org; Mon, 17 May 2004 01:35:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPaly-00075Z-00 for ipv6@ietf.org; Mon, 17 May 2004 01:34:47 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1BPakO-0006XE-00 for ipv6@ietf.org; Mon, 17 May 2004 01:33:08 -0400 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4H5VhhQ017385 for ; Sun, 16 May 2004 23:31:44 -0600 (MDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0HXU00601EQI6A@bur-mail2.east.sun.com> (original mail from Sebastien.Roy@Sun.COM) for ipv6@ietf.org; Mon, 17 May 2004 01:33:08 -0400 (EDT) Received: from Sun.COM (punchin-seb.SFBay.Sun.COM [192.9.61.15]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0HXU001FSFF6ND@bur-mail2.east.sun.com>; Mon, 17 May 2004 01:33:08 -0400 (EDT) Date: Mon, 17 May 2004 01:32:15 -0400 From: Sebastien Roy Subject: Re: Scope Issue In-reply-to: <20040517042433.10792.qmail@web8304.mail.in.yahoo.com> To: Girish Kamath Cc: "sasson, shuki" , ipv6@ietf.org Message-id: <40A84E5F.3000204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.5 (X11/20040212) References: <20040517042433.10792.qmail@web8304.mail.in.yahoo.com> Content-Transfer-Encoding: 7BIT 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Girish Kamath wrote: > NS message *always* uses a link-local address as a source address. That is false. The source address of NS packets SHOULD be the same as the source address of the packet that promps the NS packet to be sent. See section 7.2.2 of RFC2461. > Is it true even when a node is configured with global > unicast addresses. Taking our example if we have node A which is > configured with both link-local and global unicast address can node A > form a NS message with link-local as source address and destination as > global unicast address(B's address) to refresh its neighbor cache? Sure, it can (there's no MUST in the spec), but why would it? -Seb -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 02:10:26 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24659 for ; Mon, 17 May 2004 02:10:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbEb-00065O-0b for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 02:04:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H64KY4023394 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 02:04:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbD7-0005KX-CQ for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 02:02:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18710 for ; Mon, 17 May 2004 02:02:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPbD3-0007lV-U9 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 02:02:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPbCN-0007TU-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 02:02:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPbBW-0007AT-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 02:01:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPb5b-0003dK-9R; Mon, 17 May 2004 01:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPaxS-0002jG-Jc for ipv6@optimus.ietf.org; Mon, 17 May 2004 01:46:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16119 for ; Mon, 17 May 2004 01:46:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPaxP-0002rQ-BR for ipv6@ietf.org; Mon, 17 May 2004 01:46:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPawQ-0002Z5-00 for ipv6@ietf.org; Mon, 17 May 2004 01:45:34 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BPavP-00020k-00 for ipv6@ietf.org; Mon, 17 May 2004 01:44:31 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:4103:5074:9c90:4e33]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1142C15273; Mon, 17 May 2004 14:44:23 +0900 (JST) Date: Mon, 17 May 2004 14:44:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Fred Templin Cc: ipv6@ietf.org, h.soliman@flarion.com Subject: Re: RFC2461(bis) Issue - LLAO's for NS/NA In-Reply-To: <40994FE0.1070406@iprg.nokia.com> References: <72479c729d88.729d8872479c@mail1.monash.edu.au> <40994FE0.1070406@iprg.nokia.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Wed, 05 May 2004 13:34:40 -0700, >>>>> Fred Templin said: > Suggested fix is to change the 4th sentence of the first paragraph > of section 7.2.4 to: > "If the solicitation's IP Destination Address is a multicast address, > the node MUST include its link-layer address (if it has one) > as a Target Link-Layer Address option in the advertisement." The suggestion looks sane. 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 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 02:18:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00502 for ; Mon, 17 May 2004 02:18:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbRF-0002ev-5H for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 02:17:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H6HPXL010222 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 02:17:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbQW-0002O6-33 for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 02:16:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29837 for ; Mon, 17 May 2004 02:16:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPbQS-0004Kg-JW for ipv6-web-archive@ietf.org; Mon, 17 May 2004 02:16:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPbPT-0003yj-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 02:15:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPbOP-0003Tl-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 02:14:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbFK-0006VO-VH; Mon, 17 May 2004 02:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbA3-00047Q-LY for ipv6@optimus.ietf.org; Mon, 17 May 2004 01:59:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16562 for ; Mon, 17 May 2004 01:59:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPbA0-0006n7-A5 for ipv6@ietf.org; Mon, 17 May 2004 01:59:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPb90-0006Re-00 for ipv6@ietf.org; Mon, 17 May 2004 01:58:35 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BPb7v-0005uC-00 for ipv6@ietf.org; Mon, 17 May 2004 01:57:27 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:4103:5074:9c90:4e33]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id DF7FD1525D; Mon, 17 May 2004 14:57:27 +0900 (JST) Date: Mon, 17 May 2004 14:57:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Girish Kamath Cc: ipv6@ietf.org Subject: Re: Scope Issue In-Reply-To: <20040506155920.78473.qmail@web8302.mail.in.yahoo.com> References: <20040506155920.78473.qmail@web8302.mail.in.yahoo.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 >>>>> On Thu, 6 May 2004 16:59:20 +0100 (BST), >>>>> Girish Kamath said: > For Neighbor Discovery messages, is it mandatory that the scope of the source and destination address should match? > If i have just a link-local unicast address on a node A connected to another node B which has global unicast addresses configured, can i form a ND message with source address as link-local unicast address and destination address as global unicast address when sending a ND packet from A to B. Yes, you can. 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 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 03:44:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04770 for ; Mon, 17 May 2004 03:44:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcm2-0008Ov-2s for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 03:42:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H7gw3a032289 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 03:42:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcjv-00081d-47 for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 03:40:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04623 for ; Mon, 17 May 2004 03:40:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPcjs-0006oX-OM for ipv6-web-archive@ietf.org; Mon, 17 May 2004 03:40:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPcix-0006Wd-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 03:39:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPciL-0006EZ-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 03:39:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcbT-0006ZI-9T; Mon, 17 May 2004 03:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcTc-0005Zd-6g for ipv6@optimus.ietf.org; Mon, 17 May 2004 03:23:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03875 for ; Mon, 17 May 2004 03:23:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPcTZ-0001Xk-US for ipv6@ietf.org; Mon, 17 May 2004 03:23:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPcSW-0001E7-00 for ipv6@ietf.org; Mon, 17 May 2004 03:22:49 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BPcRP-0000tI-00 for ipv6@ietf.org; Mon, 17 May 2004 03:21:39 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:4103:5074:9c90:4e33]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E2DE31525D; Mon, 17 May 2004 16:21:38 +0900 (JST) Date: Mon, 17 May 2004 16:21:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mukesh.Gupta@nokia.com Cc: Subject: Re: ICMPv3: Message Source Address Determination.. In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401F79A35@daebe009.americas.nokia.com> References: <8D260779A766FB4A9C1739A476F84FA401F79A35@daebe009.americas.nokia.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Thu, 13 May 2004 14:54:23 -0500, >>>>> Mukesh.Gupta@nokia.com said: > Pekka raised a concern about the usability of one of the > methods (section 2.2 (c)) to select the source address > of the ICMPv3 packet. I want to know if anyone has > implemented it ? or how useful and practical this > method is in your opinion ? I've once tried to implement this case, particularly for the scenario where a router is sending an ICMPv6 destination unreachable message when it finds the next hop is unreachable. However, I personally haven't find this very useful, and, in fact, I've even not known whether it was really working. After several revises, our current code does not have this trick. Regarding the revise for icmp-v3, I have no particular opinion. Although I personally see no clear benefits of 2.2. (c), I don't see clear disadvantage either. And, through my recent experiences on the rfc2462bis work, people seem to disagree on removing an already-documented feature in a recycling work unless the feature is clearly shown to be harmful. In the end, I can live with or without removing 2.2 (c). 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 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 05:02:27 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08668 for ; Mon, 17 May 2004 05:02:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPdxW-0002U0-Uk for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 04:58:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H8ws33009544 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 04:58:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPdwa-0002I2-JM for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 04:57:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08491 for ; Mon, 17 May 2004 04:57:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPdwX-0007cM-HR for ipv6-web-archive@ietf.org; Mon, 17 May 2004 04:57:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPdvh-0007JO-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 04:57:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPdur-000703-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 04:56:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPdm7-0000sl-65; Mon, 17 May 2004 04:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPdj4-0000Pb-Fb for ipv6@optimus.ietf.org; Mon, 17 May 2004 04:43:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07727 for ; Mon, 17 May 2004 04:43:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPdj1-0003In-Fu for ipv6@ietf.org; Mon, 17 May 2004 04:43:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPdi2-0002zK-00 for ipv6@ietf.org; Mon, 17 May 2004 04:42:55 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BPdhN-0002gF-00 for ipv6@ietf.org; Mon, 17 May 2004 04:42:15 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:4103:5074:9c90:4e33]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9BACC1525D for ; Mon, 17 May 2004 17:42:13 +0900 (JST) Date: Mon, 17 May 2004 17:42:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols In-Reply-To: References: 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Are folks happy with the following approach? I've not seen any objections (or any agreements either), but I'm not sure if I can start editing based on the proposal, considering the fact that this is quite a big set of changes. Explicit support or objections are highly appreciated. If the list is still silent, I'll start revising the document anyway. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp >>>>> On Thu, 13 May 2004 20:00:14 +0900, >>>>> JINMEI Tatuya said: >> Although his suggestion was apparently supported by several key >> players in this group, I'm afraid details on actual changes for >> rfc2462bis may still vary. So I'll soon throw concrete idea of the >> changes based on my own interpretation of his suggestion in a separate >> message. > And here are the proposed changes. The basic idea is: > 1. clarify (change) the meaning of the M/O flags; they are just hints > of availability of the corresponding services, not triggers for > invoking the protocols under a certain level of requirement > 2. remove "requirements" regarding these flags according to the above > change > 3. (optionally) make a separate document (standard or BCP) on how to > interact the protocols with these flags > (In the followings, I'm assuming we have agreed that > - we should clearly specify the corresponding protocols for the M/O > flags > - the protocol for the M flag is DHCPv6 (RFC3315) > - the protocol for the O flag is the "stateless" subset of DHCPv6 > (RFC3736) > but these details are not the essential part of the proposal.) > The followings are some concrete examples of how I'd revise the > document based on the idea. > For 1, I'd revise the following sentence of RFC2462 Section 4 (page > 9): > A "managed address configuration" flag indicates whether hosts > should use stateful autoconfiguration to obtain addresses. > to: > A "managed address configuration" flag indicates whether DHCPv6 is > available for hosts to obtain addresses. > For 2, > - remove the notion of the ManagedFlag and OtherConfigFlag > (conceptual) variables defined in Section 5.2, since these flags > will become meaningless if we do not mandate invoking particular > protocols by the RA M/O flags. > - remove "requirement" sentences like the following one > 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, requesting both address > information and other information. > (Section 5.5.3 of RFC2462) > - remove Section 5.5.2 of RFC2462 (that mandates performing the > "stateful" protocol when no RAs) > Hopefully, these are not so different from what others imagined by > Christian's suggestion. But I'm not that optimistic, and expect > objections. Please make comments on the idea shown above, > particularly if you have an objection. > Thanks, > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 05:25:39 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09506 for ; Mon, 17 May 2004 05:25:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPeJg-0005Il-HF for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 05:21:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H9LmAS020358 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 05:21:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPeDx-0004h7-N0 for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 05:15:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09235 for ; Mon, 17 May 2004 05:15:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPeDu-0005OF-G3 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 05:15:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPeCx-000542-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 05:14:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPeC4-0004k4-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 05:13:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPe5R-0003LV-Sx; Mon, 17 May 2004 05:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPe2H-0002uS-TA for ipv6@optimus.ietf.org; Mon, 17 May 2004 05:03:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08825 for ; Mon, 17 May 2004 05:03:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPe2E-0001eB-IW for ipv6@ietf.org; Mon, 17 May 2004 05:03:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPe1E-0001KY-00 for ipv6@ietf.org; Mon, 17 May 2004 05:02:45 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BPe0G-00011N-00 for ipv6@ietf.org; Mon, 17 May 2004 05:01:44 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4H91j7s004666 for ; Mon, 17 May 2004 10:01:45 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA20205 for ; Mon, 17 May 2004 10:01:44 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4H91iv09350 for ipv6@ietf.org; Mon, 17 May 2004 10:01:44 +0100 Date: Mon, 17 May 2004 10:01:44 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols Message-ID: <20040517090144.GC8946@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 On Mon, May 17, 2004 at 05:42:29PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > Explicit support or objections are highly appreciated. If the list is > still silent, I'll start revising the document anyway. I agree with the changes, though... > > - remove "requirement" sentences like the following one > > 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, requesting both address > > information and other information. > > (Section 5.5.3 of RFC2462) > > - remove Section 5.5.2 of RFC2462 (that mandates performing the > > "stateful" protocol when no RAs) Perhaps these can be written as "may" rather than "should"? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 05:35:55 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10050 for ; Mon, 17 May 2004 05:35:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPeRj-0006Rg-Nf for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 05:30:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H9U7fs024773 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 05:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPeNg-00061d-9S for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 05:25:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09540 for ; Mon, 17 May 2004 05:25:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPeNc-0000aO-Vb for ipv6-web-archive@ietf.org; Mon, 17 May 2004 05:25:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPeMi-0000HQ-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 05:24:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPeLw-0007mC-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 05:24:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPeEC-0004oK-Fd; Mon, 17 May 2004 05:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPe9z-0003sK-Ch for ipv6@optimus.ietf.org; Mon, 17 May 2004 05:11:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09028 for ; Mon, 17 May 2004 05:11:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPe9v-00046W-OM for ipv6@ietf.org; Mon, 17 May 2004 05:11:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPe8x-0003nI-00 for ipv6@ietf.org; Mon, 17 May 2004 05:10:43 -0400 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1BPe7w-0003PP-00 for ipv6@ietf.org; Mon, 17 May 2004 05:09:40 -0400 Received: from [128.176.184.156] (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.11/8.12.9) with ESMTP id i4H99Up0013916 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 17 May 2004 11:09:35 +0200 (CEST) Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols From: "Christian Strauf (JOIN)" To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= Cc: ipv6@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: JOIN-Team, WWU-Muenster Message-Id: <1084784969.9587.30.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 17 May 2004 11:09:30 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jinmei, > Explicit support or objections are highly appreciated. If the list is > still silent, I'll start revising the document anyway. I support all of your proposed changes. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 07:42:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15589 for ; Mon, 17 May 2004 07:42:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgTO-0006V1-VU for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 07:39:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HBdwpH024979 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 07:39:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgOB-0005Wc-Eb for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 07:34:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14765 for ; Mon, 17 May 2004 07:34:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPgOA-0001BL-QU for ipv6-web-archive@ietf.org; Mon, 17 May 2004 07:34:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPgMv-0000pp-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 07:33:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPgMD-0000Vl-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 07:32:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgDy-0003oa-V4; Mon, 17 May 2004 07:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPg91-000343-93 for ipv6@optimus.ietf.org; Mon, 17 May 2004 07:18:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13964 for ; Mon, 17 May 2004 07:18:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPg90-0004Bv-KQ for ipv6@ietf.org; Mon, 17 May 2004 07:18:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPg83-0003r9-00 for ipv6@ietf.org; Mon, 17 May 2004 07:17:56 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BPg76-0003Ux-00 for ipv6@ietf.org; Mon, 17 May 2004 07:16:57 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:4103:5074:9c90:4e33]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4CB7A1525D; Mon, 17 May 2004 20:16:49 +0900 (JST) Date: Mon, 17 May 2004 20:17:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Chown Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols In-Reply-To: <20040517090144.GC8946@login.ecs.soton.ac.uk> References: <20040517090144.GC8946@login.ecs.soton.ac.uk> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Mon, 17 May 2004 10:01:44 +0100, >>>>> Tim Chown said: >> Explicit support or objections are highly appreciated. If the list is >> still silent, I'll start revising the document anyway. > I agree with the changes, though... >> > - remove "requirement" sentences like the following one >> > 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, requesting both address >> > information and other information. >> > (Section 5.5.3 of RFC2462) >> > - remove Section 5.5.2 of RFC2462 (that mandates performing the >> > "stateful" protocol when no RAs) > Perhaps these can be written as "may" rather than "should"? Please let me check: are you suggesting to replace the "should"s with "may"s instead of removing these sentences (which is my proposal)? 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 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 08:05:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16967 for ; Mon, 17 May 2004 08:05:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgqc-0001CS-S8 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 08:03:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HC3w6L004609 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 08:03:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgni-0000rK-8K for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 08:00:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16775 for ; Mon, 17 May 2004 08:00:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPgnh-0002UV-Cy for ipv6-web-archive@ietf.org; Mon, 17 May 2004 08:00:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPgmf-0002Ab-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 07:59:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPgle-0001qt-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 07:58:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgdB-0007uN-BN; Mon, 17 May 2004 07:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgbU-0007h0-3b for ipv6@optimus.ietf.org; Mon, 17 May 2004 07:48:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16022 for ; Mon, 17 May 2004 07:48:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPgbT-00064K-9V for ipv6@ietf.org; Mon, 17 May 2004 07:48:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPgaG-0005h7-00 for ipv6@ietf.org; Mon, 17 May 2004 07:47:04 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BPgZI-0005Ir-00 for ipv6@ietf.org; Mon, 17 May 2004 07:46:04 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4HBk37s008733 for ; Mon, 17 May 2004 12:46:03 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA00404 for ; Mon, 17 May 2004 12:45:59 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4HBjxb14304 for ipv6@ietf.org; Mon, 17 May 2004 12:45:59 +0100 Date: Mon, 17 May 2004 12:45:59 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols Message-ID: <20040517114559.GO8946@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <20040517090144.GC8946@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 On Mon, May 17, 2004 at 08:17:04PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > Please let me check: are you suggesting to replace the "should"s with > "may"s instead of removing these sentences (which is my proposal)? Yes. I suspect implementations may do both, thus rather than implementors looking at the spec and wondering whether the issue has been considered, a "may" shows that it has, and the behaviour is their choice. I do not feel strongly on it though, so would also support removal. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 08:43:21 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19142 for ; Mon, 17 May 2004 08:43:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhQu-0006tt-Rl for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 08:41:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HCfSiR026521 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 08:41:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhK0-0005uG-7y for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 08:34:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18551 for ; Mon, 17 May 2004 08:34:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPhJz-0005fd-3G for ipv6-web-archive@ietf.org; Mon, 17 May 2004 08:34:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPhHs-00051J-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 08:32:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPhGf-0004af-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 08:30:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPh6D-0003jA-V0; Mon, 17 May 2004 08:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPh1n-000328-2G for ipv6@optimus.ietf.org; Mon, 17 May 2004 08:15:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17852 for ; Mon, 17 May 2004 08:15:29 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPh1l-0007Qv-QW for ipv6@ietf.org; Mon, 17 May 2004 08:15:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPgzh-0006iv-00 for ipv6@ietf.org; Mon, 17 May 2004 08:13:22 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BPgxe-0005jU-00 for ipv6@ietf.org; Mon, 17 May 2004 08:11:14 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4HCBDe27246 for ; Mon, 17 May 2004 15:11:13 +0300 (EET DST) X-Scanned: Mon, 17 May 2004 15:11:09 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4HCB9dZ028583 for ; Mon, 17 May 2004 15:11:09 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00In69uf; Mon, 17 May 2004 15:11:07 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4HCB7H23398 for ; Mon, 17 May 2004 15:11:07 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 May 2004 15:11:06 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 May 2004 15:11:06 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: DNS support in the Node Requirements draft Date: Mon, 17 May 2004 15:11:06 +0300 Message-ID: Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols Thread-Index: AcQ8Bcy4IXYkwkcqRGWY/bUzhMlv+wAADGUg To: X-OriginalArrivalTime: 17 May 2004 12:11:06.0521 (UTC) FILETIME=[0805A890:01C43C08] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, Based upon some discussion regarding a DISCUSS during IESG review, I am=20 updating section 5.2 DNS Current text says: DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] and [RFC-3596] MAY be supported. Not all nodes will need to resolve names. All nodes that need to resolve names SHOULD implement stub- resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with support for: - AAAA type Resource Records [RFC-3596]; - reverse addressing in ip6.arpa using PTR records [RFC-3152]; - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 octets. Suggested new text is: DNS, is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] and [RFC-3596]. Not all nodes will need to resolve names, and those that will never need to resolve DNS names do not need to implement resolver functionality. However, the ability to resolve names is a basic infrastructure capability that applications rely on and generally needs to be supported. All nodes that need to=20 resolve names SHOULD implement stub-resolver [RFC-1034] = functionality,=20 in RFC 1034 section 5.3.1 with support for: - AAAA type Resource Records [RFC-3596]; - reverse addressing in ip6.arpa using PTR records [RFC-3152]; - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 octets. Let me know if this causes anyone any trouble. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 13:07:20 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05725 for ; Mon, 17 May 2004 13:07:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlL4-0001pX-N5 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 12:51:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HGpgv5007035 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 12:51:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlEs-00012D-4z for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 12:45:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04224 for ; Mon, 17 May 2004 12:45:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPlEq-0004MQ-It for ipv6-web-archive@ietf.org; Mon, 17 May 2004 12:45:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlDy-00041o-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 12:44:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPlDM-0003h4-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 12:43:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkz8-0006LO-2A; Mon, 17 May 2004 12:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkqp-0004WA-Ow for ipv6@optimus.ietf.org; Mon, 17 May 2004 12:20:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02322 for ; Mon, 17 May 2004 12:20:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPkqo-00034t-B5 for ipv6@ietf.org; Mon, 17 May 2004 12:20:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPkpm-0002iF-00 for ipv6@ietf.org; Mon, 17 May 2004 12:19:22 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1BPkow-0002Mv-00 for ipv6@ietf.org; Mon, 17 May 2004 12:18:30 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4HGGthO017660; Mon, 17 May 2004 10:16:56 -0600 (MDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4HGIKQ15241; Mon, 17 May 2004 18:18:20 +0200 (MEST) Date: Mon, 17 May 2004 09:18:23 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Overall your proposal is good. > - remove "requirement" sentences like the following one > 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, requesting both address > information and other information. > (Section 5.5.3 of RFC2462) I think I'm suggesting the same thing as Tim. Loosing the above setence means that implementations might not look for changes in the flag value (but perhaps instead only look at the flag in the first RA). So saying something like Hosts which invoke DHCPv6 based on the ManagedFlag need to not only look for this flag when booting, but also observe whether the ManagedFlag changes from FALSE to TRUE in a subsequent Router Advertisement. > > - remove Section 5.5.2 of RFC2462 (that mandates performing the > > "stateful" protocol when no RAs) Restating that to not be a requirement also makes sense. I think the section should become more of a note which points out that in the absense of any routers hence router advertisements, stateless address autoconfiguration isn't available and that a host MAY wish to use DHCPv6 in this case. It would presumably make sense to clarify in that section that even if this is done the host continues to operate the stateless protocol i.e. the reception of a router advertisement (with A-flag in one or more prefix option) in the future will trigger stateless. This is to make it more clear that the absense of a router while booting must not automatically "turn off" the stateless protocol. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 13:43:31 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07896 for ; Mon, 17 May 2004 13:43:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPm1d-0008QR-M1 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 13:35:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HHZfcf032388 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 13:35:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlyU-0007qW-Ij for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 13:32:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07150 for ; Mon, 17 May 2004 13:32:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPlyS-0004yq-IF for ipv6-web-archive@ietf.org; Mon, 17 May 2004 13:32:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlxa-0004dy-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 13:31:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPlx1-0004Ic-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 13:30:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlel-00056p-Gr; Mon, 17 May 2004 13:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlXV-0003RK-N3 for ipv6@optimus.ietf.org; Mon, 17 May 2004 13:04:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05417 for ; Mon, 17 May 2004 13:04:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPlXT-0003A1-RW for ipv6@ietf.org; Mon, 17 May 2004 13:04:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlWM-0002nX-00 for ipv6@ietf.org; Mon, 17 May 2004 13:03:23 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BPlVN-0002Qx-00 for ipv6@ietf.org; Mon, 17 May 2004 13:02:21 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4HH2Ldc021882 for ; Mon, 17 May 2004 11:02:21 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HXV00J2KBBW1Z@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 17 May 2004 11:02:21 -0600 (MDT) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HXV003Z1BBVL2@mail.sun.net> for ipv6@ietf.org; Mon, 17 May 2004 11:02:20 -0600 (MDT) Date: Mon, 17 May 2004 10:02:17 -0700 From: Alain Durand Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols In-reply-to: <1084784969.9587.30.camel@kummerog.uni-muenster.de> To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Cc: "'IETF IPv6 Mailing List'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1084784969.9587.30.camel@kummerog.uni-muenster.de> Content-Transfer-Encoding: 7BIT 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On May 17, 2004, at 2:09 AM, Christian Strauf (JOIN) wrote: > Jinmei, > >> Explicit support or objections are highly appreciated. If the list is >> still silent, I'll start revising the document anyway. > I support all of your proposed changes. Same here. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 14:45:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13699 for ; Mon, 17 May 2004 14:45:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmz4-00023g-EH for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 14:37:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HIb6Q5007912 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 14:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmsd-0000gV-C2 for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 14:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12246 for ; Mon, 17 May 2004 14:30:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPmsa-0002Q3-Qp for ipv6-web-archive@ietf.org; Mon, 17 May 2004 14:30:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPmrQ-0001qA-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 14:29:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPmpl-00018x-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 14:27:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPma2-000642-4b; Mon, 17 May 2004 14:11:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmSJ-0003Th-Pg for ipv6@optimus.ietf.org; Mon, 17 May 2004 14:03:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08990 for ; Mon, 17 May 2004 14:03:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPmSH-00008a-Ek for ipv6@ietf.org; Mon, 17 May 2004 14:03:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPmRK-0007cP-00 for ipv6@ietf.org; Mon, 17 May 2004 14:02:15 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BPmQk-0007HK-00 for ipv6@ietf.org; Mon, 17 May 2004 14:01:38 -0400 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 May 2004 11:01:06 -0700 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 May 2004 11:01:04 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 May 2004 11:00:01 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 17 May 2004 11:00:03 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 17 May 2004 11:00:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols Date: Mon, 17 May 2004 11:00:11 -0700 Message-ID: Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols thread-index: AcQ8NNefHhwamdVRQfqqKX9jP32x2gAA+PsQ From: "Christian Huitema" To: "Alain Durand" , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Cc: "IETF IPv6 Mailing List" X-OriginalArrivalTime: 17 May 2004 18:00:40.0887 (UTC) FILETIME=[DDB7EC70:01C43C38] Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > >> Explicit support or objections are highly appreciated. If the list is > >> still silent, I'll start revising the document anyway. > > I support all of your proposed changes. > > Same here. Me too -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 17:05:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27592 for ; Mon, 17 May 2004 17:05:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoI0-0003dL-Vo for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 16:00:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HK0iD2013965 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 16:00:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPo6f-0007v7-BO for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 15:49:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19549 for ; Mon, 17 May 2004 15:48:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPo6d-0007ar-RA for ipv6-web-archive@ietf.org; Mon, 17 May 2004 15:48:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPo5K-00078n-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 15:47:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPo4M-0006l1-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 15:46:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnbl-0006Jw-Bd; Mon, 17 May 2004 15:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnRZ-0007Ic-FK for ipv6@optimus.ietf.org; Mon, 17 May 2004 15:06:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15374 for ; Mon, 17 May 2004 15:06:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPnRW-0000AC-JX for ipv6@ietf.org; Mon, 17 May 2004 15:06:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPnQl-0007cT-00 for ipv6@ietf.org; Mon, 17 May 2004 15:05:43 -0400 Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BPnQ0-0007EY-00 for ipv6@ietf.org; Mon, 17 May 2004 15:04:56 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 18 May 2004 06:19:57 +0530 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4HJ3n8s009610; Mon, 17 May 2004 12:03:51 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-212.cisco.com [10.86.242.212]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIN55984; Mon, 17 May 2004 15:04:13 -0400 (EDT) Message-Id: <4.3.2.7.2.20040517144644.02b5d0f0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 May 2004 15:04:17 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols Cc: ipv6@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 I am basically in agreement with your approach; here are a couple of specific comments: > > 1. clarify (change) the meaning of the M/O flags; they are just hints > > of availability of the corresponding services, not triggers for > > invoking the protocols under a certain level of requirement Rather than "hints", the M/O flags explicitly indicate that the corresponding service is intended to be available (note that the service might not be available due to some network or system failure). > > 2. remove "requirements" regarding these flags according to the above > > change Agreed. > > 3. (optionally) make a separate document (standard or BCP) on how to > > interact the protocols with these flags Can you give some examples of what conditions or interactions might be included in such a document? I agree that we are in consensus about your three basic assumptions: > > - we should clearly specify the corresponding protocols for the M/O > > flags > > - the protocol for the M flag is DHCPv6 (RFC3315) > > - the protocol for the O flag is the "stateless" subset of DHCPv6 > > (RFC3736) Considering your specific examples: > > For 1, I'd revise the following sentence of RFC2462 Section 4 (page > > 9): > > > A "managed address configuration" flag indicates whether hosts > > should use stateful autoconfiguration to obtain addresses. > > > to: > > > A "managed address configuration" flag indicates whether DHCPv6 is > > available for hosts to obtain addresses. Agreed. > > For 2, > > - remove the notion of the ManagedFlag and OtherConfigFlag > > (conceptual) variables defined in Section 5.2, since these flags > > will become meaningless if we do not mandate invoking particular > > protocols by the RA M/O flags. Agreed. > > - remove "requirement" sentences like the following one > > 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, requesting both address > > information and other information. > > (Section 5.5.3 of RFC2462) This particular sentence would go away because of the previous bullet (removing ManagedFlag and OtherConfigFlag)? In general, editing out requirements sentences sounds like the right thing to do. As an aside, thinking about legacy implementations, I think the idea of making the M/O flags indicators rather than triggers will avoid backward compatibility problems. For example, if an implementation uses an OtherConfigFlag according to the current RFCs, it will use DHCPv6 for other configuration when the O flag first transitions to the set state, and continue to use DHCPv6 regardless of subsequent transitions. Such behavior seems to be compatible with the proposed changes (both practically and because the proposed changes make no requirements on client behavior). What about the situation if the 'M' flag transitions from set to not set? I don't have a good answer off the top of my hear...perhaps this situation is an example of what should go into the BCP document you suggest? > > - remove Section 5.5.2 of RFC2462 (that mandates performing the > > "stateful" protocol when no RAs) Yeah, I guess this would fall under the general recommendation that M/O are indicators and not triggers, and the client behavior if no RAs are received might be discussed in the BCP doc... - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 17:17:15 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29405 for ; Mon, 17 May 2004 17:17:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPogn-0005pk-SK for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 16:26:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HKQLEv022406 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 16:26:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPo8k-0000RU-3f for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 15:51:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19871 for ; Mon, 17 May 2004 15:51:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPo8h-0000fd-FI for ipv6-web-archive@ietf.org; Mon, 17 May 2004 15:51:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPo7b-0000D5-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 15:49:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPo6I-0007YB-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 15:48:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnrE-0002nY-Lf; Mon, 17 May 2004 15:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnZ7-0004uc-RR for ipv6@optimus.ietf.org; Mon, 17 May 2004 15:14:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16446 for ; Mon, 17 May 2004 15:14:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPnZ6-000355-2T for ipv6@ietf.org; Mon, 17 May 2004 15:14:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPnY3-0002fz-00 for ipv6@ietf.org; Mon, 17 May 2004 15:13:16 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BPnWz-0001yO-00 for ipv6@ietf.org; Mon, 17 May 2004 15:12:09 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4HJBaC1002277; Mon, 17 May 2004 12:11:37 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-212.cisco.com [10.86.242.212]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIN58020; Mon, 17 May 2004 15:11:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20040517150630.02b5b2d8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 May 2004 15:11:18 -0400 To: Erik Nordmark From: Ralph Droms Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipv6@ietf.org In-Reply-To: References: <"Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 I think Jinmei-san suggested deleting the whole notion of an internal-to-the-implementation ManagedFlag and OtherConfigFlag. I extrapolated from that suggestion that the host would (in a stateless way) base its behavior on the most recently received values for M/O (which, I guess, means the implementation really does need ManagedFlag and OtherConfigFlag). So, as soon as the M/O bits transition to set, the host would begin using DHCPv6. The host behavior when the M/O flags transition from set to unset is a little less clear. In the case of the O flag, the host will stop using DHCPv6 for other configuration information. Should it also stop using the configuration information it received through DHCPv6? Similarly, when the M flag transitions from set to unset, should the host stop using any addresses obtained through DHCPv6? Or should the host simply not try to extend the lifetimes of any assigned addresses? - Ralph At 09:18 AM 5/17/2004 -0700, Erik Nordmark wrote: >Overall your proposal is good. > > > - remove "requirement" sentences like the following one > > 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, requesting both address > > information and other information. > > (Section 5.5.3 of RFC2462) > >I think I'm suggesting the same thing as Tim. >Loosing the above setence means that implementations might not >look for changes in the flag value (but perhaps instead only look >at the flag in the first RA). >So saying something like > Hosts which invoke DHCPv6 based on the ManagedFlag need to > not only look for this flag when booting, but also observe whether > the ManagedFlag changes from FALSE to TRUE in a subsequent Router > Advertisement. > > > > - remove Section 5.5.2 of RFC2462 (that mandates performing the > > > "stateful" protocol when no RAs) > >Restating that to not be a requirement also makes sense. >I think the section should become more of a note which points out >that in the absense of any routers hence router advertisements, >stateless address autoconfiguration isn't available >and that a host MAY wish to use DHCPv6 in this case. > >It would presumably make sense to clarify in that section that even >if this is done the host continues to operate the stateless protocol >i.e. the reception of a router advertisement (with A-flag in one >or more prefix option) in the future will trigger stateless. >This is to make it more clear that the absense of a router while >booting must not automatically "turn off" the stateless protocol. > > Erik > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 17:39:05 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02643 for ; Mon, 17 May 2004 17:39:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpTL-0003Bi-8o for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 17:16:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HLGV1s012249 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 17:16:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoe7-0004Ot-5g for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 16:23:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22861 for ; Mon, 17 May 2004 16:23:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPoe5-0005NT-Dk for ipv6-web-archive@ietf.org; Mon, 17 May 2004 16:23:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPocm-0004gk-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 16:22:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPobU-0004Ac-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 16:20:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPo7y-0008Ip-HJ; Mon, 17 May 2004 15:50:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnvO-0003cO-6y for ipv6@optimus.ietf.org; Mon, 17 May 2004 15:37:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18761 for ; Mon, 17 May 2004 15:37:20 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPnvM-0003pN-Ty for ipv6@ietf.org; Mon, 17 May 2004 15:37:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPnub-0003VZ-00 for ipv6@ietf.org; Mon, 17 May 2004 15:36:33 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BPntc-0003AB-00 for ipv6@ietf.org; Mon, 17 May 2004 15:35:32 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4HJZRe07270; Mon, 17 May 2004 22:35:27 +0300 (EET DST) X-Scanned: Mon, 17 May 2004 22:35:21 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4HJZLQ5001312; Mon, 17 May 2004 22:35:21 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 0036EmfV; Mon, 17 May 2004 22:35:20 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4HJZJH10452; Mon, 17 May 2004 22:35:19 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 May 2004 14:34:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv3: Message Source Address Determination.. Date: Mon, 17 May 2004 14:34:47 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79A39@daebe009.americas.nokia.com> Thread-Topic: ICMPv3: Message Source Address Determination.. Thread-Index: AcQ737yqBYYd+/ZHTFeuHWRrj5MLyQAZKs7w To: Cc: X-OriginalArrivalTime: 17 May 2004 19:34:47.0922 (UTC) FILETIME=[039D1520:01C43C46] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jinmei, I agree that we should not try to remove already=20 documented features in recycling work if it is not causing any harm. But the current RFC says "If the node has more than one=20 unicast address, it must choose the Source Address of the=20 message as follows:". It is not MUST in all caps but if an implementation is not using point (c) to determine the source IP address, can we say that the implementation is not conformant with the RFC ? I don't seem to understand the logic in that point. Let say we have the following network. (...) <-- I1 --> A <-- I2/I3/I4 --> (...) and A receives a packet on I1 that needs to be forwarded to one of I2/I3 or I4. The packet forwarding fails because A does not have a route for the destination. Now A generates the ICMP error. Is the point (c) suggesting to use the src address from I2, I3 or I4 ? Or it is suggesting to use the src from I1 ? From the text, it seems like it suggests to use the src address of the interface where the packet should have been forwarded but as we don't have a route, we don't know where it was to be forwarded. I think, most of the implementations would use the src=20 address of I1 in this case. So my question is that is it ok to leave this point as "required" in the RFC if noone will be able to implement=20 it ? Regards Mukesh > -----Original Message----- > From: jinmei@isl.rdc.toshiba.co.jp=20 > [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Monday, May 17, 2004 12:22 AM > To: Gupta Mukesh (Nokia-NET/MtView) > Cc: ipv6@ietf.org > Subject: Re: ICMPv3: Message Source Address Determination.. >=20 >=20 > >>>>> On Thu, 13 May 2004 14:54:23 -0500,=20 > >>>>> Mukesh.Gupta@nokia.com said: >=20 > > Pekka raised a concern about the usability of one of the > > methods (section 2.2 (c)) to select the source address=20 > > of the ICMPv3 packet. I want to know if anyone has=20 > > implemented it ? or how useful and practical this=20 > > method is in your opinion ? >=20 > I've once tried to implement this case, particularly for the scenario > where a router is sending an ICMPv6 destination unreachable message > when it finds the next hop is unreachable. However, I personally > haven't find this very useful, and, in fact, I've even not known > whether it was really working. After several revises, our current > code does not have this trick. >=20 > Regarding the revise for icmp-v3, I have no particular opinion. > Although I personally see no clear benefits of 2.2. (c), I don't see > clear disadvantage either. And, through my recent experiences on the > rfc2462bis work, people seem to disagree on removing an > already-documented feature in a recycling work unless the feature is > clearly shown to be harmful. >=20 > In the end, I can live with or without removing 2.2 (c). >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 21:44:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20541 for ; Mon, 17 May 2004 21:44:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPtaq-0003m5-0J for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 21:40:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I1eVns014504 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 21:40:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPtTP-0001Ih-6j for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 21:32:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19867 for ; Mon, 17 May 2004 21:32:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPtTM-0002X6-Fg for ipv6-web-archive@ietf.org; Mon, 17 May 2004 21:32:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPtSF-00026b-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 21:31:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPtR7-0001fu-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 21:30:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPt6O-00038R-CB; Mon, 17 May 2004 21:09:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPt10-00021b-Ey for ipv6@optimus.ietf.org; Mon, 17 May 2004 21:03:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18482 for ; Mon, 17 May 2004 21:03:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPt0x-0007OU-TK for ipv6@ietf.org; Mon, 17 May 2004 21:03:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPszz-00072A-00 for ipv6@ietf.org; Mon, 17 May 2004 21:02:27 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BPsz2-0006L6-00 for ipv6@ietf.org; Mon, 17 May 2004 21:01:28 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4I10n6b022279; Mon, 17 May 2004 18:00:50 -0700 (PDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4I10kQ23077; Tue, 18 May 2004 03:00:47 +0200 (MEST) Date: Mon, 17 May 2004 18:00:48 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols To: Ralph Droms Cc: Erik Nordmark , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipv6@ietf.org In-Reply-To: "Your message with ID" <4.3.2.7.2.20040517150630.02b5b2d8@flask.cisco.com> Message-ID: MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 > I think Jinmei-san suggested deleting the whole notion of an > internal-to-the-implementation ManagedFlag and OtherConfigFlag. I > extrapolated from that suggestion that the host would (in a stateless way) > base its behavior on the most recently received values for M/O (which, I > guess, means the implementation really does need ManagedFlag and > OtherConfigFlag). So, as soon as the M/O bits transition to set, the host > would begin using DHCPv6. I think the intent is not to prescribe "begin using" but merely to make it clear that the transition means that DHCPv6 is now available whereas before the transition it was not available. > The host behavior when the M/O flags transition from set to unset is a > little less clear. In the case of the O flag, the host will stop using > DHCPv6 for other configuration information. Should it also stop using the > configuration information it received through DHCPv6? > > Similarly, when the M flag transitions from set to unset, should the host > stop using any addresses obtained through DHCPv6? Or should the host simply > not try to extend the lifetimes of any assigned addresses? And the higher-level question is whether it is important to recommend a particular host behavior in those cases. I think one can make the case that life is easier for the network administrator if all implementations behave the same during these transitions, but given that we don't seem to want to prescribe that DHCPv6 is trigger by the "on" transitions, perhaps it doesn't make sense to try to prescribe behavior for the "off" transitions? I think what is apparent is that after an "off" transition it isn't useful for a host to try to renew information (addresses or others) that it has received from DHCPv6, since the flags being "off" means that the DHCPv6 service (the full or the stateless, respectively) isn't available. Perhaps we should make this statement in the document. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 17 23:54:27 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27043 for ; Mon, 17 May 2004 23:54:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPvaX-0002Lg-A3 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 23:48:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I3mLa3009025 for ipv6-archive@odin.ietf.org; Mon, 17 May 2004 23:48:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPvR9-0000kM-TJ for ipv6-web-archive@optimus.ietf.org; Mon, 17 May 2004 23:38:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26390 for ; Mon, 17 May 2004 23:38:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPvR7-000222-TJ for ipv6-web-archive@ietf.org; Mon, 17 May 2004 23:38:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPvQ7-0001eb-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 23:37:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPvOv-0000xL-00 for ipv6-web-archive@ietf.org; Mon, 17 May 2004 23:36:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPvJo-00073u-LX; Mon, 17 May 2004 23:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPvFc-00063w-L2 for ipv6@optimus.ietf.org; Mon, 17 May 2004 23:26:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25656 for ; Mon, 17 May 2004 23:26:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPvFa-0005Cs-MA for ipv6@ietf.org; Mon, 17 May 2004 23:26:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPvEY-0004lN-00 for ipv6@ietf.org; Mon, 17 May 2004 23:25:39 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BPvDU-0004Le-00 for ipv6@ietf.org; Mon, 17 May 2004 23:24:33 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:6ddb:59fc:dfd8:cff3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8FDB51525D; Tue, 18 May 2004 12:24:31 +0900 (JST) Date: Tue, 18 May 2004 12:24:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mukesh.Gupta@nokia.com Cc: Subject: Re: ICMPv3: Message Source Address Determination.. In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401F79A39@daebe009.americas.nokia.com> References: <8D260779A766FB4A9C1739A476F84FA401F79A39@daebe009.americas.nokia.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Mon, 17 May 2004 14:34:47 -0500, >>>>> Mukesh.Gupta@nokia.com said: > I agree that we should not try to remove already > documented features in recycling work if it is > not causing any harm. Before making detailed discussions, I'd repeat my position to avoid confusion. I can live with either action (remove or leave 2.2 (c)). If I have the right to choose one, I'd remove that part (because that part is not very useful and removing it will make the specification simpler), but if someone wants to leave it, I won't fight against the opinion. > But the current RFC says "If the node has more than one > unicast address, it must choose the Source Address of the > message as follows:". It is not MUST in all caps but > if an implementation is not using point (c) to determine > the source IP address, can we say that the implementation > is not conformant with the RFC ? I don't think so. IMO, the requirement described in 2.2 (c) is not so clear to detect conformance or non-conformance about a particular implementation, especially from a look outside the implementation. In fact, the RFC (or icmp-v3-03) says: (c) If the message is a response to a message sent to an address that does not belong to the node, the Source Address should be ^^^^^^^^^ that unicast address belonging to the node that will be most ^^^^^^^^^^^^^^^^^ helpful in diagnosing the error. For example, if the message is ^^^^^^^ ^^^^^^^^^^^ a response to a packet forwarding action that cannot complete successfully, the Source Address should be a unicast address ^^^^^^^^^ belonging to the interface on which the packet forwarding failed. This part uses "should", not "must", while the other rules (a, b and d) say "must". Second, the criteria to choose the address is "will be most helpful", which is quite subjective. And finally, the latter sentence is just an example, not a part of the rule definition. So, my understanding is that this part leaves great flexibility for implementations on the interpretation of what "will be most helpful" or how to realize that. In that sense, any implementation can be conformant with this requirement, IMO. > I don't seem to understand the logic in that point. Let say > we have the following network. > (...) <-- I1 --> A <-- I2/I3/I4 --> (...) > and A receives a packet on I1 that needs to be forwarded to > one of I2/I3 or I4. The packet forwarding fails because A > does not have a route for the destination. Now A generates > the ICMP error. Is the point (c) suggesting to use the src > address from I2, I3 or I4 ? Or it is suggesting to use the > src from I1 ? From the text, it seems like it suggests to > use the src address of the interface where the packet should > have been forwarded but as we don't have a route, we don't > know where it was to be forwarded. > I think, most of the implementations would use the src > address of I1 in this case. That's probably true. Just FYI: our latest implementation simply applies the default address selection rules defined in RFC3483 to the destination address of the ICMPv6 error packet (the source address of the original packet). Assuming the outgoing interface of the error packet is I1 and I1 has an address with an appropriate scope for the destination, it's very likely that an address on I1 is chosen. But in any event, I don't think the above scenario is the intended one described in the example of 2.2 (c). The intended scenario, in my understanding, is as follows: (....) <--- I1 ---> A <--I2---> B I3/I4 A receives a packet on I1 that needs to be forwarded to the next hop B via I2. A then detects that B is unreachable (after sending several neighbor solicitations) and generates an ICMPv6 error. According to 2.2(c), A will choose an address on I2 as the source address of the error message in order to highlight that the error occurs in the network attached to I2. > So my question is that is it ok to leave this point as > "required" in the RFC if noone will be able to implement > it ? Answering the question in a literal sense, I'd say yes. Again, (IMO), the "requirement" will not make "non-compliant" implementations even for the implementation that does nothing about 2.2 (c) internally, as I said above. Meanwhile, you may want to recall the discussion about "deprecating" the M/O flags for rfc2462bis. In that discussion, even with the fact that almost no implementations behave on the flags as described in RFC2462, many people were against deprecating the flags, saying "even if we've not seen such an implementation, it doesn't mean there is none", "do not break anything which is currently working well just because it does not seem to be very useful", etc. I myself won't apply that logic in this case, though. 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 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 02:32:21 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17761 for ; Tue, 18 May 2004 02:32:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPy35-0006gN-GK for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 02:26:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I6PxbJ025684 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 02:25:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPy18-0005XA-9q for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 02:23:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17215 for ; Tue, 18 May 2004 02:23:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPy14-0002Ro-PK for ipv6-web-archive@ietf.org; Tue, 18 May 2004 02:23:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPy0A-00023Z-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 02:22:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPxzQ-0001fg-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 02:22:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPxog-000789-Vo; Tue, 18 May 2004 02:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPxiW-0003OI-LS for ipv6@optimus.ietf.org; Tue, 18 May 2004 02:04:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07723 for ; Tue, 18 May 2004 02:04:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPxiT-0002qQ-2R for ipv6@ietf.org; Tue, 18 May 2004 02:04:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPxhS-0002Su-00 for ipv6@ietf.org; Tue, 18 May 2004 02:03:38 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BPxgJ-0001kF-00 for ipv6@ietf.org; Tue, 18 May 2004 02:02:27 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:593f:c050:20ec:fb29]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 71F5415265; Tue, 18 May 2004 15:02:27 +0900 (JST) Date: Tue, 18 May 2004 15:02:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols In-Reply-To: <4.3.2.7.2.20040517144644.02b5d0f0@flask.cisco.com> References: <4.3.2.7.2.20040517144644.02b5d0f0@flask.cisco.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Mon, 17 May 2004 15:04:17 -0400, >>>>> Ralph Droms said: >> > 3. (optionally) make a separate document (standard or BCP) on how to >> > interact the protocols with these flags > Can you give some examples of what conditions or interactions might be > included in such a document? It's just a rough sketch, but I'm currently thinking about a document that describes - how a host that implements DHCPv6 should behave. The host would have an internal (conceptual) variable, controlling the policy about autoconfiguration, which should have at least three values: 1: it should invoke DHCPv6 for address autoconfiguration regardless of the content of receiving RAs or the existence of RAs 2: it should invoke DHCPv6 for address autoconfiguration if and only if it sees an RA changing the M bit from unset to set 3: it should not invoke DHCPv6 for address autoconfiguration regardless of the content of receiving RAs or the existence of RAs - same thing for a host that implements the "stateless" subset of DHCPv6 (RFC3736) for other configuration information. The details can change based on further discussion, of course. But at the moment, I'd like to know if we can start editing rfc2462bis with an expectation that we'll have some separate document like above. And, > What about the situation if the 'M' flag transitions from set to not set? I > don't have a good answer off the top of my hear...perhaps this situation is > an example of what should go into the BCP document you suggest? Yes, probably. BTW: RFC2462 currently says the transition from set to unset means "nothing": If the value of the ManagedFlag changes from TRUE to FALSE, the host should continue running the stateful address autoconfiguration, i.e., the change in the value of the ManagedFlag has no effect. (Section 5.5.3) Personally, I don't think this behavior makes much sense, but of course we'll need to be careful if we try to change this (in the "BCP" document, or wherever) since it may have an effect on existing implementations. 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 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 03:16:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20052 for ; Tue, 18 May 2004 03:16:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyd5-0007gW-78 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 03:03:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I73BFh029535 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 03:03:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyX5-0005fp-Vv for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 02:57:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18962 for ; Tue, 18 May 2004 02:56:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPyX2-0007iO-3F for ipv6-web-archive@ietf.org; Tue, 18 May 2004 02:56:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPyVw-0007K2-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 02:55:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPyUs-0006wC-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 02:54:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyLW-0002qn-OJ; Tue, 18 May 2004 02:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyBi-0000EK-MS for ipv6@optimus.ietf.org; Tue, 18 May 2004 02:34:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18007 for ; Tue, 18 May 2004 02:34:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPyBe-00072e-TD for ipv6@ietf.org; Tue, 18 May 2004 02:34:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPyAg-0006e8-00 for ipv6@ietf.org; Tue, 18 May 2004 02:33:50 -0400 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1BPy9q-0006Dk-00 for ipv6@ietf.org; Tue, 18 May 2004 02:32:58 -0400 Received: from [128.176.184.156] (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.11/8.12.9) with ESMTP id i4I6WhJW025310 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 May 2004 08:32:48 +0200 (CEST) Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols From: "Christian Strauf (JOIN)" To: Ralph Droms Cc: ipv6@ietf.org In-Reply-To: <4.3.2.7.2.20040517150630.02b5b2d8@flask.cisco.com> References: <"Your message with ID" <4.3.2.7.2.20040517150630.02b5b2d8@flask.cisco.com> Content-Type: text/plain Organization: JOIN-Team, WWU-Muenster Message-Id: <1084861962.23616.15.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 18 May 2004 08:32:42 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ralph, > The host behavior when the M/O flags transition from set to unset is a > little less clear. In the case of the O flag, the host will stop using > DHCPv6 for other configuration information. Should it also stop using the > configuration information it received through DHCPv6? > > Similarly, when the M flag transitions from set to unset, should the host > stop using any addresses obtained through DHCPv6? Or should the host simply > not try to extend the lifetimes of any assigned addresses? very good questions. If Jinmei thinks that Tim's approach of using "may"s is good, then I believe one should also propose a behaviour in the cases when M/O bits are switching to unflagged. E.g.: (a) If the O flag is unset, a client may discontinue using stateless DHCPv6 and it may choose to discontinue using configuration information that was received while the O flag was set. Similarly, I would propose something like (b) If the M flag is being unset, a DHCPv6 client may choose to send a Renew/Rebind message. If no renewal/rebinding is possible the client may discontinue using stateful DHCPv6. If the O flag is set, a client may try to receive other configuration information using stateless DHCPv6. Otherwise, a client may choose to behave as described in (a). for the M flag. Of course there are other ways of reacting to M/O flags that switch to unflagged but I think that the above behaviour is reasonable. Trying a Renew/Rebind will also handle the question if or if not a client should continue using addresses that where received while the M flag was set (basically, the DHCPv6 server will decide). Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 03:18:18 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20225 for ; Tue, 18 May 2004 03:18:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyqJ-0002g7-3x for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 03:16:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I7Gpte010294 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 03:16:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPydu-000803-EN for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 03:04:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19341 for ; Tue, 18 May 2004 03:03:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPydq-0002iU-J9 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:03:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPyck-0002Ij-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:02:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPycE-0001vM-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:02:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyLl-0002tF-Ja; Tue, 18 May 2004 02:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyFS-0000y3-N8 for ipv6@optimus.ietf.org; Tue, 18 May 2004 02:38:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18216 for ; Tue, 18 May 2004 02:38:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPyFO-0000k0-VE for ipv6@ietf.org; Tue, 18 May 2004 02:38:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPyES-0000NA-00 for ipv6@ietf.org; Tue, 18 May 2004 02:37:44 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BPyDT-0007nJ-00 for ipv6@ietf.org; Tue, 18 May 2004 02:36:44 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:593f:c050:20ec:fb29]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 818EA1525D; Tue, 18 May 2004 15:36:38 +0900 (JST) Date: Tue, 18 May 2004 15:36:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: Ralph Droms , ipv6@ietf.org Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols In-Reply-To: References: <4.3.2.7.2.20040517150630.02b5b2d8@flask.cisco.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Mon, 17 May 2004 18:00:48 -0700 (PDT), >>>>> Erik Nordmark said: >> I think Jinmei-san suggested deleting the whole notion of an >> internal-to-the-implementation ManagedFlag and OtherConfigFlag. I >> extrapolated from that suggestion that the host would (in a stateless way) >> base its behavior on the most recently received values for M/O (which, I >> guess, means the implementation really does need ManagedFlag and >> OtherConfigFlag). So, as soon as the M/O bits transition to set, the host >> would begin using DHCPv6. > I think the intent is not to prescribe "begin using" but merely to make it > clear that the transition means that DHCPv6 is now available > whereas before the transition it was not available. My intention was basically to stop prescribing "begin using" and make it clear that the transition means the availability. In that sense, Erik is correct. But then I also suggested to remove ManagedFlag and OtherConfigFlag (which are internal-to-the-implementation) since they are only meaningful when we are prescribing the invocation of DHCPv6, so Ralph's understanding is also correct in that sense. Regarding whether the host would begin using DHCPv6 at the transition of the M flag from unset to set: rfc2462bis wouldn't say anything about this point by the original intention. If we can agree on making a separate BCP document, it will clarify this point. 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 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 03:42:05 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21478 for ; Tue, 18 May 2004 03:42:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPz3r-0006MC-6s for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 03:30:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I7Up9P024436 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 03:30:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPz2s-00062z-LM for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 03:29:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20845 for ; Tue, 18 May 2004 03:29:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPz2q-0005Kp-FR for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:29:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPz1q-0004vu-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:28:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPz0o-0004XL-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:27:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyrb-0003DS-4Y; Tue, 18 May 2004 03:18:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPygv-0000IZ-N6 for ipv6@optimus.ietf.org; Tue, 18 May 2004 03:07:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19590 for ; Tue, 18 May 2004 03:07:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPygr-00046A-LN for ipv6@ietf.org; Tue, 18 May 2004 03:07:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPyfz-0003f4-00 for ipv6@ietf.org; Tue, 18 May 2004 03:06:12 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BPyf1-0003D7-00 for ipv6@ietf.org; Tue, 18 May 2004 03:05:11 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:593f:c050:20ec:fb29]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 74D0315267; Tue, 18 May 2004 16:05:11 +0900 (JST) Date: Tue, 18 May 2004 16:05:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols In-Reply-To: References: 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Mon, 17 May 2004 09:18:23 -0700 (PDT), >>>>> Erik Nordmark said: >> - remove "requirement" sentences like the following one >> 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, requesting both address >> information and other information. >> (Section 5.5.3 of RFC2462) > I think I'm suggesting the same thing as Tim. > Loosing the above setence means that implementations might not ^^^^^^^ you meant "Losing" here, didn't you? > look for changes in the flag value (but perhaps instead only look > at the flag in the first RA). > So saying something like > Hosts which invoke DHCPv6 based on the ManagedFlag need to > not only look for this flag when booting, but also observe whether > the ManagedFlag changes from FALSE to TRUE in a subsequent Router > Advertisement. Good point. Then how about the following approach? - change the definition of ManagedFlag From: ManagedFlag Copied from the M flag field (i.e., the "managed address configuration" flag) of the most recently received Router Advertisement message. The flag indicates whether or not addresses are to be configured using the stateful autoconfiguration mechanism. It starts out in a FALSE state. To: ManagedFlag Copied from the M flag field (i.e., the "managed address configuration" flag) of the most recently received Router Advertisement message. The flag indicates whether or not DHCPv6 is available to obtain addresses. It starts out in a FALSE state. - and revise Section 5.5.3 as follows: On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), a host copies the value of the advertisement's M bit into ManagedFlag. If the value of ManagedFlag changes from FALSE to TRUE, it indicates DHCPv6 becomes available for address autoconfiguration. The details of how the host should react to this change will be described in a separate. (I'm assuming we'll have a separate document to describe the details. But if we cannot agree on this path, we'll need to revise the proposed text above accordingly.) 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 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 03:46:27 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21627 for ; Tue, 18 May 2004 03:46:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzEG-0000Wr-LS for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 03:41:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I7fa6d002024 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 03:41:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPz3l-0006Gk-Kd for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 03:30:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20886 for ; Tue, 18 May 2004 03:30:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPz3j-0005kj-BW for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:30:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPz2l-0005K6-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:29:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPz1c-0004c8-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:28:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyrg-0003Dy-EW; Tue, 18 May 2004 03:18:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPykb-0000q4-S9 for ipv6@optimus.ietf.org; Tue, 18 May 2004 03:10:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19778 for ; Tue, 18 May 2004 03:10:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPykX-0005dI-Qb for ipv6@ietf.org; Tue, 18 May 2004 03:10:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPyjf-0005Fv-00 for ipv6@ietf.org; Tue, 18 May 2004 03:10:00 -0400 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1BPyj7-0004sA-00 for ipv6@ietf.org; Tue, 18 May 2004 03:09:25 -0400 Received: from [128.176.184.156] (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.11/8.12.9) with ESMTP id i4I79Gae025836 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 May 2004 09:09:17 +0200 (CEST) Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols From: "Christian Strauf (JOIN)" To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= Cc: Ralph Droms , ipv6@ietf.org In-Reply-To: References: <4.3.2.7.2.20040517144644.02b5d0f0@flask.cisco.com> Content-Type: text/plain Organization: JOIN-Team, WWU-Muenster Message-Id: <1084864156.23616.39.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 18 May 2004 09:09:16 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > - how a host that implements DHCPv6 should behave. The host would > have an internal (conceptual) variable, controlling the policy about > autoconfiguration, which should have at least three values: > 1: it should invoke DHCPv6 for address autoconfiguration regardless > of the content of receiving RAs or the existence of RAs > 2: it should invoke DHCPv6 for address autoconfiguration if and only > if it sees an RA changing the M bit from unset to set > 3: it should not invoke DHCPv6 for address autoconfiguration > regardless of the content of receiving RAs or the existence of > RAs > - same thing for a host that implements the "stateless" subset of > DHCPv6 (RFC3736) for other configuration information. This might be tricky to implement. A potential problem would be how to get the M information that arrives in the kernel space to a program like DHCPv6 that runs in the user space (on many operating systems). It would be easy to integrate this behaviour in a DHCPv6 client if that client would listen to RAs and read M/O bits itself. You could then store the policy information 1-2 in the DHCPv6 client's configuration while policy 3 would be covered by not starting the DHCPv6 client at all. Same goes for RFC3736-like behaviour. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 03:49:44 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21819 for ; Tue, 18 May 2004 03:49:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzJ7-0001Ni-Av for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 03:46:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I7kbOw005304 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 03:46:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzEd-0000f4-D1 for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 03:41:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21456 for ; Tue, 18 May 2004 03:41:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPzEb-0002QG-1I for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:41:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzDl-00021C-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:41:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPzCv-0001cm-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:40:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPz39-00067Y-9j; Tue, 18 May 2004 03:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyt9-0003ai-TS for ipv6@optimus.ietf.org; Tue, 18 May 2004 03:19:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20368 for ; Tue, 18 May 2004 03:19:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPyt7-0001NF-Jd for ipv6@ietf.org; Tue, 18 May 2004 03:19:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPys7-0000w1-00 for ipv6@ietf.org; Tue, 18 May 2004 03:18:44 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1BPyr5-000093-00 for ipv6@ietf.org; Tue, 18 May 2004 03:17:39 -0400 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 00:17:08 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 May 2004 00:17:09 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 00:16:29 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 May 2004 00:17:05 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 May 2004 00:15:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rfc2462bis] relationship between M/O flags and relatedprotocols Date: Tue, 18 May 2004 00:16:53 -0700 Message-ID: Thread-Topic: [rfc2462bis] relationship between M/O flags and relatedprotocols thread-index: AcQ8pRZEq5RVs6vQS+uOo6COughZxQAAkHeg From: "Christian Huitema" To: "Christian Strauf \(JOIN\)" , "Ralph Droms" Cc: X-OriginalArrivalTime: 18 May 2004 07:15:22.0262 (UTC) FILETIME=[E2085B60:01C43CA7] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Of course there are other ways of reacting to M/O flags that switch to > unflagged but I think that the above behaviour is reasonable.=20 The problem with this approach is that it is speculative. The text is not particularly wrong, but other behaviors may also make sense, e.g. sticking to the lease until it ends. The downside with speculative text is that it creates a weak spot in the RFC. Ask yourself how much of the text will still be valid in 5 years, when have more operation experience. The normative text will probably still be, but there is a high likelihood that the speculative text will be off-base. What will we do then? Rewrite the entire RFC? When writing standards, less is more. If we are not sure about something, it is probably better to just leave it out. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 03:58:34 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22247 for ; Tue, 18 May 2004 03:58:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzSa-0003y6-A6 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 03:56:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I7uO4Q015255 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 03:56:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzMn-0002kd-IL for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 03:50:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21872 for ; Tue, 18 May 2004 03:50:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPzMl-0005dX-4H for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:50:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzLf-0005Cd-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:49:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPzKc-0004mF-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 03:48:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzEq-0000g7-EZ; Tue, 18 May 2004 03:42:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPz7m-00072d-2E for ipv6@optimus.ietf.org; Tue, 18 May 2004 03:34:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21093 for ; Tue, 18 May 2004 03:34:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPz7j-0007RK-Ml for ipv6@ietf.org; Tue, 18 May 2004 03:34:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPz6k-00071o-00 for ipv6@ietf.org; Tue, 18 May 2004 03:33:51 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BPz5o-0006br-00 for ipv6@ietf.org; Tue, 18 May 2004 03:32:53 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:593f:c050:20ec:fb29]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8FAEC1525D; Tue, 18 May 2004 16:32:53 +0900 (JST) Date: Tue, 18 May 2004 16:33:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Christian Strauf (JOIN)" Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols In-Reply-To: <1084864156.23616.39.camel@kummerog.uni-muenster.de> References: <4.3.2.7.2.20040517144644.02b5d0f0@flask.cisco.com> <1084864156.23616.39.camel@kummerog.uni-muenster.de> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.5 required=5.0 tests=AWL,SUBJ_HAS_SPACES autolearn=no version=2.60 >>>>> On Tue, 18 May 2004 09:09:16 +0200, >>>>> "Christian Strauf (JOIN)" said: >> - how a host that implements DHCPv6 should behave. The host would >> have an internal (conceptual) variable, controlling the policy about >> autoconfiguration, which should have at least three values: >> 1: it should invoke DHCPv6 for address autoconfiguration regardless >> of the content of receiving RAs or the existence of RAs >> 2: it should invoke DHCPv6 for address autoconfiguration if and only >> if it sees an RA changing the M bit from unset to set >> 3: it should not invoke DHCPv6 for address autoconfiguration >> regardless of the content of receiving RAs or the existence of >> RAs >> - same thing for a host that implements the "stateless" subset of >> DHCPv6 (RFC3736) for other configuration information. > This might be tricky to implement. A potential problem would be how to > get the M information that arrives in the kernel space to a program like > DHCPv6 that runs in the user space (on many operating systems). Let me check...this should apply to the current RFC2462, shouldn't it? I'm not sure why you are making this point in this context... 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 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 04:17:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23002 for ; Tue, 18 May 2004 04:17:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzlK-0000Td-10 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 04:15:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I8FjjX001819 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 04:15:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzbo-0005zf-BI for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 04:05:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22637 for ; Tue, 18 May 2004 04:05:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPzbl-0004BO-Ov for ipv6-web-archive@ietf.org; Tue, 18 May 2004 04:05:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzam-0003n1-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 04:04:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPzZx-0003Pa-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 04:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzTC-0004Af-Cl; Tue, 18 May 2004 03:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzNP-0002lc-6G for ipv6@optimus.ietf.org; Tue, 18 May 2004 03:51:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21920 for ; Tue, 18 May 2004 03:51:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPzNM-00061m-MM for ipv6@ietf.org; Tue, 18 May 2004 03:51:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzMJ-0005b4-00 for ipv6@ietf.org; Tue, 18 May 2004 03:49:56 -0400 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1BPzLK-00059c-00 for ipv6@ietf.org; Tue, 18 May 2004 03:48:55 -0400 Received: from [128.176.184.156] (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.11/8.12.9) with ESMTP id i4I7mjBV026666 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 May 2004 09:48:50 +0200 (CEST) Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols From: "Christian Strauf (JOIN)" To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= Cc: ipv6@ietf.org In-Reply-To: References: <4.3.2.7.2.20040517144644.02b5d0f0@flask.cisco.com> <1084864156.23616.39.camel@kummerog.uni-muenster.de> Content-Type: text/plain Organization: JOIN-Team, WWU-Muenster Message-Id: <1084866510.23616.50.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 18 May 2004 09:48:30 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Let me check...this should apply to the current RFC2462, shouldn't it? > I'm not sure why you are making this point in this context... No, I was referring to your suggestion of writing a document (standard or BCP) about the details of the protocol interaction which I believe is a good idea because my feeling is that there are too many open questions at the moment that need answers which could be given in such a document. I that context, I think that it might be useful to figure out very early at which level to implement the policies you suggest (kernel space (IPv6 stack) or user space (DHCPv6 client)). That was basically what I wanted to remark. The comment was not targeted at changes of RFC2462. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 04:24:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23456 for ; Tue, 18 May 2004 04:24:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzrI-0001k8-NV for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 04:21:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I8LulY006692 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 04:21:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzmg-0000mk-Ro for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 04:17:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22995 for ; Tue, 18 May 2004 04:17:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPzme-0007mL-31 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 04:17:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzlU-0007Hm-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 04:15:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPzkQ-0006p7-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 04:14:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzV9-0004j7-Eu; Tue, 18 May 2004 03:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzRF-0003ke-OH for ipv6@optimus.ietf.org; Tue, 18 May 2004 03:55:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22084 for ; Tue, 18 May 2004 03:55:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPzRD-0007cE-6X for ipv6@ietf.org; Tue, 18 May 2004 03:54:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzQD-0007EZ-00 for ipv6@ietf.org; Tue, 18 May 2004 03:53:58 -0400 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1BPzPf-0006qe-00 for ipv6@ietf.org; Tue, 18 May 2004 03:53:23 -0400 Received: from [128.176.184.156] (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.11/8.12.9) with ESMTP id i4I7r8qV026717 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 May 2004 09:53:09 +0200 (CEST) Subject: RE: [rfc2462bis] relationship between M/O flags and relatedprotocols From: "Christian Strauf (JOIN)" To: Christian Huitema Cc: Ralph Droms , ipv6@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: JOIN-Team, WWU-Muenster Message-Id: <1084866788.23623.56.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 18 May 2004 09:53:08 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christian, > When writing standards, less is more. If we are not sure about > something, it is probably better to just leave it out. yes, I agree with you. That's why I suggested to use the text only if the "may"s as Tim suggested seem to be an appropriate choice. But I see your point in leaving this as open as possible and in only adding details to it if interoperability issues arise. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 05:20:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27328 for ; Tue, 18 May 2004 05:20:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0jq-0006QD-Fd for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 05:18:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I9IICB024677 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 05:18:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0b0-0004Ex-UY for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 05:09:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26455 for ; Tue, 18 May 2004 05:09:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ0ax-0005xZ-Np for ipv6-web-archive@ietf.org; Tue, 18 May 2004 05:09:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ0ZS-00056b-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 05:07:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ0Y1-0004XR-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 05:06:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0PG-0001Vl-CH; Tue, 18 May 2004 04:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0NA-00011i-9P for ipv6@optimus.ietf.org; Tue, 18 May 2004 04:54:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25681 for ; Tue, 18 May 2004 04:54:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ0N7-00003u-6S for ipv6@ietf.org; Tue, 18 May 2004 04:54:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ0MC-0007Tf-00 for ipv6@ietf.org; Tue, 18 May 2004 04:53:53 -0400 Received: from zns001-0m9001.yokogawa.co.jp ([203.174.79.138]) by ietf-mx with esmtp (Exim 4.12) id 1BQ0LI-00076D-00 for ipv6@ietf.org; Tue, 18 May 2004 04:52:56 -0400 Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.11.7+Sun/8.11.6) with ESMTP id i4I8qsk04426 for ; Tue, 18 May 2004 17:52:55 +0900 (JST) Received: from EXCHANGE04.jp.ykgw.net (zex001-0m9004.jp.ykgw.net [10.0.10.55]) by zns001-0m9001.yokogawa.co.jp (8.11.7+Sun/8.11.6) with ESMTP id i4I8qrT04418 for ; Tue, 18 May 2004 17:52:53 +0900 (JST) Received: from cpc001-12698-02 ([10.0.103.208]) by EXCHANGE04.jp.ykgw.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 May 2004 17:52:53 +0900 Date: Tue, 18 May 2004 17:52:53 +0900 From: OOTOMO Hiroyuki Subject: RFC2460 problem - error processing of Routing Header To: ipv6@ietf.org Organization: Yokogawa Electric Corp. X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-ID: X-OriginalArrivalTime: 18 May 2004 08:52:53.0617 (UTC) FILETIME=[81B64610:01C43CB5] 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Hi, all. I found a problem in RFC2460, about error processing of Routing Header. It does not define the behavior of End Node when the End Node received the packet which has odd Hdr.Ext.Len. (Section 4.4) > A Routing header is not examined or processed until it reaches the > node identified in the Destination Address field of the IPv6 header. > In that node, dispatching on the Next Header field of the immediately > preceding header causes the Routing header module to be invoked, > which, in the case of Routing Type 0, performs the following > algorithm: > > if Segments Left = 0 { > proceed to process the next header in the packet, whose type is > identified by the Next Header field in the Routing header > } > else if Hdr Ext Len is odd { > send an ICMP Parameter Problem, Code 0, message to the Source > Address, pointing to the Hdr Ext Len field, and discard the > packet > } <<< snip >>> When the IPv6 packet with the Routing Header is as follows (example): [IPv6 Header] Source Address: host-0 Destination Address: host-4 Next Header: Routing Header [Routing Header] Next Header: ICMPv6 Hdr.Ext.Len: 5 Routing Type: 0 Segment Left: 0 Address: router-1 Address: router-2 Address: router-3 [ICMPv6] ICMPv6 Echo Request The Routing Header in this packet has Hdr.Ext.Len with invalid odd number and Segment Left with 0. RFC says that the End Node (host-4) will process the Next Header (ICMPv6), but Hdr.Ext.Len has inaccurate value, so Host-4 does not have the way to get the correct starting point of the Next Header. [Routing Header processing] Segment Left == 0 -> goes to Next Header [Between the Routing Header and the Next Header (not defined)] Header Ext. Length == 5 (odd) -> discards the packet and transmits ICMP Parameter Problem? -> or seeks 5*8 = 40 octets without considering HdrExtLen is odd? (There is not the starting point of the Next Header. There is the middle of Address[3] in Routing Header.) [Next Header processing] (What will happen?) I think that End Node should also check like Intermediate Node that the Hdr.Ext.Len is not odd number, because Hdr.Ext.Len is used by not only Intermediate Node but End Node. So I propose to replace the first two items of the algorithm. > if Hdr Ext Len is odd { > send an ICMP Parameter Problem, Code 0, message to the Source > Address, pointing to the Hdr Ext Len field, and discard the > packet > } > else if Segments Left = 0 { > proceed to process the next header in the packet, whose type is > identified by the Next Header field in the Routing header > } Thank you. -- OOTOMO Hiroyuki Gr. 1, Engeneering department 1, Development center, ATE headquarters Yokogawa Electric Corporation URL: http://www.yokogawa.com/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 07:12:45 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03967 for ; Tue, 18 May 2004 07:12:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2ND-0005WI-1A for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 07:03:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IB33Dn021218 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 07:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2Ac-00034b-6l for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 06:50:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02666 for ; Tue, 18 May 2004 06:49:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ2AY-0001Iv-3x for ipv6-web-archive@ietf.org; Tue, 18 May 2004 06:49:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ29U-0000rM-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 06:48:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ28L-000095-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 06:47:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ1x7-00088m-2Z; Tue, 18 May 2004 06:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ1tQ-0007Bw-EC for ipv6@optimus.ietf.org; Tue, 18 May 2004 06:32:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01609 for ; Tue, 18 May 2004 06:32:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ1tM-0001ke-Fn for ipv6@ietf.org; Tue, 18 May 2004 06:32:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ1sJ-0001HU-00 for ipv6@ietf.org; Tue, 18 May 2004 06:31:08 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ1rD-0000Qa-00 for ipv6@ietf.org; Tue, 18 May 2004 06:29:59 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4IATRSu005468; Tue, 18 May 2004 03:29:28 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-11.cisco.com [10.86.242.11]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIO11903; Tue, 18 May 2004 06:29:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20040518062005.02b9e168@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 May 2004 06:25:36 -0400 To: Erik Nordmark From: Ralph Droms Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols Cc: Erik Nordmark , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipv6@ietf.org In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20040517150630.02b5b2d8@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 At 06:00 PM 5/17/2004 -0700, Erik Nordmark wrote: > > I think Jinmei-san suggested deleting the whole notion of an > > internal-to-the-implementation ManagedFlag and OtherConfigFlag. I > > extrapolated from that suggestion that the host would (in a stateless way) > > base its behavior on the most recently received values for M/O (which, I > > guess, means the implementation really does need ManagedFlag and > > OtherConfigFlag). So, as soon as the M/O bits transition to set, the host > > would begin using DHCPv6. > >I think the intent is not to prescribe "begin using" but merely to make it >clear that the transition means that DHCPv6 is now available >whereas before the transition it was not available. I agree; the flag indicates DHCPv6 is available and the spec will not prescribe host behavior based on the availability of DHCPv6... > > The host behavior when the M/O flags transition from set to unset is a > > little less clear. In the case of the O flag, the host will stop using > > DHCPv6 for other configuration information. Should it also stop using the > > configuration information it received through DHCPv6? > > > > Similarly, when the M flag transitions from set to unset, should the host > > stop using any addresses obtained through DHCPv6? Or should the host > simply > > not try to extend the lifetimes of any assigned addresses? > >And the higher-level question is whether it is important to >recommend a particular host behavior in those cases. Yes. >I think one can make the case that life is easier for the network >administrator if all implementations behave the same during these >transitions, but given that we don't seem to want to prescribe that >DHCPv6 is trigger by the "on" transitions, perhaps it doesn't make >sense to try to prescribe behavior for the "off" transitions? No, it doesn't make sense to prescribe the behavior in RFC 2462bis. Would it be useful to discuss alternatives and capture that discussion in a BCP? >I think what is apparent is that after an "off" transition it >isn't useful for a host to try to renew information (addresses or others) >that it has received from DHCPv6, since the flags being "off" means >that the DHCPv6 service (the full or the stateless, respectively) >isn't available. Yes ... sending more DHCPv6 message when the flag is off probably doesn't make sense. There might be some question about what the host does with the information previously obtained through DHCPv6. >Perhaps we should make this statement in the document. It might even be something explicitly non-prescriptive like "This document does not prescribe how a host behaves in response to the M/O flags." > Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 07:24:17 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05145 for ; Tue, 18 May 2004 07:24:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2Vr-0007ks-QW for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 07:11:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IBBxJk029806 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 07:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2JI-0004m8-2v for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 06:59:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03108 for ; Tue, 18 May 2004 06:58:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ2JD-0004vH-Sm for ipv6-web-archive@ietf.org; Tue, 18 May 2004 06:58:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ2IH-0004WW-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 06:57:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ2HH-000481-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 06:56:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ29e-0002kM-EB; Tue, 18 May 2004 06:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ1y6-0008Oz-6Y for ipv6@optimus.ietf.org; Tue, 18 May 2004 06:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01944 for ; Tue, 18 May 2004 06:37:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ1y2-0003kC-6X for ipv6@ietf.org; Tue, 18 May 2004 06:37:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ1x2-0003M2-00 for ipv6@ietf.org; Tue, 18 May 2004 06:36:01 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ1wI-0002iY-00 for ipv6@ietf.org; Tue, 18 May 2004 06:35:14 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 May 2004 02:41:58 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4IAYhC1024458; Tue, 18 May 2004 03:34:43 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-11.cisco.com [10.86.242.11]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIO12101; Tue, 18 May 2004 06:34:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20040518062744.02bf2000@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 May 2004 06:32:26 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols Cc: ipv6@ietf.org In-Reply-To: References: <4.3.2.7.2.20040517144644.02b5d0f0@flask.cisco.com> <4.3.2.7.2.20040517144644.02b5d0f0@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Your list of behaviors is a good starting point for a BCP document. As you point out, if we know there is rough consensus in support of writing such a doc, RFC 2462bis can proceed without explicit prescription of client behavior. I remember (my memory, of course, may be faulty) that the behavior of the client you cite from RFC 2462 was specified to avoid DoS attacks in which rouge RAs with the M/O flags set to off would not cause hosts to stop using DHCPv6. - Ralph At 03:02 PM 5/18/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Mon, 17 May 2004 15:04:17 -0400, > >>>>> Ralph Droms said: > > >> > 3. (optionally) make a separate document (standard or BCP) on how to > >> > interact the protocols with these flags > > > Can you give some examples of what conditions or interactions might be > > included in such a document? > >It's just a rough sketch, but I'm currently thinking about a document >that describes > >- how a host that implements DHCPv6 should behave. The host would > have an internal (conceptual) variable, controlling the policy about > autoconfiguration, which should have at least three values: > 1: it should invoke DHCPv6 for address autoconfiguration regardless > of the content of receiving RAs or the existence of RAs > 2: it should invoke DHCPv6 for address autoconfiguration if and only > if it sees an RA changing the M bit from unset to set > 3: it should not invoke DHCPv6 for address autoconfiguration > regardless of the content of receiving RAs or the existence of > RAs >- same thing for a host that implements the "stateless" subset of > DHCPv6 (RFC3736) for other configuration information. > >The details can change based on further discussion, of course. But at >the moment, I'd like to know if we can start editing rfc2462bis with >an expectation that we'll have some separate document like above. > >And, > > > What about the situation if the 'M' flag transitions from set to not > set? I > > don't have a good answer off the top of my hear...perhaps this situation is > > an example of what should go into the BCP document you suggest? > >Yes, probably. > >BTW: RFC2462 currently says the transition from set to unset means >"nothing": > > If the value of the ManagedFlag > changes from TRUE to FALSE, the host should continue running the > stateful address autoconfiguration, i.e., the change in the value of > the ManagedFlag has no effect. > (Section 5.5.3) > >Personally, I don't think this behavior makes much sense, but of >course we'll need to be careful if we try to change this (in the "BCP" >document, or wherever) since it may have an effect on existing >implementations. > > 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 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 07:31:08 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05986 for ; Tue, 18 May 2004 07:31:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2jR-0003jD-7t for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 07:26:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IBQ1CL014316 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 07:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2ak-0000r1-I8 for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 07:17:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04432 for ; Tue, 18 May 2004 07:17:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ2ak-0004Ob-0v for ipv6-web-archive@ietf.org; Tue, 18 May 2004 07:17:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ2ZI-0003ik-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 07:15:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ2Xy-0003CC-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 07:14:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2PD-0005n2-Qc; Tue, 18 May 2004 07:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2B9-000360-Hi for ipv6@optimus.ietf.org; Tue, 18 May 2004 06:50:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02735 for ; Tue, 18 May 2004 06:50:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ2B5-0001MB-2m for ipv6@ietf.org; Tue, 18 May 2004 06:50:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ29s-0000v5-00 for ipv6@ietf.org; Tue, 18 May 2004 06:49:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BQ296-0000UX-00 for ipv6@ietf.org; Tue, 18 May 2004 06:48:28 -0400 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1BQ297-000HlO-IR for ipv6@ietf.org; Tue, 18 May 2004 10:48:29 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #274 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #274] [rfc2462bis] MLD spec conflict on random delay for first packet In-Reply-To: Managed-BY: RT 3.0.9 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Tue, 18 May 2004 10:48:29 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 > [jinmei@isl.rdc.toshiba.co.jp - Mon Feb 09 06:37:31 2004]: > > Proposed Resolution (revised): revise the latter part of > Section 5.4.2 as follows: The proposed change was incorporated in the latest draft (00), and I've not seen any objections to it. I now conclude everyone is fine with the resolution and close this issue. (Any comments to reopen the issue are of course welcome.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 07:32:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06058 for ; Tue, 18 May 2004 07:32:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2jg-0003zY-1p for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 07:26:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IBQGQ5015338 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 07:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2ge-0002jZ-33 for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 07:23:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05055 for ; Tue, 18 May 2004 07:23:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ2gd-0007IE-IY for ipv6-web-archive@ietf.org; Tue, 18 May 2004 07:23:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ2fZ-0006qY-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 07:22:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ2eX-0006OV-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 07:20:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2PF-0005nE-4V; Tue, 18 May 2004 07:05:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2B9-000362-TB for ipv6@optimus.ietf.org; Tue, 18 May 2004 06:50:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02738 for ; Tue, 18 May 2004 06:50:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ2B5-0001MH-PK for ipv6@ietf.org; Tue, 18 May 2004 06:50:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ29t-0000vF-00 for ipv6@ietf.org; Tue, 18 May 2004 06:49:18 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BQ296-0000UZ-00 for ipv6@ietf.org; Tue, 18 May 2004 06:48:28 -0400 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1BQ298-000Hlb-6F for ipv6@ietf.org; Tue, 18 May 2004 10:48:30 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #274 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #274] [rfc2462bis] MLD spec conflict on random delay for first packet In-Reply-To: Managed-BY: RT 3.0.9 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Tue, 18 May 2004 10:48:30 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 > [jinmei@isl.rdc.toshiba.co.jp - Mon Feb 09 06:37:31 2004]: > > Proposed Resolution (revised): revise the latter part of > Section 5.4.2 as follows: The proposed change was incorporated in the latest draft (00), and I've not seen any objections to it. I now conclude everyone is fine with the resolution and close this issue. (Any comments to reopen the issue are of course welcome.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 07:32:17 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06081 for ; Tue, 18 May 2004 07:32:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2kB-0004HQ-Uz for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 07:26:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IBQllo016447 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 07:26:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2hn-000345-An for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 07:24:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05166 for ; Tue, 18 May 2004 07:24:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ2hm-0007lJ-Pt for ipv6-web-archive@ietf.org; Tue, 18 May 2004 07:24:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ2gl-0007JK-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 07:23:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ2fn-0006sQ-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 07:22:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2PH-0005nc-Of; Tue, 18 May 2004 07:05:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2FQ-0003yS-E5 for ipv6@optimus.ietf.org; Tue, 18 May 2004 06:55:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02942 for ; Tue, 18 May 2004 06:54:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ2FM-0003LN-82 for ipv6@ietf.org; Tue, 18 May 2004 06:54:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ2EJ-0002wX-00 for ipv6@ietf.org; Tue, 18 May 2004 06:53:52 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BQ2DL-0002Y7-00 for ipv6@ietf.org; Tue, 18 May 2004 06:52:51 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4IAqq7s006447 for ; Tue, 18 May 2004 11:52:52 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA08280 for ; Tue, 18 May 2004 11:52:49 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4IAqmN17303 for ipv6@ietf.org; Tue, 18 May 2004 11:52:48 +0100 Date: Tue, 18 May 2004 11:52:48 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: [rfc2462bis] relationship between M/O flags and related Message-ID: <20040518105248.GN12314@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <4.3.2.7.2.20040517144644.02b5d0f0@flask.cisco.com> <4.3.2.7.2.20040517144644.02b5d0f0@flask.cisco.com> <4.3.2.7.2.20040518062744.02bf2000@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20040518062744.02bf2000@flask.cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 On Tue, May 18, 2004 at 06:32:26AM -0400, Ralph Droms wrote: > Your list of behaviors is a good starting point for a BCP document. As you > point out, if we know there is rough consensus in support of writing such a > doc, RFC 2462bis can proceed without explicit prescription of client > behavior. > > I remember (my memory, of course, may be faulty) that the behavior of the > client you cite from RFC 2462 was specified to avoid DoS attacks in which > rouge RAs with the M/O flags set to off would not cause hosts to stop using > DHCPv6. So would such a document branch out to include cases like a node moving between networks when using M and/or O hints? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 08:37:10 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10204 for ; Tue, 18 May 2004 08:37:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3o3-0000tW-DF for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 08:34:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ICYpXi003439 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 08:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3Yn-0001Zm-1M for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 08:19:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08441 for ; Tue, 18 May 2004 08:19:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ3Ym-0006Ca-0p for ipv6-web-archive@ietf.org; Tue, 18 May 2004 08:19:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ3Xq-0005np-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 08:18:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ3Wv-0005Qb-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 08:17:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3LO-0006Fh-Fz; Tue, 18 May 2004 08:05:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3GI-0005Dv-6a for ipv6@optimus.ietf.org; Tue, 18 May 2004 07:59:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07632 for ; Tue, 18 May 2004 07:59:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ3GH-0006mz-7P for ipv6@ietf.org; Tue, 18 May 2004 07:59:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ3FL-0006Q0-00 for ipv6@ietf.org; Tue, 18 May 2004 07:58:59 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ3EQ-0005eN-00 for ipv6@ietf.org; Tue, 18 May 2004 07:58:02 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 18 May 2004 04:03:04 +0000 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4IBvQSu014865; Tue, 18 May 2004 04:57:26 -0700 (PDT) Received: from cisco.com (dhcp-data-vlan10-23-143.cisco.com [144.254.23.143]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA29887; Tue, 18 May 2004 04:57:24 -0700 (PDT) Message-ID: <40A9FA28.3080507@cisco.com> Date: Tue, 18 May 2004 13:57:28 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: "Christian Strauf (JOIN)" , Ralph Droms , ipv6@ietf.org Subject: Re: [rfc2462bis] relationship between M/O flags and relatedprotocols References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christian Huitema wrote: > The downside with speculative text is that it creates a weak spot in the > RFC. Ask yourself how much of the text will still be valid in 5 years, > when have more operation experience. The normative text will probably > still be, but there is a high likelihood that the speculative text will > be off-base. What will we do then? Rewrite the entire RFC? We update it like anything else. In the end what enterprises will need are a set of predictable behaviors so they know how long transition states will last. So long as you can answer those questions in the draft, life is good. Eliot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 08:58:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11661 for ; Tue, 18 May 2004 08:58:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4A5-00005Z-2G for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 08:57:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ICvbkK000337 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 08:57:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ45g-0006nJ-OE for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 08:53:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11260 for ; Tue, 18 May 2004 08:53:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ45f-0004tG-BB for ipv6-web-archive@ietf.org; Tue, 18 May 2004 08:53:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ44i-0004UV-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 08:52:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ43f-00046p-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 08:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3oR-000182-CI; Tue, 18 May 2004 08:35:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3bw-0002Ic-8Q for ipv6@optimus.ietf.org; Tue, 18 May 2004 08:22:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08663 for ; Tue, 18 May 2004 08:22:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ3bv-0007QG-60 for ipv6@ietf.org; Tue, 18 May 2004 08:22:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ3b0-00071s-00 for ipv6@ietf.org; Tue, 18 May 2004 08:21:23 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ3aO-0006cm-00 for ipv6@ietf.org; Tue, 18 May 2004 08:20:44 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 May 2004 04:27:28 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4ICKBSu002769; Tue, 18 May 2004 05:20:11 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIO16382; Tue, 18 May 2004 08:20:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20040518081413.02beb4a8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 May 2004 08:18:25 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols Cc: Erik Nordmark , ipv6@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Regarding the last paragraph of suggested text: On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), a host copies the value of the advertisement's M bit into ManagedFlag. If the value of ManagedFlag changes from FALSE to TRUE, it indicates DHCPv6 becomes available for address autoconfiguration. The details of how the host should react to this change will be described in a separate. mentioning just the FALSE to TRUE transition seems too limited (why is just the time of transition interesting?) How about: On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), a host copies the value of the advertisement's M bit into ManagedFlag, which saves the mostly recently received value of the M bit. The details of how the host uses the M bit to control the use of DHCPv6 for address assignment will be described in a separate document. - Ralph At 04:05 PM 5/18/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Mon, 17 May 2004 09:18:23 -0700 (PDT), > >>>>> Erik Nordmark said: > > >> - remove "requirement" sentences like the following one > >> 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, requesting both address > >> information and other information. > >> (Section 5.5.3 of RFC2462) > > > I think I'm suggesting the same thing as Tim. > > Loosing the above setence means that implementations might not > ^^^^^^^ you meant "Losing" here, didn't you? > > > look for changes in the flag value (but perhaps instead only look > > at the flag in the first RA). > > So saying something like > > Hosts which invoke DHCPv6 based on the ManagedFlag need to > > not only look for this flag when booting, but also observe whether > > the ManagedFlag changes from FALSE to TRUE in a subsequent Router > > Advertisement. > >Good point. Then how about the following approach? > >- change the definition of ManagedFlag > > From: > ManagedFlag Copied from the M flag field (i.e., the > "managed address configuration" flag) of the most > recently received Router Advertisement message. > The flag indicates whether or not addresses are > to be configured using the stateful > autoconfiguration mechanism. It starts out in a > FALSE state. > To: > ManagedFlag Copied from the M flag field (i.e., the > "managed address configuration" flag) of the most > recently received Router Advertisement message. > The flag indicates whether or not DHCPv6 is > available to obtain addresses. It starts out > in a FALSE state. > >- and revise Section 5.5.3 as follows: > > On receipt of a valid Router Advertisement (as defined in > [DISCOVERY]), a host copies the value of the advertisement's M bit > into ManagedFlag. If the value of ManagedFlag changes from FALSE to > TRUE, it indicates DHCPv6 becomes available for address > autoconfiguration. The details of how the host should react to > this change will be described in a separate. > >(I'm assuming we'll have a separate document to describe the details. >But if we cannot agree on this path, we'll need to revise the proposed >text above accordingly.) > > 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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 08:59:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11812 for ; Tue, 18 May 2004 08:59:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4AT-0000Vl-4l for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 08:58:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ICw1Nj001960 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 08:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ47Y-0007QI-Sj for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 08:55:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11351 for ; Tue, 18 May 2004 08:54:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ47X-0005jL-HD for ipv6-web-archive@ietf.org; Tue, 18 May 2004 08:54:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ46X-0005HI-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 08:53:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ45V-0004kN-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 08:52:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3oS-00018a-RT; Tue, 18 May 2004 08:35:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3cY-0002rR-5N for ipv6@optimus.ietf.org; Tue, 18 May 2004 08:22:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08685 for ; Tue, 18 May 2004 08:22:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ3cW-0007m7-Uz for ipv6@ietf.org; Tue, 18 May 2004 08:22:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ3bX-0007My-00 for ipv6@ietf.org; Tue, 18 May 2004 08:21:56 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ3aQ-0006co-00 for ipv6@ietf.org; Tue, 18 May 2004 08:20:46 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4ICKBSw002769; Tue, 18 May 2004 05:20:14 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIO16383; Tue, 18 May 2004 08:20:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20040518081912.02bf1e80@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 May 2004 08:20:03 -0400 To: Tim Chown From: Ralph Droms Subject: Re: [rfc2462bis] relationship between M/O flags and related Cc: ipv6@ietf.org In-Reply-To: <20040518105248.GN12314@login.ecs.soton.ac.uk> References: <4.3.2.7.2.20040518062744.02bf2000@flask.cisco.com> <4.3.2.7.2.20040517144644.02b5d0f0@flask.cisco.com> <4.3.2.7.2.20040517144644.02b5d0f0@flask.cisco.com> <4.3.2.7.2.20040518062744.02bf2000@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Yes - mobility (and DNAv6?) would be good topics for a BCP doc... - Ralph At 11:52 AM 5/18/2004 +0100, Tim Chown wrote: >On Tue, May 18, 2004 at 06:32:26AM -0400, Ralph Droms wrote: > > Your list of behaviors is a good starting point for a BCP document. As you > > point out, if we know there is rough consensus in support of writing such a > > doc, RFC 2462bis can proceed without explicit prescription of client > > behavior. > > > > I remember (my memory, of course, may be faulty) that the behavior of the > > client you cite from RFC 2462 was specified to avoid DoS attacks in which > > rouge RAs with the M/O flags set to off would not cause hosts to stop using > > DHCPv6. > >So would such a document branch out to include cases like a node moving >between networks when using M and/or O hints? > >Tim > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 09:35:46 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14230 for ; Tue, 18 May 2004 09:35:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4Yb-0000gI-Lg for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 09:22:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IDMvvd002619 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 09:22:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4HL-0002i6-Ft for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 09:05:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12252 for ; Tue, 18 May 2004 09:05:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ4HK-00029D-4h for ipv6-web-archive@ietf.org; Tue, 18 May 2004 09:05:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ4GL-0001lh-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 09:04:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ4FO-0001N4-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 09:03:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4Al-0000br-0w; Tue, 18 May 2004 08:58:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3y6-0003l6-Hs for ipv6@optimus.ietf.org; Tue, 18 May 2004 08:45:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10909 for ; Tue, 18 May 2004 08:45:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ3y5-0001pw-7g for ipv6@ietf.org; Tue, 18 May 2004 08:45:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ3x5-0001Sq-00 for ipv6@ietf.org; Tue, 18 May 2004 08:44:12 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BQ3wa-00015w-00 for ipv6@ietf.org; Tue, 18 May 2004 08:43:40 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:593f:c050:20ec:fb29]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A957815263 for ; Tue, 18 May 2004 21:43:30 +0900 (JST) Date: Tue, 18 May 2004 21:43:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis issue 281] Requirement for 64bit I/F ID 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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: if you've forgotten the discussion, please first refer to the following URL (and its followups if necessary): https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01797.html ] In this message, I pointed out that there might be possible conflict between the IPv6 address architecture and link specific documents (e.g. IPv6 over ethernet), and asked how we can clarify the point. Unfortunately, I've not seen a direct answer to the question...I now think it's time to decide how we should deal with this issue in rfc2462bis. In the previous discussion, some people wanted to "hard code" the assumption that the interface identifier is 64-bit long. But there was an opposite opinion that wanted to avoid the hardcoding. I personally think it is beyond the right of rfc2462bis to hardcode the value, regardless of whether fixing the IFID length is a good idea or not. The real problem is the conflict I pointed out, which is outside of rfc2462bis. If we tried to give an "answer" in rfc2462bis, we'd implicitly affect the other documents. But at the same time, I guess it is irresponsible to leave the RFC2462 text on this point as is, because we know this issue has been annoying implementors. So, my basic idea is to clarify the current situation with realistic compromise. Specifically, - add some notes after the definition of "interface identifier" (RFC2462 section 2) as follows: Note that [ADDR-ARCH] and the link-type specific document can potentially conflict with each other about the length of the interface identifier, whereas there has been no conflict in the actual specifications. The case where the two documents actually conflict is outside the scope of this document. - describe the possible conflict I pointed out in an appendix or somewhere in the document, and refer to the description from the above note. - emphasize that "64-bit" is not hardcoded. For example, after the following sentence of Section 5.3 Note that interface identifiers will typically be 64-bits long and based on EUI-64 identifiers as described in [ADDR-ARCH]. make an additional note like this: It should also be noted, however, that the exact length and the way the identifier is created is defined in a separate link-type specific document. An implementations SHOULD NOT assume the typical cases, but SHOULD follow the link-type specific document. Is this a reasonable approach? 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 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 09:35:55 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14251 for ; Tue, 18 May 2004 09:35:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4Yi-0000jU-0R for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 09:23:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IDN3EA002808 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 09:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4MC-00047f-LS for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 09:10:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12632 for ; Tue, 18 May 2004 09:10:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ4MB-00047t-6S for ipv6-web-archive@ietf.org; Tue, 18 May 2004 09:10:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ4LF-0003l4-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 09:09:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ4Kd-0003OJ-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 09:08:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4Ao-0000cZ-8Y; Tue, 18 May 2004 08:58:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ41k-0004I8-Ri for ipv6@optimus.ietf.org; Tue, 18 May 2004 08:49:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11063 for ; Tue, 18 May 2004 08:48:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ41j-0003LO-Gp for ipv6@ietf.org; Tue, 18 May 2004 08:48:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ40j-0002xt-00 for ipv6@ietf.org; Tue, 18 May 2004 08:47:57 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BQ3zi-0002QD-00 for ipv6@ietf.org; Tue, 18 May 2004 08:46:54 -0400 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1BQ3zi-0005Yv-HO for ipv6@ietf.org; Tue, 18 May 2004 12:46:54 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #278 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #278] [rfc2462bis issue 278] Router autoconfiguring itself In-Reply-To: Managed-BY: RT 3.0.9 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Tue, 18 May 2004 12:46:54 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 No opinions, so I'll adopt the resolution of "do nothing" as I proposed on the list, and close this issue. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 09:35:56 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14268 for ; Tue, 18 May 2004 09:35:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4ZF-0000m8-24 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 09:23:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IDNb8T002972 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 09:23:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4OB-0004ma-Uk for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 09:12:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12731 for ; Tue, 18 May 2004 09:12:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ4OA-0004vo-AC for ipv6-web-archive@ietf.org; Tue, 18 May 2004 09:12:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ4NI-0004Yl-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 09:11:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ4Me-0004A2-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 09:10:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4Ap-0000cm-F5; Tue, 18 May 2004 08:58:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ41l-0004IF-KR for ipv6@optimus.ietf.org; Tue, 18 May 2004 08:49:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11066 for ; Tue, 18 May 2004 08:48:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ41k-0003LT-6B for ipv6@ietf.org; Tue, 18 May 2004 08:49:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ40j-0002y1-00 for ipv6@ietf.org; Tue, 18 May 2004 08:47:58 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BQ3zj-0002RO-00 for ipv6@ietf.org; Tue, 18 May 2004 08:46:55 -0400 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1BQ3zj-0005ZG-7v for ipv6@ietf.org; Tue, 18 May 2004 12:46:55 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #278 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #278] [rfc2462bis issue 278] Router autoconfiguring itself In-Reply-To: Managed-BY: RT 3.0.9 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Tue, 18 May 2004 12:46:55 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 No opinions, so I'll adopt the resolution of "do nothing" as I proposed on the list, and close this issue. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 12:36:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26140 for ; Tue, 18 May 2004 12:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7S2-00040f-3R for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 12:28:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IGSMt1015414 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 12:28:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7CQ-0007tc-RN for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 12:12:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24969 for ; Tue, 18 May 2004 12:12:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ7CP-0004LL-D1 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 12:12:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ7BO-0004HA-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 12:11:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ7Au-0004E1-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 12:10:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ6zh-0003iX-1I; Tue, 18 May 2004 11:59:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ6p0-0000iV-2Z for ipv6@optimus.ietf.org; Tue, 18 May 2004 11:48:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23865 for ; Tue, 18 May 2004 11:47:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ6oz-00033C-1I for ipv6@ietf.org; Tue, 18 May 2004 11:48:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ6oC-00031Y-00 for ipv6@ietf.org; Tue, 18 May 2004 11:47:13 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1BQ6ng-0002xL-00 for ipv6@ietf.org; Tue, 18 May 2004 11:46:40 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4IFk9lg102028 for ; Tue, 18 May 2004 15:46:09 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4IFk8Xs259298 for ; Tue, 18 May 2004 17:46:08 +0200 Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA25080 for ; Tue, 18 May 2004 17:46:08 +0200 Message-ID: <40AA2FC7.302@zurich.ibm.com> Date: Tue, 18 May 2004 17:46:15 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit JINMEI Tatuya wrote: > [Note: if you've forgotten the discussion, please first refer to the > following URL (and its followups if necessary): > https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01797.html ] > > In this message, I pointed out that there might be possible conflict > between the IPv6 address architecture and link specific documents > (e.g. IPv6 over ethernet), and asked how we can clarify the point. > > Unfortunately, I've not seen a direct answer to the question...I now > think it's time to decide how we should deal with this issue in > rfc2462bis. First of all let's not forget that the addressing architecture is 100% unambiguous in saying that unicast interface IDs are required to be 64 bits, so a link-specific document that attempted to define a different ID length would be in direct conflict with RFC 3513. So the question *cannot* arise unless RFC 3513 is updated or the IESG approves something that is broken. That being so, I think it is reasonable to make 2462bis immune to theoretical future changes. But I have some comments on your proposals... > > In the previous discussion, some people wanted to "hard code" the > assumption that the interface identifier is 64-bit long. But there > was an opposite opinion that wanted to avoid the hardcoding. > > I personally think it is beyond the right of rfc2462bis to hardcode > the value, regardless of whether fixing the IFID length is a good idea > or not. The real problem is the conflict I pointed out, which is > outside of rfc2462bis. If we tried to give an "answer" in rfc2462bis, > we'd implicitly affect the other documents. Fully agree > > But at the same time, I guess it is irresponsible to leave the RFC2462 > text on this point as is, because we know this issue has been annoying > implementors. In my view, only because they failed to review the addressing architecture, which is unambiguous. > > So, my basic idea is to clarify the current situation with realistic > compromise. > > Specifically, > > - add some notes after the definition of "interface identifier" > (RFC2462 section 2) as follows: > > Note that [ADDR-ARCH] and the link-type specific document can > potentially conflict with each other about the length of the > interface identifier, No they can't, because no such link-specific document should be allowed by the IESG without an explicit update to [ADDR-ARCH]. > whereas there has been no conflict in the > actual specifications. The case where the two documents actually > conflict is outside the scope of this document. So I think this note needs to be rewritten: Note that a future revision of [ADDR-ARCH] and a future link-type specific document could potentially allow for an interface identifier of length other than 64 bits. > > - describe the possible conflict I pointed out in an appendix or > somewhere in the document, and refer to the description from the > above note. It isn't a *conflict* if the IESG does its job. It's a possible *change*. > > - emphasize that "64-bit" is not hardcoded. For example, after the > following sentence of Section 5.3 > > Note that interface identifiers will typically be 64-bits > long and based on EUI-64 identifiers as described in [ADDR-ARCH]. Actually the word "typically" is now a bug since [ADDR-ARCH] requires the length to be 64. > > make an additional note like this: > > It should also be noted, however, that the exact length and the > way the identifier is created is defined in a separate link-type > specific document. An implementations SHOULD NOT assume the > typical cases, but SHOULD follow the link-type specific document. OK but add As noted above, this would also require an update to [ADDR-ARCH]. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 13:08:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28063 for ; Tue, 18 May 2004 13:08:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7zW-0005y4-OI for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 13:02:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IH2wf6022936 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 13:02:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7uq-0004lo-26 for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 12:58:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27297 for ; Tue, 18 May 2004 12:58:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ7uo-00075l-9Q for ipv6-web-archive@ietf.org; Tue, 18 May 2004 12:58:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ7tx-000728-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 12:57:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ7td-0006yv-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 12:56:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7jD-0001f9-If; Tue, 18 May 2004 12:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7Wg-000630-Js for ipv6@optimus.ietf.org; Tue, 18 May 2004 12:33:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25961 for ; Tue, 18 May 2004 12:33:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ7Wf-0005U6-3Z for ipv6@ietf.org; Tue, 18 May 2004 12:33:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ7Vn-0005RB-00 for ipv6@ietf.org; Tue, 18 May 2004 12:32:15 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1BQ7VR-0005NX-00 for ipv6@ietf.org; Tue, 18 May 2004 12:31:53 -0400 Message-ID: <03e701c43cf5$b57c1ac0$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Brian E Carpenter" , References: <40AA2FC7.302@zurich.ibm.com> Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID Date: Tue, 18 May 2004 09:32:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jinmei/Brian, I agree with Brian's comments. RFC 3587 is very clear that unless the first three bits of the address are set to 0, the interface id is required to be 64 bits. So there should be no conflict. jak ----- Original Message ----- From: "Brian E Carpenter" To: Sent: Tuesday, May 18, 2004 8:46 AM Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID > JINMEI Tatuya wrote: > > [Note: if you've forgotten the discussion, please first refer to the > > following URL (and its followups if necessary): > > https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01797.html ] > > > > In this message, I pointed out that there might be possible conflict > > between the IPv6 address architecture and link specific documents > > (e.g. IPv6 over ethernet), and asked how we can clarify the point. > > > > Unfortunately, I've not seen a direct answer to the question...I now > > think it's time to decide how we should deal with this issue in > > rfc2462bis. > > First of all let's not forget that the addressing architecture is 100% > unambiguous in saying that unicast interface IDs are required to be > 64 bits, so a link-specific document that attempted to define a different > ID length would be in direct conflict with RFC 3513. So the question > *cannot* arise unless RFC 3513 is updated or the IESG approves something > that is broken. > > That being so, I think it is reasonable to make 2462bis immune to > theoretical future changes. But I have some comments on your > proposals... > > > > > In the previous discussion, some people wanted to "hard code" the > > assumption that the interface identifier is 64-bit long. But there > > was an opposite opinion that wanted to avoid the hardcoding. > > > > I personally think it is beyond the right of rfc2462bis to hardcode > > the value, regardless of whether fixing the IFID length is a good idea > > or not. The real problem is the conflict I pointed out, which is > > outside of rfc2462bis. If we tried to give an "answer" in rfc2462bis, > > we'd implicitly affect the other documents. > > Fully agree > > > > > But at the same time, I guess it is irresponsible to leave the RFC2462 > > text on this point as is, because we know this issue has been annoying > > implementors. > > In my view, only because they failed to review the addressing architecture, > which is unambiguous. > > > > > So, my basic idea is to clarify the current situation with realistic > > compromise. > > > > Specifically, > > > > - add some notes after the definition of "interface identifier" > > (RFC2462 section 2) as follows: > > > > Note that [ADDR-ARCH] and the link-type specific document can > > potentially conflict with each other about the length of the > > interface identifier, > > No they can't, because no such link-specific document should be > allowed by the IESG without an explicit update to [ADDR-ARCH]. > > > whereas there has been no conflict in the > > actual specifications. The case where the two documents actually > > conflict is outside the scope of this document. > > So I think this note needs to be rewritten: > > Note that a future revision of [ADDR-ARCH] and a future link-type > specific document could potentially allow for an interface identifier > of length other than 64 bits. > > > > > - describe the possible conflict I pointed out in an appendix or > > somewhere in the document, and refer to the description from the > > above note. > > It isn't a *conflict* if the IESG does its job. It's a possible *change*. > > > > - emphasize that "64-bit" is not hardcoded. For example, after the > > following sentence of Section 5.3 > > > > Note that interface identifiers will typically be 64-bits > > long and based on EUI-64 identifiers as described in [ADDR-ARCH]. > > Actually the word "typically" is now a bug since [ADDR-ARCH] requires > the length to be 64. > > > > make an additional note like this: > > > > It should also be noted, however, that the exact length and the > > way the identifier is created is defined in a separate link-type > > specific document. An implementations SHOULD NOT assume the > > typical cases, but SHOULD follow the link-type specific document. > > OK but add > As noted above, this would also require an update to [ADDR-ARCH]. > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 14:01:44 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01843 for ; Tue, 18 May 2004 14:01:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8kg-0000CE-Pg for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 13:51:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IHpgu9000754 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 13:51:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8ht-00084S-Ov for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 13:48:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00360 for ; Tue, 18 May 2004 13:48:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ8hr-0002UD-Fi for ipv6-web-archive@ietf.org; Tue, 18 May 2004 13:48:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8gQ-0002FH-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 13:47:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ8fl-0002A7-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 13:46:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8Ta-0005Xz-T3; Tue, 18 May 2004 13:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8My-0003r6-DG for ipv6@optimus.ietf.org; Tue, 18 May 2004 13:27:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29159 for ; Tue, 18 May 2004 13:27:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ8Mv-00019A-Gi for ipv6@ietf.org; Tue, 18 May 2004 13:27:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8Lw-00015r-00 for ipv6@ietf.org; Tue, 18 May 2004 13:26:09 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BQ8LG-000101-00 for ipv6@ietf.org; Tue, 18 May 2004 13:25:26 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4IHNgLr025800; Tue, 18 May 2004 10:23:43 -0700 (PDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4IHNeQ04653; Tue, 18 May 2004 19:23:40 +0200 (MEST) Date: Tue, 18 May 2004 10:23:42 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , rdroms@cisco.com Cc: Erik Nordmark , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 > > Loosing the above setence means that implementations might not > ^^^^^^^ you meant "Losing" here, didn't you? Yes. (I'm assuming we'll have a separate document to describe the details. But if we cannot agree on this path, we'll need to revise the proposed text above accordingly.) That assumption is fine with me. Ralph suggested: > mentioning just the FALSE to TRUE transition seems too limited (why is just > the time of transition interesting?) How about: > > On receipt of a valid Router Advertisement (as defined in > [DISCOVERY]), a host copies the value of the advertisement's M bit > into ManagedFlag, which saves the mostly recently received value of > the M bit. The details of how the host uses the M bit to control > the use of DHCPv6 for address assignment will be described in a > separate document. Better. But how about also stating that it might be useful to detect when the flag values change. For instance, On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), a host copies the value of the advertisement's M bit into ManagedFlag, which saves the mostly recently received value of the M bit. The details of how the host uses the ManagedFlag, including any use of the "on" and "off" transitions for this flag, to control the use of DHCPv6 for address assignment will be described in a separate document. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 14:44:55 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04810 for ; Tue, 18 May 2004 14:44:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9TS-0002AZ-Jo for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 14:37:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IIbwj3008340 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 14:37:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9Iz-0000in-F7 for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 14:27:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03736 for ; Tue, 18 May 2004 14:27:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9Iw-0005L1-VK for ipv6-web-archive@ietf.org; Tue, 18 May 2004 14:27:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9I7-0005J6-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 14:26:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9HI-0005Gt-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 14:25:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ93T-0003yg-JT; Tue, 18 May 2004 14:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8sk-0001Ny-AU for ipv6@optimus.ietf.org; Tue, 18 May 2004 14:00:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01673 for ; Tue, 18 May 2004 14:00:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ8si-0003Q2-0F for ipv6@ietf.org; Tue, 18 May 2004 14:00:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8rj-0003MG-00 for ipv6@ietf.org; Tue, 18 May 2004 13:59:00 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ8qq-0003In-00 for ipv6@ietf.org; Tue, 18 May 2004 13:58:04 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 May 2004 10:03:12 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4IHvVC1021366; Tue, 18 May 2004 10:57:32 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIO50361; Tue, 18 May 2004 13:57:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20040518135646.02b460a8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 May 2004 13:57:27 -0400 To: Erik Nordmark From: Ralph Droms Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Erik Nordmark , ipv6@ietf.org In-Reply-To: References: <"Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Erik - your proposed text looks good to me... - Ralph At 10:23 AM 5/18/2004 -0700, Erik Nordmark wrote: >Better. But how about also stating that it might be useful to detect >when the flag values change. For instance, > On receipt of a valid Router Advertisement (as defined in > [DISCOVERY]), a host copies the value of the advertisement's M bit > into ManagedFlag, which saves the mostly recently received value of > the M bit. The details of how the host uses the ManagedFlag, > including any use of the "on" and "off" transitions for this flag, to >control > the use of DHCPv6 for address assignment will be described in a > separate document. > > Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 17:26:21 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20204 for ; Tue, 18 May 2004 17:26:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBwr-000399-Ef for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 17:16:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ILGTbu012095 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 17:16:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBpT-00011l-MA for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 17:08:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18559 for ; Tue, 18 May 2004 17:08:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQBpQ-0004J7-KG for ipv6-web-archive@ietf.org; Tue, 18 May 2004 17:08:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQBoK-0004Am-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 17:07:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQBnO-00044r-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 17:06:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBXS-0003Hm-12; Tue, 18 May 2004 16:50:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQB6P-0001gY-TK for ipv6@optimus.ietf.org; Tue, 18 May 2004 16:22:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13364 for ; Tue, 18 May 2004 16:22:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQB6O-0006Sb-2l for ipv6@ietf.org; Tue, 18 May 2004 16:22:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQB4v-0006EB-00 for ipv6@ietf.org; Tue, 18 May 2004 16:20:45 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BQB2v-0005oZ-00 for ipv6@ietf.org; Tue, 18 May 2004 16:18:41 -0400 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 13:18:04 -0700 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 May 2004 13:03:06 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 13:03:15 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 13:02:27 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 May 2004 13:03:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols Date: Tue, 18 May 2004 13:03:01 -0700 Message-ID: Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols thread-index: AcQ9BYnwJfwxsN4xR7u2TtElJukTqgADEWdw From: "Christian Huitema" To: "Ralph Droms" , "Erik Nordmark" Cc: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , "Erik Nordmark" , X-OriginalArrivalTime: 18 May 2004 20:03:42.0887 (UTC) FILETIME=[38257B70:01C43D13] Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > >Better. But how about also stating that it might be useful to detect > >when the flag values change. For instance, > > On receipt of a valid Router Advertisement (as defined in > > [DISCOVERY]), a host copies the value of the advertisement's M bit > > into ManagedFlag, which saves the mostly recently received value of > > the M bit. The details of how the host uses the ManagedFlag, > > including any use of the "on" and "off" transitions for this flag, > to > >control > > the use of DHCPv6 for address assignment will be described in a > > separate document. Well, I for one would rather leave the entire handling of the Managed flag to the to-be-written RFC. I see the point of assuming that the flag will be visible through some kind of API for the DHCPv6 process, but I would rather not build a dependency to another document. If we write something, it should be short, e.g.: On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), a host copies the value of the advertisement's M bit into ManagedFlag, which saves the mostly recently received value of the M bit. That is, don't speculate on possible usage. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 17:33:10 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20444 for ; Tue, 18 May 2004 17:33:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQC6E-0005S4-UE for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 17:26:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ILQArx020948 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 17:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBxA-0003Dd-P4 for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 17:16:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19425 for ; Tue, 18 May 2004 17:16:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQBx8-0005Lq-Iw for ipv6-web-archive@ietf.org; Tue, 18 May 2004 17:16:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQBw1-00059k-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 17:15:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQBtu-0004qE-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 17:13:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBjq-0007C2-Tn; Tue, 18 May 2004 17:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBVd-0001pc-Qh for ipv6@optimus.ietf.org; Tue, 18 May 2004 16:48:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16840 for ; Tue, 18 May 2004 16:48:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQBVb-0002HQ-RV for ipv6@ietf.org; Tue, 18 May 2004 16:48:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQBUi-000291-00 for ipv6@ietf.org; Tue, 18 May 2004 16:47:24 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1BQBTh-00021c-00 for ipv6@ietf.org; Tue, 18 May 2004 16:46:21 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4IKiahO018758; Tue, 18 May 2004 14:44:36 -0600 (MDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4IKk0Q20765; Tue, 18 May 2004 22:46:00 +0200 (MEST) Date: Tue, 18 May 2004 13:46:03 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols To: Christian Huitema Cc: Ralph Droms , Erik Nordmark , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 > Well, I for one would rather leave the entire handling of the Managed flag > to the to-be-written RFC. I see the point of assuming that the flag will be > visible through some kind of API for the DHCPv6 process, but I would rather > not build a dependency to another document. I'm certainly not implying any API. Why do you think the text with the forward reference to "a separate document" implies any API? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 18:21:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24510 for ; Tue, 18 May 2004 18:21:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCqO-0003k3-Bw for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 18:13:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IMDqCp014372 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 18:13:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCmo-0000gW-PG for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 18:10:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23316 for ; Tue, 18 May 2004 18:10:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQCml-0001Lk-VJ for ipv6-web-archive@ietf.org; Tue, 18 May 2004 18:10:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQClq-0001Hz-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 18:09:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQCkt-0001EX-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 18:08:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCVG-0002g8-G1; Tue, 18 May 2004 17:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCKo-00013n-Og for ipv6@optimus.ietf.org; Tue, 18 May 2004 17:41:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20873 for ; Tue, 18 May 2004 17:41:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQCKm-00075B-Cv for ipv6@ietf.org; Tue, 18 May 2004 17:41:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQCJu-00072e-00 for ipv6@ietf.org; Tue, 18 May 2004 17:40:18 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1BQCJa-0006zh-00 for ipv6@ietf.org; Tue, 18 May 2004 17:39:58 -0400 Message-ID: <051f01c43d20$c2c20700$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "IPV6 WG" Subject: Technical Differences between IPv6 and IPv4? Date: Tue, 18 May 2004 14:40:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Is there an RFC or a technical document somewhere with a concise, bulleted list of technical differences between IPv6 and IPv4? jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 19:02:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26639 for ; Tue, 18 May 2004 19:02:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQDV1-000626-J3 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 18:55:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IMtpE1023179 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 18:55:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQDIl-0003lR-UX for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 18:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25837 for ; Tue, 18 May 2004 18:43:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQDIi-0003n5-U9 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 18:43:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQDHn-0003ih-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 18:42:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQDGv-0003eB-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 18:41:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQD69-0000rI-60; Tue, 18 May 2004 18:30:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCvZ-0006JB-IK for ipv6@optimus.ietf.org; Tue, 18 May 2004 18:19:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24399 for ; Tue, 18 May 2004 18:19:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQCvW-0001yi-MM for ipv6@ietf.org; Tue, 18 May 2004 18:19:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQCuj-0001w2-00 for ipv6@ietf.org; Tue, 18 May 2004 18:18:22 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BQCtt-0001nR-00 for ipv6@ietf.org; Tue, 18 May 2004 18:17:29 -0400 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 15:16:55 -0700 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 May 2004 15:16:53 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 15:16:59 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 15:16:11 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 May 2004 15:17:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols Date: Tue, 18 May 2004 15:17:00 -0700 Message-ID: Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols thread-index: AcQ9GTBMntDkw7W8Q3mEcUkDADwTXgADD6Ig From: "Christian Huitema" To: "Erik Nordmark" Cc: "Ralph Droms" , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , X-OriginalArrivalTime: 18 May 2004 22:17:23.0701 (UTC) FILETIME=[E4EC9250:01C43D25] Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I'm certainly not implying any API. > Why do you think the text with the forward reference to "a separate > document" > implies any API? The forward reference is asking the implementers to manage an extraneous state variable. As far as ND is concerned, the host can be entirely conformant and interoperate fine with others without that state variable. So, the only reason for the state variable is to facilitate the implementation of something else than ND, which will use the value of the state variable. For that you need some form of API. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 19:34:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28077 for ; Tue, 18 May 2004 19:34:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQE5W-0006eD-Mu for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 19:33:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4INXYI9025539 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 19:33:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQDwl-0004Ee-3t for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 19:24:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27543 for ; Tue, 18 May 2004 19:24:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQDwj-0006Ue-Jr for ipv6-web-archive@ietf.org; Tue, 18 May 2004 19:24:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQDvs-0006PT-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 19:23:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQDv4-0006JT-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 19:22:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQDet-0008Kx-E7; Tue, 18 May 2004 19:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQDWU-0006tK-Ta for ipv6@optimus.ietf.org; Tue, 18 May 2004 18:57:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26327 for ; Tue, 18 May 2004 18:57:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQDWR-0004b3-Oh for ipv6@ietf.org; Tue, 18 May 2004 18:57:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQDVY-0004Wj-00 for ipv6@ietf.org; Tue, 18 May 2004 18:56:25 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BQDV6-0004Si-00 for ipv6@ietf.org; Tue, 18 May 2004 18:55:56 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4IMtM815066; Tue, 18 May 2004 15:55:22 -0700 X-mProtect: <200405182255> Nokia Silicon Valley Messaging Protection Received: from danocdhcp013080.americas.nokia.com (172.19.13.80, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdqP5BbI; Tue, 18 May 2004 15:55:20 PDT Message-Id: <4.3.2.7.2.20040518154636.01c6e750@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 May 2004 15:52:54 -0700 To: James Kempf From: Bob Hinden Subject: Re: Technical Differences between IPv6 and IPv4? Cc: IPV6 WG In-Reply-To: <051f01c43d20$c2c20700$366115ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 James, At 02:40 PM 5/18/2004, James Kempf wrote: >Is there an RFC or a technical document somewhere with a concise, bulleted >list of technical differences between IPv6 and IPv4? There is a short list in the introduction section of RFC2460 "Internet Protocol, Version 6 (IPv6) Specification". There is also some of this in RFC 1752 "The Recommendation for the IP Next Generation Protocol". Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue May 18 20:44:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01435 for ; Tue, 18 May 2004 20:44:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQF7k-0002zn-Cz for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 20:39:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J0duc8011510 for ipv6-archive@odin.ietf.org; Tue, 18 May 2004 20:39:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQF5G-0002IL-I8 for ipv6-web-archive@optimus.ietf.org; Tue, 18 May 2004 20:37:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01213 for ; Tue, 18 May 2004 20:37:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQF5E-0004Aw-F8 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 20:37:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQF4Z-00047W-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 20:36:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQF43-00042o-00 for ipv6-web-archive@ietf.org; Tue, 18 May 2004 20:36:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQEvK-0008RT-F2; Tue, 18 May 2004 20:27:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQEmo-0006ZO-94 for ipv6@optimus.ietf.org; Tue, 18 May 2004 20:18:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00190 for ; Tue, 18 May 2004 20:18:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQEmm-0002kY-46 for ipv6@ietf.org; Tue, 18 May 2004 20:18:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQElu-0002hP-00 for ipv6@ietf.org; Tue, 18 May 2004 20:17:23 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQElJ-0002ca-00 for ipv6@ietf.org; Tue, 18 May 2004 20:16:46 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 May 2004 16:21:57 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4J0GDC1026176; Tue, 18 May 2004 17:16:14 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-133.cisco.com [10.86.242.133]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIO85091; Tue, 18 May 2004 20:16:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20040518201209.02c0eef0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 May 2004 20:16:15 -0400 To: "Christian Huitema" From: Ralph Droms Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols Cc: "Erik Nordmark" , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 I share your concern about mandating the implementation of a possibly extraneous state variable. Perhaps replacing your suggested text: On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), a host copies the value of the advertisement's M bit into ManagedFlag, which saves the mostly recently received value of the M bit. with: The details of how a host uses the M bit from a valid Router Advertisement it receives will be described in a separate document. would indicate that the use of the M bit is left to the implementation but is not prescribed here? - Ralph At 03:17 PM 5/18/2004 -0700, Christian Huitema wrote: > > I'm certainly not implying any API. > > Why do you think the text with the forward reference to "a separate > > document" > > implies any API? > >The forward reference is asking the implementers to manage an extraneous >state variable. As far as ND is concerned, the host can be entirely >conformant and interoperate fine with others without that state variable. >So, the only reason for the state variable is to facilitate the >implementation of something else than ND, which will use the value of the >state variable. For that you need some form of API. > >-- Christian Huitema > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 19 06:02:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26835 for ; Wed, 19 May 2004 06:02:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNjh-0008Qs-Ek for ipv6-archive@odin.ietf.org; Wed, 19 May 2004 05:51:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9pfqi032405 for ipv6-archive@odin.ietf.org; Wed, 19 May 2004 05:51:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNVH-0003wK-Jx for ipv6-web-archive@optimus.ietf.org; Wed, 19 May 2004 05:36:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24452 for ; Wed, 19 May 2004 05:36:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQNVD-0003y1-9S for ipv6-web-archive@ietf.org; Wed, 19 May 2004 05:36:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNUD-0003jc-00 for ipv6-web-archive@ietf.org; Wed, 19 May 2004 05:35:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQNTC-0003WX-00 for ipv6-web-archive@ietf.org; Wed, 19 May 2004 05:34:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN5b-0007Uu-JO; Wed, 19 May 2004 05:10:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQLZz-0004EY-5N for ipv6@optimus.ietf.org; Wed, 19 May 2004 03:33:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18520 for ; Wed, 19 May 2004 03:33:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQLZw-0001uL-MF for ipv6@ietf.org; Wed, 19 May 2004 03:33:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQLYw-0001md-00 for ipv6@ietf.org; Wed, 19 May 2004 03:32:27 -0400 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1BQLXy-0001dT-00 for ipv6@ietf.org; Wed, 19 May 2004 03:31:26 -0400 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 14B787FF0; Wed, 19 May 2004 09:31:23 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 26297-52; Wed, 19 May 2004 09:30:52 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 9DD277F67; Wed, 19 May 2004 09:30:51 +0200 (CEST) Subject: Re: Technical Differences between IPv6 and IPv4? From: Jeroen Massar To: Bob Hinden Cc: James Kempf , IPV6 WG In-Reply-To: <4.3.2.7.2.20040518154636.01c6e750@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20040518154636.01c6e750@mailhost.iprg.nokia.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-V3SCY68OPvLLs8izKRgY" Organization: Unfix Message-Id: <1084951846.22699.1170.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 19 May 2004 09:30:46 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 --=-V3SCY68OPvLLs8izKRgY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-05-19 at 00:52, Bob Hinden wrote: > James, >=20 > At 02:40 PM 5/18/2004, James Kempf wrote: > >Is there an RFC or a technical document somewhere with a concise, bullet= ed > >list of technical differences between IPv6 and IPv4? >=20 > There is a short list in the introduction section of RFC2460 "Internet=20 > Protocol, Version 6 (IPv6) Specification". There is also some of this in= =20 > RFC 1752 "The Recommendation for the IP Next Generation Protocol". The following should also do the trick btw, they generally tell the story about IPv6, comparing to IPv4 and all the new bells and whistles but in presentation, shortcut style. For complete details of course you will have to check the RFC's. Steve Deering's IPv6 Masterclass: http://www.isoc.nl/activ/2002-Masterclass-IETF-IPv6.htm Cisco's ABC to IPv6: http://www.cisco.com/en/US/products/sw/iosswrel/ios_abcs_ios_the_abcs_ip_ve= rsion_6_listing.html IPv6 from a thousand feet: http://www.heanet.ie/conferences/2002/presentations/NRM/siframes.html At least these are the few ones I point people to when they request "What is IPv6" "What is better" "What changed" etc. As for the more programming inclined, see: http://www.kame.net/newsletter/19980604/ by Jun-ichiro itojun Itoh http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html by Eva M. Castro. Though the latter two describe AF independency which is another step into the future. Greets, Jeroen --=-V3SCY68OPvLLs8izKRgY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBAqw0lKaooUjM+fCMRAgKaAJ0UePWsGeE4ndEYu8HHd4mdo03lpACdFpzH TDRqhO3NaKnEN9qCh0Ifs/E= =gwCu -----END PGP SIGNATURE----- --=-V3SCY68OPvLLs8izKRgY-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 19 06:04:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26960 for ; Wed, 19 May 2004 06:04:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNl4-0000j3-UN for ipv6-archive@odin.ietf.org; Wed, 19 May 2004 05:53:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9r6GK002789 for ipv6-archive@odin.ietf.org; Wed, 19 May 2004 05:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNet-0006vI-LI for ipv6-web-archive@optimus.ietf.org; Wed, 19 May 2004 05:46:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25468 for ; Wed, 19 May 2004 05:46:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQNel-0005zU-Kw for ipv6-web-archive@ietf.org; Wed, 19 May 2004 05:46:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNdl-0005lt-00 for ipv6-web-archive@ietf.org; Wed, 19 May 2004 05:45:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQNcl-0005be-00 for ipv6-web-archive@ietf.org; Wed, 19 May 2004 05:44:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN7d-0007jx-Ch; Wed, 19 May 2004 05:12:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQMRT-0002aV-TD for ipv6@optimus.ietf.org; Wed, 19 May 2004 04:28:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21213 for ; Wed, 19 May 2004 04:28:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQMRR-0001X1-1m for ipv6@ietf.org; Wed, 19 May 2004 04:28:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQMQN-0001PP-00 for ipv6@ietf.org; Wed, 19 May 2004 04:27:40 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BQMQ1-0001HC-00 for ipv6@ietf.org; Wed, 19 May 2004 04:27:21 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:993e:717a:76f0:fd69]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 98AF21525D; Wed, 19 May 2004 17:27:13 +0900 (JST) Date: Wed, 19 May 2004 17:27:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian E Carpenter Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID In-Reply-To: <40AA2FC7.302@zurich.ibm.com> References: <40AA2FC7.302@zurich.ibm.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Tue, 18 May 2004 17:46:15 +0200, >>>>> Brian E Carpenter said: >> In this message, I pointed out that there might be possible conflict >> between the IPv6 address architecture and link specific documents >> (e.g. IPv6 over ethernet), and asked how we can clarify the point. >> >> Unfortunately, I've not seen a direct answer to the question...I now >> think it's time to decide how we should deal with this issue in >> rfc2462bis. > First of all let's not forget that the addressing architecture is 100% > unambiguous in saying that unicast interface IDs are required to be > 64 bits, so a link-specific document that attempted to define a different > ID length would be in direct conflict with RFC 3513. So the question > *cannot* arise unless RFC 3513 is updated or the IESG approves something > that is broken. I don't think I forgot the point. I know RFC3513 and RFC 3587 are 100% unambiguous. I know link-specific documents (e.g. IPv6 over ethernet) are also 100% unambiguous. The problem is that the two sets of unambiguous documents may conflict with each other or at least the two sets may seem to conflict for implementors. >> But at the same time, I guess it is irresponsible to leave the RFC2462 >> text on this point as is, because we know this issue has been annoying >> implementors. > In my view, only because they failed to review the addressing architecture, > which is unambiguous. I don't think so, because RFC2462 uses link-specific documents as the primary source about (the length of the) the IFID: interface identifier - a link-dependent identifier for an interface that is (at least) unique per link [ADDR-ARCH]. [...] The exact length of an interface identifier and the way it is created is defined in a separate link-type specific document that covers issues related to the transmission of IP over a particular link type (e.g., [IPv6-ETHER]). BTW: according to what you were saying, it seems to me that 1. the primary source should actually be the ADDR-ARCH document, not link-specific documents 2. link-specific documents must be consistent with ADDR-ARCH. If not, the IESG will reject the document. If this is the case, I'm just happy with it (is there any direct reference which states that ADDR-ARCH is the primary?). Then it will probably be enough to revise the definition to: interface identifier - a link-dependent identifier for an interface that is (at least) unique per link [ADDR-ARCH]. [...] The exact length of an interface identifier is defined in [ADDR-ARCH] based on the address format. The way it is created is defined in a separate link-type specific document that covers issues related to the transmission of IP over a particular link type (e.g., [IPv6-ETHER]). perhaps with a note like this: The link-type specific document may also define the length of the interface identifier. However, it must be consistent with the definition in [ADDR-ARCH]. (If there is a reference that I asked above, it's also good to add the reference here.) 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 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 19 06:04:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26990 for ; Wed, 19 May 2004 06:04:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNm9-00011e-6Z for ipv6-archive@odin.ietf.org; Wed, 19 May 2004 05:54:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9sC5A003928 for ipv6-archive@odin.ietf.org; Wed, 19 May 2004 05:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNgE-0007LD-DN for ipv6-web-archive@optimus.ietf.org; Wed, 19 May 2004 05:48:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25644 for ; Wed, 19 May 2004 05:48:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQNg9-0006HR-Qj for ipv6-web-archive@ietf.org; Wed, 19 May 2004 05:48:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNfI-00063T-00 for ipv6-web-archive@ietf.org; Wed, 19 May 2004 05:47:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQNe9-0005pj-00 for ipv6-web-archive@ietf.org; Wed, 19 May 2004 05:45:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN7x-0007uQ-ES; Wed, 19 May 2004 05:12:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQMtU-00062p-Mp for ipv6@optimus.ietf.org; Wed, 19 May 2004 04:57:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22369 for ; Wed, 19 May 2004 04:57:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQMtR-0005Ty-GS for ipv6@ietf.org; Wed, 19 May 2004 04:57:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQMsT-0005K4-00 for ipv6@ietf.org; Wed, 19 May 2004 04:56:42 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BQMrz-0005Bp-00 for ipv6@ietf.org; Wed, 19 May 2004 04:56:11 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:993e:717a:76f0:fd69]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 61DC11525D; Wed, 19 May 2004 17:56:12 +0900 (JST) Date: Wed, 19 May 2004 17:56:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: "Christian Huitema" , "Erik Nordmark" , Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols In-Reply-To: <4.3.2.7.2.20040518201209.02c0eef0@flask.cisco.com> <20040517114559.GO8946@login.ecs.soton.ac.uk> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Tue, 18 May 2004 20:16:15 -0400, >>>>> Ralph Droms said: > I share your concern about mandating the implementation of a possibly > extraneous state variable. Perhaps replacing your suggested text: > On receipt of a valid Router Advertisement (as defined in > [DISCOVERY]), a host copies the value of the advertisement's M bit > into ManagedFlag, which saves the mostly recently received value of > the M bit. > with: > The details of how a host uses the M bit from a valid Router > Advertisement it receives will be described in a separate document. > would indicate that the use of the M bit is left to the implementation but > is not prescribed here? (I can personally live with any of the proposals, but) Please let me clarify the things...it seems to me that Christian (H) wanted two things: 1. minimize referring to other documents 2. avoid using a possibly extraneous state variable (ManagedFlag) But in Christian's proposal (the first one of the above citation) he only addressed the first point. On the other hand, your (Ralph's) proposal, you seem to have addressed the second point. According to what Christian originally said, either proposal seems to me incomplete... Meanwhile, there was a different opinion that it would be better to clearly show the issue around the M/O flags has been considered: >>>>> On Mon, 17 May 2004 12:45:59 +0100, >>>>> Tim Chown said: >> Please let me check: are you suggesting to replace the "should"s with >> "may"s instead of removing these sentences (which is my proposal)? > Yes. I suspect implementations may do both, thus rather than implementors > looking at the spec and wondering whether the issue has been considered, > a "may" shows that it has, and the behaviour is their choice. Considering all the three points, if Christian's main point is to avoid the state variable rather than to minimize references, I guess the last proposal from Ralph is the best: The details of how a host uses the M bit from a valid Router Advertisement it receives will be described in a separate document. (but if so, the appropriate place to put this text is not Section 5.5.3, but should be some introductory part of the document (section 1 and/or 4, probably). Also, with this proposal we'll remove the definition of ManagedFlag from Section 5.2. 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 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 19 06:43:40 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29693 for ; Wed, 19 May 2004 06:43:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQOUL-0001OO-PJ for ipv6-archive@odin.ietf.org; Wed, 19 May 2004 06:39:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JAdr0n005353 for ipv6-archive@odin.ietf.org; Wed, 19 May 2004 06:39:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQOMP-0000By-7q for ipv6-web-archive@optimus.ietf.org; Wed, 19 May 2004 06:31:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28863 for ; Wed, 19 May 2004 06:31:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQOML-0005vN-BD for ipv6-web-archive@ietf.org; Wed, 19 May 2004 06:31:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQOLU-0005ky-00 for ipv6-web-archive@ietf.org; Wed, 19 May 2004 06:30:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQOKV-0005bB-00 for ipv6-web-archive@ietf.org; Wed, 19 May 2004 06:29:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQOF5-0007B6-3D; Wed, 19 May 2004 06:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQO9w-0006AF-5C for ipv6@optimus.ietf.org; Wed, 19 May 2004 06:18:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28065 for ; Wed, 19 May 2004 06:18:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQO9s-0003rV-DK for ipv6@ietf.org; Wed, 19 May 2004 06:18:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQO94-0003ht-00 for ipv6@ietf.org; Wed, 19 May 2004 06:17:55 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1BQO89-0003Qb-00 for ipv6@ietf.org; Wed, 19 May 2004 06:16:57 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4JAGMAN053788 for ; Wed, 19 May 2004 10:16:22 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4JAGMYB268564 for ; Wed, 19 May 2004 12:16:22 +0200 Received: from zurich.ibm.com (sig-9-145-226-16.de.ibm.com [9.145.226.16]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA73430 for ; Wed, 19 May 2004 12:16:21 +0200 Message-ID: <40AB33FB.8020300@zurich.ibm.com> Date: Wed, 19 May 2004 12:16:27 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID References: <40AA2FC7.302@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jinmei, I believe your proposed new text at the bottom is correct. 2462bis should not open the door to conflict in future link-layer specs. Brian JINMEI Tatuya wrote: >>>>>>On Tue, 18 May 2004 17:46:15 +0200, >>>>>>Brian E Carpenter said: > > >>>In this message, I pointed out that there might be possible conflict >>>between the IPv6 address architecture and link specific documents >>>(e.g. IPv6 over ethernet), and asked how we can clarify the point. >>> >>>Unfortunately, I've not seen a direct answer to the question...I now >>>think it's time to decide how we should deal with this issue in >>>rfc2462bis. > > >>First of all let's not forget that the addressing architecture is 100% >>unambiguous in saying that unicast interface IDs are required to be >>64 bits, so a link-specific document that attempted to define a different >>ID length would be in direct conflict with RFC 3513. So the question >>*cannot* arise unless RFC 3513 is updated or the IESG approves something >>that is broken. > > > I don't think I forgot the point. I know RFC3513 and RFC 3587 are > 100% unambiguous. I know link-specific documents (e.g. IPv6 over > ethernet) are also 100% unambiguous. The problem is that the two sets > of unambiguous documents may conflict with each other or at least the > two sets may seem to conflict for implementors. > > >>>But at the same time, I guess it is irresponsible to leave the RFC2462 >>>text on this point as is, because we know this issue has been annoying >>>implementors. > > >>In my view, only because they failed to review the addressing architecture, >>which is unambiguous. > > > I don't think so, because RFC2462 uses link-specific documents as the > primary source about (the length of the) the IFID: > > interface identifier - a link-dependent identifier for an interface > that is (at least) unique per link [ADDR-ARCH]. > [...] > The exact length of an interface identifier and the way > it is created is defined in a separate link-type specific > document that covers issues related to the transmission of IP > over a particular link type (e.g., [IPv6-ETHER]). > > BTW: according to what you were saying, it seems to me that > > 1. the primary source should actually be the ADDR-ARCH document, not > link-specific documents > 2. link-specific documents must be consistent with ADDR-ARCH. If not, > the IESG will reject the document. > > If this is the case, I'm just happy with it (is there any direct > reference which states that ADDR-ARCH is the primary?). Then it will > probably be enough to revise the definition to: > > interface identifier - a link-dependent identifier for an interface > that is (at least) unique per link [ADDR-ARCH]. > [...] > The exact length of an interface identifier is defined in > [ADDR-ARCH] based on the address format. The way it is > created is defined in a separate link-type specific document > that covers issues related to the transmission of IP over a > particular link type (e.g., [IPv6-ETHER]). > > perhaps with a note like this: > > The link-type specific document may also define the length of > the interface identifier. However, it must be consistent with > the definition in [ADDR-ARCH]. > > (If there is a reference that I asked above, it's also good to add the > reference here.) > > 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 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 19 16:15:48 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11022 for ; Wed, 19 May 2004 16:15:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXHU-0000hl-JD for ipv6-archive@odin.ietf.org; Wed, 19 May 2004 16:03:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JK3CdU002710 for ipv6-archive@odin.ietf.org; Wed, 19 May 2004 16:03:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWuc-000310-LU for ipv6-web-archive@optimus.ietf.org; Wed, 19 May 2004 15:39:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06692 for ; Wed, 19 May 2004 15:39:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQWub-0000Sw-9H for ipv6-web-archive@ietf.org; Wed, 19 May 2004 15:39:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQWrh-0007XS-00 for ipv6-web-archive@ietf.org; Wed, 19 May 2004 15:36:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQWqD-0007Am-00 for ipv6-web-archive@ietf.org; Wed, 19 May 2004 15:35:02 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQWgM-0003EJ-KN for ipv6-web-archive@ietf.org; Wed, 19 May 2004 15:24:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVqv-0007Lq-UG; Wed, 19 May 2004 14:31:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVLI-0002uQ-At for ipv6@optimus.ietf.org; Wed, 19 May 2004 13:59:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27496 for ; Wed, 19 May 2004 13:58:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQVLF-0003cL-NK for ipv6@ietf.org; Wed, 19 May 2004 13:58:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQVKO-0003Xw-00 for ipv6@ietf.org; Wed, 19 May 2004 13:58:05 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BQVJx-0003T6-00 for ipv6@ietf.org; Wed, 19 May 2004 13:57:37 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4JHudLr006423; Wed, 19 May 2004 10:56:40 -0700 (PDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4JHubQ05712; Wed, 19 May 2004 19:56:37 +0200 (MEST) Date: Wed, 19 May 2004 10:56:39 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols To: Christian Huitema Cc: Erik Nordmark , Ralph Droms , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 > > I'm certainly not implying any API. > > Why do you think the text with the forward reference to "a separate > > document" > > implies any API? > > The forward reference is asking the implementers to manage an extraneous > state variable. As far as ND is concerned, the host can be entirely > conformant and interoperate fine with others without that state variable. > So, the only reason for the state variable is to facilitate the > implementation of something else than ND, which will use the value of the > state variable. For that you need some form of API. Christian, I'm confused. You had propopsed text which still had the ManagedFlag in there. Your proposal was: On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), a host copies the value of the advertisement's M bit into ManagedFlag, which saves the mostly recently received value of the M bit. So if you think that the existence of the ManagedFlag implies that there is an API (which I don't think FWIW) then shouldn't you argue that all existance of ManagedFlag (and OtherConfigFlag) should be removed from the document? (and not just the above paragraph) Hence I'm confused. My concern is that in removing all mention of the state transitions we are removing information from the document, yet we haven't shown that that information is incorrect. (We haven't shown that it is needed either, but the approach seems to be leave things unchanged unless there is a reasonably strong case.) Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed May 19 17:33:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19338 for ; Wed, 19 May 2004 17:33:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYaN-0006NF-3Z for ipv6-archive@odin.ietf.org; Wed, 19 May 2004 17:26:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JLQlgn024499 for ipv6-archive@odin.ietf.org; Wed, 19 May 2004 17:26:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXbl-0007yZ-Bj for ipv6-web-archive@optimus.ietf.org; Wed, 19 May 2004 16:24:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11858 for ; Wed, 19 May 2004 16:24:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQXbj-0007G3-FK for ipv6-web-archive@ietf.org; Wed, 19 May 2004 16:24:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQXam-0007A3-00 for ipv6-web-archive@ietf.org; Wed, 19 May 2004 16:23:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQXaV-00074B-00 for ipv6-web-archive@ietf.org; Wed, 19 May 2004 16:22:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXJf-0001f3-EE; Wed, 19 May 2004 16:05:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWxv-000471-12 for ipv6@optimus.ietf.org; Wed, 19 May 2004 15:42:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07428 for ; Wed, 19 May 2004 15:42:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQWxt-00012V-7O for ipv6@ietf.org; Wed, 19 May 2004 15:42:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQWtq-0000GM-00 for ipv6@ietf.org; Wed, 19 May 2004 15:38:47 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1BQWqy-0007NK-00 for ipv6@ietf.org; Wed, 19 May 2004 15:35:48 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id B36F4A646; Wed, 19 May 2004 15:35:47 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 19 May 2004 15:35:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols Date: Wed, 19 May 2004 15:35:41 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644BFAE@tayexc13.americas.cpqcorp.net> Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols Thread-Index: AcQ91xcFpKENFEO4QiySOjdEUn4e6gAAUYdw From: "Bound, Jim" To: "Erik Nordmark" , "Christian Huitema" Cc: "Ralph Droms" , =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= , X-OriginalArrivalTime: 19 May 2004 19:35:46.0468 (UTC) FILETIME=[7B55FE40:01C43DD8] Content-Transfer-Encoding: base64 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RXJpaywNCg0KSnVzdCBjaGVja2luZy4gIFdlIGRvIG5lZWQgdGhlIE0gYml0IGZvciB0aG9zZSB3 YW50aW5nIHRvIHVzZSBzdGF0ZWZ1bD8gIE9yIGRvIHlvdSBub3QgYWdyZWU/DQoNCnRoYW5rcw0K L2ppbSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2LWFkbWlu QGlldGYub3JnIFttYWlsdG86aXB2Ni1hZG1pbkBpZXRmLm9yZ10gT24gDQo+IEJlaGFsZiBPZiBF cmlrIE5vcmRtYXJrDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDE5LCAyMDA0IDE6NTcgUE0NCj4g VG86IENocmlzdGlhbiBIdWl0ZW1hDQo+IENjOiBFcmlrIE5vcmRtYXJrOyBSYWxwaCBEcm9tczsg SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiTsgaXB2NkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS RTogW3JmYzI0NjJiaXNdIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIE0vTyBmbGFncyBhbmQgDQo+IHJl bGF0ZWQgcHJvdG9jb2xzDQo+IA0KPiA+ID4gSSdtIGNlcnRhaW5seSBub3QgaW1wbHlpbmcgYW55 IEFQSS4NCj4gPiA+IFdoeSBkbyB5b3UgdGhpbmsgdGhlIHRleHQgd2l0aCB0aGUgZm9yd2FyZCBy ZWZlcmVuY2UgdG8gDQo+ICJhIHNlcGFyYXRlIA0KPiA+ID4gZG9jdW1lbnQiDQo+ID4gPiBpbXBs aWVzIGFueSBBUEk/DQo+ID4gDQo+ID4gVGhlIGZvcndhcmQgcmVmZXJlbmNlIGlzIGFza2luZyB0 aGUgaW1wbGVtZW50ZXJzIHRvIG1hbmFnZSBhbiANCj4gPiBleHRyYW5lb3VzIHN0YXRlIHZhcmlh YmxlLiBBcyBmYXIgYXMgTkQgaXMgY29uY2VybmVkLCB0aGUgDQo+IGhvc3QgY2FuIGJlIA0KPiA+ IGVudGlyZWx5IGNvbmZvcm1hbnQgYW5kIGludGVyb3BlcmF0ZSBmaW5lIHdpdGggb3RoZXJzIA0K PiB3aXRob3V0IHRoYXQgc3RhdGUgdmFyaWFibGUuDQo+ID4gU28sIHRoZSBvbmx5IHJlYXNvbiBm b3IgdGhlIHN0YXRlIHZhcmlhYmxlIGlzIHRvIGZhY2lsaXRhdGUgdGhlIA0KPiA+IGltcGxlbWVu dGF0aW9uIG9mIHNvbWV0aGluZyBlbHNlIHRoYW4gTkQsIHdoaWNoIHdpbGwgdXNlIA0KPiB0aGUg dmFsdWUgb2YgDQo+ID4gdGhlIHN0YXRlIHZhcmlhYmxlLiBGb3IgdGhhdCB5b3UgbmVlZCBzb21l IGZvcm0gb2YgQVBJLg0KPiANCj4gQ2hyaXN0aWFuLA0KPiANCj4gSSdtIGNvbmZ1c2VkLiBZb3Ug aGFkIHByb3BvcHNlZCB0ZXh0IHdoaWNoIHN0aWxsIGhhZCB0aGUgDQo+IE1hbmFnZWRGbGFnIGlu IHRoZXJlLiBZb3VyIHByb3Bvc2FsIHdhczoNCj4gICAgICBPbiByZWNlaXB0IG9mIGEgdmFsaWQg Um91dGVyIEFkdmVydGlzZW1lbnQgKGFzIGRlZmluZWQgaW4NCj4gICAgICBbRElTQ09WRVJZXSks IGEgaG9zdCBjb3BpZXMgdGhlIHZhbHVlIG9mIHRoZSANCj4gYWR2ZXJ0aXNlbWVudCdzIE0gYml0 DQo+ICAgICAgaW50byBNYW5hZ2VkRmxhZywgd2hpY2ggc2F2ZXMgdGhlIG1vc3RseSByZWNlbnRs eSANCj4gcmVjZWl2ZWQgdmFsdWUgb2YNCj4gICAgICB0aGUgTSBiaXQuDQo+IA0KPiBTbyBpZiB5 b3UgdGhpbmsgdGhhdCB0aGUgZXhpc3RlbmNlIG9mIHRoZSBNYW5hZ2VkRmxhZyBpbXBsaWVzIA0K PiB0aGF0IHRoZXJlIGlzIGFuIEFQSSAod2hpY2ggSSBkb24ndCB0aGluayBGV0lXKSB0aGVuIA0K PiBzaG91bGRuJ3QgeW91IGFyZ3VlIHRoYXQgYWxsIGV4aXN0YW5jZSBvZiBNYW5hZ2VkRmxhZyAo YW5kIA0KPiBPdGhlckNvbmZpZ0ZsYWcpIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIGRvY3Vt ZW50PyAoYW5kIA0KPiBub3QganVzdCB0aGUgYWJvdmUgcGFyYWdyYXBoKSBIZW5jZSBJJ20gY29u ZnVzZWQuDQo+IA0KPiBNeSBjb25jZXJuIGlzIHRoYXQgaW4gcmVtb3ZpbmcgYWxsIG1lbnRpb24g b2YgdGhlIHN0YXRlIA0KPiB0cmFuc2l0aW9ucyB3ZSBhcmUgcmVtb3ZpbmcgaW5mb3JtYXRpb24g ZnJvbSB0aGUgZG9jdW1lbnQsIA0KPiB5ZXQgd2UgaGF2ZW4ndCBzaG93biB0aGF0IHRoYXQgaW5m b3JtYXRpb24gaXMgaW5jb3JyZWN0Lg0KPiAoV2UgaGF2ZW4ndCBzaG93biB0aGF0IGl0IGlzIG5l ZWRlZCBlaXRoZXIsIGJ1dCB0aGUgYXBwcm9hY2ggDQo+IHNlZW1zIHRvIGJlIGxlYXZlIHRoaW5n cyB1bmNoYW5nZWQgdW5sZXNzIHRoZXJlIGlzIGEgDQo+IHJlYXNvbmFibHkgc3Ryb25nIGNhc2Uu KQ0KPiANCj4gICBFcmlrDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtp bmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUg UmVxdWVzdHM6IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gDQo+IA0K -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 20 01:04:25 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13892 for ; Thu, 20 May 2004 01:04:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQfeY-0003x2-BR for ipv6-archive@odin.ietf.org; Thu, 20 May 2004 00:59:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K4xYCs015181 for ipv6-archive@odin.ietf.org; Thu, 20 May 2004 00:59:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQfdU-0003Yw-DU for ipv6-web-archive@optimus.ietf.org; Thu, 20 May 2004 00:58:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13522 for ; Thu, 20 May 2004 00:58:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQfdR-00026K-PK for ipv6-web-archive@ietf.org; Thu, 20 May 2004 00:58:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQfcX-0001wz-00 for ipv6-web-archive@ietf.org; Thu, 20 May 2004 00:57:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQfbV-0001nO-00 for ipv6-web-archive@ietf.org; Thu, 20 May 2004 00:56:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQfUL-0001Dm-T4; Thu, 20 May 2004 00:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQfRt-0000cN-FH for ipv6@optimus.ietf.org; Thu, 20 May 2004 00:46:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12881 for ; Thu, 20 May 2004 00:46:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQfRq-00003G-PK for ipv6@ietf.org; Thu, 20 May 2004 00:46:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQfQn-0007hV-00 for ipv6@ietf.org; Thu, 20 May 2004 00:45:22 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BQfQQ-0007Ym-00 for ipv6@ietf.org; Thu, 20 May 2004 00:44:58 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4K4iSLc026321; Wed, 19 May 2004 23:44:28 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 19 May 2004 23:44:27 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LHV8QKAL; Thu, 20 May 2004 00:44:26 -0400 Date: Thu, 20 May 2004 00:43:29 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: OOTOMO Hiroyuki cc: ipv6@ietf.org Subject: Re: RFC2460 problem - error processing of Routing Header In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830D8F6D7A@eammlex037.lmc.ericsson.se> Message-ID: <7B2A7784F4B7F0409947481F3F3FEF83103BCEA1-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi Ootomo, See comments inline. Regards Suresh On Tue, 18 May 2004, OOTOMO Hiroyuki wrote: >Hi, all. > >I found a problem in RFC2460, about error processing of Routing Header. >It does not define the behavior of End Node when the End Node received >the packet which has odd Hdr.Ext.Len. > > >(Section 4.4) >> A Routing header is not examined or processed until it reaches the >> node identified in the Destination Address field of the IPv6 header. >> In that node, dispatching on the Next Header field of the immediately >> preceding header causes the Routing header module to be invoked, >> which, in the case of Routing Type 0, performs the following >> algorithm: >> >> if Segments Left = 0 { >> proceed to process the next header in the packet, whose type is >> identified by the Next Header field in the Routing header >> } >> else if Hdr Ext Len is odd { >> send an ICMP Parameter Problem, Code 0, message to the Source >> Address, pointing to the Hdr Ext Len field, and discard the >> packet >> } ><<< snip >>> > > >When the IPv6 packet with the Routing Header is as follows (example): > > [IPv6 Header] > Source Address: host-0 > Destination Address: host-4 > Next Header: Routing Header > [Routing Header] > Next Header: ICMPv6 > Hdr.Ext.Len: 5 > Routing Type: 0 > Segment Left: 0 > Address: router-1 > Address: router-2 > Address: router-3 > [ICMPv6] > ICMPv6 Echo Request > > >The Routing Header in this packet has Hdr.Ext.Len with invalid odd number >and Segment Left with 0. This packet will NEVER reach host-4. Consider the packet when it reaches router-1 [IPv6 Header] Source Address: host-0 Destination Address: router-1 Next Header: Routing Header [Routing Header] Next Header: ICMPv6 Hdr.Ext.Len: 5 Routing Type: 0 Segment Left: 3 Address: router-2 Address: router-3 Address: host-4 [ICMPv6] ICMPv6 Echo Request router-1 will follow the algorithm for RH processing. The Segments Left is greater than 0. So it will check the header ext len and find it to be odd. It will drop the packet and send an ICMP message back to host-0. I guess the general idea is that the first destination node will detect the problem with the header ext len. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 20 06:07:57 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09128 for ; Thu, 20 May 2004 06:07:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQkQw-0000Jg-Q1 for ipv6-archive@odin.ietf.org; Thu, 20 May 2004 06:05:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KA5oMF001216 for ipv6-archive@odin.ietf.org; Thu, 20 May 2004 06:05:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQkKs-0007mj-Mn for ipv6-web-archive@optimus.ietf.org; Thu, 20 May 2004 05:59:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08748 for ; Thu, 20 May 2004 05:59:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQkKp-0006Nd-1O for ipv6-web-archive@ietf.org; Thu, 20 May 2004 05:59:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQkJq-0006Br-00 for ipv6-web-archive@ietf.org; Thu, 20 May 2004 05:58:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQkIz-00060T-00 for ipv6-web-archive@ietf.org; Thu, 20 May 2004 05:57:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQk9t-0006JV-Cr; Thu, 20 May 2004 05:48:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQk22-0005AL-9g for ipv6@optimus.ietf.org; Thu, 20 May 2004 05:40:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08075 for ; Thu, 20 May 2004 05:40:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQk1y-0002g5-NM for ipv6@ietf.org; Thu, 20 May 2004 05:40:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQk0z-0002S4-00 for ipv6@ietf.org; Thu, 20 May 2004 05:39:02 -0400 Received: from zns001-0m9001.yokogawa.co.jp ([203.174.79.138]) by ietf-mx with esmtp (Exim 4.12) id 1BQk08-0002Da-00 for ipv6@ietf.org; Thu, 20 May 2004 05:38:09 -0400 Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.11.7+Sun/8.11.6) with ESMTP id i4K9c8C23298 for ; Thu, 20 May 2004 18:38:08 +0900 (JST) Received: from EXCHANGE04.jp.ykgw.net (zex001-0m9004.jp.ykgw.net [10.0.10.55]) by zns001-0m9001.yokogawa.co.jp (8.11.7+Sun/8.11.6) with ESMTP id i4K9c7k23289; Thu, 20 May 2004 18:38:07 +0900 (JST) Received: from cpc001-12698-02 ([10.0.103.208]) by EXCHANGE04.jp.ykgw.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 20 May 2004 18:38:07 +0900 Date: Thu, 20 May 2004 18:38:07 +0900 From: OOTOMO Hiroyuki Subject: Re: RFC2460 problem - error processing of Routing Header To: Suresh Krishnan Cc: ipv6@ietf.org Organization: Yokogawa Electric Corp. In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF83103BCEA1-100000@eammlex037.lmc.ericsson.se> References: <7B2A7784F4B7F0409947481F3F3FEF83103BCEA1-100000@eammlex037.lmc.ericsson.se> X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-ID: X-OriginalArrivalTime: 20 May 2004 09:38:07.0078 (UTC) FILETIME=[27E31060:01C43E4E] 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Hi Shresh. > This packet will NEVER reach host-4. Consider the packet when it > reaches router-1 <<< snipped >>> > router-1 will follow the algorithm for RH processing. The Segments Left is > greater than 0. So it will check the header ext len and find it to be odd. > It will drop the packet and send an ICMP message back to host-0. I guess > the general idea is that the first destination node will detect the > problem with the header ext len. Of course what you said is true, but it is the case when the first destination node (and all intermediate nodes) was normal. What I said in previous mail is the case when the packet reached to End Node unfortunately. e.g., If all routers via which the packet goes have broken (although it is a very rare case) and overlook the invalid Hdr.Ext.Len, the trouble will happen. e.g., If an evil node transmit the packet with odd Hdr.Ext.Len and zero Segment Left suddenly, the trouble will happen. Isn't it connected with other vulnerabilities and become a security hole etc.? -- OOTOMO Hiroyuki -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 20 12:13:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28611 for ; Thu, 20 May 2004 12:13:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpv0-00048P-I4 for ipv6-archive@odin.ietf.org; Thu, 20 May 2004 11:57:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KFvEr8015889 for ipv6-archive@odin.ietf.org; Thu, 20 May 2004 11:57:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpe3-0006Nr-MX for ipv6-web-archive@optimus.ietf.org; Thu, 20 May 2004 11:39:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24981 for ; Thu, 20 May 2004 11:39:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpe1-0005Yk-UX for ipv6-web-archive@ietf.org; Thu, 20 May 2004 11:39:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpd4-0005SP-00 for ipv6-web-archive@ietf.org; Thu, 20 May 2004 11:38:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQpcA-0005MC-00 for ipv6-web-archive@ietf.org; Thu, 20 May 2004 11:37:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQp6e-0004T3-5r; Thu, 20 May 2004 11:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQnPl-000603-7J for ipv6@optimus.ietf.org; Thu, 20 May 2004 09:16:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15921 for ; Thu, 20 May 2004 09:16:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQnPj-0006Hh-Iy for ipv6@ietf.org; Thu, 20 May 2004 09:16:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQnOp-00065L-00 for ipv6@ietf.org; Thu, 20 May 2004 09:15:52 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BQnO5-0005sq-00 for ipv6@ietf.org; Thu, 20 May 2004 09:15:05 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:b1fe:fc0c:423c:28f]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 05A1015263; Thu, 20 May 2004 22:14:56 +0900 (JST) Date: Thu, 20 May 2004 22:14:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian E Carpenter Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID In-Reply-To: <40AB33FB.8020300@zurich.ibm.com> References: <40AA2FC7.302@zurich.ibm.com> <40AB33FB.8020300@zurich.ibm.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Wed, 19 May 2004 12:16:27 +0200, >>>>> Brian E Carpenter said: > Jinmei, I believe your proposed new text at the bottom is correct. > 2462bis should not open the door to conflict in future link-layer > specs. Okay, but after re-reading the proposed new text, I then changed my mind a bit; it should be better to use link specific documents as the primary source of the IFID length. Otherwise, the implementor would wonder how they should do if a received prefix in an RA does not match ones for which ADDR-ARCH defines the corresponding IFID length. So, the better text would be as follows: interface identifier - a link-dependent identifier for an interface that is (at least) unique per link [ADDR-ARCH]. Stateless address autoconfiguration combines an interface identifier with a prefix to form an address. From address autoconfiguration's perspective, an interface identifier is a bit string of known length. The exact length of an interface identifier and the way it is created is defined in a separate link-type specific document that covers issues related to the transmission of IP over a particular link type (e.g., [IPv6-ETHER]). (i.e., the same text as RFC2462) with a note about the relationship between ADDR-ARCH and link specific documents to avoid confusion: Note that [ADDR-ARCH] also defines the length of the interface identifiers for some set of addresses, but the two sets of definitions must be consistent. It should also be good to emphasize that the implementation should not assume the particular constant "64" like this: Note that a future revision of [ADDR-ARCH] and a future link-type specific document could potentially allow for an interface identifier of length other than 64 bits. Thus, an implementation should not assume that particular constant. Rather, it should expect any lengths of interface identifiers. (the text you proposed in an earlier message) Makes sense? 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 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 20 15:06:59 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12668 for ; Thu, 20 May 2004 15:06:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQspe-0006vl-Rw for ipv6-archive@odin.ietf.org; Thu, 20 May 2004 15:03:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KJ3sEQ026641 for ipv6-archive@odin.ietf.org; Thu, 20 May 2004 15:03:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQser-0008NI-Bc for ipv6-web-archive@optimus.ietf.org; Thu, 20 May 2004 14:52:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11436 for ; Thu, 20 May 2004 14:52:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQseo-0002Zl-Co for ipv6-web-archive@ietf.org; Thu, 20 May 2004 14:52:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQse5-0002WB-00 for ipv6-web-archive@ietf.org; Thu, 20 May 2004 14:51:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQsdc-0002Rn-00 for ipv6-web-archive@ietf.org; Thu, 20 May 2004 14:51:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsUe-0005lG-II; Thu, 20 May 2004 14:42:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsLb-0001FL-JU for ipv6@optimus.ietf.org; Thu, 20 May 2004 14:32:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09970 for ; Thu, 20 May 2004 14:32:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQsLY-0000g0-UV for ipv6@ietf.org; Thu, 20 May 2004 14:32:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQsKZ-0000aP-00 for ipv6@ietf.org; Thu, 20 May 2004 14:31:47 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BQsJa-0000Pz-00 for ipv6@ietf.org; Thu, 20 May 2004 14:30:46 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4KIS9oK010913; Thu, 20 May 2004 11:28:10 -0700 (PDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4KIS7Q23928; Thu, 20 May 2004 20:28:07 +0200 (MEST) Date: Thu, 20 May 2004 10:31:48 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols To: "Bound, Jim" Cc: Erik Nordmark , Christian Huitema , Ralph Droms , =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= , ipv6@ietf.org In-Reply-To: "Your message with ID" <9C422444DE99BC46B3AD3C6EAFC9711B0644BFAE@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 > Just checking. We do need the M bit for those wanting to use stateful? Or > do you not agree? I agree with the Jinmei's definition that the M bit indicates to the host that DHCPv6 for IP address configuration is available on the link. With that definition it is possible to build hosts that initialize efficiently, by only trying to use DHCPv6 when the router advertisements say that it is available. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu May 20 20:43:57 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09002 for ; Thu, 20 May 2004 20:43:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQy66-0006oa-90 for ipv6-archive@odin.ietf.org; Thu, 20 May 2004 20:41:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L0fEBd026196 for ipv6-archive@odin.ietf.org; Thu, 20 May 2004 20:41:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQy33-00067c-00 for ipv6-web-archive@optimus.ietf.org; Thu, 20 May 2004 20:38:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08738 for ; Thu, 20 May 2004 20:38:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQy30-0006v2-P5 for ipv6-web-archive@ietf.org; Thu, 20 May 2004 20:38:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQy2I-0006qb-00 for ipv6-web-archive@ietf.org; Thu, 20 May 2004 20:37:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQy1B-0006l7-00 for ipv6-web-archive@ietf.org; Thu, 20 May 2004 20:36:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQxvG-0003Y3-CZ; Thu, 20 May 2004 20:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQxob-0002Qr-PG for ipv6@optimus.ietf.org; Thu, 20 May 2004 20:23:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08181 for ; Thu, 20 May 2004 20:23:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQxoZ-0005z2-L2 for ipv6@ietf.org; Thu, 20 May 2004 20:23:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQxne-0005vQ-00 for ipv6@ietf.org; Thu, 20 May 2004 20:22:11 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BQxn6-0005pm-00 for ipv6@ietf.org; Thu, 20 May 2004 20:21:36 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4L0L0Lc019727; Thu, 20 May 2004 19:21:00 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 20 May 2004 19:20:50 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LHV8QTDQ; Thu, 20 May 2004 20:20:48 -0400 Date: Thu, 20 May 2004 20:19:49 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: OOTOMO Hiroyuki cc: Suresh Krishnan , Subject: Re: RFC2460 problem - error processing of Routing Header In-Reply-To: Message-ID: MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi Ootomo See comments inline. Regards Suresh On Thu, 20 May 2004, OOTOMO Hiroyuki wrote: >Hi Shresh. > >> This packet will NEVER reach host-4. Consider the packet when it >> reaches router-1 ><<< snipped >>> >> router-1 will follow the algorithm for RH processing. The Segments Left is >> greater than 0. So it will check the header ext len and find it to be odd. >> It will drop the packet and send an ICMP message back to host-0. I guess >> the general idea is that the first destination node will detect the >> problem with the header ext len. > >Of course what you said is true, but it is the case >when the first destination node (and all intermediate nodes) >was normal. > >What I said in previous mail is the case when the packet >reached to End Node unfortunately. > >e.g., If all routers via which the packet goes have broken >(although it is a very rare case) and overlook the invalid >Hdr.Ext.Len, the trouble will happen. Even if we check the header length before checking the segments left we can still have a problem. > >e.g., If an evil node transmit the packet with odd Hdr.Ext.Len >and zero Segment Left suddenly, the trouble will happen. The evil node can transmit the packet with an EVEN header ext len which is WRONG and the new algorithm can still not catch it. So I guess it is not worth it trying to change the algorithm as the cons outweigh the pros. > >Isn't it connected with other vulnerabilities and become >a security hole etc.? > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 21 02:04:04 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28052 for ; Fri, 21 May 2004 02:04:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR2yX-0006LJ-SM for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 01:53:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L5rjsf024381 for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 01:53:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR2yB-00068T-WA for ipv6-web-archive@optimus.ietf.org; Fri, 21 May 2004 01:53:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23553 for ; Fri, 21 May 2004 01:53:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR2y8-0000A0-Rq for ipv6-web-archive@ietf.org; Fri, 21 May 2004 01:53:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR2xJ-00002c-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 01:52:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR2wR-0007it-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 01:51:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR2p7-0004LB-Ro; Fri, 21 May 2004 01:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR2nP-000400-B9 for ipv6@optimus.ietf.org; Fri, 21 May 2004 01:42:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23120 for ; Fri, 21 May 2004 01:42:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR2nL-0006Zv-Vh for ipv6@ietf.org; Fri, 21 May 2004 01:42:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR2mQ-0006Tt-00 for ipv6@ietf.org; Fri, 21 May 2004 01:41:15 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BR2lt-0006OC-00 for ipv6@ietf.org; Fri, 21 May 2004 01:40:41 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:9d2d:1b97:76ed:d268]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id DAB951525D; Fri, 21 May 2004 14:40:39 +0900 (JST) Date: Fri, 21 May 2004 14:40:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: Christian Huitema , Ralph Droms , ipv6@ietf.org Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols In-Reply-To: References: 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Wed, 19 May 2004 10:56:39 -0700 (PDT), >>>>> Erik Nordmark said: > So if you think that the existence of the ManagedFlag implies that there > is an API (which I don't think FWIW) then shouldn't you argue that > all existance of ManagedFlag (and OtherConfigFlag) should be removed > from the document? (and not just the above paragraph) > Hence I'm confused. I was also confused about the same point, so I asked a question to clarify the intention in a separate message...but I've not seen a response to it. > My concern is that in removing all mention of the state transitions > we are removing information from the document, yet we haven't shown > that that information is incorrect. > (We haven't shown that it is needed either, but the approach seems to > be leave things unchanged unless there is a reasonably strong case.) Assuming it's okay for Christian to mention other documents on details, can you live with the last proposal from Ralph? The details of how a host uses the M flag from a valid Router Advertisement it receives will be described in a separate document. Or, if you feel happier by mentioning changes of the M bit explicitly, we could alternatively say The details of how a host uses the M flag, including any use of the "on" and "off" transitions for this flag, to control the use of DHCPv6 for address assignment will be described in a separate document. (based on a previous text from Ralph) This way, we can avoid the use of the "possibly extraneous state variable" which is internal information in the implementation, while keeping the essential idea about external behavior. 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 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 21 02:39:24 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09097 for ; Fri, 21 May 2004 02:39:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR3WC-0004HH-2z for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 02:28:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L6SWP5016422 for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 02:28:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR3Uy-0003mQ-Oq for ipv6-web-archive@optimus.ietf.org; Fri, 21 May 2004 02:27:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08453 for ; Fri, 21 May 2004 02:27:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR3Uv-0004Jv-6X for ipv6-web-archive@ietf.org; Fri, 21 May 2004 02:27:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR3U0-0004Bh-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 02:26:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR3T9-00045C-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 02:25:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR3L5-0007eY-34; Fri, 21 May 2004 02:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR3Df-0003tq-2v for ipv6@optimus.ietf.org; Fri, 21 May 2004 02:09:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03343 for ; Fri, 21 May 2004 02:09:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR3Db-0001xh-Hk for ipv6@ietf.org; Fri, 21 May 2004 02:09:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR3CZ-0001qL-00 for ipv6@ietf.org; Fri, 21 May 2004 02:08:16 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BR3Bb-0001d6-00 for ipv6@ietf.org; Fri, 21 May 2004 02:07:15 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 May 2004 23:06:45 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 May 2004 23:06:45 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 May 2004 23:06:51 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 May 2004 23:06:17 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 20 May 2004 23:07:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols Date: Thu, 20 May 2004 23:06:40 -0700 Message-ID: Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols thread-index: AcQ+9kCMAA72NaJjS8CcuSL3wJzVYQAA0Nfg From: "Christian Huitema" To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , "Erik Nordmark" Cc: "Ralph Droms" , X-OriginalArrivalTime: 21 May 2004 06:07:18.0656 (UTC) FILETIME=[DF40C800:01C43EF9] Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Assuming it's okay for Christian to mention other documents on > details, can you live with the last proposal from Ralph? > > The details of how a host uses the M flag from a valid Router > Advertisement it receives will be described in a separate document. I can certainly live with that, but I would rather say: The details of how a host may use the M flag from a valid Router Advertisement it receives will be described in a separate document. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 21 03:38:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12648 for ; Fri, 21 May 2004 03:38:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR4Za-0002sI-VZ for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 03:36:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L7a6hb011044 for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 03:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR4SK-0001Vy-U6 for ipv6-web-archive@optimus.ietf.org; Fri, 21 May 2004 03:28:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12255 for ; Fri, 21 May 2004 03:28:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR4SI-00055j-Oe for ipv6-web-archive@ietf.org; Fri, 21 May 2004 03:28:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR4Q8-0004w2-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 03:26:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR4PD-0004oo-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 03:25:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR4I6-0007F0-UN; Fri, 21 May 2004 03:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR48f-0004Yp-3w for ipv6@optimus.ietf.org; Fri, 21 May 2004 03:08:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11048 for ; Fri, 21 May 2004 03:08:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR48a-0002Gn-Uq for ipv6@ietf.org; Fri, 21 May 2004 03:08:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR47g-0002Az-00 for ipv6@ietf.org; Fri, 21 May 2004 03:07:17 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BR478-00024z-00 for ipv6@ietf.org; Fri, 21 May 2004 03:06:43 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:9d2d:1b97:76ed:d268]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 934C615263 for ; Fri, 21 May 2004 16:06:42 +0900 (JST) Date: Fri, 21 May 2004 16:06:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis issue 281] "64-bit assumption" and prefix length 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 One more question about the prefix (and IFID) length. Since the IFID length is defined in the link specific document (which must be consistent with addr-arch, based on discussions so far) and the prefix length is 128 - IFID_length by definition, the appropriate prefix length must implicitly given by the link specific document. The implementors may wonder why the RA bothers to specify the prefix length in its prefix information option. Recall that we have had a similar discussion in the context of 2461bis: https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01600.html My conclusion to this point including the one in the 2461bis context is as follows: The prefix length in the prefix information option has non trivial meaning for specifying an on-link prefix with the L flag. For this purpose, the length can be shorter (or perhaps even longer) than "128 - IFID_length". For example, if the following four prefixes should be regarded as "on-link": 2001:db8:0:00::/64, 2001:db8:0:01::/64, 2001:db8:0:10::/64, 2001:db8:0:11::/64 then the administrator may want to advertise the set of the prefixes as "on-link" by sending a single aggregated prefix "2001:db8::/62" with the L flag being set, instead of sending the four prefixes separately. So, my answer to Hesham's question (see the message available at the above URL), what we should do is: just accept any lengths of prefixes in terms of the "on-link" processing. We may or may not want to add an explicit note that the "prefix length + IFID_length" may not be equal to 128 but it's okay for the on-link determination. For rfc2462bis, I'd add a note to bullet d) of Section 5.5.3: If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. like this: Note that the appropriate prefix length should be determined by the interface identifier length and in that sense the advertised prefix length is meaningless information. However, the advertised prefix length has non trivial meaning for on-link determination in Neighbor Discovery where the sume of the prefix length and the interface identifier length may not be equal to 128. Thus, it should be safe to validate the advertised prefix length here, in order to detect and avoid a configuration error specifying an invalid prefix length in the context of address autoconfiguration. Comments? 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 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 21 04:44:52 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15661 for ; Fri, 21 May 2004 04:44:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5VK-0000Ek-4R for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 04:35:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L8Zj8B000879 for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 04:35:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5OG-0006yB-1p for ipv6-web-archive@optimus.ietf.org; Fri, 21 May 2004 04:28:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14668 for ; Fri, 21 May 2004 04:28:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5OD-0005D3-Ab for ipv6-web-archive@ietf.org; Fri, 21 May 2004 04:28:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5NQ-00055C-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 04:27:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR5Md-0004wP-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 04:26:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5F9-0004rc-7I; Fri, 21 May 2004 04:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5AW-0003ZQ-ES for ipv6@optimus.ietf.org; Fri, 21 May 2004 04:14:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13849 for ; Fri, 21 May 2004 04:14:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5AT-0003Bc-NM for ipv6@ietf.org; Fri, 21 May 2004 04:14:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR59V-00033O-00 for ipv6@ietf.org; Fri, 21 May 2004 04:13:14 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BR58Y-0002vE-00 for ipv6@ietf.org; Fri, 21 May 2004 04:12:14 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:9d2d:1b97:76ed:d268]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 61B4C15263 for ; Fri, 21 May 2004 17:12:11 +0900 (JST) Date: Fri, 21 May 2004 17:12:11 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis] reword "stateful" for other config info? 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 One (perhaps last) question about the M/O flags for rfc2462bis: Currently, RFC2462 uses the term "stateful" as the counter part of the "stateless" configuration defined in RFC2462, both for address configuration (the M flag) and for other configuration (the O flag). Using "stateful" should be okay for address configuration (the M flag part). However, as Ralph pointed out before, "stateful" may not be appropriate for other configuration information: https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg02262.html In particular, the fact that RFC3736 (which we are primarily considering as the protocol for the O flag) is entitled "*Stateless* Dynamic Host Configuration Protocol (DHCP) Service for IPv6" will confuse implementors if we keep calling it "stateful" in rfc2462bis. So, I strongly believe we should clarify this point in some way. Possible solutions would include: 1. remove "stateful" from the definition of the O flag (in rfc2461bis), that is, change O 1-bit "Other stateful configuration" flag. When set, hosts use the administered (stateful) protocol for autoconfiguration of other (non-address) information. The use of this flag is described in [ADDRCONF]. (RFC2461 Section 4.2) to (e.g.): O 1-bit "Other configuration" flag. When set, hosts use a separate protocol for autoconfiguration of other (non-address) information. The use of this flag is described in [ADDRCONF]. and reword rfc2462bis accordingly. 2. do not touch the definition of the O flag, but add notes for clarification in rfc2462bis like this: While the flag and the corresponding protocol are called "stateful" in order to highlight the contrast to the stateless protocol defined in this document, the intended protocol [RFC3736] is also defined to work in a stateless fashion. This is based on a result, through experiments, that all known "other" configuration information can be managed by a stateless server, that is, a server that does not maintain state of each client that the server provides with the configuration information. I personally prefer the former with small preference since it should be a cleaner clarification. But I can live with the second approach, too. What do others think? Is there any other opinions? 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 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 21 05:38:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18936 for ; Fri, 21 May 2004 05:38:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6S6-0000AU-EZ for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 05:36:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L9aUxH000636 for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 05:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6OE-0007ME-6W for ipv6-web-archive@optimus.ietf.org; Fri, 21 May 2004 05:32:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18499 for ; Fri, 21 May 2004 05:32:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR6OA-0007LR-Qy for ipv6-web-archive@ietf.org; Fri, 21 May 2004 05:32:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR6NJ-0007DD-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 05:31:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR6MY-00074M-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 05:30:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR67Y-00033g-1G; Fri, 21 May 2004 05:15:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5wC-0008Fl-D7 for ipv6@optimus.ietf.org; Fri, 21 May 2004 05:03:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16969 for ; Fri, 21 May 2004 05:03:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5w9-00033x-6B for ipv6@ietf.org; Fri, 21 May 2004 05:03:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5ve-0002up-00 for ipv6@ietf.org; Fri, 21 May 2004 05:02:59 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BR5uf-0002iA-00 for ipv6@ietf.org; Fri, 21 May 2004 05:01:57 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4L91wWE027899 for ; Fri, 21 May 2004 10:01:58 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA11386 for ; Fri, 21 May 2004 10:01:55 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4L91tR16583 for ipv6@ietf.org; Fri, 21 May 2004 10:01:55 +0100 Date: Fri, 21 May 2004 10:01:55 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: [rfc2462bis] reword "stateful" for other config info? Message-ID: <20040521090155.GN14686@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 On Fri, May 21, 2004 at 05:12:11PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > What do others think? Is there any other opinions? It depends where the state is :) For example, there is a proposal to have lifetime information for the other configuration (non address) data. http://www.ietf.org/internet-drafts/draft-venaas-dhc-lifetime-01.txt Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 21 06:28:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22002 for ; Fri, 21 May 2004 06:28:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR74A-0003Bb-Ea for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 06:15:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LAFo6x012248 for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 06:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6yN-0000Tb-Cf for ipv6-web-archive@optimus.ietf.org; Fri, 21 May 2004 06:09:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20665 for ; Fri, 21 May 2004 06:09:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR6yJ-0005Tl-MG for ipv6-web-archive@ietf.org; Fri, 21 May 2004 06:09:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR6wj-00056N-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 06:08:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR6vG-0004ps-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 06:06:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6o0-0005n1-D5; Fri, 21 May 2004 05:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6ed-0003lx-VY for ipv6@optimus.ietf.org; Fri, 21 May 2004 05:49:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19599 for ; Fri, 21 May 2004 05:49:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR6ea-0002C2-Bn for ipv6@ietf.org; Fri, 21 May 2004 05:49:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR6di-00021o-00 for ipv6@ietf.org; Fri, 21 May 2004 05:48:30 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BR6d3-0001tK-00 for ipv6@ietf.org; Fri, 21 May 2004 05:47:49 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:9d2d:1b97:76ed:d268]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 89EFE1525D; Fri, 21 May 2004 18:47:32 +0900 (JST) Date: Fri, 21 May 2004 18:47:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Chown Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] reword "stateful" for other config info? In-Reply-To: <20040521090155.GN14686@login.ecs.soton.ac.uk> References: <20040521090155.GN14686@login.ecs.soton.ac.uk> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Fri, 21 May 2004 10:01:55 +0100, >>>>> Tim Chown said: >> What do others think? Is there any other opinions? > It depends where the state is :) Of course, but the important point is to avoid the possible confusion that comes from the following facts: - RFC2462 calls the protocol for the O flag "stateful" - RFC3736, which we are primarily considering as the protocol for the O flag, contains "Stateless" in its title In this sense, > For example, there is a proposal to have lifetime information for the other > configuration (non address) data. > http://www.ietf.org/internet-drafts/draft-venaas-dhc-lifetime-01.txt the existence of the lifetime option does not affect anything about the discussion, IMO. 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 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 21 06:55:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23421 for ; Fri, 21 May 2004 06:55:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7XW-0001Lp-Km for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 06:46:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LAkALc005189 for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 06:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7Is-0006gb-Co for ipv6-web-archive@optimus.ietf.org; Fri, 21 May 2004 06:31:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22270 for ; Fri, 21 May 2004 06:30:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR7Io-0001YY-FK for ipv6-web-archive@ietf.org; Fri, 21 May 2004 06:30:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR7Hu-0001Kw-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 06:30:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR7H5-00016b-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 06:29:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR76H-0003r3-Ts; Fri, 21 May 2004 06:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR703-0001E7-49 for ipv6@optimus.ietf.org; Fri, 21 May 2004 06:11:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20793 for ; Fri, 21 May 2004 06:11:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR6zz-0005m2-AI for ipv6@ietf.org; Fri, 21 May 2004 06:11:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR6y4-0005Rl-00 for ipv6@ietf.org; Fri, 21 May 2004 06:09:32 -0400 Received: from zns001-0m9002.yokogawa.co.jp ([203.174.79.139]) by ietf-mx with esmtp (Exim 4.12) id 1BR6wO-00053g-00 for ipv6@ietf.org; Fri, 21 May 2004 06:07:48 -0400 Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.11.7+Sun/8.11.6) with ESMTP id i4LA7kx00839 for ; Fri, 21 May 2004 19:07:46 +0900 (JST) Received: from EXCHANGE04.jp.ykgw.net (zex001-0m9004.jp.ykgw.net [10.0.10.55]) by zns001-0m9002.yokogawa.co.jp (8.11.7+Sun/8.11.6) with ESMTP id i4LA7jU00832; Fri, 21 May 2004 19:07:45 +0900 (JST) Received: from cpc001-12698-02 ([10.0.103.208]) by EXCHANGE04.jp.ykgw.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 May 2004 19:07:45 +0900 Date: Fri, 21 May 2004 19:07:45 +0900 From: OOTOMO Hiroyuki Subject: Re: RFC2460 problem - error processing of Routing Header To: Suresh Krishnan Cc: Organization: Yokogawa Electric Corp. In-Reply-To: References: X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-ID: X-OriginalArrivalTime: 21 May 2004 10:07:45.0612 (UTC) FILETIME=[766390C0:01C43F1B] 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Hi, Suresh. > >e.g., If all routers via which the packet goes have broken > >(although it is a very rare case) and overlook the invalid > >Hdr.Ext.Len, the trouble will happen. > > Even if we check the header length before checking the segments left we > can still have a problem. > > > > >e.g., If an evil node transmit the packet with odd Hdr.Ext.Len > >and zero Segment Left suddenly, the trouble will happen. > > The evil node can transmit the packet with an EVEN header ext len which is > WRONG and the new algorithm can still not catch it. So I guess it is not > worth it trying to change the algorithm as the cons outweigh the pros. I understand. My proposal will solve a half of this problem, but it will not clear the remaining half. It was not a wonderful solution to deserve to correct RFC. I will consider the better methods. Thank you. -- OOTOMO Hiroyuki -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 21 07:00:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23769 for ; Fri, 21 May 2004 07:00:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7iG-0005Cf-VW for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 06:57:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LAvGnW020001 for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 06:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7ax-0003cJ-Ab for ipv6-web-archive@optimus.ietf.org; Fri, 21 May 2004 06:49:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23199 for ; Fri, 21 May 2004 06:49:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR7at-0004xu-8I for ipv6-web-archive@ietf.org; Fri, 21 May 2004 06:49:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR7Zv-0004k9-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 06:48:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR7Z4-0004Vb-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 06:47:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7J1-0006iG-Ji; Fri, 21 May 2004 06:31:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR78K-0004BG-5N for ipv6@optimus.ietf.org; Fri, 21 May 2004 06:20:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21625 for ; Fri, 21 May 2004 06:20:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR78G-0007Ph-0r for ipv6@ietf.org; Fri, 21 May 2004 06:20:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR77Q-0007D1-00 for ipv6@ietf.org; Fri, 21 May 2004 06:19:12 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BR76I-0006wj-00 for ipv6@ietf.org; Fri, 21 May 2004 06:18:02 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4LAHwWE029394 for ; Fri, 21 May 2004 11:17:58 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA16401 for ; Fri, 21 May 2004 11:17:54 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4LAHsc18098 for ipv6@ietf.org; Fri, 21 May 2004 11:17:54 +0100 Date: Fri, 21 May 2004 11:17:54 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: [rfc2462bis] reword "stateful" for other config info? Message-ID: <20040521101754.GP14686@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <20040521090155.GN14686@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 On Fri, May 21, 2004 at 06:47:32PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > - RFC2462 calls the protocol for the O flag "stateful" > - RFC3736, which we are primarily considering as the protocol for the > O flag, contains "Stateless" in its title OK, understood, and yes I agree. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 21 13:10:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15837 for ; Fri, 21 May 2004 13:10:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDW1-0004aV-Vs for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 13:09:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LH91fI017635 for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 13:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDUg-0003oe-5y for ipv6-web-archive@optimus.ietf.org; Fri, 21 May 2004 13:07:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15566 for ; Fri, 21 May 2004 13:07:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRDUe-0004oh-CV for ipv6-web-archive@ietf.org; Fri, 21 May 2004 13:07:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRDTh-0004le-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 13:06:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRDT2-0004ix-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 13:05:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDGd-0000lJ-DF; Fri, 21 May 2004 12:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDAK-0007jp-TT for ipv6@optimus.ietf.org; Fri, 21 May 2004 12:46:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14315 for ; Fri, 21 May 2004 12:46:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRDAJ-0003Kg-60 for ipv6@ietf.org; Fri, 21 May 2004 12:46:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRD9K-0003FR-00 for ipv6@ietf.org; Fri, 21 May 2004 12:45:34 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1BRD8M-0003BB-00 for ipv6@ietf.org; Fri, 21 May 2004 12:44:34 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4LGgUMP028588; Fri, 21 May 2004 10:42:31 -0600 (MDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4LGhuQ12785; Fri, 21 May 2004 18:43:57 +0200 (MEST) Date: Fri, 21 May 2004 09:43:58 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , Christian Huitema , Ralph Droms , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 > Or, if you feel happier by mentioning changes of the M bit explicitly, > we could alternatively say > > The details of how a host uses the M flag, including any use of > the "on" and "off" transitions for this flag, to control the use > of DHCPv6 for address assignment will be described in a separate > document. > (based on a previous text from Ralph) > > This way, we can avoid the use of the "possibly extraneous state > variable" which is internal information in the implementation, while > keeping the essential idea about external behavior. The text above is fine with me. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 21 13:35:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17193 for ; Fri, 21 May 2004 13:35:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDu2-0001w2-Pf for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 13:33:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LHXotX007439 for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 13:33:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDqg-0000xI-9P for ipv6-web-archive@optimus.ietf.org; Fri, 21 May 2004 13:30:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16617 for ; Fri, 21 May 2004 13:30:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRDqe-0006DT-92 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 13:30:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRDpG-00060I-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 13:28:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRDoQ-0005vF-04 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 13:28:02 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BRDmE-0001jG-MF for ipv6-web-archive@ietf.org; Fri, 21 May 2004 13:25:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDem-0006kp-03; Fri, 21 May 2004 13:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDZU-0005bo-Qz for ipv6@optimus.ietf.org; Fri, 21 May 2004 13:12:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15895 for ; Fri, 21 May 2004 13:12:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRDZS-0005De-U8 for ipv6@ietf.org; Fri, 21 May 2004 13:12:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRDYa-0005AQ-00 for ipv6@ietf.org; Fri, 21 May 2004 13:11:41 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BRDXn-00053H-00 for ipv6@ietf.org; Fri, 21 May 2004 13:10:51 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 May 2004 10:10:49 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4LHAH30021802; Fri, 21 May 2004 13:10:17 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-118.cisco.com [10.86.242.118]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIR38717; Fri, 21 May 2004 13:10:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20040521130950.02c1d5d0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 May 2004 13:10:14 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [rfc2462bis] relationship between M/O flags and related protocols Cc: Erik Nordmark , Christian Huitema , ipv6@ietf.org In-Reply-To: References: <"Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 This text is fine with me, too. - Ralph At 09:43 AM 5/21/2004 -0700, Erik Nordmark wrote: > > Or, if you feel happier by mentioning changes of the M bit explicitly, > > we could alternatively say > > > > The details of how a host uses the M flag, including any use of > > the "on" and "off" transitions for this flag, to control the use > > of DHCPv6 for address assignment will be described in a separate > > document. > > (based on a previous text from Ralph) > > > > This way, we can avoid the use of the "possibly extraneous state > > variable" which is internal information in the implementation, while > > keeping the essential idea about external behavior. > >The text above is fine with me. > > Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 21 23:38:41 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23212 for ; Fri, 21 May 2004 23:38:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRNJ3-0002t0-8O for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 23:36:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M3aH8L011094 for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 23:36:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRNFg-00027r-SB for ipv6-web-archive@optimus.ietf.org; Fri, 21 May 2004 23:32:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22873 for ; Fri, 21 May 2004 23:32:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRNFd-0004JH-FY for ipv6-web-archive@ietf.org; Fri, 21 May 2004 23:32:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRNEJ-0004C2-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 23:31:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRNDT-00045f-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 23:30:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRN2M-0007ne-AX; Fri, 21 May 2004 23:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRMre-0005iP-5Q for ipv6@optimus.ietf.org; Fri, 21 May 2004 23:07:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22063 for ; Fri, 21 May 2004 23:07:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRMrY-0001pE-Ns for ipv6@ietf.org; Fri, 21 May 2004 23:07:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRMqY-0001jB-00 for ipv6@ietf.org; Fri, 21 May 2004 23:06:50 -0400 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1BRMpZ-0001ap-00 for ipv6@ietf.org; Fri, 21 May 2004 23:05:49 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 7213920; Fri, 21 May 2004 23:05:49 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 23:05:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols Date: Fri, 21 May 2004 23:05:44 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C12F@tayexc13.americas.cpqcorp.net> Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols Thread-Index: AcQ/WKKvDaApsPJwSSOdcMCpmAmU1wAUPlWA From: "Bound, Jim" To: "Ralph Droms" , =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= Cc: "Erik Nordmark" , "Christian Huitema" , X-OriginalArrivalTime: 22 May 2004 03:05:49.0163 (UTC) FILETIME=[AF05C3B0:01C43FA9] Content-Transfer-Encoding: base64 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TWUgdG9vIGFuZCBDaHJpc3RpYW4gSCdzIHVzZSBvZiAibWF5IiB1cGRhdGUuDQovamltIA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGlwdjYtYWRtaW5AaWV0Zi5vcmcg W21haWx0bzppcHY2LWFkbWluQGlldGYub3JnXSBPbiANCj4gQmVoYWxmIE9mIFJhbHBoIERyb21z DQo+IFNlbnQ6IEZyaWRheSwgTWF5IDIxLCAyMDA0IDE6MTAgUE0NCj4gVG86IEpJTk1FSSBUYXR1 eWEgLyDnpZ7mmI7pgZTlk4kNCj4gQ2M6IEVyaWsgTm9yZG1hcms7IENocmlzdGlhbiBIdWl0ZW1h OyBpcHY2QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbcmZjMjQ2MmJpc10gcmVsYXRpb25zaGlw IGJldHdlZW4gTS9PIGZsYWdzIGFuZCANCj4gcmVsYXRlZCBwcm90b2NvbHMNCj4gDQo+IFRoaXMg dGV4dCBpcyBmaW5lIHdpdGggbWUsIHRvby4NCj4gDQo+IC0gUmFscGgNCj4gDQo+IEF0IDA5OjQz IEFNIDUvMjEvMjAwNCAtMDcwMCwgRXJpayBOb3JkbWFyayB3cm90ZToNCj4gPiA+IE9yLCBpZiB5 b3UgZmVlbCBoYXBwaWVyIGJ5IG1lbnRpb25pbmcgY2hhbmdlcyBvZiB0aGUgTSBiaXQgDQo+ID4g PiBleHBsaWNpdGx5LCB3ZSBjb3VsZCBhbHRlcm5hdGl2ZWx5IHNheQ0KPiA+ID4NCj4gPiA+ICAg ICAgVGhlIGRldGFpbHMgb2YgaG93IGEgaG9zdCB1c2VzIHRoZSBNIGZsYWcsIGluY2x1ZGluZyAN Cj4gYW55IHVzZSBvZg0KPiA+ID4gICAgICB0aGUgIm9uIiBhbmQgIm9mZiIgdHJhbnNpdGlvbnMg Zm9yIHRoaXMgZmxhZywgdG8gDQo+IGNvbnRyb2wgdGhlIHVzZQ0KPiA+ID4gICAgICBvZiBESENQ djYgZm9yIGFkZHJlc3MgYXNzaWdubWVudCB3aWxsIGJlIGRlc2NyaWJlZCANCj4gaW4gYSBzZXBh cmF0ZQ0KPiA+ID4gICAgICBkb2N1bWVudC4NCj4gPiA+IChiYXNlZCBvbiBhIHByZXZpb3VzIHRl eHQgZnJvbSBSYWxwaCkNCj4gPiA+DQo+ID4gPiBUaGlzIHdheSwgd2UgY2FuIGF2b2lkIHRoZSB1 c2Ugb2YgdGhlICJwb3NzaWJseSBleHRyYW5lb3VzIHN0YXRlIA0KPiA+ID4gdmFyaWFibGUiIHdo aWNoIGlzIGludGVybmFsIGluZm9ybWF0aW9uIGluIHRoZSANCj4gaW1wbGVtZW50YXRpb24sIHdo aWxlIA0KPiA+ID4ga2VlcGluZyB0aGUgZXNzZW50aWFsIGlkZWEgYWJvdXQgZXh0ZXJuYWwgYmVo YXZpb3IuDQo+ID4NCj4gPlRoZSB0ZXh0IGFib3ZlIGlzIGZpbmUgd2l0aCBtZS4NCj4gPg0KPiA+ ICAgRXJpaw0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3Rz OiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IA0KPiANCg== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri May 21 23:38:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23230 for ; Fri, 21 May 2004 23:38:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRNJ4-0002tc-HF for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 23:36:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M3aI5N011127 for ipv6-archive@odin.ietf.org; Fri, 21 May 2004 23:36:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRNGq-0002Kx-Bc for ipv6-web-archive@optimus.ietf.org; Fri, 21 May 2004 23:34:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22927 for ; Fri, 21 May 2004 23:33:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRNGm-0004VS-Lq for ipv6-web-archive@ietf.org; Fri, 21 May 2004 23:33:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRNFO-0004Ij-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 23:32:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRNEB-0004Bd-00 for ipv6-web-archive@ietf.org; Fri, 21 May 2004 23:31:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRN3M-0007s9-IX; Fri, 21 May 2004 23:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRMtg-0006E2-Dv for ipv6@optimus.ietf.org; Fri, 21 May 2004 23:10:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22179 for ; Fri, 21 May 2004 23:09:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRMtb-00023T-5I for ipv6@ietf.org; Fri, 21 May 2004 23:09:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRMsk-0001xO-00 for ipv6@ietf.org; Fri, 21 May 2004 23:09:07 -0400 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1BRMs8-0001qy-00 for ipv6@ietf.org; Fri, 21 May 2004 23:08:28 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 33B16A541; Fri, 21 May 2004 23:08:29 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 23:08:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [rfc2462bis] reword "stateful" for other config info? Date: Fri, 21 May 2004 23:08:24 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C131@tayexc13.americas.cpqcorp.net> Thread-Topic: [rfc2462bis] reword "stateful" for other config info? Thread-Index: AcQ/FY/imjHiJhn0QAicenHAZkOklwAlG4pg From: "Bound, Jim" To: =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= , X-OriginalArrivalTime: 22 May 2004 03:08:28.0953 (UTC) FILETIME=[0E43C890:01C43FAA] Content-Transfer-Encoding: base64 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SmlubWVpLA0KDQpZb3VyIHdvcmRpbmcgd29ya3MgZm9yIG1lIHdlbGwuICBHb29kIHN1Z2dlc3Rp b24gdG9vLg0KDQovamltIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IGlwdjYtYWRtaW5AaWV0Zi5vcmcgW21haWx0bzppcHY2LWFkbWluQGlldGYub3JnXSBPbiANCj4g QmVoYWxmIE9mIEpJTk1FSSBUYXR1eWEgLyA/Pz8/DQo+IFNlbnQ6IEZyaWRheSwgTWF5IDIxLCAy MDA0IDQ6MTIgQU0NCj4gVG86IGlwdjZAaWV0Zi5vcmcNCj4gU3ViamVjdDogW3JmYzI0NjJiaXNd IHJld29yZCAic3RhdGVmdWwiIGZvciBvdGhlciBjb25maWcgaW5mbz8NCj4gDQo+IE9uZSAocGVy aGFwcyBsYXN0KSBxdWVzdGlvbiBhYm91dCB0aGUgTS9PIGZsYWdzIGZvciByZmMyNDYyYmlzOg0K PiANCj4gQ3VycmVudGx5LCBSRkMyNDYyIHVzZXMgdGhlIHRlcm0gInN0YXRlZnVsIiBhcyB0aGUg Y291bnRlciANCj4gcGFydCBvZiB0aGUgInN0YXRlbGVzcyIgY29uZmlndXJhdGlvbiBkZWZpbmVk IGluIFJGQzI0NjIsIA0KPiBib3RoIGZvciBhZGRyZXNzIGNvbmZpZ3VyYXRpb24gKHRoZSBNIGZs YWcpIGFuZCBmb3Igb3RoZXIgDQo+IGNvbmZpZ3VyYXRpb24gKHRoZSBPIGZsYWcpLg0KPiANCj4g VXNpbmcgInN0YXRlZnVsIiBzaG91bGQgYmUgb2theSBmb3IgYWRkcmVzcyBjb25maWd1cmF0aW9u IA0KPiAodGhlIE0gZmxhZyBwYXJ0KS4NCj4gDQo+IEhvd2V2ZXIsIGFzIFJhbHBoIHBvaW50ZWQg b3V0IGJlZm9yZSwgInN0YXRlZnVsIiBtYXkgbm90IGJlIA0KPiBhcHByb3ByaWF0ZSBmb3Igb3Ro ZXIgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbjoNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWwtYXJjaGl2ZS93b3JraW5nLWdyb3Vwcy9pcHY2L2N1cnJlbnQNCj4gL21zZzAyMjYyLmh0bWwN Cj4gDQo+IEluIHBhcnRpY3VsYXIsIHRoZSBmYWN0IHRoYXQgUkZDMzczNiAod2hpY2ggd2UgYXJl IHByaW1hcmlseSANCj4gY29uc2lkZXJpbmcgYXMgdGhlIHByb3RvY29sIGZvciB0aGUgTyBmbGFn KSBpcyBlbnRpdGxlZCANCj4gIipTdGF0ZWxlc3MqIER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9u IFByb3RvY29sIChESENQKSANCj4gU2VydmljZSBmb3IgSVB2NiIgd2lsbCBjb25mdXNlIGltcGxl bWVudG9ycyBpZiB3ZSBrZWVwIA0KPiBjYWxsaW5nIGl0ICJzdGF0ZWZ1bCIgaW4gcmZjMjQ2MmJp cy4NCj4gDQo+IFNvLCBJIHN0cm9uZ2x5IGJlbGlldmUgd2Ugc2hvdWxkIGNsYXJpZnkgdGhpcyBw b2ludCBpbiBzb21lIHdheS4NCj4gUG9zc2libGUgc29sdXRpb25zIHdvdWxkIGluY2x1ZGU6DQo+ IA0KPiAxLiByZW1vdmUgInN0YXRlZnVsIiBmcm9tIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBPIGZs YWcgKGluDQo+ICAgIHJmYzI0NjFiaXMpLCB0aGF0IGlzLCBjaGFuZ2UNCj4gDQo+ICAgICAgIE8g ICAgICAgICAgICAgIDEtYml0ICJPdGhlciBzdGF0ZWZ1bCBjb25maWd1cmF0aW9uIiBmbGFnLiAg V2hlbg0KPiAgICAgICAgICAgICAgICAgICAgICBzZXQsIGhvc3RzIHVzZSB0aGUgYWRtaW5pc3Rl cmVkIA0KPiAoc3RhdGVmdWwpIHByb3RvY29sDQo+ICAgICAgICAgICAgICAgICAgICAgIGZvciBh dXRvY29uZmlndXJhdGlvbiBvZiBvdGhlciAobm9uLWFkZHJlc3MpDQo+ICAgICAgICAgICAgICAg ICAgICAgIGluZm9ybWF0aW9uLiAgVGhlIHVzZSBvZiB0aGlzIGZsYWcgaXMgDQo+IGRlc2NyaWJl ZCBpbg0KPiAgICAgICAgICAgICAgICAgICAgICBbQUREUkNPTkZdLg0KPiAgICAgICAoUkZDMjQ2 MSBTZWN0aW9uIDQuMikNCj4gDQo+ICAgIHRvIChlLmcuKToNCj4gDQo+ICAgICAgIE8gICAgICAg ICAgICAgIDEtYml0ICJPdGhlciBjb25maWd1cmF0aW9uIiBmbGFnLiAgV2hlbg0KPiAgICAgICAg ICAgICAgICAgICAgICBzZXQsIGhvc3RzIHVzZSBhIHNlcGFyYXRlIHByb3RvY29sDQo+ICAgICAg ICAgICAgICAgICAgICAgIGZvciBhdXRvY29uZmlndXJhdGlvbiBvZiBvdGhlciAobm9uLWFkZHJl c3MpDQo+ICAgICAgICAgICAgICAgICAgICAgIGluZm9ybWF0aW9uLiAgVGhlIHVzZSBvZiB0aGlz IGZsYWcgaXMgDQo+IGRlc2NyaWJlZCBpbg0KPiAgICAgICAgICAgICAgICAgICAgICBbQUREUkNP TkZdLg0KPiANCj4gICAgYW5kIHJld29yZCByZmMyNDYyYmlzIGFjY29yZGluZ2x5Lg0KPiANCj4g Mi4gZG8gbm90IHRvdWNoIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBPIGZsYWcsIGJ1dCBhZGQgbm90 ZXMgZm9yDQo+ICAgIGNsYXJpZmljYXRpb24gaW4gcmZjMjQ2MmJpcyBsaWtlIHRoaXM6DQo+IA0K PiAgICAgICBXaGlsZSB0aGUgZmxhZyBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgcHJvdG9jb2wgYXJl IGNhbGxlZA0KPiAgICAgICAic3RhdGVmdWwiIGluIG9yZGVyIHRvIGhpZ2hsaWdodCB0aGUgY29u dHJhc3QgdG8gdGhlIHN0YXRlbGVzcw0KPiAgICAgICBwcm90b2NvbCBkZWZpbmVkIGluIHRoaXMg ZG9jdW1lbnQsIHRoZSBpbnRlbmRlZCBwcm90b2NvbA0KPiAgICAgICBbUkZDMzczNl0gaXMgYWxz byBkZWZpbmVkIHRvIHdvcmsgaW4gYSBzdGF0ZWxlc3MgZmFzaGlvbi4gIFRoaXMNCj4gICAgICAg aXMgYmFzZWQgb24gYSByZXN1bHQsIHRocm91Z2ggZXhwZXJpbWVudHMsIHRoYXQgYWxsIGtub3du DQo+ICAgICAgICJvdGhlciIgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBjYW4gYmUgbWFuYWdl ZCBieSBhIHN0YXRlbGVzcw0KPiAgICAgICBzZXJ2ZXIsIHRoYXQgaXMsIGEgc2VydmVyIHRoYXQg ZG9lcyBub3QgbWFpbnRhaW4gc3RhdGUgb2YgZWFjaA0KPiAgICAgICBjbGllbnQgdGhhdCB0aGUg c2VydmVyIHByb3ZpZGVzIHdpdGggdGhlIGNvbmZpZ3VyYXRpb24NCj4gICAgICAgaW5mb3JtYXRp b24uDQo+IA0KPiBJIHBlcnNvbmFsbHkgcHJlZmVyIHRoZSBmb3JtZXIgd2l0aCBzbWFsbCBwcmVm ZXJlbmNlIHNpbmNlIGl0IA0KPiBzaG91bGQgYmUgYSBjbGVhbmVyIGNsYXJpZmljYXRpb24uICBC dXQgSSBjYW4gbGl2ZSB3aXRoIHRoZSANCj4gc2Vjb25kIGFwcHJvYWNoLCB0b28uDQo+IA0KPiBX aGF0IGRvIG90aGVycyB0aGluaz8gIElzIHRoZXJlIGFueSBvdGhlciBvcGluaW9ucz8NCj4gDQo+ IAkJCQkJSklOTUVJLCBUYXR1eWENCj4gCQkJCQlDb21tdW5pY2F0aW9uIFBsYXRmb3JtIExhYi4N Cj4gCQkJCQlDb3Jwb3JhdGUgUiZEIENlbnRlciwgDQo+IFRvc2hpYmEgQ29ycC4NCj4gCQkJCQlq aW5tZWlAaXNsLnJkYy50b3NoaWJhLmNvLmpwDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQ djYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlz dHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat May 22 00:21:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25480 for ; Sat, 22 May 2004 00:21:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRNv0-0001wW-9T for ipv6-archive@odin.ietf.org; Sat, 22 May 2004 00:15:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M4FU2k007466 for ipv6-archive@odin.ietf.org; Sat, 22 May 2004 00:15:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRNp0-0000Ve-VM for ipv6-web-archive@optimus.ietf.org; Sat, 22 May 2004 00:09:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24994 for ; Sat, 22 May 2004 00:09:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRNoy-0000s6-DA for ipv6-web-archive@ietf.org; Sat, 22 May 2004 00:09:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRNoW-0000l5-00 for ipv6-web-archive@ietf.org; Sat, 22 May 2004 00:08:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRNnW-0000c2-00 for ipv6-web-archive@ietf.org; Sat, 22 May 2004 00:07:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRNf8-00073d-9P; Fri, 21 May 2004 23:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRNS4-0004zP-LT for ipv6@optimus.ietf.org; Fri, 21 May 2004 23:45:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23941 for ; Fri, 21 May 2004 23:45:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRNS1-0005mN-RY for ipv6@ietf.org; Fri, 21 May 2004 23:45:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRNQp-0005dM-00 for ipv6@ietf.org; Fri, 21 May 2004 23:44:20 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1BRNPT-0005TE-00 for ipv6@ietf.org; Fri, 21 May 2004 23:42:55 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 0F588DA; Fri, 21 May 2004 23:42:57 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 23:42:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols Date: Fri, 21 May 2004 23:42:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C136@tayexc13.americas.cpqcorp.net> Thread-Topic: [rfc2462bis] relationship between M/O flags and related protocols Thread-Index: AcQ+mIMPSEmBPaHOTjmzTB7ST0szCwBFk0+Q From: "Bound, Jim" To: "Erik Nordmark" Cc: "Christian Huitema" , "Ralph Droms" , =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= , X-OriginalArrivalTime: 22 May 2004 03:42:56.0733 (UTC) FILETIME=[DEC1F8D0:01C43FAE] Content-Transfer-Encoding: base64 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 T0suICBJIGFncmVlIHRvby4NCnRoYW5rcw0KL2ppbSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBFcmlrIE5vcmRtYXJrIFttYWlsdG86RXJpay5Ob3JkbWFya0BzdW4u Y29tXSANCj4gU2VudDogVGh1cnNkYXksIE1heSAyMCwgMjAwNCAxOjMyIFBNDQo+IFRvOiBCb3Vu ZCwgSmltDQo+IENjOiBFcmlrIE5vcmRtYXJrOyBDaHJpc3RpYW4gSHVpdGVtYTsgUmFscGggRHJv bXM7IEpJTk1FSSANCj4gVGF0dXlhIC8g56We5piO6YGU5ZOJOyBpcHY2QGlldGYub3JnDQo+IFN1 YmplY3Q6IFJFOiBbcmZjMjQ2MmJpc10gcmVsYXRpb25zaGlwIGJldHdlZW4gTS9PIGZsYWdzIGFu ZCANCj4gcmVsYXRlZCBwcm90b2NvbHMNCj4gDQo+ID4gSnVzdCBjaGVja2luZy4gIFdlIGRvIG5l ZWQgdGhlIE0gYml0IGZvciB0aG9zZSB3YW50aW5nIHRvIHVzZSANCj4gPiBzdGF0ZWZ1bD8gIE9y IGRvIHlvdSBub3QgYWdyZWU/DQo+IA0KPiBJIGFncmVlIHdpdGggdGhlIEppbm1laSdzIGRlZmlu aXRpb24gdGhhdCB0aGUgTSBiaXQgaW5kaWNhdGVzIA0KPiB0byB0aGUgaG9zdCB0aGF0IERIQ1B2 NiBmb3IgSVAgYWRkcmVzcyBjb25maWd1cmF0aW9uIGlzIA0KPiBhdmFpbGFibGUgb24gdGhlIGxp bmsuDQo+IA0KPiBXaXRoIHRoYXQgZGVmaW5pdGlvbiBpdCBpcyBwb3NzaWJsZSB0byBidWlsZCBo b3N0cyB0aGF0IA0KPiBpbml0aWFsaXplIGVmZmljaWVudGx5LCBieSBvbmx5IHRyeWluZyB0byB1 c2UgREhDUHY2IHdoZW4gdGhlIA0KPiByb3V0ZXIgYWR2ZXJ0aXNlbWVudHMgc2F5IHRoYXQgaXQg aXMgYXZhaWxhYmxlLg0KPiANCj4gICAgRXJpaw0KPiANCj4gDQo+IA0K -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat May 22 07:34:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00305 for ; Sat, 22 May 2004 07:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUf7-00082L-Fi for ipv6-archive@odin.ietf.org; Sat, 22 May 2004 07:27:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MBRXne030889 for ipv6-archive@odin.ietf.org; Sat, 22 May 2004 07:27:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUXL-0006Z2-3P for ipv6-web-archive@optimus.ietf.org; Sat, 22 May 2004 07:19:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29647 for ; Sat, 22 May 2004 07:19:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRUXK-0006qK-Ki for ipv6-web-archive@ietf.org; Sat, 22 May 2004 07:19:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRUWT-0006dE-00 for ipv6-web-archive@ietf.org; Sat, 22 May 2004 07:18:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRUVQ-0006My-00 for ipv6-web-archive@ietf.org; Sat, 22 May 2004 07:17:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUIV-0003OW-HJ; Sat, 22 May 2004 07:04:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRU7t-0000f5-H2 for ipv6@optimus.ietf.org; Sat, 22 May 2004 06:53:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28062 for ; Sat, 22 May 2004 06:53:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRU7p-00029s-8T for ipv6@ietf.org; Sat, 22 May 2004 06:53:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRU6u-00021k-00 for ipv6@ietf.org; Sat, 22 May 2004 06:52:12 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BRU6B-0001tq-00; Sat, 22 May 2004 06:51:27 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4MApTWE001471; Sat, 22 May 2004 11:51:29 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA16099; Sat, 22 May 2004 11:51:24 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4MApOP05968; Sat, 22 May 2004 11:51:24 +0100 Date: Sat, 22 May 2004 11:51:24 +0100 From: Tim Chown To: dhcwg@ietf.org Cc: ipv6@ietf.org Subject: Re: [dhcwg] Deafult Router information for DHCPv6 Message-ID: <20040522105124.GD5178@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org, ipv6@ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B0644C130@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0644C130@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 This reminds me, I don't think the IPv6 nodes requirements draft has yet gone final, since draft-ietf-ipv6-node-requirements-08 still exists on the IETF I-D area. Should we not update this before it goes final with the wording that has been agreed for the M and O flags, and also to clarify the assertion below, that RAs are the way to get default router and onlink prefix information? It would be a shame to not convey this consensus in the nodes document. In the draft, that's at least section 4.5.2 and 4.5.5 that probably need a tweak. Tim On Fri, May 21, 2004 at 11:07:47PM -0400, Bound, Jim wrote: > Christian, > > I have been down this patha and I cannot see a good case for this to be > in DHCPv6. I concur with Eric and Bernie. The entire conversion of > routes on a link should come from ND RA. Once the edge link routers > have the prefixes it is automatic for the hosts. I can see any good > reason to add state to the IPv6 network architecture for route > propogation? > > thanks > /jim > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > > Behalf Of Cristian Cadar > > Sent: Friday, May 21, 2004 4:50 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Deafult Router information for DHCPv6 > > > > > > Hi, > > > > I know that this issue was already discussed on the list but > > I ran into a problem which I would like to clarify here. > > Seemingly the only way for getting the default router > > information is to make use of the RA. So when I'm using > > dhcpv6 and want get the default router information is it a > > MUST to use the RA for this pourpose? I could not find any > > statement in any of the RFC/drafts saying that. > > I mean for the time being I cannot see any other possibility. > > There might be scenarios where the use of RA is not desired > > and prefering to have a dhcpv6 option carrying this > > information along. If the use of RA is not a MUST I think we > > need a new option. > > > > > > Thanks, > > Cristian > > > > > > > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat May 22 08:30:32 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03888 for ; Sat, 22 May 2004 08:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRVWy-0002hf-Ii for ipv6-archive@odin.ietf.org; Sat, 22 May 2004 08:23:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MCNCm5010389 for ipv6-archive@odin.ietf.org; Sat, 22 May 2004 08:23:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRVKW-0007Ya-Ek for ipv6-web-archive@optimus.ietf.org; Sat, 22 May 2004 08:10:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02767 for ; Sat, 22 May 2004 08:10:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRVKV-0000Dz-BA for ipv6-web-archive@ietf.org; Sat, 22 May 2004 08:10:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRVJZ-00003T-00 for ipv6-web-archive@ietf.org; Sat, 22 May 2004 08:09:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRVIh-0007hg-00 for ipv6-web-archive@ietf.org; Sat, 22 May 2004 08:08:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRV6g-0004R6-PU; Sat, 22 May 2004 07:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUzD-0003J5-A3 for ipv6@optimus.ietf.org; Sat, 22 May 2004 07:48:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01441 for ; Sat, 22 May 2004 07:48:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRUzC-00045n-CC for ipv6@ietf.org; Sat, 22 May 2004 07:48:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRUyJ-0003wW-00 for ipv6@ietf.org; Sat, 22 May 2004 07:47:24 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1BRUxW-0003mW-00 for ipv6@ietf.org; Sat, 22 May 2004 07:46:34 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 301CE92B3; Sat, 22 May 2004 07:46:34 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 22 May 2004 07:46:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Work Group Last Call for "Default Router Preferences and More-Specific Routes" Date: Sat, 22 May 2004 07:46:29 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C13B@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Work Group Last Call for "Default Router Preferences and More-Specific Routes" Thread-Index: AcQyN/HMm0yKOk7WROSnNVkhzHtGPwNuk8rg From: "Bound, Jim" To: "Bob Hinden" , X-OriginalArrivalTime: 22 May 2004 11:46:33.0960 (UTC) FILETIME=[6E5F6E80:01C43FF2] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Bob and Brian, I am fine with this and it is good spec. One question in my mind is do we want to use up precious RSVD bits in the RA message or make this an option? It would also work as option as I see it and save using up the RA RSVD header bits. thanks /jim=20 > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On=20 > Behalf Of Bob Hinden > Sent: Tuesday, May 04, 2004 8:14 PM > To: ipv6@ietf.org > Subject: IPv6 Work Group Last Call for "Default Router=20 > Preferences and More-Specific Routes" >=20 > This is a IPv6 working group last call for comments on=20 > advancing the following document as an Proposed Standard: >=20 > Title : Default Router Preferences and=20 > More-Specific Routes > Author(s) : R. Draves, D. Thaler > Filename : draft-ietf-ipv6-router-selection-03.txt > Pages : 13 > Date : 2003-12-18 >=20 > This is a two week working group last call that will end on=20 > May 18, 2004. >=20 > Please direct substantive comments to the IPv6 mailing list. =20 > Editorial comments can be sent directly to the authors. >=20 > Regards, > Bob & Brian > IPv6 WG co-chairs >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat May 22 10:39:50 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10293 for ; Sat, 22 May 2004 10:39:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRXcP-0002Yb-GT for ipv6-archive@odin.ietf.org; Sat, 22 May 2004 10:36:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MEavWW009825 for ipv6-archive@odin.ietf.org; Sat, 22 May 2004 10:36:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRXX7-0001DT-Vv for ipv6-web-archive@optimus.ietf.org; Sat, 22 May 2004 10:31:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09924 for ; Sat, 22 May 2004 10:31:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRXX5-0000lX-Jn for ipv6-web-archive@ietf.org; Sat, 22 May 2004 10:31:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRXW5-0000bO-00 for ipv6-web-archive@ietf.org; Sat, 22 May 2004 10:30:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRXVh-0000Rv-00 for ipv6-web-archive@ietf.org; Sat, 22 May 2004 10:30:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRXNx-0007xz-HB; Sat, 22 May 2004 10:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRXIW-00078W-6x for ipv6@optimus.ietf.org; Sat, 22 May 2004 10:16:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08787 for ; Sat, 22 May 2004 10:16:20 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRXIT-0005ob-V0 for ipv6@ietf.org; Sat, 22 May 2004 10:16:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRXHa-0005eI-00 for ipv6@ietf.org; Sat, 22 May 2004 10:15:27 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BRXGq-0005UZ-00 for ipv6@ietf.org; Sat, 22 May 2004 10:14:45 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4MEESE18094 for ; Sat, 22 May 2004 17:14:28 +0300 (EET DST) X-Scanned: Sat, 22 May 2004 17:14:24 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4MEEOQK001135 for ; Sat, 22 May 2004 17:14:24 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00w2faAF; Sat, 22 May 2004 17:14:23 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4MEENH25573 for ; Sat, 22 May 2004 17:14:23 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 22 May 2004 17:14:22 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Updated Node Requirements Date: Sat, 22 May 2004 17:14:23 +0300 Message-ID: Thread-Topic: [dhcwg] Deafult Router information for DHCPv6 Thread-Index: AcQ/7kKBrOoSYkvMSzKfDltmJRc9fgAGIEkQ To: X-OriginalArrivalTime: 22 May 2004 14:14:23.0167 (UTC) FILETIME=[14D504F0:01C44007] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I have just sent the draft in. The updates cover the IESG DISCUSSes. Issue tracker has been updated: http://danforsberg.info:8080/draft-ietf-ipv6-node-requirements/issue?:col= umns=3Dtitle,category,id,creation,creator,priority,status,assignedto&:sor= t=3Dpriority&:group=3Ddocument&:pagesize=3D50&:startwith=3D0 Look under both draft-ietf-ipv6-node-requirements-07.txt and = draft-ietf-ipv6-node-requirements-08.txt, as the -07 addressed Bert's & = Steve's comments, while -08 addresses the rest. The draft should be out early next week, in the meantime, it can be = found here: http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-09.txt thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat May 22 10:53:35 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10974 for ; Sat, 22 May 2004 10:53:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRXqi-0005yj-E3 for ipv6-archive@odin.ietf.org; Sat, 22 May 2004 10:51:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MEpiN7022976 for ipv6-archive@odin.ietf.org; Sat, 22 May 2004 10:51:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRXmh-0004VQ-LE for ipv6-web-archive@optimus.ietf.org; Sat, 22 May 2004 10:47:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10608 for ; Sat, 22 May 2004 10:47:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRXme-0003bo-Qw for ipv6-web-archive@ietf.org; Sat, 22 May 2004 10:47:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRXlf-0003R4-00 for ipv6-web-archive@ietf.org; Sat, 22 May 2004 10:46:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRXl6-0003GW-00 for ipv6-web-archive@ietf.org; Sat, 22 May 2004 10:45:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRXcV-0002b0-2G; Sat, 22 May 2004 10:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRXQZ-00008f-4j for ipv6@optimus.ietf.org; Sat, 22 May 2004 10:24:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09458 for ; Sat, 22 May 2004 10:24:39 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRXQW-0007GK-Qj for ipv6@ietf.org; Sat, 22 May 2004 10:24:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRXPW-00072a-00 for ipv6@ietf.org; Sat, 22 May 2004 10:23:39 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BRXOv-0006rB-00; Sat, 22 May 2004 10:23:02 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4MEMmv03300; Sat, 22 May 2004 17:22:48 +0300 (EET DST) X-Scanned: Sat, 22 May 2004 17:22:35 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4MEMZUF018466; Sat, 22 May 2004 17:22:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00mZGREa; Sat, 22 May 2004 17:22:34 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4MEMXH16645; Sat, 22 May 2004 17:22:33 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 22 May 2004 17:22:32 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Default Router information for DHCPv6 Date: Sat, 22 May 2004 17:22:32 +0300 Message-ID: Thread-Topic: [dhcwg] Deafult Router information for DHCPv6 Thread-Index: AcQ/7kKBrOoSYkvMSzKfDltmJRc9fgAGfDiA To: , Cc: X-OriginalArrivalTime: 22 May 2004 14:22:32.0896 (UTC) FILETIME=[38BBBC00:01C44008] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Tim, > This reminds me, I don't think the IPv6 nodes requirements draft has = yet > gone final, since draft-ietf-ipv6-node-requirements-08 still exists on = the > IETF I-D area. Just updated it to clear current DISCUSSes. =20 > Should we not update this before it goes final with the wording that = has > been agreed for the M and O flags, and also to clarify the assertion = below, > that RAs are the way to get default router and onlink prefix = information? >=20 > It would be a shame to not convey this consensus in the nodes = document. > In the draft, that's at least section 4.5.2 and 4.5.5 that probably = need a=20 > tweak. Take a look at the current draft, a copy can be found here:=20 http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-09.txt and let me know what you think should be modified. Please note that the idea was that this document should not update any existing RFCs, so we cannot prescribe new behavior. thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun May 23 00:27:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14437 for ; Sun, 23 May 2004 00:27:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRkUy-00063A-UA for ipv6-archive@odin.ietf.org; Sun, 23 May 2004 00:22:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4N4M8w9023256 for ipv6-archive@odin.ietf.org; Sun, 23 May 2004 00:22:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRkQ9-0005Gq-1R for ipv6-web-archive@optimus.ietf.org; Sun, 23 May 2004 00:17:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14260 for ; Sun, 23 May 2004 00:17:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRkQ6-0005o1-Jk for ipv6-web-archive@ietf.org; Sun, 23 May 2004 00:17:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRkPL-0005aP-00 for ipv6-web-archive@ietf.org; Sun, 23 May 2004 00:16:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRkOa-0005La-00 for ipv6-web-archive@ietf.org; Sun, 23 May 2004 00:15:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRkHK-0003Q6-8a; Sun, 23 May 2004 00:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRkD8-0002P2-LV for ipv6@optimus.ietf.org; Sun, 23 May 2004 00:03:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13812 for ; Sun, 23 May 2004 00:03:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRkD6-0002wF-BD for ipv6@ietf.org; Sun, 23 May 2004 00:03:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRkAw-0002bb-00 for ipv6@ietf.org; Sun, 23 May 2004 00:01:27 -0400 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1BRkAH-0002Ic-00 for ipv6@ietf.org; Sun, 23 May 2004 00:00:45 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 1319132D for ; Sun, 23 May 2004 00:00:16 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 23 May 2004 00:00:16 -0400 Message-Id: <20040523040016.1319132D@cyteen.hactrn.net> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.7 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.95% | 18 | 23.17% | 96314 | jinmei@isl.rdc.toshiba.co.jp 10.98% | 9 | 12.53% | 52087 | rdroms@cisco.com 8.54% | 7 | 7.47% | 31069 | erik.nordmark@sun.com 8.54% | 7 | 7.34% | 30513 | tjc@ecs.soton.ac.uk 6.10% | 5 | 7.18% | 29834 | jim.bound@hp.com 6.10% | 5 | 5.61% | 23333 | huitema@windows.microsoft.com 6.10% | 5 | 5.10% | 21206 | ipng@uni-muenster.de 4.88% | 4 | 3.13% | 13018 | rt+ipv6-2462bis@rt.psg.com 3.66% | 3 | 3.74% | 15546 | hiroyuki.ootomo@jp.yokogawa.com 3.66% | 3 | 3.55% | 14752 | john.loughney@nokia.com 2.44% | 2 | 3.45% | 14351 | brc@zurich.ibm.com 2.44% | 2 | 2.56% | 10647 | suresh.krishnan@ericsson.ca 2.44% | 2 | 2.46% | 10233 | kempf@docomolabs-usa.com 1.22% | 1 | 2.54% | 10577 | girishnk75@yahoo.co.in 1.22% | 1 | 1.63% | 6778 | mukesh.gupta@nokia.com 1.22% | 1 | 1.33% | 5527 | jeroen@unfix.org 1.22% | 1 | 1.16% | 4826 | msa@burp.tkv.asdf.org 1.22% | 1 | 1.16% | 4823 | ftemplin@iprg.nokia.com 1.22% | 1 | 1.04% | 4310 | sra+ipng@hactrn.net 1.22% | 1 | 1.01% | 4217 | sebastien.roy@sun.com 1.22% | 1 | 1.01% | 4184 | lear@cisco.com 1.22% | 1 | 0.97% | 4017 | alain.durand@sun.com 1.22% | 1 | 0.86% | 3579 | bob.hinden@nokia.com --------+------+--------+----------+------------------------ 100.00% | 82 |100.00% | 415741 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun May 23 01:40:24 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16444 for ; Sun, 23 May 2004 01:40:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRlYe-00023x-6t for ipv6-archive@odin.ietf.org; Sun, 23 May 2004 01:30:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4N5U0x5007922 for ipv6-archive@odin.ietf.org; Sun, 23 May 2004 01:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRlWl-0001hI-Hp for ipv6-web-archive@optimus.ietf.org; Sun, 23 May 2004 01:28:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16160 for ; Sun, 23 May 2004 01:28:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRlWi-0006GE-E2 for ipv6-web-archive@ietf.org; Sun, 23 May 2004 01:28:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRlVp-00062q-00 for ipv6-web-archive@ietf.org; Sun, 23 May 2004 01:27:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRlVI-0005pa-00 for ipv6-web-archive@ietf.org; Sun, 23 May 2004 01:26:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRlP0-0008UQ-Ry; Sun, 23 May 2004 01:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRlN3-00085F-7Q for ipv6@optimus.ietf.org; Sun, 23 May 2004 01:18:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15901 for ; Sun, 23 May 2004 01:17:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRlN0-0003xS-6C for ipv6@ietf.org; Sun, 23 May 2004 01:17:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRlM1-0003jd-00 for ipv6@ietf.org; Sun, 23 May 2004 01:16:58 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BRlL5-0003NK-00 for ipv6@ietf.org; Sun, 23 May 2004 01:15:59 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:587e:bff9:bea7:bcdb]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8E6771525D; Sun, 23 May 2004 14:15:53 +0900 (JST) Date: Sun, 23 May 2004 14:15:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bound, Jim" Cc: Subject: Re: [rfc2462bis] reword "stateful" for other config info? In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0644C131@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B0644C131@tayexc13.americas.cpqcorp.net> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Fri, 21 May 2004 23:08:24 -0400, >>>>> "Bound, Jim" said: > Your wording works for me well. Good suggestion too. Thanks, glad to hear that. But please let me check one thing: do you have any preference between the solutions? That is, >> 1. remove "stateful" from the definition of the O flag (in >> rfc2461bis), [...] >> and reword rfc2462bis accordingly. or >> 2. do not touch the definition of the O flag, but add notes for >> clarification in rfc2462bis like this: [snip] I guess you meant solution 2 by "wording", but I'm not really sure. Thanks, 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 -------------------------------------------------------------------- From exim@www1.ietf.org Sun May 23 05:10:09 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07129 for ; Sun, 23 May 2004 05:10:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRoyA-0005UE-JE for ipv6-archive@odin.ietf.org; Sun, 23 May 2004 05:08:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4N98YQC021088 for ipv6-archive@odin.ietf.org; Sun, 23 May 2004 05:08:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRorI-0003sP-P3 for ipv6-web-archive@optimus.ietf.org; Sun, 23 May 2004 05:01:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06785 for ; Sun, 23 May 2004 05:01:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRorF-00034G-I8 for ipv6-web-archive@ietf.org; Sun, 23 May 2004 05:01:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRoqH-0002oR-00 for ipv6-web-archive@ietf.org; Sun, 23 May 2004 05:00:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRopU-0002Xu-00 for ipv6-web-archive@ietf.org; Sun, 23 May 2004 04:59:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRok7-0002P3-Q0; Sun, 23 May 2004 04:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRoiI-0002DZ-15 for ipv6@optimus.ietf.org; Sun, 23 May 2004 04:52:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06539 for ; Sun, 23 May 2004 04:52:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRoiE-0000nH-U0 for ipv6@ietf.org; Sun, 23 May 2004 04:52:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRohG-0000WS-00 for ipv6@ietf.org; Sun, 23 May 2004 04:51:06 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1BRogB-000029-00 for ipv6@ietf.org; Sun, 23 May 2004 04:49:59 -0400 Received: from vies1kbx.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i4N8nUEP029890 for ; Sun, 23 May 2004 10:49:30 +0200 Received: from vies141a.sie.siemens.at (vies1kbx [158.226.135.174]) by vies1kbx.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i4N8nTgP011059 for ; Sun, 23 May 2004 10:49:29 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Sun, 23 May 2004 10:49:46 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AB97@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IPV6 IETF (E-mail)" Subject: draft-daniel-dhc-ipv6in4-opt-03.txt Date: Sun, 23 May 2004 10:45:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.6 required=5.0 tests=AWL,DEAR_SOMETHING autolearn=no version=2.60 Dear Sirs, I highly appreciated finding your draft concerning "DHCP Option for Configuring IPv6-over-IPv4 Tunnels" at IETF. To my mind this is one of the simplest form of a first transition for mobile (GPRS) operators to supply IPv6 to their customers. After finding the tunnel endpoint via your DHCP option a dual stack mobile phone can do autoconfiguration (or DHCPv6) accros the tunnel and obtain a globally unique IPv6 address, allthough its IPv4 address is only private. (no DAD is needed as link-local address is constructed from IPv4 address, which is unique within operators area). I hope that your suggestion evolves to an RFC soon. Best regards Peter Grubmair -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun May 23 19:01:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12703 for ; Sun, 23 May 2004 19:01:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS1vh-0003Jm-Uh for ipv6-archive@odin.ietf.org; Sun, 23 May 2004 18:58:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4NMwrrq012754 for ipv6-archive@odin.ietf.org; Sun, 23 May 2004 18:58:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS1rl-0002iL-A2 for ipv6-web-archive@optimus.ietf.org; Sun, 23 May 2004 18:54:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12466 for ; Sun, 23 May 2004 18:54:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS1ri-0003oR-0p for ipv6-web-archive@ietf.org; Sun, 23 May 2004 18:54:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS1qr-0003Y9-00 for ipv6-web-archive@ietf.org; Sun, 23 May 2004 18:53:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS1q1-0003It-00 for ipv6-web-archive@ietf.org; Sun, 23 May 2004 18:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS1kD-0001Yf-Gn; Sun, 23 May 2004 18:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS1j0-0001Q9-Ty for ipv6@optimus.ietf.org; Sun, 23 May 2004 18:45:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12138 for ; Sun, 23 May 2004 18:45:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS1ix-0001Tk-P6 for ipv6@ietf.org; Sun, 23 May 2004 18:45:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS1hy-0001Dw-00 for ipv6@ietf.org; Sun, 23 May 2004 18:44:42 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BS1gv-0000kb-00; Sun, 23 May 2004 18:43:38 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4NMhWWE010738; Sun, 23 May 2004 23:43:33 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA00748; Sun, 23 May 2004 23:43:28 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4NMhSJ10175; Sun, 23 May 2004 23:43:28 +0100 Date: Sun, 23 May 2004 23:43:28 +0100 From: Tim Chown To: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: [dhcwg] Default Router information for DHCPv6 Message-ID: <20040523224328.GB9749@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org, ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 On Sat, May 22, 2004 at 05:22:32PM +0300, john.loughney@nokia.com wrote: > > > Should we not update this before it goes final with the wording that has > > been agreed for the M and O flags, and also to clarify the assertion below, > > that RAs are the way to get default router and onlink prefix information? > > > > It would be a shame to not convey this consensus in the nodes document. > > In the draft, that's at least section 4.5.2 and 4.5.5 that probably need a > > tweak. > > Take a look at the current draft, a copy can be found here: > http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-09.txt > > and let me know what you think should be modified. Please note that > the idea was that this document should not update any existing RFCs, > so we cannot prescribe new behavior. Ah, good point. However, the 2462 update is due to be submitted very soon, so is it worth waiting on that one to get the more appropriate text in this nodes document? Regarding changes, there would be three I'd suggest. The first two point into 2462-bis, so we just need to (as Christian would say) use the "less is more" maxim, so do something like this: 1. In 5.3.1 change "IPv6 Nodes that use DHCP for address assignment initiate DHCP to obtain IPv6 addresses and other configuration information upon receipt of a Router Advertisement with the 'M' flag set, as described in section 5.5.3 of RFC 2462." to "The method by which IPv6 Nodes that use DHCP for address assignment can obtain IPv6 addresses and other configuration information upon receipt of a Router Advertisement with the 'M' flag set is described in section 5.5.3 of RFC 2462." (leaves the suggestion of M being "mandatory" without using the "MAY" term) 2. In 5.3.2 change "Those IPv6 Nodes that use DHCP to obtain other configuration information initiate DHCP for other configuration information upon receipt of a Router Advertisement with the 'O' flag set, as described in section 5.5.3 of RFC 2462." to "The method by which IPv6 Nodes that use DHCP to obtain other configuration information can obtain other configuration information upon receipt of a Router Advertisement with the 'O' flag set is described in section 5.5.3 of RFC 2462." (ideally that "can" would be a "may", but that suggests something that is not finalised yet, so would be a change of meaning, which you don't want) 3. Add a section 5.5.3: "5.3.3 Use of Router Advertisements in Managed Environments Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) are expected to determine their default router information and on-link prefix information from received Router Advertisements." (Perhaps some people may think this is saying too much, or the section heading could be improved, but if the opinion on the list is consensus, we should add it? You may wish to add reference to Stateless DHCPv6 in that extra section too?) Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 24 02:46:00 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15270 for ; Mon, 24 May 2004 02:45:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9Bh-0004OR-5P for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 02:43:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O6hrgj016879 for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 02:43:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS97D-0003jo-Hr for ipv6-web-archive@optimus.ietf.org; Mon, 24 May 2004 02:39:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15020 for ; Mon, 24 May 2004 02:39:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS979-0005LN-HF for ipv6-web-archive@ietf.org; Mon, 24 May 2004 02:39:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS96G-00053v-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 02:38:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS95P-0004mZ-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 02:37:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8xP-000249-Fj; Mon, 24 May 2004 02:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8uc-0001gX-4x for ipv6@optimus.ietf.org; Mon, 24 May 2004 02:26:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14413 for ; Mon, 24 May 2004 02:26:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS8uY-0001Vd-GK for ipv6@ietf.org; Mon, 24 May 2004 02:26:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS8td-0001Dp-00 for ipv6@ietf.org; Mon, 24 May 2004 02:25:14 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BS8ss-0000iP-00 for ipv6@ietf.org; Mon, 24 May 2004 02:24:27 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4O6Nru23130; Mon, 24 May 2004 09:23:53 +0300 Date: Mon, 24 May 2004 09:23:53 +0300 (EEST) From: Pekka Savola To: Grubmair Peter cc: "IPV6 IETF (E-mail)" Subject: Re: draft-daniel-dhc-ipv6in4-opt-03.txt In-Reply-To: <4D50D5110555D5119F270800062B41650532AB97@viee10pa.erd.siemens.at> Message-ID: MIME-Version: 1.0 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 On Sun, 23 May 2004, Grubmair Peter wrote: > To my mind this is one of the simplest form of a first transition > for mobile (GPRS) operators to supply IPv6 to > their customers. This option doesn't yet give any means to the tunnel server to discover the address of the UE. How do you figure this should be done? Btw. this discussion is better placed on the v6ops list, or dhc list. -- 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 24 08:20:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01161 for ; Mon, 24 May 2004 08:20:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEDJ-0004cX-HP for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 08:05:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OC5rnN017760 for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 08:05:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSE6J-0003AF-5r for ipv6-web-archive@optimus.ietf.org; Mon, 24 May 2004 07:58:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29540 for ; Mon, 24 May 2004 07:58:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSE6I-0001mm-9L for ipv6-web-archive@ietf.org; Mon, 24 May 2004 07:58:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSE5L-0001Rt-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 07:57:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSE4b-00016x-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 07:56:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDrC-0001Hk-27; Mon, 24 May 2004 07:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDaH-0007Or-P1 for ipv6@optimus.ietf.org; Mon, 24 May 2004 07:25:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27943 for ; Mon, 24 May 2004 07:25:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSDaH-0006WA-5O for ipv6@ietf.org; Mon, 24 May 2004 07:25:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSDZJ-0006Ae-00 for ipv6@ietf.org; Mon, 24 May 2004 07:24:34 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BSDYX-0005qQ-00 for ipv6@ietf.org; Mon, 24 May 2004 07:23:45 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:455a:453:f505:e499]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0950B15272 for ; Mon, 24 May 2004 20:23:35 +0900 (JST) Date: Mon, 24 May 2004 20:23:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis] summary and proposal about the M/O flags 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 All, Thanks for the feedback on this subject so far. I think we are now approaching a consensus, so here is a summary of resolution. - keep the M/O flags - clearly specify the protocols for the flags: RFC3315 for M and RFC3736 for O - clarify (change) the meaning of the M/O flags; they are just hints of availability of the corresponding services, not triggers for invoking the protocols under a certain level of requirement - remove or reword "requirements" regarding these flags according to the above change - remove ManagedFlag and OtherConfigFlag, which were implementation-internal variables in RFC2462 tightly depending on the "requirement" nature of the M/O flags - clarify the possible confusion coming from the fact that RFC3736 calls itself "stateless" while rfc2462bis uses "stateful" - leave the actual usage of the M/O flags will be used to a separate document. rfc2462bis mentions the other document The followings are the specific changes I'd propose. These are just a draft of draft, but would be very close to the final text (unless I get serious comments). I'm referring to rfc2462bis-00 as the "old" text, but it should not be so different from RFC2462 on this matter. 1. revise abstract as follows: [...] The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. [...] [...] The details of autoconfiguration using the stateful protocol are specified elsewhere. To: [...] The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information can be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they can be obtained through the stateless mechanism, the stateful mechanism, or both. [...] [...] The details of autoconfiguration using the stateful protocol is specified in RFC3315 and RFC3736. 2. same change as the previous one to the first paragraph of Section 1. 3. Revise the third paragraph of Section 1 to: In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a DHCPv6 server. Servers maintain a database that keeps track of which addresses have been assigned to which hosts. The stateful autoconfiguration protocol allows hosts to obtain addresses, other configuration information or both from a server. Stateless and stateful autoconfiguration complement each other. For example, a host can use stateless autoconfiguration to configure its own addresses, but use stateful autoconfiguration to obtain other information. 4. add the following paragraph between the third and fourths paragraphs of Section 1: To obtain other configuration information without configuring addresses in the stateful autoconfiguration model, a subset of DHCPv6 will be used [RFC3736]. While the model is called "stateful" in order to highlight the contrast to the stateless protocol defined in this document, the intended protocol is also defined to work in a stateless fashion. This is based on a result, through operational experiments, that all known "other" configuration information can be managed by a stateless server, that is, a server that does not maintain state of each client that the server provides with the configuration information. 5. revise the last sentence of the (current) fourth paragraph of Section 1: [...] The site administrator specifies which type of autoconfiguration to use through the setting of appropriate fields in Router Advertisement messages [5]. To: [...] The site administrator specifies which type of autoconfiguration is available through the setting of appropriate fields in Router Advertisement messages [5]. 6. revise the last bullet of the list in Section 3: o System administrators need the ability to specify whether stateless autoconfiguration, stateful autoconfiguration, or both should be used. Router Advertisements include flags specifying which mechanisms a host should use. To: o System administrators need the ability to specify whether stateless autoconfiguration, stateful autoconfiguration, or both is available. Router Advertisements include flags specifying which mechanisms a host can use. 7. revise the fifth paragraph of Section 4 (page 9) as follows: The next phase of autoconfiguration involves obtaining a Router Advertisement or determining that no routers are present. If routers are present, they will send Router Advertisements that specify what sort of autoconfiguration a host should do. If no routers are present, stateful autoconfiguration should be invoked. To: The next phase of autoconfiguration involves obtaining a Router Advertisement or determining that no routers are present. If routers are present, they will send Router Advertisements that specify what sort of autoconfiguration a host can do. When no routers are present, stateful autoconfiguration may be available. 8. revise the sixth paragraph of Section 4 as follows: [...] Router Advertisements contain two flags indicating what type of stateful autoconfiguration (if any) should be performed. A "managed address configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain addresses. An "other stateful configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain additional information (excluding addresses). To: [...] Router Advertisements contain two flags indicating what type of stateful autoconfiguration (if any) is available. A "managed address configuration (M)" flag indicates whether hosts can use stateful autoconfiguration [RFC3315] to obtain addresses. An "other stateful configuration (O)" flag indicates whether hosts can use stateful autoconfiguration [RFC3736] to obtain additional information (excluding addresses). 9. add the following to the end of the previous part: The details of how a host may use the M flags, including any use of the "on" and "off" transitions for this flag, to control the use of the stateful protocol for address assignment will be described in a separate document. Similarly, the details of how a host may use the O flags, including any use of the "on" and "off" transitions for this flag, to control the use of the stateful protocol for getting other configuration information will be described in a separate document. 10. remove the definitions of ManagedFlag and OtherConfigFlag from Section 5.2 (page 12). We'll also need to adjust the wording around the definition. 11. revise Section 5.5.2 as follows: Even if a link has no routers, stateful autoconfiguration to obtain addresses and other configuration information may still be available, and hosts may want to use the mechanism. From the perspective of autoconfiguration, a link has no routers if no Router Advertisements are received after having sent a small number of Router Solicitations as described in RFC 2461 [5]. 12. remove the first and second paragraphs of Section 5.5.3 ("requirements" parts of the M/O flags). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 24 08:54:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02951 for ; Mon, 24 May 2004 08:54:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEoz-0002DA-Sg for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 08:44:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OCinw4008499 for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 08:44:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEhq-0000TQ-7Y for ipv6-web-archive@optimus.ietf.org; Mon, 24 May 2004 08:37:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02112 for ; Mon, 24 May 2004 08:37:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSEho-0006Pu-T2 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 08:37:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSEgy-00068d-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 08:36:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSEgV-0005qh-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 08:36:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSETu-00077Q-4E; Mon, 24 May 2004 08:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEIv-0005VH-5G for ipv6@optimus.ietf.org; Mon, 24 May 2004 08:11:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00757 for ; Mon, 24 May 2004 08:11:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSEIu-0006GC-1a for ipv6@ietf.org; Mon, 24 May 2004 08:11:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSEI3-0005wv-00 for ipv6@ietf.org; Mon, 24 May 2004 08:10:48 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BSEGw-0005dJ-00 for ipv6@ietf.org; Mon, 24 May 2004 08:09:38 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:455a:453:f505:e499]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0CC2B15263 for ; Mon, 24 May 2004 21:09:37 +0900 (JST) Date: Mon, 24 May 2004 21:09:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID In-Reply-To: References: <40AA2FC7.302@zurich.ibm.com> <40AB33FB.8020300@zurich.ibm.com> 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 >>>>> On Thu, 20 May 2004 22:14:54 +0900, >>>>> JINMEI Tatuya said: >> Jinmei, I believe your proposed new text at the bottom is correct. >> 2462bis should not open the door to conflict in future link-layer >> specs. > Okay, but after re-reading the proposed new text, I then changed my > mind a bit; it should be better to use link specific documents as the > primary source of the IFID length. Otherwise, the implementor would > wonder how they should do if a received prefix in an RA does not match > ones for which ADDR-ARCH defines the corresponding IFID length. (snip) No responses..., assuming everyone is fine with the last text of mine, here is a set of concrete proposals on this issue. (I'm intentionally removing the hard-coded "64"s in the proposals). Please review the proposals and make comments on them (if necessary). 1. revise the definition of "interface identifier" (at the end of Section 2) as follows: interface identifier - a link-dependent identifier for an interface that is (at least) unique per link [4]. Stateless address autoconfiguration combines an interface identifier with a prefix to form an address. From address autoconfiguration's perspective, an interface identifier is a bit string of known length. The exact length of an interface identifier and the way it is created is defined in a separate link-type specific document that covers issues related to the transmission of IP over a particular link type (e.g., IPv6 over Ethernet [2]). Note that [4] also defines the length of the interface identifiers for some set of addresses, but the two sets of definitions must be consistent. In many cases, the identifier will be derived from the interface's link-layer address. 2. revise the last sentence of the second paragraph of Section 5.3 as follows: From: [...] If the interface identifier is more than 118 bits in length, autoconfiguration fails and manual configuration is required. Note that interface identifiers will typically be 64-bits long and based on EUI-64 identifiers as described in [4]. To: [...] If the interface identifier is more than 118 bits in length, autoconfiguration fails and manual configuration is required. The length of the interface identifier is defined in a separate link-type specific document, which should also be consistent with [4] (see Section 2). These documents will carefully define the length so that link-local addresses can be autoconfigured on the link. 3. revise the paragraph after the diagram in bullet d) of Section 5.5.3 as follows: From: If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. An implementation MAY wish to log a system management error in this case. It is the responsibility of the system administrator to insure that the lengths of prefixes contained in Router Advertisements are consistent with the length of interface identifiers for that link type. Note that interface identifiers will typically be 64-bits long and based on EUI-64 identifiers as described in [4]. To: If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. An implementation MAY wish to log a system management error in this case. The length of the interface identifier is defined in a separate link-type specific document, which should also be consistent with [4] (see Section 2). It is the responsibility of the system administrator to insure that the lengths of prefixes contained in Router Advertisements are consistent with the length of interface identifiers for that link type. It should be noted, however, that this does not mean the advertised prefix length is meaningless. In fact, the advertised length has non trivial meaning for on-link determination in Neighbor Discovery [5] where the sume of the prefix length and the interface identifier length may not be equal to 128. Thus, it should be safe to validate the advertised prefix length here, in order to detect and avoid a configuration error specifying an invalid prefix length in the context of address autoconfiguration. Note that a future revision of [4] and a future link-type specific document, which will still be consistent with each other, could potentially allow for an interface identifier of length other than the value defined in the current documents. Thus, an implementation should not assume a particular constant. Rather, it should expect any lengths of interface identifiers. 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 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 24 09:07:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03568 for ; Mon, 24 May 2004 09:07:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSExn-0003SX-PO for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 08:53:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OCrtxc013293 for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 08:53:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEoe-00024J-0t for ipv6-web-archive@optimus.ietf.org; Mon, 24 May 2004 08:44:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02395 for ; Mon, 24 May 2004 08:44:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSEoc-0000jE-Lr for ipv6-web-archive@ietf.org; Mon, 24 May 2004 08:44:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSEnq-0000PB-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 08:43:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSEml-00004D-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 08:42:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSETy-00078C-A3; Mon, 24 May 2004 08:23:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEOT-0005yD-TA for ipv6@optimus.ietf.org; Mon, 24 May 2004 08:17:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01095 for ; Mon, 24 May 2004 08:17:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSEOS-0000Dx-IO for ipv6@ietf.org; Mon, 24 May 2004 08:17:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSENa-0007jU-00 for ipv6@ietf.org; Mon, 24 May 2004 08:16:30 -0400 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1BSEMd-0007Rw-00 for ipv6@ietf.org; Mon, 24 May 2004 08:15:31 -0400 Received: from [128.176.184.156] (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.11/8.12.9) with ESMTP id i4OCFJYC007995 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 24 May 2004 14:15:24 +0200 (CEST) Subject: Re: [rfc2462bis] summary and proposal about the M/O flags From: "Christian Strauf (JOIN)" To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= Cc: ipv6@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: JOIN-Team, WWU-Muenster Message-Id: <1085400918.25345.7.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 24 May 2004 14:15:19 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jinmei, > Thanks for the feedback on this subject so far. thank you for the comprehensive summary, it looks very good! > 11. revise Section 5.5.2 as follows: > > Even if a link has no routers, stateful autoconfiguration to obtain > addresses and other configuration information may still be > available, and hosts may want to use the mechanism. From the > perspective of autoconfiguration, a link has no routers if no > Router Advertisements are received after having sent a small number > of Router Solicitations as described in RFC 2461 [5]. Since there was a question regarding DHCPv6 and default router information options on the DHC-WG's mailing list, one short question to clarify the meaning of this paragraph: would you say that "routers have to send RAs if they forward packages" is a valid interpretation of this paragraph? Thanks in advance for clarifying this. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon May 24 09:31:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05157 for ; Mon, 24 May 2004 09:31:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFPX-0007bx-IS for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 09:22:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ODMZ1J029257 for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 09:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFFl-00062P-RF for ipv6-web-archive@optimus.ietf.org; Mon, 24 May 2004 09:12:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03965 for ; Mon, 24 May 2004 09:12:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFFk-0001eB-6b for ipv6-web-archive@ietf.org; Mon, 24 May 2004 09:12:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFEm-0001KO-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 09:11:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSFDn-00011M-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 09:10:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSF3k-0003zC-94; Mon, 24 May 2004 09:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEqY-0002Sp-L6 for ipv6@optimus.ietf.org; Mon, 24 May 2004 08:46:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02494 for ; Mon, 24 May 2004 08:46:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSEqX-0001LT-7v for ipv6@ietf.org; Mon, 24 May 2004 08:46:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSEpZ-00012Z-00 for ipv6@ietf.org; Mon, 24 May 2004 08:45:26 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1BSEod-0000Rb-00 for ipv6@ietf.org; Mon, 24 May 2004 08:44:27 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4OChvlg049442 for ; Mon, 24 May 2004 12:43:57 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4OChu6M119020 for ; Mon, 24 May 2004 14:43:56 +0200 Received: from zurich.ibm.com (sig-9-145-240-202.de.ibm.com [9.145.240.202]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA43656 for ; Mon, 24 May 2004 14:43:56 +0200 Message-ID: <40B1EE10.8020704@zurich.ibm.com> Date: Mon, 24 May 2004 14:44:00 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID References: <40AA2FC7.302@zurich.ibm.com> <40AB33FB.8020300@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit OK - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM JINMEI Tatuya wrote: >>>>>>On Wed, 19 May 2004 12:16:27 +0200, >>>>>>Brian E Carpenter said: > > >>Jinmei, I believe your proposed new text at the bottom is correct. >>2462bis should not open the door to conflict in future link-layer >>specs. > > > Okay, but after re-reading the proposed new text, I then changed my > mind a bit; it should be better to use link specific documents as the > primary source of the IFID length. Otherwise, the implementor would > wonder how they should do if a received prefix in an RA does not match > ones for which ADDR-ARCH defines the corresponding IFID length. > > So, the better text would be as follows: > > interface identifier - a link-dependent identifier for an interface > that is (at least) unique per link [ADDR-ARCH]. Stateless > address autoconfiguration combines an interface identifier with > a prefix to form an address. From address autoconfiguration's > perspective, an interface identifier is a bit string of known > length. The exact length of an interface identifier and the way > it is created is defined in a separate link-type specific > document that covers issues related to the transmission of IP > over a particular link type (e.g., [IPv6-ETHER]). > (i.e., the same text as RFC2462) > > with a note about the relationship between ADDR-ARCH and link specific > documents to avoid confusion: > > Note that [ADDR-ARCH] also defines the length of the interface > identifiers for some set of addresses, but the two sets of > definitions must be consistent. > > It should also be good to emphasize that the implementation should not > assume the particular constant "64" like this: > > Note that a future revision of [ADDR-ARCH] and a future link-type > specific document could potentially allow for an interface identifier > of length other than 64 bits. Thus, an implementation should not > assume that particular constant. Rather, it should expect any > lengths of interface identifiers. > > (the text you proposed in an earlier message) > > Makes sense? > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------