From exim@www1.ietf.org Thu Apr 1 14:07: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 OAA26186 for ; Thu, 1 Apr 2004 14:07:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B97XG-0000kN-A3 for ipv6-archive@odin.ietf.org; Thu, 01 Apr 2004 14:07:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31J7U6L002867 for ipv6-archive@odin.ietf.org; Thu, 1 Apr 2004 14:07:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B97XF-0000kA-NL for ipv6-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 14:07:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26142 for ; Thu, 1 Apr 2004 14:07:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B97X3-0006Jd-00 for ipv6-web-archive@ietf.org; Thu, 01 Apr 2004 14:07:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B97W7-0006Ct-00 for ipv6-web-archive@ietf.org; Thu, 01 Apr 2004 14:06:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B97VF-00064k-00 for ipv6-web-archive@ietf.org; Thu, 01 Apr 2004 14:05:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B97Tu-0000GZ-ST; Thu, 01 Apr 2004 14:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B97TM-0000FC-8s for ipv6@optimus.ietf.org; Thu, 01 Apr 2004 14:03:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25998 for ; Thu, 1 Apr 2004 14:03:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B97T9-0005sT-00 for ipv6@ietf.org; Thu, 01 Apr 2004 14:03:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B97SA-0005n7-00 for ipv6@ietf.org; Thu, 01 Apr 2004 14:02:15 -0500 Received: from 209-162-215-52.dq1sn.easystreet.com ([209.162.215.52] helo=southstation.m5p.com) by ietf-mx with esmtp (Exim 4.12) id 1B97RC-0005e7-00 for ipv6@ietf.org; Thu, 01 Apr 2004 14:01:15 -0500 Received: from m5p.com (mailhost.m5p.com [10.100.0.247]) by southstation.m5p.com (8.12.11/8.12.11) with ESMTP id i31J0fO5028743 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Apr 2004 11:00:41 -0800 (PST) Received: (from george@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i31J0fYd028740; Thu, 1 Apr 2004 11:00:41 -0800 (PST) Date: Thu, 1 Apr 2004 11:00:41 -0800 (PST) Message-Id: <200404011900.i31J0fYd028740@m5p.com> From: george+ipng@m5p.com To: ipv6@ietf.org Subject: Free Random Numbers X-Scanned-By: MIMEDefang 2.39 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.8 required=5.0 tests=AWL,NO_REAL_NAME, SUB_FREE_OFFER autolearn=no version=2.60 To celebrate the second anniversary of my unsuccessful campaign to become Benevolent Internet Dictator, I'm handing out free random numbers, which you should UNDER NO CIRCUMSTANCES use as a Unique Local Address prefix. Please see http://www.f-iw.org/random.cgi for more details. Felicitations of the day! -- George Mitchell -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 1 14:40: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 OAA27246 for ; Thu, 1 Apr 2004 14:40:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B983E-0002PZ-ML for ipv6-archive@odin.ietf.org; Thu, 01 Apr 2004 14:40:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31JeW9k009265 for ipv6-archive@odin.ietf.org; Thu, 1 Apr 2004 14:40:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B983E-0002PM-Gj for ipv6-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 14:40:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27190 for ; Thu, 1 Apr 2004 14:40:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9831-0001oF-00 for ipv6-web-archive@ietf.org; Thu, 01 Apr 2004 14:40:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B982C-0001j3-00 for ipv6-web-archive@ietf.org; Thu, 01 Apr 2004 14:39:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B981U-0001dW-00 for ipv6-web-archive@ietf.org; Thu, 01 Apr 2004 14:38:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B980o-0001zl-IF; Thu, 01 Apr 2004 14:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B980F-0001xl-Er for ipv6@optimus.ietf.org; Thu, 01 Apr 2004 14:37:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27085 for ; Thu, 1 Apr 2004 14:37:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9802-0001Uu-00 for ipv6@ietf.org; Thu, 01 Apr 2004 14:37:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B97z5-0001Ot-00 for ipv6@ietf.org; Thu, 01 Apr 2004 14:36:16 -0500 Received: from 209-162-215-52.dq1sn.easystreet.com ([209.162.215.52] helo=southstation.m5p.com) by ietf-mx with esmtp (Exim 4.12) id 1B97y8-0001DC-00 for ipv6@ietf.org; Thu, 01 Apr 2004 14:35:16 -0500 Received: from m5p.com (mailhost.m5p.com [10.100.0.247]) by southstation.m5p.com (8.12.11/8.12.11) with ESMTP id i31JYdrN029223 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Apr 2004 11:34:45 -0800 (PST) Received: (from george@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i31JYdhA029220; Thu, 1 Apr 2004 11:34:39 -0800 (PST) Date: Thu, 1 Apr 2004 11:34:39 -0800 (PST) Message-Id: <200404011934.i31JYdhA029220@m5p.com> From: george+ipng@m5p.com To: ipv6@ietf.org Subject: Additional Note X-Scanned-By: MIMEDefang 2.39 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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 You can get your free random number via IPv6 at http://www6.f-iw.org/random.cgi. -- George Mitchell -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 2 10:34: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 KAA14321 for ; Fri, 2 Apr 2004 10:34:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Nqs-0005sf-Tk for ipv6-archive@odin.ietf.org; Fri, 02 Apr 2004 07:32:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32CWoxK022606 for ipv6-archive@odin.ietf.org; Fri, 2 Apr 2004 07:32:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9KbU-0004qX-VN for ipv6-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 04:04:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29824 for ; Fri, 2 Apr 2004 04:04:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9KbS-0006AI-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 04:04:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9KaX-00063z-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 04:03:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9KZo-0005xw-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 04:03:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9GEp-0000jV-2R; Thu, 01 Apr 2004 23:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9DHu-0002h4-Dg for ipv6@optimus.ietf.org; Thu, 01 Apr 2004 20:16:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17230 for ; Thu, 1 Apr 2004 20:15:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9DHs-0000UW-00 for ipv6@ietf.org; Thu, 01 Apr 2004 20:16:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9DGs-0000Ir-00 for ipv6@ietf.org; Thu, 01 Apr 2004 20:14:59 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1B9DGD-00008D-00 for ipv6@ietf.org; Thu, 01 Apr 2004 20:14:17 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HVI0090GREYB3@mailout2.samsung.com> for ipv6@ietf.org; Fri, 02 Apr 2004 10:13:46 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HVI00CR9REWH9@mailout2.samsung.com> for ipv6@ietf.org; Fri, 02 Apr 2004 10:13:44 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HVI006JBREVKZ@mmp1.samsung.com> for ipv6@ietf.org; Fri, 02 Apr 2004 10:13:44 +0900 (KST) Date: Fri, 02 Apr 2004 10:14:02 +0900 From: "S. Daniel Park" Subject: test To: ietf@sait.samsung.co.kr Cc: ipv6@ietf.org Message-id: <00d001c4184f$c8fa8200$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 - 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 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 2 12:21: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 MAA19785 for ; Fri, 2 Apr 2004 12:21:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9QbP-0006Kt-UD for ipv6-archive@odin.ietf.org; Fri, 02 Apr 2004 10:29:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32FT3YP024346 for ipv6-archive@odin.ietf.org; Fri, 2 Apr 2004 10:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9NYV-0004pq-0J for ipv6-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 07:13:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05845 for ; Fri, 2 Apr 2004 07:13:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9NYU-00058e-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 07:13:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9NXl-00052G-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 07:13:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9NX8-0004uq-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 07:12:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9KC7-0003LE-TT; Fri, 02 Apr 2004 03:38:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9FMF-000524-Fp for ipv6@optimus.ietf.org; Thu, 01 Apr 2004 22:28:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29522 for ; Thu, 1 Apr 2004 22:28:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9FMC-0004By-00 for ipv6@ietf.org; Thu, 01 Apr 2004 22:28:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9FLI-00045c-00 for ipv6@ietf.org; Thu, 01 Apr 2004 22:27:41 -0500 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1B9FKE-0003v4-00 for ipv6@ietf.org; Thu, 01 Apr 2004 22:26:36 -0500 Received: from l04955 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HVI004KOX8YQV@mta0.huawei.com> for ipv6@ietf.org; Fri, 02 Apr 2004 11:19:48 +0800 (CST) Date: Fri, 02 Apr 2004 11:22:20 +0800 From: lidefeng Subject: Question about the Site-local Unicast Address in IPv6 To: ipv6@ietf.org Message-id: <004d01c41861$b5d2c540$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 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.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, all, There are many kinds of unicast address in IPv6, one of them is "site-local address", and it is designed for the address assignment in a single site. and you know, there is a concept of "site" in BGP/MPLS VPN too, could anyone please tell me if there is any difference between them, or are they the same meaning? TIA and Best Regards Defeng Li -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 2 16:36: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 QAA02025 for ; Fri, 2 Apr 2004 16:36:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WKp-0005M0-6Z for ipv6-archive@odin.ietf.org; Fri, 02 Apr 2004 16:36:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LaJnh020580 for ipv6-archive@odin.ietf.org; Fri, 2 Apr 2004 16:36:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WKp-0005Lr-0K for ipv6-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:36:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01954 for ; Fri, 2 Apr 2004 16:36:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WKn-0005y7-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 16:36:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WJv-0005nM-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 16:35:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9WJ5-0005e0-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 16:34:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9TOg-0004ub-D8; Fri, 02 Apr 2004 13:28:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9R8H-0000D5-EA for ipv6@optimus.ietf.org; Fri, 02 Apr 2004 11:03:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16143 for ; Fri, 2 Apr 2004 11:02:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9R8E-0004kt-00 for ipv6@ietf.org; Fri, 02 Apr 2004 11:02:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9R7K-0004Vz-00 for ipv6@ietf.org; Fri, 02 Apr 2004 11:02:03 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1B9R5d-0003qm-00 for ipv6@ietf.org; Fri, 02 Apr 2004 11:00:17 -0500 Received: from eamrcnt716.exu.ericsson.se (eamrcnt716.exu.ericsson.se [138.85.90.247]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i32FxcLc003472 for ; Fri, 2 Apr 2004 09:59:38 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt716.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Apr 2004 09:57:08 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <2DNB6JNP>; Fri, 2 Apr 2004 09:59:23 -0600 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 GPWXJN9Y; Fri, 2 Apr 2004 10:59:43 -0500 Date: Fri, 2 Apr 2004 10:59:24 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: lidefeng cc: ipv6@ietf.org Subject: Re: Question about the Site-local Unicast Address in IPv6 In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830D8F6C36@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 02 Apr 2004 15:57:08.0890 (UTC) FILETIME=[273C2FA0:01C418CB] 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 Difeng, The site-local addresses in IPv6 have been deprecated. One of the reasons for the deprecation was that the "site" was not clearly defined. Take a look at the unique local addresses draft to see if it meets your requirements. draft-ietf-ipv6-unique-local-addr-03.txt Regards Suresh On Fri, 2 Apr 2004, lidefeng wrote: >Hi, all, > >There are many kinds of unicast address in IPv6, one of them is "site-local >address", and it is designed for the address assignment > in a single site. and you know, there is a concept of "site" in BGP/MPLS >VPN too, could anyone please tell me if there is any difference between >them, or are they the same meaning? > >TIA and Best Regards > >Defeng Li > > >-------------------------------------------------------------------- >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 Apr 2 16:52:34 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 QAA04278 for ; Fri, 2 Apr 2004 16:52:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wa1-0007uE-Lw for ipv6-archive@odin.ietf.org; Fri, 02 Apr 2004 16:52:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32Lq1Ro030250 for ipv6-archive@odin.ietf.org; Fri, 2 Apr 2004 16:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Vn4-000176-LO for ipv6-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:01:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28712 for ; Fri, 2 Apr 2004 16:01:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Vn3-0006eT-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 16:01:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9VmF-0006TT-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 16:00:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9VlI-0006F6-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 15:59:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SJr-0007gn-8d; Fri, 02 Apr 2004 12:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9QSb-00049E-R3 for ipv6@optimus.ietf.org; Fri, 02 Apr 2004 10:19:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13300 for ; Fri, 2 Apr 2004 10:19:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9QSZ-0005lz-00 for ipv6@ietf.org; Fri, 02 Apr 2004 10:19:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9QRe-0005fg-00 for ipv6@ietf.org; Fri, 02 Apr 2004 10:18:58 -0500 Received: from 153.red-213-4-13.pooles.rima-tde.net ([213.4.13.153] helo=kerberos.felipe-alfaro.com) by ietf-mx with esmtp (Exim 4.12) id 1B9QQl-0005S9-00 for ipv6@ietf.org; Fri, 02 Apr 2004 10:18:04 -0500 Received: from [192.168.0.100] (teapot.felipe-alfaro.com [192.168.0.100]) by kerberos.felipe-alfaro.com (Postfix) with ESMTP id 9B1D142E8E; Fri, 2 Apr 2004 17:17:22 +0200 (CEST) Subject: Re: Question about the Site-local Unicast Address in IPv6 From: Felipe Alfaro Solana To: lidefeng Cc: ipv6@ietf.org In-Reply-To: <004d01c41861$b5d2c540$07436e0a@HUAWEI.COM> References: <004d01c41861$b5d2c540$07436e0a@HUAWEI.COM> Content-Type: text/plain Message-Id: <1080919038.1336.7.camel@teapot.felipe-alfaro.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-1) Date: Fri, 02 Apr 2004 17:17:18 +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 On Fri, 2004-04-02 at 05:22, lidefeng wrote: > There are many kinds of unicast address in IPv6, one of them is "site-local > address", and it is designed for the address assignment > in a single site. and you know, there is a concept of "site" in BGP/MPLS > VPN too, could anyone please tell me if there is any difference between > them, or are they the same meaning? I wouldn't bother much with site-local addresses are they are in the process of being deprecated. Instead, use Unique Local IPv6 Unicast Addresses as described in http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-03.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 2 17:10: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 RAA06907 for ; Fri, 2 Apr 2004 17:10:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9W3n-0006BC-3n for ipv6-archive@odin.ietf.org; Fri, 02 Apr 2004 16:18:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LIg6T023754 for ipv6-archive@odin.ietf.org; Fri, 2 Apr 2004 16:18:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SyY-0003DK-4L for ipv6-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 13:01:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21155 for ; Fri, 2 Apr 2004 13:01:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9SyW-0005o4-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 13:01:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Sxa-0005gw-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 13:00:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Swq-0005aC-00 for ipv6-web-archive@ietf.org; Fri, 02 Apr 2004 12:59:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9R5R-0008Fz-2R; Fri, 02 Apr 2004 11:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9O8W-0006nS-5S for ipv6@optimus.ietf.org; Fri, 02 Apr 2004 07:51:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07377 for ; Fri, 2 Apr 2004 07:51:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9O8V-0002OT-00 for ipv6@ietf.org; Fri, 02 Apr 2004 07:51:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9O7d-0002Gw-00 for ipv6@ietf.org; Fri, 02 Apr 2004 07:50:09 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1B9O74-00027w-00 for ipv6@ietf.org; Fri, 02 Apr 2004 07:49:34 -0500 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 i32Cn2L17413; Fri, 2 Apr 2004 04:49:02 -0800 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 i32D3ZQP032755 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 2 Apr 2004 05:03:40 -0800 Message-ID: <406D6118.3090307@innovationslab.net> Date: Fri, 02 Apr 2004 07:48:24 -0500 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: lidefeng CC: ipv6@ietf.org Subject: Re: Question about the Site-local Unicast Address in IPv6 References: <004d01c41861$b5d2c540$07436e0a@HUAWEI.COM> In-Reply-To: <004d01c41861$b5d2c540$07436e0a@HUAWEI.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 The ambiguous site-local addresses are being deprecated. Please see draft-ietf-ipv6-deprecate-site-local-03.txt. The definition of a site is intentionally ambiguous. That is, an operator can define the IPv6 site to be the same as or different from the VPN site. Regards, Brian lidefeng wrote: > Hi, all, > > There are many kinds of unicast address in IPv6, one of them is "site-local > address", and it is designed for the address assignment > in a single site. and you know, there is a concept of "site" in BGP/MPLS > VPN too, could anyone please tell me if there is any difference between > them, or are they the same meaning? > > TIA and Best Regards > > Defeng Li > > > -------------------------------------------------------------------- > 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 Sat Apr 3 00:52: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 AAA25069 for ; Sat, 3 Apr 2004 00:52:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9e4A-0008Fs-QX for ipv6-archive@odin.ietf.org; Sat, 03 Apr 2004 00:51:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i335pcvM031733 for ipv6-archive@odin.ietf.org; Sat, 3 Apr 2004 00:51:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9e4A-0008Fk-K7 for ipv6-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 00:51:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25052 for ; Sat, 3 Apr 2004 00:51:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9e47-0004MU-00 for ipv6-web-archive@ietf.org; Sat, 03 Apr 2004 00:51:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9e3D-0004E7-00 for ipv6-web-archive@ietf.org; Sat, 03 Apr 2004 00:50:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9e2I-00045f-00 for ipv6-web-archive@ietf.org; Sat, 03 Apr 2004 00:49:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9e1e-0007IG-6b; Sat, 03 Apr 2004 00:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9e19-0006s3-WB for ipv6@optimus.ietf.org; Sat, 03 Apr 2004 00:48:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24982 for ; Sat, 3 Apr 2004 00:48:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9e17-0003v3-00 for ipv6@ietf.org; Sat, 03 Apr 2004 00:48:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9e0D-0003n1-00 for ipv6@ietf.org; Sat, 03 Apr 2004 00:47:33 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9dzA-0003YO-00 for ipv6@ietf.org; Sat, 03 Apr 2004 00:46:28 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i335jH112511; Sat, 3 Apr 2004 08:45:17 +0300 Date: Sat, 3 Apr 2004 08:45:16 +0300 (EEST) From: Pekka Savola To: Felipe Alfaro Solana cc: lidefeng , Subject: Re: Question about the Site-local Unicast Address in IPv6 In-Reply-To: <1080919038.1336.7.camel@teapot.felipe-alfaro.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 Fri, 2 Apr 2004, Felipe Alfaro Solana wrote: > On Fri, 2004-04-02 at 05:22, lidefeng wrote: > > > There are many kinds of unicast address in IPv6, one of them is "site-local > > address", and it is designed for the address assignment > > in a single site. and you know, there is a concept of "site" in BGP/MPLS > > VPN too, could anyone please tell me if there is any difference between > > them, or are they the same meaning? > > I wouldn't bother much with site-local addresses are they are in the > process of being deprecated. Instead, use Unique Local IPv6 Unicast > Addresses as described in > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-03.txt Instead, I'd recommend not using local addressing at all. -- 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 Sun Apr 4 00:05:50 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 AAA18694 for ; Sun, 4 Apr 2004 00:05:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zox-0000mt-IH for ipv6-archive@odin.ietf.org; Sun, 04 Apr 2004 00:05:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3455Nuw003027 for ipv6-archive@odin.ietf.org; Sun, 4 Apr 2004 00:05:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zox-0000mk-7N for ipv6-web-archive@optimus.ietf.org; Sun, 04 Apr 2004 00:05:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18682 for ; Sun, 4 Apr 2004 00:05:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9zou-0002ce-00 for ipv6-web-archive@ietf.org; Sun, 04 Apr 2004 00:05:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9znw-0002Wd-00 for ipv6-web-archive@ietf.org; Sun, 04 Apr 2004 00:04:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9znH-0002Qv-00 for ipv6-web-archive@ietf.org; Sun, 04 Apr 2004 00:03:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zmg-0008S0-Iw; Sun, 04 Apr 2004 00:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zmW-0008RT-Ft for ipv6@optimus.ietf.org; Sun, 04 Apr 2004 00:02:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18581 for ; Sun, 4 Apr 2004 00:02:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9zmU-0002L7-00 for ipv6@ietf.org; Sun, 04 Apr 2004 00:02:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9zlo-0002EH-00 for ipv6@ietf.org; Sun, 04 Apr 2004 00:02:09 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1B9zkg-00023G-00 for ipv6@ietf.org; Sun, 04 Apr 2004 00:00:58 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 41E61262 for ; Sun, 4 Apr 2004 00:00:18 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 04 Apr 2004 00:00:18 -0500 Message-Id: <20040404050018.41E61262@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 --------+------+--------+----------+------------------------ 16.67% | 4 | 19.41% | 21526 | brian@innovationslab.net 16.67% | 4 | 17.46% | 19367 | pekkas@netcore.fi 8.33% | 2 | 7.44% | 8255 | erik.nordmark@sun.com 8.33% | 2 | 5.79% | 6423 | george+ipng@m5p.com 4.17% | 1 | 6.64% | 7361 | info@caitr.org 4.17% | 1 | 5.36% | 5943 | greg.daley@eng.monash.edu.au 4.17% | 1 | 4.59% | 5087 | huitema@windows.microsoft.com 4.17% | 1 | 4.52% | 5017 | rdroms@cisco.com 4.17% | 1 | 4.38% | 4858 | ot@cisco.com 4.17% | 1 | 4.11% | 4561 | suresh.krishnan@ericsson.ca 4.17% | 1 | 3.98% | 4414 | sra+ipng@hactrn.net 4.17% | 1 | 3.79% | 4206 | sharkey@zoic.org 4.17% | 1 | 3.57% | 3960 | margaret@thingmagic.com 4.17% | 1 | 3.24% | 3598 | felipe_alfaro@linuxmail.org 4.17% | 1 | 2.98% | 3304 | lidefeng@huawei.com 4.17% | 1 | 2.72% | 3015 | killyeon@yahoo.com --------+------+--------+----------+------------------------ 100.00% | 24 |100.00% | 110895 | 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 Apr 5 18:03: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 SAA14117 for ; Mon, 5 Apr 2004 18:03: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 1BAcB6-0004l5-1h for ipv6-archive@odin.ietf.org; Mon, 05 Apr 2004 18:02:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35M2m7s018291 for ipv6-archive@odin.ietf.org; Mon, 5 Apr 2004 18:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAcB5-0004kg-ME for ipv6-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 18:02: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 SAA14063 for ; Mon, 5 Apr 2004 18:02:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAcB3-0003Cw-00 for ipv6-web-archive@ietf.org; Mon, 05 Apr 2004 18:02:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAbui-00005B-00 for ipv6-web-archive@ietf.org; Mon, 05 Apr 2004 17:45:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAbIZ-0004bg-00 for ipv6-web-archive@ietf.org; Mon, 05 Apr 2004 17:06:27 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAbIZ-0002hP-MM for ipv6-web-archive@ietf.org; Mon, 05 Apr 2004 17:06:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbHD-0003vK-63; Mon, 05 Apr 2004 17:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbGu-0003jz-PQ for ipv6@optimus.ietf.org; Mon, 05 Apr 2004 17:04: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 RAA09634 for ; Mon, 5 Apr 2004 17:04:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAbGs-0004Fo-00 for ipv6@ietf.org; Mon, 05 Apr 2004 17:04:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAb8D-0002gn-00 for ipv6@ietf.org; Mon, 05 Apr 2004 16:55:46 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BAaoD-0007TL-00 for ipv6@ietf.org; Mon, 05 Apr 2004 16:35:05 -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); Mon, 5 Apr 2004 13:34:45 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Apr 2004 13:34:34 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 13:34:44 -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); Mon, 5 Apr 2004 13:34:32 -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, 5 Apr 2004 13:34:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.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: [ipv6mib] IP MIB issues Date: Mon, 5 Apr 2004 13:34:32 -0700 Message-ID: Thread-Topic: [ipv6mib] IP MIB issues thread-index: AcQTZLHdDt6373LKSKyZiPewcXGV4wH6HGww From: "Dave Thaler" To: , Cc: , , X-OriginalArrivalTime: 05 Apr 2004 20:34:44.0143 (UTC) FILETIME=[6DC75BF0:01C41B4D] 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 Shawn Routhier wrote: > I believe that use of "AdminStatus" in ipv4InterfaceAdminStatus and > ipv6InterfaceAdminStatus is confusing. [...] > My current position is that as I need to make changes anyway I may as > well include this change. >=20 > If there is no discussion I shall change the names of these objects. If > you feel that the names of these objects should not be changed send mail > by the deadline that the chairs specify. I agree with this change. > For issue 2 we have the following discussion: > For all instances for which it is defined, i.e., all values of i, I > believe > the value of ipv6InterfacePhysicalAddress.i is always same as the value of > ifPhysAddress.i >=20 > Thus, it is redundant, right ? [...] > If there is no discussion I shall remove this object. If you feel it is > a useful object and should be kept send mail by the deadline that the > chairs > specify. FWIW, I made exactly the same comment. I agree it should be either removed or deprecated, as appropriate. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 6 18:15:38 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 SAA05662 for ; Tue, 6 Apr 2004 18:15: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 1BAyqe-0000Zh-6h for ipv6-archive@odin.ietf.org; Tue, 06 Apr 2004 18:15:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36MFCZZ002202 for ipv6-archive@odin.ietf.org; Tue, 6 Apr 2004 18:15:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAyqe-0000ZI-0P for ipv6-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 18:15: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 SAA05619 for ; Tue, 6 Apr 2004 18:15:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAyqb-0003CD-00 for ipv6-web-archive@ietf.org; Tue, 06 Apr 2004 18:15:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAyA9-0004Ik-00 for ipv6-web-archive@ietf.org; Tue, 06 Apr 2004 17:31:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAx9R-0005RH-00 for ipv6-web-archive@ietf.org; Tue, 06 Apr 2004 16:26:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAx8z-0005vp-Kf; Tue, 06 Apr 2004 16: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 1BAx8W-0005rn-Lt for ipv6@optimus.ietf.org; Tue, 06 Apr 2004 16:25:32 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25682 for ; Tue, 6 Apr 2004 16:25:29 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BAx82-0005XG-A3; Tue, 06 Apr 2004 16:25:02 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , ipv6 mailing list , ipv6 chair , ipv6 chair Subject: Document Action: 'Requirements for IPv6 prefix delegation' to Informational RFC Message-Id: Date: Tue, 06 Apr 2004 16:25:02 -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 IESG has approved the following document: - 'Requirements for IPv6 prefix delegation ' as an Informational RFC This document is the product of the IP Version 6 Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 8 12:15: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 MAA02147 for ; Thu, 8 Apr 2004 12:15: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 1BBcBR-0005sG-4B for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 12:15:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38GFHpJ022581 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 12:15:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBcBQ-0005s8-Q4 for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 12:15: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 MAA02143 for ; Thu, 8 Apr 2004 12:15:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBcBO-0003nl-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 12:15:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBa6t-0004O2-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 10:02:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBXgn-0003qC-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 07:27:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBXfW-00052U-Vd; Thu, 08 Apr 2004 07: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 1BBXer-0004x9-Vl for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 07:25: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 HAA07739 for ; Thu, 8 Apr 2004 07:25:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBXer-0003fq-00 for ipv6@ietf.org; Thu, 08 Apr 2004 07:25:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBVoh-0003Tu-00 for ipv6@ietf.org; Thu, 08 Apr 2004 05:27:25 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BBTRC-0003DE-00 for ipv6@ietf.org; Thu, 08 Apr 2004 02:54:58 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:4ce:b977:e35c:ec79]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 94D7615214; Thu, 8 Apr 2004 15:54:52 +0900 (JST) Date: Thu, 08 Apr 2004 15:55:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipv6@ietf.org Subject: Re: rfc2462bis: new section 5.7 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 (Sorry for the long delay in response) >>>>> On Mon, 22 Mar 2004 12:03:35 -0800 (PST), >>>>> Erik Nordmark said: >> Meanwhile, I have more fundamental questions: >> >> 1. it is probably not adequate to describe this in the body of >> rfc2462bis, since it's a kind of extension, not a bug fix or a >> clarification to the existing specification. Shouldn't we rather >> move this section to appendix entitled (e.g.) "future possible >> extensions"? Or should we describe this in rfc2462bis in the first >> place? I myself do not have a particular preference, but if we >> cannot reach consensus, I'd rather remove this section from >> rfc2462bis. > I understand your concern. > Given that there are some implementations that store the prefix > in a file there is a risk (and perhaps even implementations) that > do not retain the lifetimes together with the prefix I think we should > at least add a clarification that if the prefix is retained in stable storage > in such a way that it might remain in stable storage after > the lifetimes might have expired, the end of lifetimes must also be retauned > in stable storage. > Thus I agree that the extension to suggest that implementations retrain > the prefix doesn't belong, but given that some implementations already do > having the warning about the lifetimes makes sense. Okay, so how about revising section 5.7 as follows? In this proposal, we still have the new section, but I tried to limit the description to warnings based on experiences of existing implementations. 5.7 Retaining Configured Addresses for Stability An implementation that has stable storage may want to retain addresses in the storage when the addresses were acquired using stateless address autoconfiguration. Assuming the lifetimes used are reasonable, this technique implies that a temporary outage (less than the valid lifetime) of a router will never result in the node losing its global address even if the node were to reboot. When this technique is used, it should also be noted that the expiration times of the preferred and valid lifetimes should be retained, instead of or in addition to the lifetimes themselves, in order to avoid unexpected lifetime expiration during the boot period. Further details on this kind of extension are beyond the scope of this document. >> 2. this extension may conflict with the rule that "if no router >> exists, then stateful configuration MUST be performed" (though we >> are now discussing the requirement level on this). Assuming the >> current requirement level, should we also describe the relationship >> (or ordering) between the two alternatives? For example, should we >> require that this extension (i.e., retaining the address) be used >> only after the attempt of stateful address configuration fails? > If we take your suggestion that the extension is out of scope > for the clarifications then we can defer this issue to a separate draft. > That of course doesn't answer your technical question. > I think the answer to the technical question lies in the DNA world. > If you can detect that you are still connected to the same link > it would be ok (when the lifetimes haven't expired) to > verify and continue to use the old configuration. > But the question is whether DNA can easily verify it is attached to the same > link when there is not a router - the schemes proposed so far seem to assume > a router (and/or a dhcp agent if stateful is used) just to do the verification > that you are on the same link as before. I tend to agree that the question should go to the DNA world. So, for now, I'll leave the second question open if the above proposal on Section 5.7 is acceptable. 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 Apr 8 18:22:57 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 SAA02090 for ; Thu, 8 Apr 2004 18:22: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 1BBhun-0005oG-PP for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 18:22:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38MMTLC022330 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 18:22:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhua-0005nj-UI for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 18:22: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 SAA02049 for ; Thu, 8 Apr 2004 18:22:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhuX-0004vK-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 18:22:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfsh-0003op-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 16:12:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBcm2-0007Jj-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 12:53:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBckz-0000gC-Od; Thu, 08 Apr 2004 12:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBckf-0000fG-A5 for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 12:51: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 MAA02909 for ; Thu, 8 Apr 2004 12:51:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBckc-00079j-00 for ipv6@ietf.org; Thu, 08 Apr 2004 12:51:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBaA5-0004yi-00 for ipv6@ietf.org; Thu, 08 Apr 2004 10:05:47 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1BBXof-0004Ts-00 for ipv6@ietf.org; Thu, 08 Apr 2004 07:35:29 -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 i38BYvL00945; Thu, 8 Apr 2004 04:34:57 -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 i38BnpQP011356 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 8 Apr 2004 04:50:01 -0700 Message-ID: <407538D1.1070803@innovationslab.net> Date: Thu, 08 Apr 2004 07:34:41 -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: Margaret Wasserman , ipv6@ietf.org Subject: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt 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 Margaret Wasserman wrote: > Hi All, > > I've completed my AD evaluation of > draft-ietf-ipv6-unique-local-addr-03.txt. My comments (attached > below) include a few substantive issues that I would like to discuss > with the WG before sending this draft to IETF last call. Thoughts? > > I have also included a few non-blocking editorial comments that should > be addresses in the next revision, if any. > > Margaret > > > SUBSTANTIVE ISSUES: > > (1) This draft doesn't mention the reverse DNS tree. Is it expected > that whatever registry assigns these values will also populate the > reverse DNS tree? Or not? Given the follow-on discussion of this point, how about the following replacement text for section 7.0: AAAA records (both forward and reverse) for Local IPv6 addresses are not expected to be installed in the global DNS because they are intended to be used for local communication inside of a site. They may be installed in the global DNS since they are unique and will not create confusion. They may not be reachable, but that is a property common to all types of global IPv6 unicast addresses. > > (2) The document says: > >> Global IDs should be assigned centrally by a single allocation >> authority because they are pseudo-random and without any structure. >> This is easiest to accomplish if there is a single source for the >> assignments. > How about the following replacement for the above text (courtesy of Brian C.)? Global IDs should be assigned under the authority of a single allocation organization because they are pseudo-random and without any structure. This is easiest to accomplish if there is a single authority for the assignments. > > This would appear to be incompatible with the IANA considerations > section that says: > >> If deemed >> appropriate, the authority may also consist of multiple organizations >> performing the authority duties. > > > To avoid a situation where a single entity can request a large number > of local prefixes and aggregate them, it isn't strictly necessary that > the addresses be allocated from a single pool. If there were several > pools (for different geographical regions, for example) random > allocations from one of those pools would achieve the same result. > > (3) The document also says: > >> The requirements for centrally assigned global ID allocations are: >> >> - Available to anyone in an unbiased manner. >> - Permanent with no periodic fees. > > > It seems strange to say that there can be no periodic fees when the > document doesn't mention fees anywhere else... Perhaps this is a > leftover from previous versions of the document that did include a fee > structure? The purpose of the second bullet is to ensure the permanent allocation of these prefixes. Periodic fees are inconsistent with permanent allocations (e.g., what happens if someone were to stop paying the periodic fee?, would the allocation be revoked and reassigned?). In addition, there is precedence for one-time, upfront fees such as this. The IEEE mechanism for MAC addresses comes immediately to mind as a similar model. > >> - Allocation on a permanent basis, without any need for renewal >> and without any procedure for de-allocation. >> - Provide mechanisms that prevent hoarding of these allocations. >> - The ownership of each individual allocation should be private, >> but should be escrowed. > > > I am not sure that requiring a permanent escrow is consistent with the > idea that there will be no ongoing revenue stream (i.e. periodic fees) > associated with an address. The escrow is to simply ensure no duplication and allow for conflict resolution. As described above the cost for maintaining an escrow can be paid for with an charge at the time of the allocation. > > (4) The algorithm for random number generation is: > >> 3.2.3 Sample Code for Pseudo-Random Global ID Algorithm >> >> The algorithm described below is intended to be used for centrally >> and locally assigned Global IDs. In each case the resulting global >> ID will be used in the appropriate prefix as defined in section 3.2. >> >> 1) Obtain the current time of day in 64-bit NTP format [NTP]. >> 2) Obtain an EUI-64 identifier from the system running this >> algorithm. If an EUI-64 does not exist, one can be created from >> a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 >> cannot be obtained or created, a suitably unique identifier, >> local to the node, should be used (e.g. system serial number). >> 3) Concatenate the time of day with the system-specific identifier >> creating a key. >> 4) Compute an MD5 digest on the key as specified in [MD5DIG]. >> 5) Use the least significant 40 bits as the Global ID. >> >> This algorithm will result in a global ID that is reasonably unique >> and can be used as a Global ID. > > > Are you intending that centrally assigned addresses will all be > generated using the EUI-64 address of a server at the centralized > registration authority? What affect would this have on the randomness > of these allocations, and does that matter? They can use the same machine with the same EUI-64 since the MD5 hash will sufficiently randomize the bits given the second input of a time stamp. However, for the centrally allocated range, we plan to add a step #6 that calls for the newly generated prefix to be tested for duplicity within the escrow of existing prefixes. > > EDITORIAL COMMENTS > >> - Allows sites to be combined or privately interconnected without >> creating any address conflicts or require renumbering of >> interfaces using these prefixes. > > > s/require/requiring Sure. > >> Site border routers and firewalls should not forward any packets with >> Local IPv6 source or destination addresses outside of the site unless >> they have been explicitly configured with routing information about >> other Local IPv6 prefixes. > > > s/other// ?? Yes. > >> 14.1 Normative References > > > Did you really manage to get through this entire document without > requiring any reference (normative or informative) to the Scoped > Address Architecture? I seem to recall some mention of link-local > addresses, for example. > > There is no dependency on the Scoped Addressing Architecture in the ULA spec. Regards, Bob & Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 8 19:12:57 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 TAA06424 for ; Thu, 8 Apr 2004 19:12: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 1BBihC-0004EZ-9O for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 19:12:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38NCU8v016271 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 19:12:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBihC-0004EM-4r for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 19:12: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 TAA06347 for ; Thu, 8 Apr 2004 19:12:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBihA-0002Kd-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 19:12:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiBV-0006lJ-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 18:39:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBgG6-000067-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 16:36:23 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBgAh-00033s-Kn for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 16:30:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBg1V-0001HD-5s; Thu, 08 Apr 2004 16:21:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBg0j-0000Nr-W5 for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 16:20:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18462; Thu, 8 Apr 2004 16:20:27 -0400 (EDT) Message-Id: <200404082020.QAA18462@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-rfc2011-update-08.txt Date: Thu, 08 Apr 2004 16:20:27 -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 : Management Information Base for the Internet Protocol (IP) Author(s) : S. Routhier Filename : draft-ietf-ipv6-rfc2011-update-08.txt Pages : 134 Date : 2004-4-8 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465 and 2466. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-08.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-rfc2011-update-08.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-rfc2011-update-08.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-4-8164335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2011-update-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2011-update-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-8164335.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 Apr 8 20:06:50 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 UAA13555 for ; Thu, 8 Apr 2004 20:06: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 1BBjXJ-00012Y-4V for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 20:06:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3906LSp003994 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 20:06:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjXI-00012G-Ko for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20:06: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 UAA13413 for ; Thu, 8 Apr 2004 20:06:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjXG-0000rP-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 20:06:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBihX-0002PB-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 19:12:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBiGr-0007Ew-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 18:45:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiGc-0008Pf-3Y; Thu, 08 Apr 2004 18: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 1BBiFh-0008NP-P2 for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 18:44: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 SAA04060 for ; Thu, 8 Apr 2004 18:44:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiFd-00079T-00 for ipv6@ietf.org; Thu, 08 Apr 2004 18:44:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBgJj-0000lb-00 for ipv6@ietf.org; Thu, 08 Apr 2004 16:40:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBdXY-0004sP-00 for ipv6@ietf.org; Thu, 08 Apr 2004 13:42:12 -0400 Received: from thrintun.hactrn.net ([66.92.66.67]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBdIV-000148-FK for ipv6@ietf.org; Thu, 08 Apr 2004 13:26:39 -0400 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D6A1018F1 for ; Thu, 8 Apr 2004 13:26:00 -0400 (EDT) Date: Thu, 08 Apr 2004 13:26:00 -0400 From: Rob Austein To: ipv6@ietf.org Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt In-Reply-To: <407538D1.1070803@innovationslab.net> References: <407538D1.1070803@innovationslab.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040408172600.D6A1018F1@thrintun.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.0 required=5.0 tests=none autolearn=no version=2.60 At Thu, 08 Apr 2004 07:34:41 -0400, Brian Haberman wrote: > > Given the follow-on discussion of this point, how about the following > replacement text for section 7.0: > > AAAA records (both forward and reverse) for Local IPv6 addresses > are not expected to be installed in the global DNS because they are > intended to be used for local communication inside of a site. They > may be installed in the global DNS since they are unique and will > not create confusion. They may not be reachable, but that is a > property common to all types of global IPv6 unicast addresses. Er, one does not generally install AAAA RRs in the reverse tree. AAAA RRs in the forward tree, PTR RRs in the IP6.ARPA reverse tree. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 8 20:07: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 UAA13724 for ; Thu, 8 Apr 2004 20:07: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 1BBjXk-00015l-DJ for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 20:06:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3906mg6004192 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 20:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjXj-00015R-Vn for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20: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 UAA13531 for ; Thu, 8 Apr 2004 20:06:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjXh-0000wy-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 20:06:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBihv-0002Tm-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 19:13:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBiNU-00008i-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 18:52:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiNO-0001u5-3U; Thu, 08 Apr 2004 18: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 1BBiMs-0001sX-9c for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 18:51: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 SAA04749 for ; Thu, 8 Apr 2004 18:51:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiMo-00005l-00 for ipv6@ietf.org; Thu, 08 Apr 2004 18:51:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBgWH-0002Mt-00 for ipv6@ietf.org; Thu, 08 Apr 2004 16:53:07 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BBdt1-0007E2-00 for ipv6@ietf.org; Thu, 08 Apr 2004 14:04:23 -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 i38I3i6N004388; Thu, 8 Apr 2004 11:03:44 -0700 (PDT) Received: from bobo (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 i38I3fQ25638; Thu, 8 Apr 2004 20:03:42 +0200 (MEST) Date: Thu, 8 Apr 2004 11:03:41 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: rfc2462bis: new section 5.7 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= 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 > Okay, so how about revising section 5.7 as follows? In this proposal, > we still have the new section, but I tried to limit the description to > warnings based on experiences of existing implementations. > > 5.7 Retaining Configured Addresses for Stability > > An implementation that has stable storage may want to retain > addresses in the storage when the addresses were acquired using > stateless address autoconfiguration. Assuming the lifetimes used are > reasonable, this technique implies that a temporary outage (less than > the valid lifetime) of a router will never result in the node losing > its global address even if the node were to reboot. When this > technique is used, it should also be noted that the expiration times > of the preferred and valid lifetimes should be retained, instead of > or in addition to the lifetimes themselves, in order to avoid > unexpected lifetime expiration during the boot period. The last part sounds like one need to make sure the address lives long enough; my concern is about it living for too long. So I'd reword the last sentence to say: When this technique is used, it should also be noted that the expiration times of the preferred and valid lifetimes must be retained, in order to prevent usage of an address after it has become invalid. > Further details on this kind of extension are beyond the scope of > this 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 Thu Apr 8 20:07: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 UAA13786 for ; Thu, 8 Apr 2004 20:07: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 1BBjXX-00013j-CA for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 20:07:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3906Z3G004067 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 20:06:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjXW-00013W-Nc for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20:06: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 UAA13481 for ; Thu, 8 Apr 2004 20:06:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjXU-0000uQ-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 20:06:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBihi-0002RO-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 19:13:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBiHa-0007IO-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 18:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiHb-0000C0-Db; Thu, 08 Apr 2004 18:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiH9-00009U-1Z for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 18:45: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 SAA04202 for ; Thu, 8 Apr 2004 18:45:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiH5-0007GJ-00 for ipv6@ietf.org; Thu, 08 Apr 2004 18:45:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBgML-00017Z-00 for ipv6@ietf.org; Thu, 08 Apr 2004 16:42:52 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BBda8-0005GJ-00 for ipv6@ietf.org; Thu, 08 Apr 2004 13:44:52 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 13:44:06 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Date: Thu, 8 Apr 2004 13:44:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Thread-Index: AcQdieKvC9kUQ2UJTQqDW3sn17zmmwABSOFQ From: "Soliman Hesham" To: "Brian Haberman" , "Margaret Wasserman" , X-OriginalArrivalTime: 08 Apr 2004 17:44:06.0095 (UTC) FILETIME=[16AA75F0:01C41D91] 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 Hi Brian,=20 One question/comment below: > > (1) This draft doesn't mention the reverse DNS tree. Is=20 > it expected > > that whatever registry assigns these values will also=20 > populate the > > reverse DNS tree? Or not? >=20 > Given the follow-on discussion of this point, how about the following > replacement text for section 7.0: >=20 > AAAA records (both forward and reverse) for Local IPv6=20 > addresses > are not expected to be installed in the global DNS=20 > because they are > intended to be used for local communication inside of=20 > a site. They > may be installed in the global DNS since they are=20 > unique and will > not create confusion. They may not be reachable, but that is a > property common to all types of global IPv6 unicast addresses. =3D> I wonder whether it is a good idea to put these addresses in the global DNS at all. My understanding of having addresses in the global DNS is that the AAAA records essentially announce that such addresses are globally reachable (with the exception of routing failure). However, in the case of local addresses this is a bit of false advertising. So shouldn't we recommend that such addresses are not to be advertised in the global DNS? Otherwise, why are they called "local addresses"?=20 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 Apr 8 20:07:48 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 UAA13820 for ; Thu, 8 Apr 2004 20:07: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 1BBjXb-00014g-7C for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 20:07:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3906dHY004125 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 20:06:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjXb-00014Q-0D for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20:06: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 UAA13501 for ; Thu, 8 Apr 2004 20:06:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjXZ-0000vH-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 20:06:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBihn-0002SN-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 19:13:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBiKZ-0007ca-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 18:49:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiKT-000153-EX; Thu, 08 Apr 2004 18: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 1BBiJU-0000q0-F9 for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 18:48: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 SAA04472 for ; Thu, 8 Apr 2004 18:47:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiJQ-0007SB-00 for ipv6@ietf.org; Thu, 08 Apr 2004 18:47:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBgRd-0001ov-00 for ipv6@ietf.org; Thu, 08 Apr 2004 16:48:18 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1BBdl9-0006RK-00 for ipv6@ietf.org; Thu, 08 Apr 2004 13:56:15 -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 i38HthL04793; Thu, 8 Apr 2004 10:55:43 -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 i38IAXQP013037 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 8 Apr 2004 11:10:46 -0700 Message-ID: <40759205.9060803@innovationslab.net> Date: Thu, 08 Apr 2004 13:55:17 -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: Soliman Hesham CC: Margaret Wasserman , ipv6@ietf.org Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hesham, Soliman Hesham wrote: > Hi Brian, > > One question/comment below: > > > > (1) This draft doesn't mention the reverse DNS tree. Is > > it expected > > > that whatever registry assigns these values will also > > populate the > > > reverse DNS tree? Or not? > > > > Given the follow-on discussion of this point, how about the following > > replacement text for section 7.0: > > > > AAAA records (both forward and reverse) for Local IPv6 > > addresses > > are not expected to be installed in the global DNS > > because they are > > intended to be used for local communication inside of > > a site. They > > may be installed in the global DNS since they are > > unique and will > > not create confusion. They may not be reachable, but that is a > > property common to all types of global IPv6 unicast addresses. > > => I wonder whether it is a good idea to put these addresses > in the global DNS at all. My understanding of having addresses > in the global DNS is that the AAAA records essentially announce > that such addresses are globally reachable (with the exception > of routing failure). However, in the case of local addresses > this is a bit of false advertising. So shouldn't > we recommend that such addresses are not to be advertised in the global > DNS? Otherwise, why are they called "local addresses"? That is why it is stated as "are not expected to be in the global DNS". There will be issues caused by them being advertised yet not reachable. Would you rather see a stronger statement against inclusion in the global DNS? My personal opinion is that they should never be in the global DNS, but that didn't seem to be the consensus of the WG. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 8 20:07:52 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 UAA13871 for ; Thu, 8 Apr 2004 20:07: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 1BBjXf-00015F-BV for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 20:07:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3906h4k004161 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 20:06:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjXf-000152-7Z for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20:06: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 UAA13515 for ; Thu, 8 Apr 2004 20:06:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjXd-0000wA-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 20:06:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBihs-0002T2-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 19:13:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBiLW-0007j8-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 18:50:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiLS-0001UO-I4; Thu, 08 Apr 2004 18: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 1BBiKk-0001JD-O5 for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 18:49: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 SAA04566 for ; Thu, 8 Apr 2004 18:49:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiKh-0007d3-00 for ipv6@ietf.org; Thu, 08 Apr 2004 18:49:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBgTb-00023U-00 for ipv6@ietf.org; Thu, 08 Apr 2004 16:50: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 1BBdpO-0006qh-00 for ipv6@ietf.org; Thu, 08 Apr 2004 14:00:38 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 14:00:06 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Date: Thu, 8 Apr 2004 14:00:06 -0400 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Thread-Index: AcQdks0HBH40TdfwSIm3gdhExVECCwAARCWg From: "Soliman Hesham" To: "Brian Haberman" CC: "Margaret Wasserman" , X-OriginalArrivalTime: 08 Apr 2004 18:00:06.0829 (UTC) FILETIME=[534ED5D0:01C41D93] 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 > That is why it is stated as "are not expected to be in the=20 > global DNS". > There will be issues caused by them being advertised yet not=20 > reachable. > Would you rather see a stronger statement against inclusion in the > global DNS? =3D> I think this makes sense. Something like "SHOULD NOT". >=20 > My personal opinion is that they should never be in the=20 > global DNS,=20 =3D> Agreed. but > that didn't seem to be the consensus of the WG. =3D> At least you and I agree FWIW :)=20 Perhaps I missed this discussion, but I can't see=20 why they should be put in the global DNS. Unless people are trying to prove that these local addresses don't require a two face DNS. It's a lost cause I think ;) 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 Apr 8 21:06:55 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 VAA18599 for ; Thu, 8 Apr 2004 21:06: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 1BBkTS-0001e1-J7 for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 21:06:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3916Qwm006317 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 21:06:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkTR-0001dk-QT for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:06: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 VAA18531 for ; Thu, 8 Apr 2004 21:06:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkTP-00003A-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 21:06:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkDv-0005V3-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 20:50:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBjqz-0002l7-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 20:26:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjpw-0002yO-Pw; Thu, 08 Apr 2004 20:25:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiz2-0005sf-43 for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 19:30: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 TAA08751 for ; Thu, 8 Apr 2004 19:30:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiz0-0004vK-00 for ipv6@ietf.org; Thu, 08 Apr 2004 19:30:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhrk-0004Tx-00 for ipv6@ietf.org; Thu, 08 Apr 2004 18:19:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBfql-0003BT-00 for ipv6@ietf.org; Thu, 08 Apr 2004 16:10:11 -0400 Received: from netcore.fi ([193.94.160.1]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBf90-0002MG-Du for ipv6@ietf.org; Thu, 08 Apr 2004 15:24:58 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i38JOjE04567; Thu, 8 Apr 2004 22:24:45 +0300 Date: Thu, 8 Apr 2004 22:24:45 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: ipv6@ietf.org Subject: Re: ND-proxy applicability and loop-prevention 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 Replying to an old message.. On Mon, 29 Mar 2004, Erik Nordmark wrote: > > The problem is that with the same trouble it takes to fully delegate a > > /64, the ISP could do a /48 as well. That is a good thing also, of > > course. My worry is that the ISPs end up doing nothing unless they > > have simple enough means available. > > My worry is that ISPs would end up doing nothing because of the existance > of nd proxy. Why would they do nothing? Do you mean that they just advertise /64 on the link and tell their customers, "just use ND-proxy, we don't bother with prefix delegation"? The ISPs would actually do something, though: they'd provide an advertised /64. One could wish for PD, but if that wouldn't happen.... Or did you mean that the ISPs would do nothing because they could no longer trust (to an extent) that the /64 they'd advertise on the P-t-P link would be used by one node only, and then would not offer any IPv6 service at all? > > I mean, the message could also be "just give every customer a > > delegated /48. If that is not possible, advertising a /64 on the link > > is better than nothing." > > Yes, but that requires a non-robust against loops nd-proxy complexity > to be added to the architecture. > In the big picture this is a distraction and not a help. As said, I don't think we absolutely need loop-free properties. We disagree on the deployment scenarios, I think. But as discussed, rather light-weight loop detection mechanism could be added with relative ease: e.g., an ND option that would be added to identify the proxy (would increase the ND message size though == bad). Another option that hasn't been explicitly mentioned which I just thought of could be reusing ND code. The ND proxy would send a NS message for an RFC3041 randomized address out on all its interfaces, and wait for a short period of time. If the same NS probe is heard back from any other interface, there is a reason to believe there is a loop somewhere. (This assumes that in this very short time frame, nobody else would be NS'ing specifically that address.) -- 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 Thu Apr 8 21:17:20 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 VAA19894 for ; Thu, 8 Apr 2004 21:17: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 1BBkdY-0003M3-I8 for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 21:16:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i391Gqvr012891 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 21:16:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkdY-0003Lq-Ch for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:16: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 VAA19807 for ; Thu, 8 Apr 2004 21:16:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkdV-0000sc-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 21:16:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkLF-0006zk-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 20:57:58 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBk7S-0004PD-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 20:43:42 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBjtc-0005I6-EF for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 20:29:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjtP-00055m-8z; Thu, 08 Apr 2004 20:29:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjRo-0000ZV-Kj for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 20:00: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 UAA12555 for ; Thu, 8 Apr 2004 20:00:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjRl-00007Y-00 for ipv6@ietf.org; Thu, 08 Apr 2004 20:00:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiVd-0001Ly-00 for ipv6@ietf.org; Thu, 08 Apr 2004 19:00:34 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBh07-0005Sc-00 for ipv6@ietf.org; Thu, 08 Apr 2004 17:23:55 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i38LNMN06639 for ; Fri, 9 Apr 2004 00:23:22 +0300 Date: Fri, 9 Apr 2004 00:23:22 +0300 (EEST) From: Pekka Savola To: ipv6@ietf.org Subject: Revising PMTUD for IPv6 to DS? 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 Hi, If draft-ietf-v6ops-mech-v2-02.txt was recycled to Draft Standard, there would be a block as it depends of Path MTU Discovery for IPv6, which is Proposed Standard. (FWIW, PMTUD for v4 is DS.) Are there any plans to revise PMTUD for v6? Arguably, the mechanism could be better, but there are plenty of implementations out there, so moving it to DS would seem justified. It would seem to make sense to work on this as PMTUD is integral to the operation of v6 as there is no on-the-fly fragmentation. -- 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 Thu Apr 8 22:02:50 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 WAA22251 for ; Thu, 8 Apr 2004 22:02: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 1BBlLb-0007x7-8p for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 22:02:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3922NSP030565 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 22:02:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlLZ-0007wu-Dw for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 22:02: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 WAA22229 for ; Thu, 8 Apr 2004 22:02:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBlLU-00047i-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 22:02:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBlHN-0003oL-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 21:58:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBlCs-0003WO-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 21:53:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlCY-0006Ij-9y; Thu, 08 Apr 2004 21: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 1BBlBk-0006H1-Ro for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 21:52: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 VAA21830 for ; Thu, 8 Apr 2004 21:52:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBlBg-0003Qw-00 for ipv6@ietf.org; Thu, 08 Apr 2004 21:52:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBl56-00030h-00 for ipv6@ietf.org; Thu, 08 Apr 2004 21:45:20 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BBkxd-0002RA-00 for ipv6@ietf.org; Thu, 08 Apr 2004 21:37:37 -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 i391at6N022758; Thu, 8 Apr 2004 18:36:56 -0700 (PDT) Received: from bobo (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 i391arQ20261; Fri, 9 Apr 2004 03:36:53 +0200 (MEST) Date: Thu, 8 Apr 2004 18:36:52 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND-proxy applicability and loop-prevention To: Pekka Savola 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 > Why would they do nothing? Do you mean that they just advertise /64 > on the link and tell their customers, "just use ND-proxy, we don't > bother with prefix delegation"? > > The ISPs would actually do something, though: they'd provide an > advertised /64. One could wish for PD, but if that wouldn't > happen.... Let's take you logic and apply it to something else to show that the logic leads to suboptimal results: One could wish for IPv6, but if that wouldn't happen ... Such a logic would lead to further discord which I don't think serves the IETF or the users of the standards that the IETF produces. The stated direction (which I think has WG rough consensus) is to use "prefix delegation" when delegating prefixes and the protocol for doing so that is defined is DHCPv6 prefix delegation. So instead of grumbling how broken this is and proposing half-measures like ND-proxy as an alternative, why can't we use the energy on making it better; implementing DHCPv6 PD, testing it, writing informational documents urging implementors to create admin interfaces that hides the complexity, implementation guides, operational experience documents, etc? > Another option that hasn't been explicitly mentioned which I just > thought of could be reusing ND code. The ND proxy would send a NS > message for an RFC3041 randomized address out on all its interfaces, > and wait for a short period of time. If the same NS probe is heard > back from any other interface, there is a reason to believe there is a > loop somewhere. (This assumes that in this very short time frame, > nobody else would be NS'ing specifically that address.) Put N of those boxes in a house, connect them in a loop, and turn of the power at the circuit breaker. When you power on they will first not forward frames (since if they did the detection doesn't prevent the loop) hence the loop detection will not detect the loop that is there, and then they will all enable forwarding of frames. I think you will step by step end up implementing something which is close to the complexity of IEEE Spanning Tree Protocol if you want this to be robust. 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 Apr 8 22:09:22 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 WAA22543 for ; Thu, 8 Apr 2004 22:09: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 1BBlRu-0000Cs-Bx for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 22:08:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3928sIY000790 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 22:08:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlRu-0000Cf-7E for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 22:08: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 WAA22503 for ; Thu, 8 Apr 2004 22:08:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBlRq-0004Z1-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 22:08:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBlOt-0004JG-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 22:05:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBlKZ-00042r-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 22:01:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlKJ-0007Xc-AU; Thu, 08 Apr 2004 22:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlJv-0007RY-TI for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 22:00: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 WAA22128 for ; Thu, 8 Apr 2004 22:00:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBlJs-0003ya-00 for ipv6@ietf.org; Thu, 08 Apr 2004 22:00:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBlFT-0003eo-00 for ipv6@ietf.org; Thu, 08 Apr 2004 21:56:04 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BBl9R-0003J2-00 for ipv6@ietf.org; Thu, 08 Apr 2004 21:49:49 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:7c9e:5c3c:7e08:4662]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 15ED915214; Fri, 9 Apr 2004 10:49:36 +0900 (JST) Date: Fri, 09 Apr 2004 10:49:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman Hesham" Cc: "Brian Haberman" , "Margaret Wasserman" , Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt 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, 8 Apr 2004 14:00:06 -0400, >>>>> "Soliman Hesham" said: > but >> that didn't seem to be the consensus of the WG. > => At least you and I agree FWIW :) > Perhaps I missed this discussion, but I can't see > why they should be put in the global DNS. Unless > people are trying to prove that these local addresses > don't require a two face DNS. It's a lost cause I think ;) As Rob pointed out, we should first clarify whether we are talking about the forward tree (using AAAA) or the reverse tree (using PTR RR with nibble + ip6.arpa labels). The reachability issue Hesham said in his first response is basically only related to the forward tree. In addition to this, I'd also like to note that draft-ietf-dnsop-ipv6-dns-issues-04.txt recommends limited-scope addresses not be in the global DNS: 2.1 Limited-scope Addresses The IPv6 addressing architecture [5] includes two kinds of local-use addresses: link-local (fe80::/10) and site-local (fec0::/10). The site-local addresses are being deprecated [7], and are only discussed in Appendix A. Link-local addresses should never be published in DNS, because they have only local (to the connected link) significance [8]. (Hmm, it's not clear if this talks about the forward tree only, the reverse tree only, or both...perhaps "both" is the intention). 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 Apr 8 22:39:37 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 WAA23434 for ; Thu, 8 Apr 2004 22:39:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlvA-00034e-GP for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 22:39:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i392d82w011812 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 22:39:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlvA-00034R-Al for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 22:39: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 WAA23421 for ; Thu, 8 Apr 2004 22:39:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBlv5-0006Rm-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 22:39:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBlu1-0006MX-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 22:37:58 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBlsR-0006Fc-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 22:36: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 1BBlsN-00023d-DT for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 22:36:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlsA-000234-7n; Thu, 08 Apr 2004 22:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlrd-0001zp-Oh for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 22:35: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 WAA23309 for ; Thu, 8 Apr 2004 22:35:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBlrZ-0006AR-00 for ipv6@ietf.org; Thu, 08 Apr 2004 22:35:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBlqH-00063Z-00 for ipv6@ietf.org; Thu, 08 Apr 2004 22:34:05 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BBlns-0005xc-00 for ipv6@ietf.org; Thu, 08 Apr 2004 22:31:36 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:7c9e:5c3c:7e08:4662]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 560911521B; Fri, 9 Apr 2004 11:31:33 +0900 (JST) Date: Fri, 09 Apr 2004 11:31:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipv6@ietf.org Subject: Re: rfc2462bis: new section 5.7 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, 8 Apr 2004 11:03:41 -0700 (PDT), >>>>> Erik Nordmark said: >> 5.7 Retaining Configured Addresses for Stability >> >> An implementation that has stable storage may want to retain >> addresses in the storage when the addresses were acquired using >> stateless address autoconfiguration. Assuming the lifetimes used are >> reasonable, this technique implies that a temporary outage (less than >> the valid lifetime) of a router will never result in the node losing >> its global address even if the node were to reboot. When this >> technique is used, it should also be noted that the expiration times >> of the preferred and valid lifetimes should be retained, instead of >> or in addition to the lifetimes themselves, in order to avoid >> unexpected lifetime expiration during the boot period. > The last part sounds like one need to make sure the address lives > long enough; my concern is about it living for too long. > So I'd reword the last sentence to say: > When this > technique is used, it should also be noted that the expiration times > of the preferred and valid lifetimes must be retained, in order to > prevent usage of an address after it has become invalid. Thanks for the suggestion. I'll use the reworded text then. 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 Apr 8 23:00:38 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 XAA24145 for ; Thu, 8 Apr 2004 23:00: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 1BBmFX-0005Fy-F1 for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 23:00:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3930Aw8020202 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 23:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBmFV-0005Fk-Hm for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 23:00: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 XAA24113 for ; Thu, 8 Apr 2004 23:00:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBmFR-0007j5-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 23:00:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBmDi-0007b2-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 22:58:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBmD6-0007Wf-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 22:57:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBmCV-0004Ud-4w; Thu, 08 Apr 2004 22: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 1BBmBp-0004TX-Ot for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 22:56: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 WAA23975 for ; Thu, 8 Apr 2004 22:56:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBmBl-0007Rr-00 for ipv6@ietf.org; Thu, 08 Apr 2004 22:56:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBmAn-0007O1-00 for ipv6@ietf.org; Thu, 08 Apr 2004 22:55:18 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBm95-0007HN-00 for ipv6@ietf.org; Thu, 08 Apr 2004 22:53:31 -0400 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1BBm8x-0000Uc-3V for ipv6@ietf.org; Fri, 09 Apr 2004 02:53:23 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #271 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 #271] Using stable storage for autoconfigured addresses In-Reply-To: Managed-BY: RT 3.0.9 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Fri, 09 Apr 2004 02:53:23 +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=AWL,NO_REAL_NAME autolearn=no version=2.60 Proposed Resolution: revise section 5.7 as follows. 5.7 Retaining Configured Addresses for Stability An implementation that has stable storage may want to retain addresses in the storage when the addresses were acquired using stateless address autoconfiguration. Assuming the lifetimes used are reasonable, this technique implies that a temporary outage (less than the valid lifetime) of a router will never result in the node losing its global address even if the node were to reboot. When this technique is used, it should also be noted that the expiration times of the preferred and valid lifetimes must be retained, in order to prevent the use of an address after it has become deprecated or invalid. Further details on this kind of extension are beyond the scope of this document. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 8 23:00:39 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 XAA24162 for ; Thu, 8 Apr 2004 23:00: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 1BBmFZ-0005GG-2i for ipv6-archive@odin.ietf.org; Thu, 08 Apr 2004 23:00:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3930CS9020220 for ipv6-archive@odin.ietf.org; Thu, 8 Apr 2004 23:00:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBmFX-0005G1-V4 for ipv6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 23:00: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 XAA24124 for ; Thu, 8 Apr 2004 23:00:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBmFT-0007jF-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 23:00:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBmDj-0007bA-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 22:58:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBmD6-0007Wg-00 for ipv6-web-archive@ietf.org; Thu, 08 Apr 2004 22:57:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBmCU-0004UR-0M; Thu, 08 Apr 2004 22: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 1BBmBl-0004TS-HD for ipv6@optimus.ietf.org; Thu, 08 Apr 2004 22:56: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 WAA23972 for ; Thu, 8 Apr 2004 22:56:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBmBg-0007Rk-00 for ipv6@ietf.org; Thu, 08 Apr 2004 22:56:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBmAn-0007Nt-00 for ipv6@ietf.org; Thu, 08 Apr 2004 22:55:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBm95-0007HL-00 for ipv6@ietf.org; Thu, 08 Apr 2004 22:53:31 -0400 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1BBm8w-0000U8-9P for ipv6@ietf.org; Fri, 09 Apr 2004 02:53:22 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #271 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 #271] Using stable storage for autoconfigured addresses In-Reply-To: Managed-BY: RT 3.0.9 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Fri, 09 Apr 2004 02:53:22 +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=AWL,NO_REAL_NAME autolearn=no version=2.60 Proposed Resolution: revise section 5.7 as follows. 5.7 Retaining Configured Addresses for Stability An implementation that has stable storage may want to retain addresses in the storage when the addresses were acquired using stateless address autoconfiguration. Assuming the lifetimes used are reasonable, this technique implies that a temporary outage (less than the valid lifetime) of a router will never result in the node losing its global address even if the node were to reboot. When this technique is used, it should also be noted that the expiration times of the preferred and valid lifetimes must be retained, in order to prevent the use of an address after it has become deprecated or invalid. Further details on this kind of extension are beyond the scope of this document. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 9 01:18: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 BAA28063 for ; Fri, 9 Apr 2004 01: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 1BBoPA-0007vQ-E1 for ipv6-archive@odin.ietf.org; Fri, 09 Apr 2004 01:18:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i395IG8Z030460 for ipv6-archive@odin.ietf.org; Fri, 9 Apr 2004 01: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 1BBoPA-0007vD-8v for ipv6-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 01:18: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 BAA28003 for ; Fri, 9 Apr 2004 01:18:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBoP7-0000a9-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 01:18:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBoNs-0000QU-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 01:16:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBoLK-0000EQ-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 01:14:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBoL4-0007TW-7E; Fri, 09 Apr 2004 01:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBoKh-0007Sf-4E for ipv6@optimus.ietf.org; Fri, 09 Apr 2004 01:13: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 BAA27781 for ; Fri, 9 Apr 2004 01:13:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBoKd-00008n-00 for ipv6@ietf.org; Fri, 09 Apr 2004 01:13:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBoIc-0007nC-00 for ipv6@ietf.org; Fri, 09 Apr 2004 01:11:31 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBoGu-0007be-00 for ipv6@ietf.org; Fri, 09 Apr 2004 01:09:44 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3958n512999; Fri, 9 Apr 2004 08:08:49 +0300 Date: Fri, 9 Apr 2004 08:08:49 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Soliman Hesham , Brian Haberman , Margaret Wasserman , Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt In-Reply-To: Message-ID: MIME-Version: 1.0 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.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 9 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > In addition to this, I'd also like to note that > draft-ietf-dnsop-ipv6-dns-issues-04.txt recommends limited-scope > addresses not be in the global DNS: > > 2.1 Limited-scope Addresses > > The IPv6 addressing architecture [5] includes two kinds of local-use > addresses: link-local (fe80::/10) and site-local (fec0::/10). The > site-local addresses are being deprecated [7], and are only discussed > in Appendix A. > > Link-local addresses should never be published in DNS, because they > have only local (to the connected link) significance [8]. > > (Hmm, it's not clear if this talks about the forward tree only, the > reverse tree only, or both...perhaps "both" is the intention). (note: I'm acting as an editor of that particular document, so suggestions are welcome.) Ack. Yes, it applies to both. Note that the latter paragraph intentionally excludes the discussion of other kinds of limited-scope addresses from discussion, i.e., it only mentions why adding link-locals is bad. The discussion of site-locals is deferred to an appendix. The relevant text from there is: To actually use site-local addresses within a site, this implies the deployment of a "split-faced" or a fragmented DNS name space, for the zones internal to the site, and the outsiders' view to it. The procedures to achieve this are not elaborated here. The implication is that site-local addresses must not be published in the public DNS. To faciliate reverse DNS (if desired) with site-local addresses, the stub resolvers must look for DNS information from the local DNS servers, not e.g. starting from the root servers, so that the site-local information may be provided locally. Note that the experience private addresses in IPv4 has shown that the root servers get loaded for requests for private address lookups in any. (FWIW, the document just passed dnsop WGLC, and is being revised, so if others have issues with this, feel free to shoot them.) Would it make sense to also include the discussion of these new unique local addresses? I've hesitated to do so, because they've been a moving target, and I'd like to avoid adding anything there which could become invalid if the document is changed prior to IESG approval. -- 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 Fri Apr 9 01:24:53 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 BAA28360 for ; Fri, 9 Apr 2004 01: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 1BBoV5-0000fH-TK for ipv6-archive@odin.ietf.org; Fri, 09 Apr 2004 01:24:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i395ONOU002551 for ipv6-archive@odin.ietf.org; Fri, 9 Apr 2004 01:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBoV5-0000f4-Oe for ipv6-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 01:24: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 BAA28339 for ; Fri, 9 Apr 2004 01:24:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBoV2-00016p-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 01:24:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBoS6-0000vD-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 01:21:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBoPx-0000he-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 01:19:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBoPu-00080R-1q; Fri, 09 Apr 2004 01: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 1BBoPW-0007yw-RA for ipv6@optimus.ietf.org; Fri, 09 Apr 2004 01:18: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 BAA28034 for ; Fri, 9 Apr 2004 01:18:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBoPT-0000cD-00 for ipv6@ietf.org; Fri, 09 Apr 2004 01:18:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBoOg-0000Tl-00 for ipv6@ietf.org; Fri, 09 Apr 2004 01:17:46 -0400 Received: from mx.uom.ac.mu ([202.60.7.12]) by ietf-mx with esmtp (Exim 4.12) id 1BBoMj-0000In-00 for ipv6@ietf.org; Fri, 09 Apr 2004 01:15:45 -0400 Received: from localhost ([]) by mx.uom.ac.mu (Merak 7.2.0) with SMTP id DWA74278 for ; Fri, 09 Apr 2004 09:15:09 +0400 Date: Fri, 09 Apr 2004 09:15:09 +0400 From: Boodhoo Avinash To: ipv6@ietf.org Subject: routing problems in IPv6 Message-ID: X-Mailer: IceWarp Web Mail 5.2.2 X-Originating-IP: 172.22.28.36 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think that the routing problems in IPv6 has been resolved. Any comments? Mr Avinash Researcher in 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 Apr 9 01:34:20 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 BAA28726 for ; Fri, 9 Apr 2004 01:34: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 1BBoeE-0001Fu-Jp for ipv6-archive@odin.ietf.org; Fri, 09 Apr 2004 01:33:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i395XoAr004817 for ipv6-archive@odin.ietf.org; Fri, 9 Apr 2004 01: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 1BBoeE-0001FI-FK for ipv6-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 01:33: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 BAA28710 for ; Fri, 9 Apr 2004 01:33:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBoeA-0001iL-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 01:33:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBoZh-0001TQ-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 01:29:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBoWr-0001FM-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 01:26:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBoWg-0000hM-Se; Fri, 09 Apr 2004 01: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 1BBoW6-0000gN-Qq for ipv6@optimus.ietf.org; Fri, 09 Apr 2004 01:25: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 BAA28382 for ; Fri, 9 Apr 2004 01:25:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBoW0-0001AB-00 for ipv6@ietf.org; Fri, 09 Apr 2004 01:25:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBoSL-0000x2-00 for ipv6@ietf.org; Fri, 09 Apr 2004 01:21:34 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1BBoQc-0000jF-00 for ipv6@ietf.org; Fri, 09 Apr 2004 01:19:46 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id BAA16640; Fri, 9 Apr 2004 01:19:32 -0400 (EDT) Date: Fri, 9 Apr 2004 01:19:32 -0400 (EDT) From: Dan Lanciani Message-Id: <200404090519.BAA16640@ss10.danlan.com> To: ipv6@ietf.org Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.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.4 required=5.0 tests=AWL autolearn=no version=2.60 "Soliman Hesham" wrote: | > That is why it is stated as "are not expected to be in the | > global DNS". | > There will be issues caused by them being advertised yet not | > reachable. | > Would you rather see a stronger statement against inclusion in the | > global DNS? | |=> I think this makes sense. Something like "SHOULD NOT". I would prefer not to see such language. | > My personal opinion is that they should never be in the | > global DNS, | |=> Agreed. | | but | > that didn't seem to be the consensus of the WG. | |=> At least you and I agree FWIW :) |Perhaps I missed this discussion, but I can't see |why they should be put in the global DNS. One might want to build an overlay network where consenting sites know how to reach each other by constructing dynamic tunnels based on some (yet to be defined) mapping function. Thus the addresses may well be reachable in some sense. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 9 05:28:21 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 FAA19549 for ; Fri, 9 Apr 2004 05:28: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 1BBsIj-00035z-6e for ipv6-archive@odin.ietf.org; Fri, 09 Apr 2004 05:27:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i399RrkM011895 for ipv6-archive@odin.ietf.org; Fri, 9 Apr 2004 05:27:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBsIj-00035m-0M for ipv6-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 05:27: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 FAA19527 for ; Fri, 9 Apr 2004 05:27:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBsIf-0005XA-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 05:27:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBsHl-0005Qr-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 05:26:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBsGM-0005KB-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 05:25:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBsFy-0002ih-9D; Fri, 09 Apr 2004 05:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBsFN-0002i0-PZ for ipv6@optimus.ietf.org; Fri, 09 Apr 2004 05:24: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 FAA19386 for ; Fri, 9 Apr 2004 05:24:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBsFK-0005DM-00 for ipv6@ietf.org; Fri, 09 Apr 2004 05:24:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBsEc-00057j-00 for ipv6@ietf.org; Fri, 09 Apr 2004 05:23:38 -0400 Received: from d212-152-6-89.cust.tele2.ch ([212.152.6.89] helo=laptop2.kurtis.pp.se) by ietf-mx with esmtp (Exim 4.12) id 1BBsD7-0004yt-00 for ipv6@ietf.org; Fri, 09 Apr 2004 05:22:05 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 4E5DF375ACC; Fri, 9 Apr 2004 11:21:58 +0200 (CEST) In-Reply-To: <200404090519.BAA16640@ss10.danlan.com> References: <200404090519.BAA16640@ss10.danlan.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <56124720-8A07-11D8-8D01-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Kurt Erik Lindqvist Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Date: Fri, 9 Apr 2004 11:21:52 +0200 To: Dan Lanciani X-Pgp-Rfc2646-Fix: 1 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-04-09, at 07.19, Dan Lanciani wrote: > > |=> At least you and I agree FWIW :) > |Perhaps I missed this discussion, but I can't see > |why they should be put in the global DNS. > > One might want to build an overlay network where consenting sites know > how > to reach each other by constructing dynamic tunnels based on some (yet > to > be defined) mapping function. Thus the addresses may well be > reachable in > some sense. But is this reason enough to have them in the global DNS tree. I don't think so... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQHZrMqarNKXTPFCVEQKaNwCgr1wxXw9gKrSnJI90AavKMkWdgRoAn2x8 WwLoQEN9JrytIhMRArA+QgIO =wLwY -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 9 06:22: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 GAA20985 for ; Fri, 9 Apr 2004 06:22: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 1BBt8v-00078o-25 for ipv6-archive@odin.ietf.org; Fri, 09 Apr 2004 06:21:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39ALnFP027446 for ipv6-archive@odin.ietf.org; Fri, 9 Apr 2004 06:21:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBt8u-00078b-4W for ipv6-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 06:21: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 GAA20970 for ; Fri, 9 Apr 2004 06:21:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBt8q-0002gm-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 06:21:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBt7j-0002ZE-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 06:20:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBt6I-0002OO-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 06:19:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBt6D-0006on-LR; Fri, 09 Apr 2004 06:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBt5S-0006nw-Lk for ipv6@optimus.ietf.org; Fri, 09 Apr 2004 06:18: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 GAA20857 for ; Fri, 9 Apr 2004 06:18:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBt5N-0002HC-00 for ipv6@ietf.org; Fri, 09 Apr 2004 06:18:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBt4K-0002Ab-00 for ipv6@ietf.org; Fri, 09 Apr 2004 06:17:04 -0400 Received: from 182.cust45.nsw.dsl.ozemail.com.au ([203.103.124.182] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1BBt2Y-00020h-00 for ipv6@ietf.org; Fri, 09 Apr 2004 06:15:14 -0400 Received: from Dupy2.nosense.org (localhost.localdomain [127.0.0.1]) by nosense.org (Postfix) with SMTP id 532873F02A; Fri, 9 Apr 2004 19:46:27 +0930 (CST) Date: Fri, 9 Apr 2004 19:46:19 +0930 From: Mark Smith To: Kurt Erik Lindqvist Cc: ipng-incoming@danlan.com, ipv6@ietf.org Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Message-Id: <20040409194619.34cd410f.ipv6@53616c7465645f5f2d3e1b50dcf8ae62157d340a7f63aa2b.nosense.org> In-Reply-To: <56124720-8A07-11D8-8D01-000A95928574@kurtis.pp.se> References: <200404090519.BAA16640@ss10.danlan.com> <56124720-8A07-11D8-8D01-000A95928574@kurtis.pp.se> Organization: The No Sense Organisation (http://www.nosense.org) X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Fri__9_Apr_2004_19_46_19_+0930_fhWTehgi6keYaOUi" 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 --Signature=_Fri__9_Apr_2004_19_46_19_+0930_fhWTehgi6keYaOUi Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Fri, 9 Apr 2004 11:21:52 +0200 Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 2004-04-09, at 07.19, Dan Lanciani wrote: > > > > > |=> At least you and I agree FWIW :) > > |Perhaps I missed this discussion, but I can't see > > |why they should be put in the global DNS. > > > > One might want to build an overlay network where consenting > > sites know how > > to reach each other by constructing dynamic tunnels based on > > some (yet to > > be defined) mapping function. Thus the addresses may well be > > reachable in > > some sense. > > But is this reason enough to have them in the global DNS tree. > I don't think so... > Rather than the dynamic mappings Dan suggested, I could imagine a corporate, WAN type IPsec VPN scenario, were the global DNS entry destinations are only accessible across the IPsec tunnels, to devices residing behind the IPsec VPN gateways. Placing unique-local addresses in the global DNS infrastructure would save having to setup split / duplicate DNS in this scenario, minimising costs. Regards, Mark. --Signature=_Fri__9_Apr_2004_19_46_19_+0930_fhWTehgi6keYaOUi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAdnf6G8bRCl8r4BERAkV4AJ4tDaJHZXchJDUiki78lNCuqki5igCeKWt6 yIzuMzbODEC6bVUksRJE388= =uSAS -----END PGP SIGNATURE----- --Signature=_Fri__9_Apr_2004_19_46_19_+0930_fhWTehgi6keYaOUi-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 9 10:05: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 KAA28674 for ; Fri, 9 Apr 2004 10:05: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 1BBwdK-0001lr-UQ for ipv6-archive@odin.ietf.org; Fri, 09 Apr 2004 10:05:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39E5QFn006803 for ipv6-archive@odin.ietf.org; Fri, 9 Apr 2004 10:05:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwdK-0001le-QS for ipv6-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 10:05: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 KAA28594 for ; Fri, 9 Apr 2004 10:05:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBwdI-0000oD-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 10:05:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBwcB-0000f5-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 10:04:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBwbC-0000UK-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 10:03:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBway-0000jm-OQ; Fri, 09 Apr 2004 10:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwaQ-0000Hm-6X for ipv6@optimus.ietf.org; Fri, 09 Apr 2004 10:02: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 KAA28262 for ; Fri, 9 Apr 2004 10:02:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBwaN-0000Tg-00 for ipv6@ietf.org; Fri, 09 Apr 2004 10:02:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBwZB-0000Mt-00 for ipv6@ietf.org; Fri, 09 Apr 2004 10:01:09 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BBwXw-0000G7-00 for ipv6@ietf.org; Fri, 09 Apr 2004 09:59:52 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2FD9115210 for ; Fri, 9 Apr 2004 22:59:45 +0900 (JST) Date: Fri, 09 Apr 2004 22:59:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis] Absence of Router Advertisements 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: 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 Regarding issue 277 of rfc2462bis (Semantics of M/O flags), I want to make a consensus on one thing. (Note: in this particular thread, please just forget the discussion about whether 2462bis should explicitly say the stateful protocol is DHCPv6.) Previously I proposed to revise section 5.5.2 as follows: > If a link has no routers, a host MAY attempt to use stateful > autoconfiguration to obtain addresses and other configuration > information. > ... > An implementation MAY provide a way to enable the > invocation of stateful autoconfiguration in this case, but the > default SHOULD be disabled. In current RFC2462, the text is "a host MUST attempt to use stateful... An implementation MAY provide a way ... but the default SHOULD be enabled". So, in my proposal, the requirement level was totally reversed. The reason I raised was as follows: >>>>> On Fri, 27 Feb 2004 21:31:57 +0900, >>>>> JINMEI Tatuya said: > To choose appropriate keywords, I'd like to be synchronized with the > node requirements draft (draft-ietf-ipv6-node-requirements-08.txt). > It says in Section 4.5.5 that: > Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- > 3315] is the standard stateful address configuration protocol; see > section 5.3 for DHCPv6 support. > Nodes which do not support Stateful Address Autoconfiguration may be > unable to obtain any IPv6 addresses aside from link-local addresses > when it receives a router advertisement with the 'M' flag (Managed > address configuration) set and which contains no prefixes advertised > for Stateless Address Autoconfiguration (see section 4.5.2). > ... > That is (in my understanding), implementing DHCPv6 is basically > optional with warnings about the case of not implementing it. I know > this was a controversial issue, but I believe the node-requirements > draft made a reasonable decision in terms of practical and realistic > deployment path while honoring future flexibility. > Another reason for the change is because we can at least use > link-local addresses within a single link without a router. I've not seen many responses to this part, but some people, including Ralph (Droms), agreed on this change in their responses. However, Greg Daley pointed out in Seoul that this change might be dangerous because there may still be a node that can forward packets from hosts but is not sending RAs (I intentionally avoid using the term "router" here, because in this context a "router" should be sending RAs). I've been thinking about this for a while, and my conclusion is that we don't have to worry about the scenario and thus do not have to reconsider the original proposal of mine (at least due to this particular issue). The reason is that the problematic scenario looks very unrealistic. If we want to force stateful configuration, we can simply do that by configuring a node as a "router" sending RAs with the M (and/or) O flags being set. And, as far as I know, all existing commercial "packet forwarders" (again, I intentionally avoid the term "router") has the ability to send RAs, and I'm quite sure that future products will. The administrator might want to skip configuring RAs by relying on the RFC2462 default, but it's very likely that this person will still have to configure a DHCPv6 server and the "forwarders" for routing protocols. Also, since there is no other defined way than the stateless autoconfiguration to configure a default router for hosts (note that DHCPv6 does not have an option for this, not as far as I know), we'll have to configure the default route on each host manually. That said, I really do not see any sane reason for relying on the default behavior. Now I want to ask: am I still miss something, or can we agree on the original 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 Fri Apr 9 17:28:22 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 RAA23681 for ; Fri, 9 Apr 2004 17:28: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 1BC3XX-0005nZ-5d for ipv6-archive@odin.ietf.org; Fri, 09 Apr 2004 17:27:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39LRthP022285 for ipv6-archive@odin.ietf.org; Fri, 9 Apr 2004 17:27:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC3XX-0005nM-0g for ipv6-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 17:27: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 RAA23643 for ; Fri, 9 Apr 2004 17:27:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC3XT-0004oz-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 17:27:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC3G2-0003Sn-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 17:09:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC2yu-0001nc-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 16:52:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2xs-0000Yh-8T; Fri, 09 Apr 2004 16:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2xm-0000Ws-HK for ipv6@optimus.ietf.org; Fri, 09 Apr 2004 16:50: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 QAA20676 for ; Fri, 9 Apr 2004 16:50:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC2xi-0001eL-00 for ipv6@ietf.org; Fri, 09 Apr 2004 16:50:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC2jx-0007ki-00 for ipv6@ietf.org; Fri, 09 Apr 2004 16:36:42 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1BC2Ps-0005wM-00 for ipv6@ietf.org; Fri, 09 Apr 2004 16:15:57 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id QAA00765; Fri, 9 Apr 2004 16:15:42 -0400 (EDT) Date: Fri, 9 Apr 2004 16:15:42 -0400 (EDT) From: Dan Lanciani Message-Id: <200404092015.QAA00765@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.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.3 required=5.0 tests=AWL autolearn=no version=2.60 Kurt Erik Lindqvist wrote: |> |=> At least you and I agree FWIW :) |> |Perhaps I missed this discussion, but I can't see |> |why they should be put in the global DNS. |> |> One might want to build an overlay network where consenting sites know |> how |> to reach each other by constructing dynamic tunnels based on some (yet |> to |> be defined) mapping function. Thus the addresses may well be |> reachable in |> some sense. | |But is this reason enough to have them in the global DNS tree. Certainly. If they are in the global DNS then the overlay network can be handled entirely by routers (or even stub hosts) that know how to look up the mapping and create the tunnels. This is the approach I intend to use if unique addresses become a reality. If the addresses are not allowed in the global DNS then multi-faced or multi-rooted DNS (or worse) hacks are required to allow applications to see the addresses in the first place. I strongly object to restricting unique addresses from the global DNS. It seriously compromises their utility and it does nothing to make anyone's life easier. Applications must already deal with the case of addresses that are not reachable because of filters. There is no reason to single these addresses out for second-class treatment. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 9 20:43: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 UAA03176 for ; Fri, 9 Apr 2004 20:43: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 1BC6am-0006k8-82 for ipv6-archive@odin.ietf.org; Fri, 09 Apr 2004 20:43:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3A0hSua025916 for ipv6-archive@odin.ietf.org; Fri, 9 Apr 2004 20:43:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC6am-0006jv-2l for ipv6-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 20:43: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 UAA03166 for ; Fri, 9 Apr 2004 20:43:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC6aj-0002Ic-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 20:43:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC6ZI-0002Au-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 20:41:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC6Yq-00023C-00 for ipv6-web-archive@ietf.org; Fri, 09 Apr 2004 20:41:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC6YR-0006GK-25; Fri, 09 Apr 2004 20:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC6Xf-0006Ff-BI for ipv6@optimus.ietf.org; Fri, 09 Apr 2004 20:40: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 UAA03059 for ; Fri, 9 Apr 2004 20:40:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC6Xb-0001vX-00 for ipv6@ietf.org; Fri, 09 Apr 2004 20:40:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC6Wm-0001o2-00 for ipv6@ietf.org; Fri, 09 Apr 2004 20:39:21 -0400 Received: from [4.16.92.133] (helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1BC6Vc-0001aP-00 for ipv6@ietf.org; Fri, 09 Apr 2004 20:38:08 -0400 Received: from eaglet (127.0.0.1:4291) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 9 Apr 2004 17:38:05 -0700 From: "Tony Hain" To: "'Dan Lanciani'" , Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Date: Fri, 9 Apr 2004 17:37:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200404092015.QAA00765@ss10.danlan.com> Thread-Index: AcQed4JYrGxnUfdbSpGS3ivLM/Dw9AAHFC/w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 I agree with Dan. Unless someone can show explicit harm to a third party by putting them in the global DNS, there is no reason to even discuss their presence or absence in the global DNS. Tony > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Dan > Lanciani > Sent: Friday, April 09, 2004 1:16 PM > To: ipv6@ietf.org > Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr- > 03.txt > > Kurt Erik Lindqvist wrote: > > |> |=> At least you and I agree FWIW :) > |> |Perhaps I missed this discussion, but I can't see > |> |why they should be put in the global DNS. > |> > |> One might want to build an overlay network where consenting sites know > |> how > |> to reach each other by constructing dynamic tunnels based on some (yet > |> to > |> be defined) mapping function. Thus the addresses may well be > |> reachable in > |> some sense. > | > |But is this reason enough to have them in the global DNS tree. > > Certainly. If they are in the global DNS then the overlay network can be > handled entirely by routers (or even stub hosts) that know how to look up > the > mapping and create the tunnels. This is the approach I intend to use if > unique > addresses become a reality. If the addresses are not allowed in the > global DNS > then multi-faced or multi-rooted DNS (or worse) hacks are required to > allow > applications to see the addresses in the first place. > > I strongly object to restricting unique addresses from the global DNS. It > seriously compromises their utility and it does nothing to make anyone's > life easier. Applications must already deal with the case of addresses > that > are not reachable because of filters. There is no reason to single these > addresses out for second-class treatment. > > Dan Lanciani > ddl@danlan.*com > > -------------------------------------------------------------------- > 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 Sat Apr 10 02:04: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 CAA15230 for ; Sat, 10 Apr 2004 02:04: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 1BCBac-00017j-IX for ipv6-archive@odin.ietf.org; Sat, 10 Apr 2004 02:03:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3A63cXb004318 for ipv6-archive@odin.ietf.org; Sat, 10 Apr 2004 02:03:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBac-00017Y-Co for ipv6-web-archive@optimus.ietf.org; Sat, 10 Apr 2004 02:03: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 CAA14681 for ; Sat, 10 Apr 2004 02:03:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCBaY-0005lS-00 for ipv6-web-archive@ietf.org; Sat, 10 Apr 2004 02:03:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCBZT-0005cH-00 for ipv6-web-archive@ietf.org; Sat, 10 Apr 2004 02:02:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BCBYX-0005M6-00 for ipv6-web-archive@ietf.org; Sat, 10 Apr 2004 02:01:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBY6-0007vp-1a; Sat, 10 Apr 2004 02: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 1BCBXF-0007YN-1M for ipv6@optimus.ietf.org; Sat, 10 Apr 2004 02:00: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 CAA10988 for ; Sat, 10 Apr 2004 02:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCBXB-0005K2-00 for ipv6@ietf.org; Sat, 10 Apr 2004 02:00:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCBVz-0005BD-00 for ipv6@ietf.org; Sat, 10 Apr 2004 01:58:52 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCBUm-0004tm-00 for ipv6@ietf.org; Sat, 10 Apr 2004 01:57:36 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3A5umC01391; Sat, 10 Apr 2004 08:56:48 +0300 Date: Sat, 10 Apr 2004 08:56:48 +0300 (EEST) From: Pekka Savola To: Tony Hain cc: "'Dan Lanciani'" , Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.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 On Fri, 9 Apr 2004, Tony Hain wrote: > I agree with Dan. Unless someone can show explicit harm to a third party by > putting them in the global DNS, there is no reason to even discuss their > presence or absence in the global DNS. I think there are two (operational -- can't be checked by the implementation) cases here: 1) putting in local addresses to global DNS names which are expected to be used by outsiders who are not interested of local addresses, or to whom local addresses could even mean a service degradation. (e.g., www.example.com, smtp.example.com, etc.etc.) 2) putting in local addresses for names which are not expected to be used (e.g., "canada.vpn.example.com", to perform some kind of "auto-discovery" functions) except who know which hostnames those are and know what they're doing. In the former, adding them makes very little sense. In the latter, adding them might be beneficial, while I'm not sure I can see the scenario as I think one might want to use global addresses instead.. > > -----Original Message----- > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Dan > > Lanciani > > Sent: Friday, April 09, 2004 1:16 PM > > To: ipv6@ietf.org > > Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr- > > 03.txt > > > > Kurt Erik Lindqvist wrote: > > > > |> |=> At least you and I agree FWIW :) > > |> |Perhaps I missed this discussion, but I can't see > > |> |why they should be put in the global DNS. > > |> > > |> One might want to build an overlay network where consenting sites know > > |> how > > |> to reach each other by constructing dynamic tunnels based on some (yet > > |> to > > |> be defined) mapping function. Thus the addresses may well be > > |> reachable in > > |> some sense. > > | > > |But is this reason enough to have them in the global DNS tree. > > > > Certainly. If they are in the global DNS then the overlay network can be > > handled entirely by routers (or even stub hosts) that know how to look up > > the > > mapping and create the tunnels. This is the approach I intend to use if > > unique > > addresses become a reality. If the addresses are not allowed in the > > global DNS > > then multi-faced or multi-rooted DNS (or worse) hacks are required to > > allow > > applications to see the addresses in the first place. > > > > I strongly object to restricting unique addresses from the global DNS. It > > seriously compromises their utility and it does nothing to make anyone's > > life easier. Applications must already deal with the case of addresses > > that > > are not reachable because of filters. There is no reason to single these > > addresses out for second-class treatment. > > > > Dan Lanciani > > ddl@danlan.*com > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > -- 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 Sat Apr 10 02:49: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 CAA25670 for ; Sat, 10 Apr 2004 02:49: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 1BCCIt-0004BA-7G for ipv6-archive@odin.ietf.org; Sat, 10 Apr 2004 02:49:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3A6nNDK016064 for ipv6-archive@odin.ietf.org; Sat, 10 Apr 2004 02:49:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCCIt-0004B0-0S for ipv6-web-archive@optimus.ietf.org; Sat, 10 Apr 2004 02:49: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 CAA25640 for ; Sat, 10 Apr 2004 02:49:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCCIo-0004cL-00 for ipv6-web-archive@ietf.org; Sat, 10 Apr 2004 02:49:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCCHd-0004Sn-00 for ipv6-web-archive@ietf.org; Sat, 10 Apr 2004 02:48:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BCCGv-0004KE-00 for ipv6-web-archive@ietf.org; Sat, 10 Apr 2004 02:47:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCCGc-0003Ki-9U; Sat, 10 Apr 2004 02:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCCFw-0003JT-DX for ipv6@optimus.ietf.org; Sat, 10 Apr 2004 02:46: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 CAA25554 for ; Sat, 10 Apr 2004 02:46:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCCFq-0004B5-00 for ipv6@ietf.org; Sat, 10 Apr 2004 02:46:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCCEX-00041W-00 for ipv6@ietf.org; Sat, 10 Apr 2004 02:44:54 -0400 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1BCCDg-0003jK-00 for ipv6@ietf.org; Sat, 10 Apr 2004 02:44:00 -0400 Received: from stephen (ip170.post-vineyard.dfw.ygnition.net [66.135.181.170]) by ns2.sea (8.12.11/8.12.5) with SMTP id i3A6h5j7032178; Fri, 9 Apr 2004 23:43:14 -0700 Message-ID: <029101c41ec7$1b203fc0$6401a8c0@stephen> From: "Stephen Sprunk" To: "Brian Haberman" , "Margaret Wasserman" , References: <407538D1.1070803@innovationslab.net> Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Date: Sat, 10 Apr 2004 01:41:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: 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 Thus spake "Brian Haberman" > Margaret Wasserman wrote: > > This would appear to be incompatible with the IANA considerations > > section that says: > > > >> If deemed > >> appropriate, the authority may also consist of multiple organizations > >> performing the authority duties. How about: IANA MAY delegate assignment capabilities to more than one entity. If this occurs, the various entities must assign addresses using a method that is indistinguishable from that of a single entity. Specifically, the method MUST prevent collisions between assignments by different entities and MUST NOT rely on subdividing the assignable address space in a manner that promotes or resembles any aggregation scheme. > >> - Available to anyone in an unbiased manner. > >> - Permanent with no periodic fees. > > > > It seems strange to say that there can be no periodic fees when the > > document doesn't mention fees anywhere else... Perhaps this is a > > leftover from previous versions of the document that did include > a fee > > structure? > > The purpose of the second bullet is to ensure the permanent allocation > of these prefixes. Periodic fees are inconsistent with permanent > allocations (e.g., what happens if someone were to stop paying the > periodic fee?, would the allocation be revoked and reassigned?). > > In addition, there is precedence for one-time, upfront fees such as > this. The IEEE mechanism for MAC addresses comes immediately to mind > as a similar model. I'm still trying to find a better phrasing for this. > > I am not sure that requiring a permanent escrow is consistent > with the > > idea that there will be no ongoing revenue stream (i.e. periodic > fees) > > associated with an address. > > The escrow is to simply ensure no duplication and allow for conflict > resolution. As described above the cost for maintaining an escrow can > be paid for with an charge at the time of the allocation. Would the escrow come into play if the allocating entity goes bankrupt or pulls out? i.e. how would these assignments get transferred to a new authority? Given the issues with NET and COM, should we specify that IANA is the owner of all assignment records (e.g. the escrow)? S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Apr 10 02:49: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 CAA25692 for ; Sat, 10 Apr 2004 02:49: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 1BCCIy-0004BW-Eh for ipv6-archive@odin.ietf.org; Sat, 10 Apr 2004 02:49:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3A6nSAN016082 for ipv6-archive@odin.ietf.org; Sat, 10 Apr 2004 02:49:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCCIy-0004BJ-9m for ipv6-web-archive@optimus.ietf.org; Sat, 10 Apr 2004 02: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 CAA25644 for ; Sat, 10 Apr 2004 02:49:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCCIt-0004cR-00 for ipv6-web-archive@ietf.org; Sat, 10 Apr 2004 02:49:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCCHd-0004Sy-00 for ipv6-web-archive@ietf.org; Sat, 10 Apr 2004 02:48:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BCCGv-0004KF-00 for ipv6-web-archive@ietf.org; Sat, 10 Apr 2004 02:47:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCCGe-0003Kx-2L; Sat, 10 Apr 2004 02:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCCG0-0003Jf-Kt for ipv6@optimus.ietf.org; Sat, 10 Apr 2004 02: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 CAA25557 for ; Sat, 10 Apr 2004 02:46:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCCFw-0004BB-00 for ipv6@ietf.org; Sat, 10 Apr 2004 02:46:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCCEY-00041e-00 for ipv6@ietf.org; Sat, 10 Apr 2004 02:44:54 -0400 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1BCCDg-0003jR-00 for ipv6@ietf.org; Sat, 10 Apr 2004 02:44:00 -0400 Received: from stephen (ip170.post-vineyard.dfw.ygnition.net [66.135.181.170]) by ns2.sea (8.12.11/8.12.5) with SMTP id i3A6h5j5032178; Fri, 9 Apr 2004 23:43:08 -0700 Message-ID: <029001c41ec7$1780d1e0$6401a8c0@stephen> From: "Stephen Sprunk" To: "Kurt Erik Lindqvist" , "Dan Lanciani" Cc: References: <200404090519.BAA16640@ss10.danlan.com> <56124720-8A07-11D8-8D01-000A95928574@kurtis.pp.se> Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Date: Sat, 10 Apr 2004 01:38:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: 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 Thus spake "Kurt Erik Lindqvist" > On 2004-04-09, at 07.19, Dan Lanciani wrote: > > |=> At least you and I agree FWIW :) > > |Perhaps I missed this discussion, but I can't see > > |why they should be put in the global DNS. > > > > One might want to build an overlay network where consenting sites know > > how > > to reach each other by constructing dynamic tunnels based on some (yet > > to > > be defined) mapping function. Thus the addresses may well be > > reachable in > > some sense. > > But is this reason enough to have them in the global DNS tree. I don't > think so... My justification is that some sites may choose to communicate privately (i.e. not via the Internet) using their local addresses. Having these addresses in the global DNS (both forward and reverse) means that each site doesn't need to add its partners' zones to all of their name servers, which is rather error-prone. Also, if local addresses somehow leak into the Internet, having reverse entries in DNS may help trace the leak. Suggested text for 7.0: AAAA and PTR records for Local IPv6 addresses MAY be installed in the global DNS at the option of the site to which they are assigned. It is expected that most sites will not make use of this option, but some sites may find benefits in doing so. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Apr 11 03:35: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 DAA15729 for ; Sun, 11 Apr 2004 03:35: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 1BCZV5-0002d5-5q for ipv6-archive@odin.ietf.org; Sun, 11 Apr 2004 03:35:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3B7ZV3Q010103 for ipv6-archive@odin.ietf.org; Sun, 11 Apr 2004 03:35:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZV5-0002cs-0P for ipv6-web-archive@optimus.ietf.org; Sun, 11 Apr 2004 03:35: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 DAA15708 for ; Sun, 11 Apr 2004 03:35:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCZV0-0004Ns-00 for ipv6-web-archive@ietf.org; Sun, 11 Apr 2004 03:35:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCZQx-0003wz-00 for ipv6-web-archive@ietf.org; Sun, 11 Apr 2004 03:31:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BCZOA-0003QB-00 for ipv6-web-archive@ietf.org; Sun, 11 Apr 2004 03:28:22 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BCZ78-0004GE-IO for ipv6-web-archive@ietf.org; Sun, 11 Apr 2004 03:10:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZ5d-00089e-UP; Sun, 11 Apr 2004 03:09:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCWBi-000515-To for ipv6@optimus.ietf.org; Sun, 11 Apr 2004 00:03: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 AAA28701 for ; Sun, 11 Apr 2004 00:03:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCWBd-0002L0-00 for ipv6@ietf.org; Sun, 11 Apr 2004 00:03:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCWAw-0002CR-00 for ipv6@ietf.org; Sun, 11 Apr 2004 00:02:31 -0400 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1BCW9P-0001vr-00 for ipv6@ietf.org; Sun, 11 Apr 2004 00:00:55 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 3319A2B6 for ; Sun, 11 Apr 2004 00:00:13 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 11 Apr 2004 00:00:13 -0400 Message-Id: <20040411040013.3319A2B6@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 --------+------+--------+----------+------------------------ 13.79% | 4 | 16.46% | 23342 | jinmei@isl.rdc.toshiba.co.jp 13.79% | 4 | 14.47% | 20524 | pekkas@netcore.fi 6.90% | 2 | 10.63% | 15072 | brian@innovationslab.net 6.90% | 2 | 7.16% | 10157 | stephen@sprunk.org 6.90% | 2 | 6.96% | 9862 | erik.nordmark@sun.com 6.90% | 2 | 6.81% | 9651 | h.soliman@flarion.com 6.90% | 2 | 5.76% | 8165 | ipng-incoming@danlan.com 6.90% | 2 | 5.36% | 7603 | rt+ipv6-2462bis@rt.psg.com 3.45% | 1 | 3.78% | 5362 | internet-drafts@ietf.org 3.45% | 1 | 3.62% | 5131 | alh-ietf@tndh.net 3.45% | 1 | 3.43% | 4857 | dthaler@windows.microsoft.com 3.45% | 1 | 3.36% | 4771 | ipv6@53616c7465645f5f2d3e1b50dcf8ae62157d340a7f63aa2b.nosense.org 3.45% | 1 | 2.89% | 4099 | sra+ipng@hactrn.net 3.45% | 1 | 2.70% | 3822 | sra@isc.org 3.45% | 1 | 2.63% | 3731 | kurtis@kurtis.pp.se 3.45% | 1 | 2.00% | 2842 | boodhooa@mx.uom.ac.mu 3.45% | 1 | 1.97% | 2799 | iesg-secretary@ietf.org --------+------+--------+----------+------------------------ 100.00% | 29 |100.00% | 141790 | 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 Apr 12 06:59:06 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 GAA14777 for ; Mon, 12 Apr 2004 06:59:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCz9E-0002M0-Bq for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 06:58:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CAwepo009044 for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 06:58:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCz9C-0002Ln-It for ipv6-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 06:58: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 GAA14757 for ; Mon, 12 Apr 2004 06:58:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCz98-0000zU-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 06:58:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCz7r-0000s5-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 06:57:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BCz6M-0000es-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 06:55:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCz5i-00021w-M3; Mon, 12 Apr 2004 06: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 1BCz4n-00020S-G6 for ipv6@optimus.ietf.org; Mon, 12 Apr 2004 06:54: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 GAA14625 for ; Mon, 12 Apr 2004 06:54:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCz4i-0000TS-00 for ipv6@ietf.org; Mon, 12 Apr 2004 06:54:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCz2j-0000Dr-00 for ipv6@ietf.org; Mon, 12 Apr 2004 06:51:57 -0400 Received: from [4.16.92.133] (helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1BCyyx-0007hQ-00 for ipv6@ietf.org; Mon, 12 Apr 2004 06:48:03 -0400 Received: from eaglet (127.0.0.1:4209) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Mon, 12 Apr 2004 03:44:19 -0700 From: "Tony Hain" To: "'Pekka Savola'" Cc: "'Dan Lanciani'" , Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Date: Mon, 12 Apr 2004 03:47:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcQewKJg3WP3E1otT6i7C7nHUeGK2ABj7R7Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 'Making sense' or not is not something that the IETF needs to specify in MUST/SHOULD/MAY terms. There may be reasons to discuss the potential impact of implementing that way, but that is the most the IETF should do. Again, unless there is impact to a 3rd party, putting local use addresses in the global DNS is none of the IETF's business. Tony > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, April 09, 2004 10:57 PM > To: Tony Hain > Cc: 'Dan Lanciani'; ipv6@ietf.org > Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr- > 03.txt > > On Fri, 9 Apr 2004, Tony Hain wrote: > > I agree with Dan. Unless someone can show explicit harm to a third party > by > > putting them in the global DNS, there is no reason to even discuss their > > presence or absence in the global DNS. > > I think there are two (operational -- can't be checked by the > implementation) cases here: > > 1) putting in local addresses to global DNS names which are expected > to be used by outsiders who are not interested of local > addresses, or to whom local addresses could even mean a > service degradation. (e.g., www.example.com, smtp.example.com, > etc.etc.) > > 2) putting in local addresses for names which are not expected to be > used (e.g., "canada.vpn.example.com", to perform some kind of > "auto-discovery" functions) except who know which hostnames those > are and know what they're doing. > > In the former, adding them makes very little sense. In the latter, > adding them might be beneficial, while I'm not sure I can see the > scenario as I think one might want to use global addresses instead.. > > > > -----Original Message----- > > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of > Dan > > > Lanciani > > > Sent: Friday, April 09, 2004 1:16 PM > > > To: ipv6@ietf.org > > > Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local- > addr- > > > 03.txt > > > > > > Kurt Erik Lindqvist wrote: > > > > > > |> |=> At least you and I agree FWIW :) > > > |> |Perhaps I missed this discussion, but I can't see > > > |> |why they should be put in the global DNS. > > > |> > > > |> One might want to build an overlay network where consenting sites > know > > > |> how > > > |> to reach each other by constructing dynamic tunnels based on some > (yet > > > |> to > > > |> be defined) mapping function. Thus the addresses may well be > > > |> reachable in > > > |> some sense. > > > | > > > |But is this reason enough to have them in the global DNS tree. > > > > > > Certainly. If they are in the global DNS then the overlay network can > be > > > handled entirely by routers (or even stub hosts) that know how to look > up > > > the > > > mapping and create the tunnels. This is the approach I intend to use > if > > > unique > > > addresses become a reality. If the addresses are not allowed in the > > > global DNS > > > then multi-faced or multi-rooted DNS (or worse) hacks are required to > > > allow > > > applications to see the addresses in the first place. > > > > > > I strongly object to restricting unique addresses from the global DNS. > It > > > seriously compromises their utility and it does nothing to make > anyone's > > > life easier. Applications must already deal with the case of > addresses > > > that > > > are not reachable because of filters. There is no reason to single > these > > > addresses out for second-class treatment. > > > > > > Dan Lanciani > > > ddl@danlan.*com > > > > > > -------------------------------------------------------------------- > > > 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 > > -------------------------------------------------------------------- > > > > -- > 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 Apr 12 09:23: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 JAA19018 for ; Mon, 12 Apr 2004 09:23: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 1BD1Om-0003L0-2I for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 09:22:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CDMqe0012826 for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 09:22:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1Ok-0003Kn-Dh for ipv6-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 09: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 JAA18992 for ; Mon, 12 Apr 2004 09:22:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD1Oi-00019V-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 09:22:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD1N3-0000xE-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 09:21:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD1LW-0000ho-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 09:19:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1L4-0002ll-41; Mon, 12 Apr 2004 09: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 1BD1KO-0002kN-9o for ipv6@optimus.ietf.org; Mon, 12 Apr 2004 09:18: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 JAA18678 for ; Mon, 12 Apr 2004 09:18:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD1KM-0000YC-00 for ipv6@ietf.org; Mon, 12 Apr 2004 09:18:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD1Io-0000JL-00 for ipv6@ietf.org; Mon, 12 Apr 2004 09:16:43 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD1I6-00007R-00 for ipv6@ietf.org; Mon, 12 Apr 2004 09:15:58 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3CDFB212899; Mon, 12 Apr 2004 16:15:11 +0300 Date: Mon, 12 Apr 2004 16:15:10 +0300 (EEST) From: Pekka Savola To: Tony Hain cc: "'Dan Lanciani'" , Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.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 On Mon, 12 Apr 2004, Tony Hain wrote: > Again, > unless there is impact to a 3rd party, putting local use addresses in the > global DNS is none of the IETF's business. If you look at the case 1) below, that for certainty is a case which would impact third parties. > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Friday, April 09, 2004 10:57 PM > > To: Tony Hain > > Cc: 'Dan Lanciani'; ipv6@ietf.org > > Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr- > > 03.txt > > > > On Fri, 9 Apr 2004, Tony Hain wrote: > > > I agree with Dan. Unless someone can show explicit harm to a third party > > by > > > putting them in the global DNS, there is no reason to even discuss their > > > presence or absence in the global DNS. > > > > I think there are two (operational -- can't be checked by the > > implementation) cases here: > > > > 1) putting in local addresses to global DNS names which are expected > > to be used by outsiders who are not interested of local > > addresses, or to whom local addresses could even mean a > > service degradation. (e.g., www.example.com, smtp.example.com, > > etc.etc.) > > > > 2) putting in local addresses for names which are not expected to be > > used (e.g., "canada.vpn.example.com", to perform some kind of > > "auto-discovery" functions) except who know which hostnames those > > are and know what they're doing. > > > > In the former, adding them makes very little sense. In the latter, > > adding them might be beneficial, while I'm not sure I can see the > > scenario as I think one might want to use global addresses instead.. > > > > > > -----Original Message----- > > > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of > > Dan > > > > Lanciani > > > > Sent: Friday, April 09, 2004 1:16 PM > > > > To: ipv6@ietf.org > > > > Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local- > > addr- > > > > 03.txt > > > > > > > > Kurt Erik Lindqvist wrote: > > > > > > > > |> |=> At least you and I agree FWIW :) > > > > |> |Perhaps I missed this discussion, but I can't see > > > > |> |why they should be put in the global DNS. > > > > |> > > > > |> One might want to build an overlay network where consenting sites > > know > > > > |> how > > > > |> to reach each other by constructing dynamic tunnels based on some > > (yet > > > > |> to > > > > |> be defined) mapping function. Thus the addresses may well be > > > > |> reachable in > > > > |> some sense. > > > > | > > > > |But is this reason enough to have them in the global DNS tree. > > > > > > > > Certainly. If they are in the global DNS then the overlay network can > > be > > > > handled entirely by routers (or even stub hosts) that know how to look > > up > > > > the > > > > mapping and create the tunnels. This is the approach I intend to use > > if > > > > unique > > > > addresses become a reality. If the addresses are not allowed in the > > > > global DNS > > > > then multi-faced or multi-rooted DNS (or worse) hacks are required to > > > > allow > > > > applications to see the addresses in the first place. > > > > > > > > I strongly object to restricting unique addresses from the global DNS. > > It > > > > seriously compromises their utility and it does nothing to make > > anyone's > > > > life easier. Applications must already deal with the case of > > addresses > > > > that > > > > are not reachable because of filters. There is no reason to single > > these > > > > addresses out for second-class treatment. > > > > > > > > Dan Lanciani > > > > ddl@danlan.*com > > > > > > > > -------------------------------------------------------------------- > > > > 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 > > > -------------------------------------------------------------------- > > > > > > > -- > > 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 > -------------------------------------------------------------------- > -- 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 Apr 12 11:34: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 LAA25340 for ; Mon, 12 Apr 2004 11:34: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 1BD3S3-0003HZ-Tm for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 11:34:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CFYNWU012613 for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 11:34:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3S3-0003HM-Pi for ipv6-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 11:34: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 LAA25300 for ; Mon, 12 Apr 2004 11:34:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD3S2-00000b-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 11:34:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD3O1-0007Oy-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 11:30:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD3LE-000732-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 11:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3Kv-000256-KB; Mon, 12 Apr 2004 11:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3KD-0001za-AR for ipv6@optimus.ietf.org; Mon, 12 Apr 2004 11:26: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 LAA24938 for ; Mon, 12 Apr 2004 11:26:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD3KB-0006vy-00 for ipv6@ietf.org; Mon, 12 Apr 2004 11:26:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD3Ez-0006TF-00 for ipv6@ietf.org; Mon, 12 Apr 2004 11:20:53 -0400 Received: from zcamail03.zca.compaq.com ([161.114.32.103]) by ietf-mx with esmtp (Exim 4.12) id 1BD39N-0005x5-00 for ipv6@ietf.org; Mon, 12 Apr 2004 11:15:05 -0400 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 6E6F5AD93 for ; Mon, 12 Apr 2004 08:14:29 -0700 (PDT) Received: from anw.zk3.dec.com (and.zk3.dec.com [16.140.64.3]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 966F53BCF for ; Mon, 12 Apr 2004 10:14:28 -0500 (CDT) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id i3CFESD0001691739; Mon, 12 Apr 2004 11:14:28 -0400 (EDT) Date: Mon, 12 Apr 2004 11:14:28 -0400 (EDT) From: Jack McCann USG Message-Id: <200404121514.i3CFESD0001691739@anw.zk3.dec.com> To: ipv6@ietf.org Subject: Re: Revising PMTUD for IPv6 to DS? 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 RFC 1981 was approved as a Draft Standard in August 1998 (see below). My attempts to have this corrected this in STD 1 have been unsuccessful. Perhaps the chairs would have better luck? - Jack ------------------------------------------------------- To: IETF-Announce Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6147) Protocol Action: Internet Protocol, Version 6 (IPv6) Specifications to Draft Standard Date: Mon, 10 Aug 1998 06:49:21 -0400 The IESG has approved publication of the following Internet-Draft as Draft Standards: o Internet Protocol, Version 6 (IPv6) Specification replacing RFC 1883, currently a Proposed Standard. o Neighbor Discovery for IP Version 6 (IPv6) , replacing RFC1970, currently a Proposed Standard o IPv6 Stateless Address Autoconfiguration , replacing RFC1971, currently a Proposed Standard o Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification replacing RFC 1885, currently a Proposed Standard The IESG also approved Path MTU Discovery for IP version 6 as a Draft Standard. These documents are the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary These documents represent the base protocols for IPv6. The IPv6 Specification defines the base IPv6 packet format and processing rules. The Neighbor Discovery specification defines how to do address resolution for neighboring nodes, as well as to how to locate neighboring routers. The Stateless Address Autoconfiguration document defines how a booting node can generate its own IP addresses without the need to maintain configuration information across machine restarts. The ICMPv6 specification defines the packet formats and processing rules for ICMP for IPv6. The Path MTU Discovery document defines how to perform Path MTU in IPv6. All nodes are required to implement Path MTU in IPv6; routers do not fragment packets they forward. Working Group Summary There is Working Group consensus for the protocols defined in these documents. There were two objections raised during Last Call, but the objections did not have support of the Working Group. However, a small clarification was made to the ICMPv6 spec to make it easier to deploy a new ICMP "Packet Too Big" message, should such a message become defined. Protocol Quality There are numerous implementations of these protocols, and extensive interoperability tests have been done via the UNH consortium and on the 6bone. The documents have been reviewed for the IESG by Jeffrey Burgan and Thomas Narten. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Apr 12 13:36: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 NAA00448 for ; Mon, 12 Apr 2004 13:36: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 1BD5Ll-0007S3-QS for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 13:36:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CHa1Yg028639 for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 13:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5Ll-0007Rq-LN for ipv6-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 13:36: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 NAA00404 for ; Mon, 12 Apr 2004 13:35:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5Lj-0000EG-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 13:35:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5JU-0007fw-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 13:33:41 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BD5Ii-0007Oy-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 13:32:53 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BD5Ch-0002Vg-KK for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 13:26:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5C5-0006Km-W6; Mon, 12 Apr 2004 13: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 1BD5Be-0006JN-Kr for ipv6@optimus.ietf.org; Mon, 12 Apr 2004 13:25: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 NAA29927 for ; Mon, 12 Apr 2004 13:25:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5Bc-0006f2-00 for ipv6@ietf.org; Mon, 12 Apr 2004 13:25:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5Am-0006XE-00 for ipv6@ietf.org; Mon, 12 Apr 2004 13:24:41 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1BD59d-0006P6-00 for ipv6@ietf.org; Mon, 12 Apr 2004 13:23:29 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id NAA29719; Mon, 12 Apr 2004 13:23:15 -0400 (EDT) Date: Mon, 12 Apr 2004 13:23:15 -0400 (EDT) From: Dan Lanciani Message-Id: <200404121723.NAA29719@ss10.danlan.com> To: ipv6@ietf.org Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.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.3 required=5.0 tests=AWL autolearn=no version=2.60 Pekka Savola wrote: |On Mon, 12 Apr 2004, Tony Hain wrote: |> Again, |> unless there is impact to a 3rd party, putting local use addresses in the |> global DNS is none of the IETF's business. | |If you look at the case 1) below, that for certainty is a case which |would impact third parties. People who are accessing your names in your DNS are not third parties; they are first parties (or maybe second parties :). Note that discussion of a "global DNS" tends to imply that there is some other kind, indirectly endorsing multi-face and such. Prohibiting addresses from a "global DNS" virtually requires the use of multi-face. Do we really want to go there? I'm not one who wants to prohibit multi-face DNS for those who want it, but I don't want to be forced to use it myself... Dan Lanciani ddl@danlan.*com |> > -----Original Message----- |> > From: Pekka Savola [mailto:pekkas@netcore.fi] |> > Sent: Friday, April 09, 2004 10:57 PM |> > To: Tony Hain |> > Cc: 'Dan Lanciani'; ipv6@ietf.org |> > Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr- |> > 03.txt |> > |> > On Fri, 9 Apr 2004, Tony Hain wrote: |> > > I agree with Dan. Unless someone can show explicit harm to a third party |> > by |> > > putting them in the global DNS, there is no reason to even discuss their |> > > presence or absence in the global DNS. |> > |> > I think there are two (operational -- can't be checked by the |> > implementation) cases here: |> > |> > 1) putting in local addresses to global DNS names which are expected |> > to be used by outsiders who are not interested of local |> > addresses, or to whom local addresses could even mean a |> > service degradation. (e.g., www.example.com, smtp.example.com, |> > etc.etc.) |> > |> > 2) putting in local addresses for names which are not expected to be |> > used (e.g., "canada.vpn.example.com", to perform some kind of |> > "auto-discovery" functions) except who know which hostnames those |> > are and know what they're doing. |> > |> > In the former, adding them makes very little sense. In the latter, |> > adding them might be beneficial, while I'm not sure I can see the |> > scenario as I think one might want to use global addresses instead.. |> > |> > > > -----Original Message----- |> > > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of |> > Dan |> > > > Lanciani |> > > > Sent: Friday, April 09, 2004 1:16 PM |> > > > To: ipv6@ietf.org |> > > > Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local- |> > addr- |> > > > 03.txt |> > > > |> > > > Kurt Erik Lindqvist wrote: |> > > > |> > > > |> |=> At least you and I agree FWIW :) |> > > > |> |Perhaps I missed this discussion, but I can't see |> > > > |> |why they should be put in the global DNS. |> > > > |> |> > > > |> One might want to build an overlay network where consenting sites |> > know |> > > > |> how |> > > > |> to reach each other by constructing dynamic tunnels based on some |> > (yet |> > > > |> to |> > > > |> be defined) mapping function. Thus the addresses may well be |> > > > |> reachable in |> > > > |> some sense. |> > > > | |> > > > |But is this reason enough to have them in the global DNS tree. |> > > > |> > > > Certainly. If they are in the global DNS then the overlay network can |> > be |> > > > handled entirely by routers (or even stub hosts) that know how to look |> > up |> > > > the |> > > > mapping and create the tunnels. This is the approach I intend to use |> > if |> > > > unique |> > > > addresses become a reality. If the addresses are not allowed in the |> > > > global DNS |> > > > then multi-faced or multi-rooted DNS (or worse) hacks are required to |> > > > allow |> > > > applications to see the addresses in the first place. |> > > > |> > > > I strongly object to restricting unique addresses from the global DNS. |> > It |> > > > seriously compromises their utility and it does nothing to make |> > anyone's |> > > > life easier. Applications must already deal with the case of |> > addresses |> > > > that |> > > > are not reachable because of filters. There is no reason to single |> > these |> > > > addresses out for second-class treatment. |> > > > |> > > > Dan Lanciani |> > > > ddl@danlan.*com |> > > > |> > > > -------------------------------------------------------------------- |> > > > 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 |> > > -------------------------------------------------------------------- |> > > |> > |> > -- |> > 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 |> -------------------------------------------------------------------- |> | |-- |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 |-------------------------------------------------------------------- | -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Apr 12 13:47:12 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 NAA01101 for ; Mon, 12 Apr 2004 13:47: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 1BD5W9-0000IH-0c for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 13:46:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CHkiBa001125 for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 13:46:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5W8-0000I4-Qn for ipv6-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 13:46: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 NAA01084 for ; Mon, 12 Apr 2004 13:46:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5W5-0001Qd-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 13:46:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5T1-00015a-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 13:43:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD5Ql-0000n4-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 13:41:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5Qd-0007xw-Pj; Mon, 12 Apr 2004 13:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5Pb-0007uj-1Y for ipv6@optimus.ietf.org; Mon, 12 Apr 2004 13:40: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 NAA00764 for ; Mon, 12 Apr 2004 13:39:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5PX-0000fa-00 for ipv6@ietf.org; Mon, 12 Apr 2004 13:39:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5Ly-0000H8-00 for ipv6@ietf.org; Mon, 12 Apr 2004 13:36:14 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BD5Jm-0007dm-00 for ipv6@ietf.org; Mon, 12 Apr 2004 13:33:58 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3CHXKn22480; Mon, 12 Apr 2004 10:33:20 -0700 X-mProtect: <200404121733> 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 smtpdzsBApE; Mon, 12 Apr 2004 10:33:18 PDT Message-Id: <4.3.2.7.2.20040412102831.033f7048@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Apr 2004 10:31:55 -0700 To: Jack McCann USG From: Bob Hinden Subject: Re: Revising PMTUD for IPv6 to DS? Cc: ipv6@ietf.org In-Reply-To: <200404121514.i3CFESD0001691739@anw.zk3.dec.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 Jack, At 08:14 AM 4/12/2004, Jack McCann USG wrote: >RFC 1981 was approved as a Draft Standard in August 1998 >(see below). My attempts to have this corrected this in >STD 1 have been unsuccessful. Perhaps the chairs would >have better luck? Thanks for reminding us. We will give it a try. This certainly resolves Pekka Savola's normative reference issue. Bob p.s. Please respond off line to Brian and me with any response you received when you tried to fix it. Thanks. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Apr 12 13:53:50 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 NAA01502 for ; Mon, 12 Apr 2004 13:53: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 1BD5cY-000166-7S for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 13:53:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CHrMPr004214 for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 13:53:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5cY-00015t-3n for ipv6-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 13:53: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 NAA01458 for ; Mon, 12 Apr 2004 13:53:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5cU-0002Sa-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 13:53:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5ar-0002Ct-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 13:51:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD5Zn-00022F-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 13:50:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5ZK-0000Ru-Tu; Mon, 12 Apr 2004 13: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 1BD5YM-0000Li-AB for ipv6@optimus.ietf.org; Mon, 12 Apr 2004 13:49: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 NAA01192 for ; Mon, 12 Apr 2004 13:48:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5YJ-0001ll-00 for ipv6@ietf.org; Mon, 12 Apr 2004 13:48:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5Wm-0001Tk-00 for ipv6@ietf.org; Mon, 12 Apr 2004 13:47:24 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5Tl-00016V-00 for ipv6@ietf.org; Mon, 12 Apr 2004 13:44:17 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3CHhh1D029095; Mon, 12 Apr 2004 19:44:07 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "" From: Iljitsch van Beijnum Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Date: Mon, 12 Apr 2004 19:44:02 +0200 To: Pekka Savola 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 On 12-apr-04, at 15:15, Pekka Savola wrote: >> Again, >> unless there is impact to a 3rd party, putting local use addresses in >> the >> global DNS is none of the IETF's business. > If you look at the case 1) below, that for certainty is a case which > would impact third parties. >>> 1) putting in local addresses to global DNS names which are expected >>> to be used by outsiders who are not interested of local >>> addresses, or to whom local addresses could even mean a >>> service degradation. (e.g., www.example.com, smtp.example.com, >>> etc.etc.) >>> 2) putting in local addresses for names which are not expected to be >>> used (e.g., "canada.vpn.example.com", to perform some kind of >>> "auto-discovery" functions) except who know which hostnames those >>> are and know what they're doing. You guys seem to be confusing two very different things: a. putting these addresses in the forward DNS tree b. putting these addresses in the reverse DNS tree Now obviously a. can be harmful, but this is immaterial as anyone can do this today anyway. I don't see how b. can be harmful in any way: only when someone has a reason to look up a certain addresses, she will see whether it's there or not. So as long as the addresses don't leak out, there is no problem. And if the addresses DO leak out, being able to look them up is a plus. The only logical conclusion is that for registry assigned unique site local addresses, the registry MUST provide the registree with the option of registering reverse DNS servers. As for randomly generated mostly-unique site locals... I think it would make sense to synthesize reverse DNS servers inside the address range in question here. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Apr 12 17:53: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 RAA17195 for ; Mon, 12 Apr 2004 17:53: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 1BD9MI-0008GF-Ui for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 17:52:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CLqoRA031751 for ipv6-archive@odin.ietf.org; Mon, 12 Apr 2004 17:52:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD9MF-0008G2-B6 for ipv6-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 17:52: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 RAA17155 for ; Mon, 12 Apr 2004 17:52:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD9MB-0005Wi-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 17:52:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD8qW-0003Uj-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 17:20:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD8TC-0001g4-00 for ipv6-web-archive@ietf.org; Mon, 12 Apr 2004 16:55:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD7LL-0003AK-2a; Mon, 12 Apr 2004 15:43:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD7AE-0004mt-Dl for ipv6@optimus.ietf.org; Mon, 12 Apr 2004 15:32: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 PAA08748 for ; Mon, 12 Apr 2004 15:32:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD7AC-0000Ky-00 for ipv6@ietf.org; Mon, 12 Apr 2004 15:32:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD78a-00008x-00 for ipv6@ietf.org; Mon, 12 Apr 2004 15:30:33 -0400 Received: from [194.15.141.71] (helo=laptop2.kurtis.pp.se) by ietf-mx with esmtp (Exim 4.12) id 1BD77X-0007iA-00 for ipv6@ietf.org; Mon, 12 Apr 2004 15:29:28 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id ED619383EA4; Mon, 12 Apr 2004 21:29:18 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Dan Lanciani'" , From: Kurt Erik Lindqvist Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Date: Mon, 12 Apr 2004 21:29:08 +0200 To: "Tony Hain" X-Pgp-Rfc2646-Fix: 1 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My main concern would be with actually _running_ the reverse three. If we are not talking about relaying on this for services and infrastructure - who do I call when it breaks? - - kurtis - On 2004-04-10, at 02.37, Tony Hain wrote: > I agree with Dan. Unless someone can show explicit harm to a third > party by > putting them in the global DNS, there is no reason to even discuss > their > presence or absence in the global DNS. > > Tony > >> -----Original Message----- >> From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of >> Dan >> Lanciani >> Sent: Friday, April 09, 2004 1:16 PM >> To: ipv6@ietf.org >> Subject: Re: Response to AD comments on >> draft-ietf-ipv6-unique-local-addr- >> 03.txt >> >> Kurt Erik Lindqvist wrote: >> >> |> |=> At least you and I agree FWIW :) >> |> |Perhaps I missed this discussion, but I can't see >> |> |why they should be put in the global DNS. >> |> >> |> One might want to build an overlay network where consenting sites >> know >> |> how >> |> to reach each other by constructing dynamic tunnels based on some >> (yet >> |> to >> |> be defined) mapping function. Thus the addresses may well be >> |> reachable in >> |> some sense. >> | >> |But is this reason enough to have them in the global DNS tree. >> >> Certainly. If they are in the global DNS then the overlay network >> can be >> handled entirely by routers (or even stub hosts) that know how to >> look up >> the >> mapping and create the tunnels. This is the approach I intend to use >> if >> unique >> addresses become a reality. If the addresses are not allowed in the >> global DNS >> then multi-faced or multi-rooted DNS (or worse) hacks are required to >> allow >> applications to see the addresses in the first place. >> >> I strongly object to restricting unique addresses from the global >> DNS. It >> seriously compromises their utility and it does nothing to make >> anyone's >> life easier. Applications must already deal with the case of >> addresses >> that >> are not reachable because of filters. There is no reason to single >> these >> addresses out for second-class treatment. >> >> Dan Lanciani >> ddl@danlan.*com >> >> -------------------------------------------------------------------- >> 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 > -------------------------------------------------------------------- > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQHruBqarNKXTPFCVEQLczgCg0H6k9Tfm76EZ9BIHSDjRLH639vQAoOt8 Ir7OcC0RPfs1+/S8PB2M3KNl =fJZR -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 13 08:28:43 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 IAA08416 for ; Tue, 13 Apr 2004 08:28: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 1BDN1S-0005cF-9a for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 08:28:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DCSECY021583 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 08:28:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDN1P-0005bw-QC for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 08:28: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 IAA08364 for ; Tue, 13 Apr 2004 08:28:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDN1O-0005FW-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 08:28:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDMyn-00053K-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 08:25:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDMwW-0004qD-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 08:23:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDMvR-0004gS-Sy; Tue, 13 Apr 2004 08: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 1BDMuW-0004Wf-DD for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 08:21: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 IAA07950 for ; Tue, 13 Apr 2004 08:21:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDMuU-0004eT-00 for ipv6@ietf.org; Tue, 13 Apr 2004 08:21:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDMqK-0004L4-00 for ipv6@ietf.org; Tue, 13 Apr 2004 08:16:44 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BDMnq-00042Q-00 for ipv6@ietf.org; Tue, 13 Apr 2004 08:14:10 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW300101ZAJN3@mailout2.samsung.com> for ipv6@ietf.org; Tue, 13 Apr 2004 21:13:31 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW3000SUZAJS6@mailout2.samsung.com> for ipv6@ietf.org; Tue, 13 Apr 2004 21:13:31 +0900 (KST) Received: from JAYABHARATHI ([107.108.70.42]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW300KLXZAHFU@mmp1.samsung.com> for ipv6@ietf.org; Tue, 13 Apr 2004 21:13:31 +0900 (KST) Date: Tue, 13 Apr 2004 17:38:29 +0530 From: Jayabharathi Subject: A small clarification required To: ipv6@ietf.org Message-id: <008301c42150$09a0f420$2a466c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/alternative; boundary="Boundary_(ID_KKRAdgJ18wPgSBxXv3RblA)" X-Priority: 3 X-MSMail-priority: Normal 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,HTML_20_30,HTML_FONT_BIG, HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_KKRAdgJ18wPgSBxXv3RblA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT In RFC 3316, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts" why there are no transition mechanisms listed. Is there any assumption behind this, that always there will be a default router in the network (that one of the transition mechanisms) to communicate with any site whether an IPv4 or IPv6 in the internet? --Boundary_(ID_KKRAdgJ18wPgSBxXv3RblA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT

In RFC 3316, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts"

why there are no transition mechanisms listed.

Is there any assumption behind this, that always there will be a default router in the network (that one of  

the transition mechanisms) to communicate with any site whether an IPv4 or IPv6 in the internet?

--Boundary_(ID_KKRAdgJ18wPgSBxXv3RblA)-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 13 08:35: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 IAA08780 for ; Tue, 13 Apr 2004 08:35: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 1BDN8P-0006Hp-O8 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 08:35:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DCZPje024161 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 08:35:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDN8O-0006Hc-9N for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 08:35: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 IAA08752 for ; Tue, 13 Apr 2004 08:35:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDN8M-0005lX-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 08:35:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDN6u-0005fm-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 08:33:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDN5i-0005Zm-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 08:32:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDN57-0005me-Dl; Tue, 13 Apr 2004 08:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDN4A-0005jp-0a for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 08: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 IAA08571 for ; Tue, 13 Apr 2004 08:31:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDN48-0005TD-00 for ipv6@ietf.org; Tue, 13 Apr 2004 08:31:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDN2s-0005MS-00 for ipv6@ietf.org; Tue, 13 Apr 2004 08:29:43 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BDN0H-00057B-00 for ipv6@ietf.org; Tue, 13 Apr 2004 08:27:01 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Apr 2004 08:26:13 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: A small clarification required Date: Tue, 13 Apr 2004 08:26:12 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42152.823516E0" Message-ID: Thread-Topic: A small clarification required Thread-Index: AcQhUfZLIHeIhovHT+e4SN++hAbo4gAANHBA From: "Soliman Hesham" To: "Jayabharathi" , X-OriginalArrivalTime: 13 Apr 2004 12:26:13.0107 (UTC) FILETIME=[82583430:01C42152] 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,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_FONT_BIG,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42152.823516E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 3316 intentionally doesn't address transition issues. These issues = are=20 addressed in the 3GPP scenarios and analysis drafts in v6ops.=20 =20 Hesham -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of Jayabharathi Sent: Tuesday, April 13, 2004 8:08 AM To: ipv6@ietf.org Subject: A small clarification required =20 In RFC 3316, "Internet Protocol Version 6 (IPv6) for Some Second and = Third Generation Cellular Hosts" why there are no transition mechanisms listed. Is there any assumption behind this, that always there will be a default router in the network (that one of =20 the transition mechanisms) to communicate with any site whether an IPv4 = or IPv6 in the internet? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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 ------_=_NextPart_001_01C42152.823516E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
RFC = 3316=20 intentionally doesn't address transition issues. These issues are=20
addressed in the=20 3GPP scenarios and analysis drafts in v6ops.
 
Hesham
-----Original Message-----
From: = ipv6-admin@ietf.org=20 [mailto:ipv6-admin@ietf.org]On Behalf Of = Jayabharathi
Sent:=20 Tuesday, April 13, 2004 8:08 AM
To: = ipv6@ietf.org
Subject:=20 A small clarification required

In RFC 3316, "Internet Protocol Version 6 (IPv6) for = Some=20 Second and Third Generation Cellular Hosts"

why there are no transition mechanisms listed.

Is there any assumption behind this, that always there will be a = default=20 router in the network (that one of  

the transition mechanisms) to communicate with any site whether an = IPv4 or=20 IPv6 in the internet?

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
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

------_=_NextPart_001_01C42152.823516E0-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 13 08:56: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 IAA09471 for ; Tue, 13 Apr 2004 08:56: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 1BDNRz-0002Zt-Br for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 08:55:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DCtdxB009901 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 08:55:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNRz-0002ZQ-62 for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 08:55: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 IAA09452 for ; Tue, 13 Apr 2004 08:55:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNRx-0006zD-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 08:55:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNQx-0006ts-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 08:54:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDNPk-0006pO-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 08:53:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNPR-0002AR-KF; Tue, 13 Apr 2004 08:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNOW-000222-8F for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 08:52: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 IAA09344 for ; Tue, 13 Apr 2004 08:52:00 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNOR-0006kh-00 for ipv6@ietf.org; Tue, 13 Apr 2004 08:51:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNNU-0006h7-00 for ipv6@ietf.org; Tue, 13 Apr 2004 08:51:01 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BDNMG-0006aU-00 for ipv6@ietf.org; Tue, 13 Apr 2004 08:49:44 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DCnSO07767; Tue, 13 Apr 2004 15:49:28 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 15:49:21 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3DCnLT4016473; Tue, 13 Apr 2004 15:49:21 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00mppP98; Tue, 13 Apr 2004 15:49:19 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DCmxs05237; Tue, 13 Apr 2004 15:48:59 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 15:44:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42155.08261D4C" Subject: RE: A small clarification required Date: Tue, 13 Apr 2004 15:44:16 +0300 Message-ID: Thread-Topic: A small clarification required Thread-Index: AcQhUptzhSipEp6yTWS2JyeO0e4fygAAghag To: , X-OriginalArrivalTime: 13 Apr 2004 12:44:25.0603 (UTC) FILETIME=[0D85DD30:01C42155] 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,HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42155.08261D4C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 At the time of writing, there were no requirements on transition. = Transition is being handled in the V6ops WG: http://www.ietf.org/html.charters/v6ops-charter.html =20 These documents deal with the transition issue: =20 Transition Scenarios for 3GPP Networks http://www.ietf.org/rfc/rfc3574.txt =20 and Analysis on IPv6 Transition in 3GPP Networks=20 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-09.txt= =20 thanks, John -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext = Jayabharathi Sent: 13 April, 2004 15:08 To: ipv6@ietf.org Subject: A small clarification required =20 In RFC 3316, "Internet Protocol Version 6 (IPv6) for Some Second and = Third Generation Cellular Hosts" why there are no transition mechanisms listed. Is there any assumption behind this, that always there will be a default = router in the network (that one of =20 the transition mechanisms) to communicate with any site whether an IPv4 = or IPv6 in the internet? ------_=_NextPart_001_01C42155.08261D4C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
At the = time of=20 writing, there were no requirements on transition. Transition is = being=20 handled in the V6ops WG:
http://www.= ietf.org/html.charters/v6ops-charter.html
 
These = documents deal=20 with the transition issue:
 
Transition Scenarios for 3GPP=20 Networks
http://www.ietf.org/rfc/rfc3= 574.txt
 
and
Analysis on = IPv6 Transition=20 in 3GPP Networks
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analy= sis-09.txt
 
thanks,
John
-----Original Message-----
From: = ipv6-admin@ietf.org=20 [mailto:ipv6-admin@ietf.org]On Behalf Of ext=20 Jayabharathi
Sent: 13 April, 2004 15:08
To:=20 ipv6@ietf.org
Subject: A small clarification=20 required

In RFC 3316, "Internet Protocol Version 6 (IPv6) for = Some=20 Second and Third Generation Cellular Hosts"

why there are no transition mechanisms listed.

Is there any assumption behind this, that always there will be a = default=20 router in the network (that one of  

the transition mechanisms) to communicate with any site whether an = IPv4 or=20 IPv6 in the internet?

------_=_NextPart_001_01C42155.08261D4C-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 13 09:58: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 JAA12383 for ; Tue, 13 Apr 2004 09:58: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 1BDOQj-0000fX-CB for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 09:58:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DDwP2O002567 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 09:58:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOQj-0000fK-6t for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 09:58: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 JAA12375 for ; Tue, 13 Apr 2004 09:58:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOQh-00049P-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 09:58:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDOPe-00044R-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 09:57:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDOOq-00040L-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 09:56:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOOR-0000OZ-Cf; Tue, 13 Apr 2004 09:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOOJ-0000Ne-W7 for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 09:55: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 JAA12313 for ; Tue, 13 Apr 2004 09:55:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOOH-0003yi-00 for ipv6@ietf.org; Tue, 13 Apr 2004 09:55:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDON6-0003tf-00 for ipv6@ietf.org; Tue, 13 Apr 2004 09:54:41 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BDOLl-0003n2-00 for ipv6@ietf.org; Tue, 13 Apr 2004 09:53:17 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5D66C15210 for ; Tue, 13 Apr 2004 22:53:07 +0900 (JST) Date: Tue, 13 Apr 2004 22:53:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis] what is the stateful configuration protocol 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 Regarding issue 277 of rfc2462bis (Semantics of M/O flags), one controversial issue is how clearly we should specify the stateful address configuration protocol. The question actually consists of the following two sub-questions: Question A: how should rfc2462bis specify the stateful protocol? possible answers: 1. clearly say that stateful address configuration is DHCPv6 2. (intentionally) do not say anything about this, and (implicitly or explicitly) leave it to the node requirements document Question B: which references should rfc2462bis have on this matter? possible answers: X. add an informative reference to RFC3315 Y. add an informative reference to node-req Z. add informative references to both RFC3315 and node-req W. do not add any references for this issue (neither RFC3315 nor node-req) Opinions vary through the discussion on the mailing list. The followings are main of them I've seen: Ralph Droms seems to prefer "1+X". http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01941.html John Loughney agreed with Ralph (though he did not show strong opinion of his own). http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01940.html Bernie Volz also seems to prefer "1+X". http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01912.html Dave Thaler seems to prefer "2+X" or "2+W". http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01918.html I personally do not have a strong opinion, but we need to move forward on this anyway. If I need to make a choice, I'd also agree with Ralph. In fact, I don't see why we cannot be clear on this after the publication of RFC3315. Perhaps we might want to leave possibilities of future extensions (including different "stateful" protocols than DHCPv6) by being unclear. But is this really a feasible reason? On the other hand, if we keep being unclear, future readers will keep wondering what is actually the stateful protocol or whether it's just enough to implement DHCPv6, etc. Even though the node requirement document would be able answer the question, they'll have to reach the document by themselves if we take Dave's suggestion. Is there any other reason for not being clear on this (i.e., not clearly say the stateful protocol is DHCPv6)? Or is this just a matter of preference? Again, I myself can live with any resolution as long as we can move forward. So, any productive comments or suggestions are welcome. 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 Tue Apr 13 10:32: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 KAA14881 for ; Tue, 13 Apr 2004 10: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 1BDOwt-0001Bv-SW for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 10:31:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DEVdqq004580 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 10:31:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOwr-0001A9-ED for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 10:31: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 KAA14867 for ; Tue, 13 Apr 2004 10:31:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOwo-0006T0-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 10:31:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDOv8-0006Md-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 10:29:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDOu2-0006G5-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 10:28:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOtP-0000eS-0o; Tue, 13 Apr 2004 10:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOsr-0000aM-5Y for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 10:27: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 KAA14554 for ; Tue, 13 Apr 2004 10:27:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOsm-00067b-00 for ipv6@ietf.org; Tue, 13 Apr 2004 10:27:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDOrQ-00061y-00 for ipv6@ietf.org; Tue, 13 Apr 2004 10:26:01 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BDOqC-0005tv-00 for ipv6@ietf.org; Tue, 13 Apr 2004 10:24:44 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW400I085C68U@mailout3.samsung.com> for ipv6@ietf.org; Tue, 13 Apr 2004 23:24:06 +0900 (KST) Received: from ep_ms3_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW40063R5C50W@mailout3.samsung.com> for ipv6@ietf.org; Tue, 13 Apr 2004 23:24:06 +0900 (KST) Received: from ep_spt02 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW400B7R5C5DX@ms3.samsung.com> for ipv6@ietf.org; Tue, 13 Apr 2004 23:24:05 +0900 (KST) Content-return: prohibited Date: Tue, 13 Apr 2004 14:24:12 +0000 (GMT) From: PARK SOO HONG Subject: Re :[rfc2462bis] what is the stateful configuration protocol X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2Jp?= =?windows-1252?B?bGUgUGxhdGZvcm0gTGFiP0VuZ2luZWVy?= To: JINMEI Tatuya / ???? , soohong.park@samsung.com Cc: "ipv6@ietf.org " Reply-to: soohong.park@samsung.com Message-id: <0HW400B7S5C5DX@ms3.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040413142358134@soohong.park X-MTR: 20040413142358134@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 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=1.7 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE, MIME_HTML_ONLY,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle I second 1+X.

AFAIC, from the beginning, this draft explicitly
considered DHCPv6 (though it was not RFC)
as a stateful mechanism.

"Stateful autoconfiguration is described in [DHCPv6]."
wrote in RFC1971, Aug. 1996.

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics


------- Original Message -------
Sender : JINMEI Tatuya / ????<jinmei@isl.rdc.toshiba.co.jp> jinmei@isl.rdc.toshiba.co.jp
Date : Apr 13, 2004 22:53
Title : [rfc2462bis] what is the stateful configuration protocol
Regarding issue 277 of rfc2462bis (Semantics of M/O flags), one
controversial issue is how clearly we should specify the stateful
address configuration protocol.

The question actually consists of the following two sub-questions:

Question A: how should rfc2462bis specify the stateful protocol?

possible answers:
  1. clearly say that stateful address configuration is DHCPv6
  2. (intentionally) do not say anything about this, and (implicitly
     or explicitly) leave it to the node requirements document

Question B: which references should rfc2462bis have on this matter?   

possible answers:
  X. add an informative reference to RFC3315
  Y. add an informative reference to node-req
  Z. add informative references to both RFC3315 and node-req
  W. do not add any references for this issue (neither RFC3315 nor node-req)

Opinions vary through the discussion on the mailing list.  The
followings are main of them I've seen:


Ralph Droms seems to prefer "1+X".
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01941.html

John Loughney agreed with Ralph (though he did not show strong opinion
of his own).
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01940.html

Bernie Volz also seems to prefer "1+X".
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01912.html

Dave Thaler seems to prefer "2+X" or "2+W".
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01918.html

I personally do not have a strong opinion, but we need to move forward
on this anyway.  If I need to make a choice, I'd also agree with
Ralph.  In fact, I don't see why we cannot be clear on this after the
publication of RFC3315.

Perhaps we might want to leave possibilities of future extensions
(including different "stateful" protocols than DHCPv6) by being
unclear.  But is this really a feasible reason?

On the other hand, if we keep being unclear, future readers will keep
wondering what is actually the stateful protocol or whether it's
just enough to implement DHCPv6, etc.  Even though the node
requirement document would be able answer the question, they'll have
to reach the document by themselves if we take Dave's suggestion.

Is there any other reason for not being clear on this (i.e., not
clearly say the stateful protocol is DHCPv6)?  Or is this just a
matter of preference?

Again, I myself can live with any resolution as long as we can move
forward.  So, any productive comments or suggestions are welcome.

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 Tue Apr 13 10:48:12 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 KAA15594 for ; Tue, 13 Apr 2004 10:48: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 1BDPBp-0002Gf-Ce for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 10:47:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DEl5jH008713 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 10:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDPBp-0002GS-93 for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 10:47: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 KAA15533 for ; Tue, 13 Apr 2004 10:47:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDPBm-0007Vc-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 10:47:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDPAi-0007SH-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 10:45:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDPA4-0007PE-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 10:45:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDP9q-0001vN-Bq; Tue, 13 Apr 2004 10: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 1BDP9j-0001uL-AQ for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 10:44: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 KAA15423 for ; Tue, 13 Apr 2004 10:44:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDP9g-0007OP-00 for ipv6@ietf.org; Tue, 13 Apr 2004 10:44:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDP8j-0007LS-00 for ipv6@ietf.org; Tue, 13 Apr 2004 10:43:53 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BDP7g-0007IC-00 for ipv6@ietf.org; Tue, 13 Apr 2004 10:42:49 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B4AF915210 for ; Tue, 13 Apr 2004 23:42:47 +0900 (JST) Date: Tue, 13 Apr 2004 23:42:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Re: [rfc2462bis] what is the stateful configuration protocol 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 Tue, 13 Apr 2004 22:53:07 +0900, >>>>> JINMEI Tatuya said: > Regarding issue 277 of rfc2462bis (Semantics of M/O flags), one > controversial issue is how clearly we should specify the stateful > address configuration protocol. (forgot to mention this) in this message, I intentionally concentrated on the stateful *address* configuration protocol. We'll also need a similar discussion about the stateful protocol for *other* configurations. However, things are much clearer for address configuration and it would help to limit the discussion scope for not making it unncessarily diverse. 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 Apr 13 11:03:01 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 LAA16142 for ; Tue, 13 Apr 2004 11:03:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDPQk-00038c-SE for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 11:02:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DF2Uti012058 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 11:02:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDPQk-00038P-OK for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 11:02: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 LAA16120 for ; Tue, 13 Apr 2004 11:02:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDPQi-0000rd-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 11:02:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDPPd-0000lb-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 11:01:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDPOs-0000gN-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 11:00:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDPOM-0002jD-Qb; Tue, 13 Apr 2004 11:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDPNf-0002hv-7H for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 10:59: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 KAA15962 for ; Tue, 13 Apr 2004 10:59:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDPNb-0000au-00 for ipv6@ietf.org; Tue, 13 Apr 2004 10:59:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDPMb-0000WQ-00 for ipv6@ietf.org; Tue, 13 Apr 2004 10:58:14 -0400 Received: from relay6.kornet.net ([211.48.62.166]) by ietf-mx with esmtp (Exim 4.12) id 1BDPLl-0000Qh-00 for ipv6@ietf.org; Tue, 13 Apr 2004 10:57:21 -0400 Received: from [221.147.173.240] (natpp00@kornet.net) by relay6.kornet.net (Terrace MailWatcher) with ESMTP id 2004041323:56:47:030745.7114.1062 for ; Tue, 13 Apr 2004 23:56:47 +0900 (KST) Message-ID: <007301c42167$8be38b70$f0ad93dd@shpark> From: "S. Daniel Park" To: Cc: "???" References: <1081864591502657886.0.ppp13@ppp13> Subject: Re: [rfc2462bis] what is the stateful configuration protocol Date: Tue, 13 Apr 2004 23:56:48 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: 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.5 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I second 1+X. AFAIC, from the beginning, this draft explicitly considered DHCPv6 (though it was not RFC) as a stateful mechanism. "Stateful autoconfiguration is described in [DHCPv6]." wrote in RFC1971, Aug. 1996. - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, Samsung Electronics. ----- Original Message ----- From: )> To: Sent: Tuesday, April 13, 2004 10:53 PM Subject: [rfc2462bis] what is the stateful configuration protocol > Regarding issue 277 of rfc2462bis (Semantics of M/O flags), one > controversial issue is how clearly we should specify the stateful > address configuration protocol. > > The question actually consists of the following two sub-questions: > > Question A: how should rfc2462bis specify the stateful protocol? > > possible answers: > 1. clearly say that stateful address configuration is DHCPv6 > 2. (intentionally) do not say anything about this, and (implicitly > or explicitly) leave it to the node requirements document > > Question B: which references should rfc2462bis have on this matter? > > possible answers: > X. add an informative reference to RFC3315 > Y. add an informative reference to node-req > Z. add informative references to both RFC3315 and node-req > W. do not add any references for this issue (neither RFC3315 nor node-req) > > Opinions vary through the discussion on the mailing list. The > followings are main of them I've seen: > > > Ralph Droms seems to prefer "1+X". > http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01941.html > > John Loughney agreed with Ralph (though he did not show strong opinion > of his own). > http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01940.html > > Bernie Volz also seems to prefer "1+X". > http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01912.html > > Dave Thaler seems to prefer "2+X" or "2+W". > http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01918.html > > I personally do not have a strong opinion, but we need to move forward > on this anyway. If I need to make a choice, I'd also agree with > Ralph. In fact, I don't see why we cannot be clear on this after the > publication of RFC3315. > > Perhaps we might want to leave possibilities of future extensions > (including different "stateful" protocols than DHCPv6) by being > unclear. But is this really a feasible reason? > > On the other hand, if we keep being unclear, future readers will keep > wondering what is actually the stateful protocol or whether it's > just enough to implement DHCPv6, etc. Even though the node > requirement document would be able answer the question, they'll have > to reach the document by themselves if we take Dave's suggestion. > > Is there any other reason for not being clear on this (i.e., not > clearly say the stateful protocol is DHCPv6)? Or is this just a > matter of preference? > > Again, I myself can live with any resolution as long as we can move > forward. So, any productive comments or suggestions are welcome. > > 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 Tue Apr 13 11:56:46 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 LAA18555 for ; Tue, 13 Apr 2004 11:56: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 1BDQGo-000704-CG for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 11:56:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DFuIhg026904 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 11:56:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDQGo-0006zr-7q for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 11:56: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 LAA18538 for ; Tue, 13 Apr 2004 11:56:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDQGm-0004j0-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 11:56:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDQFe-0004db-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 11:55:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDQEm-0004Z4-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 11:54:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDQEc-0006eK-OG; Tue, 13 Apr 2004 11:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDO2J-0006yJ-V9 for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 09:33: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 JAA11267 for ; Tue, 13 Apr 2004 09:33:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDO2G-00029W-00 for ipv6@ietf.org; Tue, 13 Apr 2004 09:33:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDO14-00025J-00 for ipv6@ietf.org; Tue, 13 Apr 2004 09:31:55 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BDNzm-0001wX-00 for ipv6@ietf.org; Tue, 13 Apr 2004 09:30:35 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <2LW94K23>; Tue, 13 Apr 2004 18:59:23 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D6B839F1@kavithai.ctd.hcltech.com> From: "Subramonia Pillai - CTD, Chennai" To: ipv6@ietf.org Subject: RFC 2461 : Neighbor Discovery Date: Tue, 13 Apr 2004 18:59:44 +0530 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.0 required=5.0 tests=none autolearn=no version=2.60 Hi, For IPv6, Should we run Neighbor Discovery protocol over PPP links? Thanks Subu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 13 14:53:22 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 OAA27224 for ; Tue, 13 Apr 2004 14:53: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 1BDSwE-0002dP-Rx for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 14:47:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DIlEgc010124 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 14:47:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDSsb-0002Dy-48 for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 14:43: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 OAA26879 for ; Tue, 13 Apr 2004 14:43:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDSsX-0004K1-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 14:43:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDSr3-0004CN-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 14:41:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDSpG-000447-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 14:40:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDShW-0000di-M9; Tue, 13 Apr 2004 14:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDSbX-0008OD-N3 for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 14:25: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 OAA26093 for ; Tue, 13 Apr 2004 14:25:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDSbS-0002ll-00 for ipv6@ietf.org; Tue, 13 Apr 2004 14:25:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDSa3-0002fu-00 for ipv6@ietf.org; Tue, 13 Apr 2004 14:24:20 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BDSZR-0002aT-00 for ipv6@ietf.org; Tue, 13 Apr 2004 14:23:41 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3DINUHS007108 for ; Tue, 13 Apr 2004 12:23:31 -0600 (MDT) Received: from fe8 (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 <0HW400HAFGF6UG@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Tue, 13 Apr 2004 12:23:30 -0600 (MDT) Received: from sun.com ([129.153.122.30]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HW400C0RGF5E4@mail.sun.net> for ipv6@ietf.org; Tue, 13 Apr 2004 12:23:30 -0600 (MDT) Date: Tue, 13 Apr 2004 11:23:29 -0700 From: Alain Durand Subject: Re: [rfc2462bis] what is the stateful configuration protocol In-reply-to: To: ipv6@ietf.org Message-id: <407C3021.6020001@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20030711 References: 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: > >Question A: how should rfc2462bis specify the stateful protocol? > >possible answers: > 1. clearly say that stateful address configuration is DHCPv6 > 2. (intentionally) do not say anything about this, and (implicitly > or explicitly) leave it to the node requirements document > 1. We have DHCPv6. Let's just use it and stop confusing people with the notion that there might be another stateful address configuration protocol. >Question B: which references should rfc2462bis have on this matter? > >possible answers: > X. add an informative reference to RFC3315 > Y. add an informative reference to node-req > Z. add informative references to both RFC3315 and node-req > W. do not add any references for this issue (neither RFC3315 nor node-req) > X. make it simple. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 13 15:07:57 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 PAA28502 for ; Tue, 13 Apr 2004 15: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 1BDTCp-0001DB-NF for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 15:04:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DJ4NC4004652 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 15:04:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDT4j-0003pS-Pl for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 14:56: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 OAA27380 for ; Tue, 13 Apr 2004 14:55:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDT4f-0005Nv-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 14:55:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDT3E-0005EE-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 14:54:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDT1v-00057z-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 14:53:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDSw2-0002aH-6R; Tue, 13 Apr 2004 14:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDSqL-00022j-9r for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 14:41: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 OAA26775 for ; Tue, 13 Apr 2004 14:41:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDSqI-00046h-00 for ipv6@ietf.org; Tue, 13 Apr 2004 14:41:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDSnu-0003wi-00 for ipv6@ietf.org; Tue, 13 Apr 2004 14:38:38 -0400 Received: from [194.15.141.71] (helo=laptop2.kurtis.pp.se) by ietf-mx with esmtp (Exim 4.12) id 1BDSmt-0003oz-00 for ipv6@ietf.org; Tue, 13 Apr 2004 14:37:35 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id A4B2B3871CF; Tue, 13 Apr 2004 20:37:24 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=UTF-8; format=fixed Message-Id: <94E52BA8-8D79-11D8-A2E0-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org From: Kurt Erik Lindqvist Subject: Re: [rfc2462bis] what is the stateful configuration protocol Date: Tue, 13 Apr 2004 20:37:13 +0200 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.613) 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.2 required=5.0 tests=AWL,UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-04-13, at 15.53, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 wrote: > Is there any other reason for not being clear on this (i.e., not > clearly say the stateful protocol is DHCPv6)? Or is this just a > matter of preference? I would prefer 2+Y. Simply to minimize dependencies... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQHwzXKarNKXTPFCVEQLqfwCg3yZRtkYnZ/lBOgIgZUlBkIo12OIAnivo gA80dTpOqPsNpwmjzmrlkixU =3Dehoy -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 13 15:41:25 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 PAA02265 for ; Tue, 13 Apr 2004 15:41: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 1BDTbo-0002Wz-I8 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 15:30:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DJUChn009724 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 15:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTZ7-00025D-0k for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 15:27: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 PAA01247 for ; Tue, 13 Apr 2004 15:27:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTZ5-000071-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 15:27:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTXk-0007nd-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 15:26:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDTWF-0007fd-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 15:24:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTO6-0007sl-78; Tue, 13 Apr 2004 15:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTDm-0001jl-Jh for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 15:05: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 PAA28007 for ; Tue, 13 Apr 2004 15:05:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTDi-00065v-00 for ipv6@ietf.org; Tue, 13 Apr 2004 15:05:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTCR-00060h-00 for ipv6@ietf.org; Tue, 13 Apr 2004 15:04:00 -0400 Received: from [194.15.141.71] (helo=laptop2.kurtis.pp.se) by ietf-mx with esmtp (Exim 4.12) id 1BDTBc-0005wI-00 for ipv6@ietf.org; Tue, 13 Apr 2004 15:03:08 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 107E238737B; Tue, 13 Apr 2004 21:03:05 +0200 (CEST) In-Reply-To: <94E52BA8-8D79-11D8-A2E0-000A95928574@kurtis.pp.se> References: <94E52BA8-8D79-11D8-A2E0-000A95928574@kurtis.pp.se> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=UTF-8; format=fixed Message-Id: <29742C9D-8D7D-11D8-A2E0-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= From: Kurt Erik Lindqvist Subject: Re: [rfc2462bis] what is the stateful configuration protocol Date: Tue, 13 Apr 2004 21:02:51 +0200 To: Kurt Erik Lindqvist X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.613) 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-04-13, at 20.37, Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 2004-04-13, at 15.53, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 wrote: > >> Is there any other reason for not being clear on this (i.e., not >> clearly say the stateful protocol is DHCPv6)? Or is this just a >> matter of preference? > > I would prefer 2+Y. Simply to minimize dependencies... After reading the first mail a bit closer...I am all for referring to=20 DHCPv6, I was arguing for not making a direct reference to the RFC but=20= rather to the node-req document. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQHw5X6arNKXTPFCVEQJEHgCffOSvNFLZf7r38dKKt89gtjnLUa0AoI5g DXQvB8suMdWQt6Zu4c1Mh0p5 =3DkS0m -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 13 16:05:23 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 QAA03549 for ; Tue, 13 Apr 2004 16:05: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 1BDTnT-0004HF-P0 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 15:42:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DJgFW5016433 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 15:42:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTd3-0002l6-Mm for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 15:31: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 PAA01579 for ; Tue, 13 Apr 2004 15:31:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTd1-0000WC-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 15:31:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTbZ-0000N5-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 15:29:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDTaG-0000Dj-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 15:28:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTQ1-0000BE-Tw; Tue, 13 Apr 2004 15: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 1BDTLp-0006vN-1a for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 15:13: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 PAA29520 for ; Tue, 13 Apr 2004 15:13:39 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTLn-0006kK-00 for ipv6@ietf.org; Tue, 13 Apr 2004 15:13:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTKO-0006eZ-00 for ipv6@ietf.org; Tue, 13 Apr 2004 15:12:13 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BDTJS-0006Yh-00 for ipv6@ietf.org; Tue, 13 Apr 2004 15:11:14 -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 i3DJB3n06289; Tue, 13 Apr 2004 22:11:04 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 22:10:47 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3DJAlGe016613; Tue, 13 Apr 2004 22:10:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00RC6leN; Tue, 13 Apr 2004 22:10:45 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DJAUs00419; Tue, 13 Apr 2004 22:10:30 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 22:10:26 +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: [rfc2462bis] what is the stateful configuration protocol Date: Tue, 13 Apr 2004 22:10:26 +0300 Message-ID: Thread-Topic: [rfc2462bis] what is the stateful configuration protocol Thread-Index: AcQhhq93jYmzqYI6R+Ct3LKKPK6FFwABC9NQ To: , X-OriginalArrivalTime: 13 Apr 2004 19:10:26.0953 (UTC) FILETIME=[FAC36790:01C4218A] 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, > >Question A: how should rfc2462bis specify the stateful protocol? > > > >possible answers: > > 1. clearly say that stateful address configuration is DHCPv6 > > 2. (intentionally) do not say anything about this, and (implicitly > > or explicitly) leave it to the node requirements document > > >=20 > 1. We have DHCPv6. Let's just use it and stop confusing people > with the notion that there might be another stateful address=20 > configuration protocol. >=20 > >Question B: which references should rfc2462bis have on this=20 > matter? =20 > > > >possible answers: > > X. add an informative reference to RFC3315 > > Y. add an informative reference to node-req > > Z. add informative references to both RFC3315 and node-req > > W. do not add any references for this issue (neither=20 > RFC3315 nor node-req) > > >=20 > X. make it simple. I agree with X. Y would make node-req specify more than the original RFC, which is not the purpose. 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 Apr 13 17:57: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 RAA12204 for ; Tue, 13 Apr 2004 17:57: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 1BDVq1-0001Uh-Et for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 17:53:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DLr1WE005706 for ipv6-archive@odin.ietf.org; Tue, 13 Apr 2004 17:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVfH-0007Dz-8C for ipv6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 17:41: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 RAA11276 for ; Tue, 13 Apr 2004 17:41:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVfD-00062E-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 17:41:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDVSf-0004u7-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 17:28:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDVHj-0003lf-00 for ipv6-web-archive@ietf.org; Tue, 13 Apr 2004 17:17:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUzo-0003dK-Qu; Tue, 13 Apr 2004 16:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTto-00057y-3q for ipv6@optimus.ietf.org; Tue, 13 Apr 2004 15:48: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 PAA02600 for ; Tue, 13 Apr 2004 15:48:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTtl-0002BH-00 for ipv6@ietf.org; Tue, 13 Apr 2004 15:48:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTqR-0001vP-00 for ipv6@ietf.org; Tue, 13 Apr 2004 15:45:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BDTo1-0001aA-00 for ipv6@ietf.org; Tue, 13 Apr 2004 15:42:49 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2004 12:36:26 -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 i3DJgDCE003138 for ; Tue, 13 Apr 2004 15:42:15 -0400 (EDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO43313; Tue, 13 Apr 2004 15:42:13 -0400 (EDT) From: "Bernie Volz" To: Subject: RE: [rfc2462bis] what is the stateful configuration protocol Date: Tue, 13 Apr 2004 15:42:12 -0400 Organization: Cisco Message-ID: <003301c4218f$6ad32940$d0412ca1@amer.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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: 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 for (1) DHCPv6 and a reference to RFC 3315 (X). - Bernie Volz -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of john.loughney@nokia.com Sent: Tuesday, April 13, 2004 3:10 PM To: Alain.Durand@Sun.COM; ipv6@ietf.org Subject: RE: [rfc2462bis] what is the stateful configuration protocol Hi all, > >Question A: how should rfc2462bis specify the stateful protocol? > > > >possible answers: > > 1. clearly say that stateful address configuration is DHCPv6 > > 2. (intentionally) do not say anything about this, and (implicitly > > or explicitly) leave it to the node requirements document > > > > 1. We have DHCPv6. Let's just use it and stop confusing people with > the notion that there might be another stateful address configuration > protocol. > > >Question B: which references should rfc2462bis have on this > matter? > > > >possible answers: > > X. add an informative reference to RFC3315 > > Y. add an informative reference to node-req > > Z. add informative references to both RFC3315 and node-req > > W. do not add any references for this issue (neither > RFC3315 nor node-req) > > > > X. make it simple. I agree with X. Y would make node-req specify more than the original RFC, which is not the purpose. John -------------------------------------------------------------------- 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 Apr 14 02:18: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 CAA20245 for ; Wed, 14 Apr 2004 02:18: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 1BDdcA-0003dg-GW for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 02:11:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E6BEHc013972 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 02: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 1BDdYR-0001Ya-Qp for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 02:07: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 CAA11452 for ; Wed, 14 Apr 2004 02:07:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDdYO-0003ik-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 02:07:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDdXZ-0003ZG-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 02:06:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDdWh-0003R8-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 02:05:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDdI7-0003qW-Ow; Wed, 14 Apr 2004 01:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDd2R-0001Xt-5W for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 01:34: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 BAA03149 for ; Wed, 14 Apr 2004 01:34:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDd2O-0007ZE-00 for ipv6@ietf.org; Wed, 14 Apr 2004 01:34:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDd1R-0007Sz-00 for ipv6@ietf.org; Wed, 14 Apr 2004 01:33:17 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BDd0W-0007Gj-00 for ipv6@ietf.org; Wed, 14 Apr 2004 01:32:21 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <2LW94YXC>; Wed, 14 Apr 2004 11:01:12 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D6B83E57@kavithai.ctd.hcltech.com> From: "Subramonia Pillai - CTD, Chennai" To: ipv6@ietf.org Subject: RFC 2461 : Neighbor Discovery Date: Wed, 14 Apr 2004 11:01:37 +0530 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.0 required=5.0 tests=none autolearn=no version=2.60 Hi, I am running IPV6CP for PPP links. I will come to know the link local address from IPV6CP itself. I can also derive (global eui-64 based) global unicast address based on IPV6CP identifier. My doubt is "Should I run ND on PPP links in addition?" Can any one please tell me with the reason? Thanks Subu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 14 02:45: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 CAA04387 for ; Wed, 14 Apr 2004 02:45: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 1BDe6y-0004dx-3i for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 02:43:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E6h4EN017840 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 02:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDe5G-0004Hw-Aa for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 02:41: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 CAA03972 for ; Wed, 14 Apr 2004 02:41:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDe5C-0007kB-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 02:41:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDe4L-0007dZ-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 02:40:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDe3b-0007XL-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 02:39:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDdyG-0002is-95; Wed, 14 Apr 2004 02:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDduP-0001gp-Sm for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 02:30: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 CAA01356 for ; Wed, 14 Apr 2004 02:30:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDduM-00067x-00 for ipv6@ietf.org; Wed, 14 Apr 2004 02:30:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDdtD-0005v3-00 for ipv6@ietf.org; Wed, 14 Apr 2004 02:28:51 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BDdru-0005eI-00 for ipv6@ietf.org; Wed, 14 Apr 2004 02:27:30 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Apr 2004 02:26:48 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: RFC 2461 : Neighbor Discovery Date: Wed, 14 Apr 2004 02:26:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: RFC 2461 : Neighbor Discovery Thread-Index: AcQh5nP3QBf4rcq5TF+nkGgCJ194NQAAXrfA From: "Soliman Hesham" To: "Subramonia Pillai - CTD, Chennai" , X-OriginalArrivalTime: 14 Apr 2004 06:26:48.0778 (UTC) FILETIME=[776A7AA0:01C421E9] 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 am running IPV6CP for PPP links. I will come to know the link local > address from IPV6CP itself. I can also derive (global eui-64=20 > based) global > unicast address based on IPV6CP identifier. >=20 > My doubt is "Should I run ND on PPP links in addition?" Can=20 > any one please > tell me with the reason? =3D> Do you want to configure a global address? If you do then you need RFC 2461. Also you might=20 need the NUD features in RFC2461 to detect reachability of the default router.=20 Hesham >=20 > Thanks > Subu >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=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 Wed Apr 14 05:44: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 FAA12180 for ; Wed, 14 Apr 2004 05:44: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 1BDgoO-0002QF-Qe for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 05:36:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E9a4Tt009306 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 05:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDge9-0000Gl-33 for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 05:25: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 FAA11355 for ; Wed, 14 Apr 2004 05:25:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDge5-00036Z-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 05:25:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDgbS-0002pe-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 05:22:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDgXq-0002aO-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 05:18:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDgNI-0005TA-VQ; Wed, 14 Apr 2004 05:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDgFv-0003c1-EC for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 05:00: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 FAA10536 for ; Wed, 14 Apr 2004 05:00:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDgFr-0000H1-00 for ipv6@ietf.org; Wed, 14 Apr 2004 05:00:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDgEu-0000AJ-00 for ipv6@ietf.org; Wed, 14 Apr 2004 04:59:25 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BDgE4-0007kp-00 for ipv6@ietf.org; Wed, 14 Apr 2004 04:58:32 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <2LW9VBQW>; Wed, 14 Apr 2004 14:27:26 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D6B84459@kavithai.ctd.hcltech.com> From: "Subramonia Pillai - CTD, Chennai" To: Soliman Hesham , ipv6@ietf.org Subject: RE: RFC 2461 : Neighbor Discovery Date: Wed, 14 Apr 2004 14:27:59 +0530 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.0 required=5.0 tests=none autolearn=no version=2.60 Hi Hesham, >From router point of view, global address can be get from Configuration. So I am still thinking, for router case do we need ND? Thanks in advance Subu -----Original Message----- From: Soliman Hesham [mailto:H.Soliman@flarion.com] Sent: Wednesday, April 14, 2004 11:57 AM To: Subramonia Pillai - CTD, Chennai; ipv6@ietf.org Subject: RE: RFC 2461 : Neighbor Discovery > I am running IPV6CP for PPP links. I will come to know the link local > address from IPV6CP itself. I can also derive (global eui-64 > based) global > unicast address based on IPV6CP identifier. > > My doubt is "Should I run ND on PPP links in addition?" Can > any one please > tell me with the reason? => Do you want to configure a global address? If you do then you need RFC 2461. Also you might need the NUD features in RFC2461 to detect reachability of the default router. Hesham > > Thanks > Subu > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. ======================================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 14 06:53: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 GAA16346 for ; Wed, 14 Apr 2004 06:53: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 1BDhxz-0000Cn-Ia for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 06:50:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EAo3Mi000782 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 06:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhpj-0007NT-Qr for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 06:41: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 GAA15870 for ; Wed, 14 Apr 2004 06:41:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDhpf-0004je-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 06:41:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDhok-0004cO-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 06:40:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDho6-0004Vf-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 06:39:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhed-0004pk-SD; Wed, 14 Apr 2004 06:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhUT-0002hd-06 for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 06:19: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 GAA13762 for ; Wed, 14 Apr 2004 06:19:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDhUP-0002AB-00 for ipv6@ietf.org; Wed, 14 Apr 2004 06:19:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDhTb-00022r-00 for ipv6@ietf.org; Wed, 14 Apr 2004 06:18:39 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BDhSp-0001s5-00 for ipv6@ietf.org; Wed, 14 Apr 2004 06:17:51 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Apr 2004 06:17:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Subject: RE: RFC 2461 : Neighbor Discovery Date: Wed, 14 Apr 2004 06:17:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: RFC 2461 : Neighbor Discovery Thread-Index: AcQh/pyX7gzE6I1jSXK3jyzBmnM7TAACWBww From: "Soliman Hesham" To: "Subramonia Pillai - CTD, Chennai" , X-OriginalArrivalTime: 14 Apr 2004 10:17:19.0055 (UTC) FILETIME=[AAE745F0:01C42209] 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 > From router point of view, global address can be get from=20 > Configuration. So > I am still thinking, for router case do we need ND? =3D> Do you think hosts connected to your router=20 will need the information I mentioned in the last=20 email? If yes, they will send RSs.=20 I don't know what you're using the router for but I don't know of any case where I can categorically say don't implement RFC 2461. I think that it's=20 basically always needed. If for nothing else, a host might want to use NUD for reachability confirmation. Hesham >=20 > Thanks in advance > Subu >=20 > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: Wednesday, April 14, 2004 11:57 AM > To: Subramonia Pillai - CTD, Chennai; ipv6@ietf.org > Subject: RE: RFC 2461 : Neighbor Discovery >=20 >=20 >=20 > > I am running IPV6CP for PPP links. I will come to know=20 > the link local > > address from IPV6CP itself. I can also derive (global eui-64=20 > > based) global > > unicast address based on IPV6CP identifier. > >=20 > > My doubt is "Should I run ND on PPP links in addition?" Can=20 > > any one please > > tell me with the reason? >=20 > =3D> Do you want to configure a global address? > If you do then you need RFC 2461. Also you might=20 > need the NUD features in RFC2461 to detect reachability > of the default router.=20 >=20 > Hesham >=20 > >=20 > > Thanks > > Subu > >=20 > >=20 > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests:=20 https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=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 Wed Apr 14 07:11:23 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 HAA16961 for ; Wed, 14 Apr 2004 07:11:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDiGE-0004LV-Jz for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 07:08:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EB8sxE016691 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 07:08:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDiC0-0003By-Q0 for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 07:04: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 HAA16842 for ; Wed, 14 Apr 2004 07:04:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDiBw-0007Sw-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 07:04:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDiAw-0007My-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 07:03:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDiAe-0007HB-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 07:03:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDi1q-0001Xt-82; Wed, 14 Apr 2004 06:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhzJ-0000af-Rg for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 06:51: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 GAA16292 for ; Wed, 14 Apr 2004 06:51:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDhzF-0005uF-00 for ipv6@ietf.org; Wed, 14 Apr 2004 06:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDhyL-0005nl-00 for ipv6@ietf.org; Wed, 14 Apr 2004 06:50:25 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BDhxV-0005c0-00 for ipv6@ietf.org; Wed, 14 Apr 2004 06:49:33 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 14 Apr 2004 03:49:08 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3EAn2BB003736 for ; Wed, 14 Apr 2004 03:49:02 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-546.cisco.com [10.82.226.34]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO82427; Wed, 14 Apr 2004 06:49:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Apr 2004 06:48:57 -0400 To: ipv6@ietf.org From: Ralph Droms Subject: Re: [rfc2462bis] what is the stateful configuration protocol 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 Jinmei-san, I think DHCPv6 ought to be cited as the protocol for other configuration information, as well. However, it seems to me the phrase "stateful protocol for *other* configurations" is a little misleading. I think the word "stateful" could be dropped. - Ralph At 11:42 PM 4/13/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Tue, 13 Apr 2004 22:53:07 +0900, > >>>>> JINMEI Tatuya said: > > > Regarding issue 277 of rfc2462bis (Semantics of M/O flags), one > > controversial issue is how clearly we should specify the stateful > > address configuration protocol. > >(forgot to mention this) in this message, I intentionally concentrated >on the stateful *address* configuration protocol. We'll also need a >similar discussion about the stateful protocol for *other* >configurations. However, things are much clearer for address >configuration and it would help to limit the discussion scope for not >making it unncessarily diverse. > > 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 Wed Apr 14 07:45: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 HAA18341 for ; Wed, 14 Apr 2004 07:45: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 1BDila-0002Sq-PH for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 07:41:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EBfIpX009465 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 07:41:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDihq-0001Ss-UG for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 07: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 HAA18027 for ; Wed, 14 Apr 2004 07:37:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDihq-0003kf-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 07:37:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDigr-0003dT-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 07:36:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDifx-0003WX-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 07:35:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDiZk-0007yd-HM; Wed, 14 Apr 2004 07:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDiTO-0006TL-8U for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 07:22: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 HAA17577 for ; Wed, 14 Apr 2004 07:22:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDiTN-0001ue-00 for ipv6@ietf.org; Wed, 14 Apr 2004 07:22:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDiSR-0001nx-00 for ipv6@ietf.org; Wed, 14 Apr 2004 07:21:31 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDiRx-0001gX-00 for ipv6@ietf.org; Wed, 14 Apr 2004 07:21:01 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3EBKk1C076242; Wed, 14 Apr 2004 13:20:46 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> References: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: [rfc2462bis] what is the stateful configuration protocol Date: Wed, 14 Apr 2004 13:20:42 +0200 To: Ralph Droms 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 On 14-apr-04, at 12:48, Ralph Droms wrote: > I think DHCPv6 ought to be cited as the protocol for other > configuration > information, as well. > However, it seems to me the phrase "stateful protocol for *other* > configurations" is a little misleading. I think the word "stateful" > could > be dropped. And terminally confuse everyone who has ever read RFC2462? It seems to me that having one bit to indicate the protocol to be used for configuration isn't all that much. Why not expand both fields to 4 bits, and then have the IANA maintain a registry? This could look something like: 0000 = RA 0001 - 0111 = TBD, fall back on RA (extra bits could be ignored as per RFC2641) 1000 = DHCPv6, handling of RA undefined 1001 = DHCPv6, RA is ignored 1010 = DHCPv6 + RA 1011 - 1111 = TBD -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 14 09:09: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 JAA22699 for ; Wed, 14 Apr 2004 09:09: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 1BDk01-0001A0-Ow for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 09:00:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ED0HV4004449 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 09:00:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDjse-0007sS-0h for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 08:52: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 IAA21885 for ; Wed, 14 Apr 2004 08:52:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDjsc-0006Uv-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 08:52:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDjro-0006O4-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 08:51:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDjrQ-0006Fw-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 08:51:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDjkJ-00068B-85; Wed, 14 Apr 2004 08:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDjf1-00050g-LJ for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 08:38: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 IAA21027 for ; Wed, 14 Apr 2004 08:38:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDjf0-00048x-00 for ipv6@ietf.org; Wed, 14 Apr 2004 08:38:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDje3-0003zb-00 for ipv6@ietf.org; Wed, 14 Apr 2004 08:37:36 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BDjd2-0003jn-00 for ipv6@ietf.org; Wed, 14 Apr 2004 08:36:32 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 14 Apr 2004 05:36:06 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3ECZuBB017553 for ; Wed, 14 Apr 2004 05:35:57 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-20.cisco.com [10.86.242.20]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO85958; Wed, 14 Apr 2004 08:35:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20040414080754.022e8848@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Apr 2004 08:35:53 -0400 To: ipv6@ietf.org From: Ralph Droms Subject: Re: [rfc2462bis] what is the stateful configuration protocol In-Reply-To: References: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> <4.3.2.7.2.20040413155905.022eb4b0@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 I suggest dropping "stateful" from the description because of the potential for confusion inherent in providing a "stateful protocol for *other* configurations" with "stateless DHCPv6" [RFC 3736]. This confusion arises from the unfortunate decision to differentiate RFC 2462 address assignment from DHCP-based address assignment by designating the former "stateless" and the latter "stateful". That difference is more accurately captured in RFC 2461bis by describing RFC 2462 address assignment as autonomous. But, "stateless address autoconfiguration" is the accepted phrase with wide dissemination at this point... In any event, perhaps the best way to simplify the protocol would be to drop the "O" bit altogether. That is, make no attempt to control how a host goes about finding the additional configuration information. There was a brief discussion about this issue at an IPv6 WG interim meeting (Aug 2002?). If I remember correctly, and at the risk of over-simplification, the point of the discussion was that, if I'm a network administrator, under what circumstances would I ever want to set the 'O' bit so that a device does not use all available mechanisms to obtain other configuration information? - Ralph At 01:20 PM 4/14/2004 +0200, Iljitsch van Beijnum wrote: >On 14-apr-04, at 12:48, Ralph Droms wrote: > >>I think DHCPv6 ought to be cited as the protocol for other configuration >>information, as well. > >>However, it seems to me the phrase "stateful protocol for *other* >>configurations" is a little misleading. I think the word "stateful" could >>be dropped. > >And terminally confuse everyone who has ever read RFC2462? > >It seems to me that having one bit to indicate the protocol to be used for >configuration isn't all that much. Why not expand both fields to 4 bits, >and then have the IANA maintain a registry? This could look something like: > >0000 = RA >0001 - 0111 = TBD, fall back on RA (extra bits could be ignored as per >RFC2641) >1000 = DHCPv6, handling of RA undefined >1001 = DHCPv6, RA is ignored >1010 = DHCPv6 + RA >1011 - 1111 = TBD -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 14 13:26: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 NAA08857 for ; Wed, 14 Apr 2004 13:26: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 1BDo13-0001Mp-Gj for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 13:17:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EHHb63005255 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 13:17:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnm9-0006HV-AB for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 13:02: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 NAA06549 for ; Wed, 14 Apr 2004 13:02:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnm7-0007dp-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 13:02:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnlI-0007Yg-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 13:01:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDnkY-0007Rv-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 13:00:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnCV-0005QR-4J; Wed, 14 Apr 2004 12:25:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmyf-0002u1-KE for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 12:11: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 MAA03598 for ; Wed, 14 Apr 2004 12:11:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmye-0003wj-00 for ipv6@ietf.org; Wed, 14 Apr 2004 12:11:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmxs-0003vP-00 for ipv6@ietf.org; Wed, 14 Apr 2004 12:10:17 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1BDmxQ-0003sF-00 for ipv6@ietf.org; Wed, 14 Apr 2004 12:09:48 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3EG9kWo003955 for ; Wed, 14 Apr 2004 10:09:46 -0600 (MDT) Received: from xpa-fe1 (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 <0HW600CJ64W9BT@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 14 Apr 2004 10:09:46 -0600 (MDT) Received: from [192.168.1.101] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HW6002884W8VI@mail.sun.net> for ipv6@ietf.org; Wed, 14 Apr 2004 10:09:45 -0600 (MDT) Date: Wed, 14 Apr 2004 09:09:44 -0700 From: Alain Durand Subject: Re: [rfc2462bis] what is the stateful configuration protocol In-reply-to: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> To: Ralph Droms Cc: ipv6@ietf.org Message-id: <24E3F5F0-8E2E-11D8-A336-00039358A080@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: <4.3.2.7.2.20040413155905.022eb4b0@flask.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 Apr 14, 2004, at 3:48 AM, Ralph Droms wrote: > Jinmei-san, > > I think DHCPv6 ought to be cited as the protocol for other > configuration > information, as well. This is the logical extension. > However, it seems to me the phrase "stateful protocol for *other* > configurations" is a little misleading. I think the word "stateful" > could > be dropped. Hummm, what about a DHCPv6 server that would return different values of some config parameters for different requesting nodes? I think the whole notion of stateful vs stateless is a bit misleading/confusing anyway, so maybe you're right, we should drop the word. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 14 13:26: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 NAA08862 for ; Wed, 14 Apr 2004 13:26: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 1BDo1D-0001V0-Fq for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 13:17:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EHHlLX005752 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 13:17:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnp5-0006fu-2E for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 13:05: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 NAA06878 for ; Wed, 14 Apr 2004 13:05:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnp3-00006r-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 13:05:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnoH-00003S-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 13:04:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDnnc-0007n5-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 13:03:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnCZ-0005RV-9V; Wed, 14 Apr 2004 12:25:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDn8X-0004T6-8p for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 12:21: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 MAA03858 for ; Wed, 14 Apr 2004 12:21:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDn8V-0004LK-00 for ipv6@ietf.org; Wed, 14 Apr 2004 12:21:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDn7W-0004HM-00 for ipv6@ietf.org; Wed, 14 Apr 2004 12:20:15 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BDn78-0004EY-00 for ipv6@ietf.org; Wed, 14 Apr 2004 12:19:50 -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); Wed, 14 Apr 2004 09:19:21 -0700 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 14 Apr 2004 09:19:19 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Apr 2004 09:19:20 -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); Wed, 14 Apr 2004 09:20:13 -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, 14 Apr 2004 09:19: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rfc2462bis] what is the stateful configuration protocol Date: Wed, 14 Apr 2004 09:19:16 -0700 Message-ID: Thread-Topic: [rfc2462bis] what is the stateful configuration protocol thread-index: AcQiHxrSHdS5XZdgQDuvixzmeVN3LwAHO/cQ From: "Christian Huitema" To: "Ralph Droms" , X-OriginalArrivalTime: 14 Apr 2004 16:19:18.0448 (UTC) FILETIME=[3CABA300:01C4223C] 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 > In any event, perhaps the best way to simplify the protocol would be to > drop > the "O" bit altogether. That is, make no attempt to control how a host > goes > about finding the additional configuration information. There was a brief > discussion about this issue at an IPv6 WG interim meeting (Aug 2002?). If > I remember correctly, and at the risk of over-simplification, the > point of the discussion was that, if I'm a network administrator, under > what > circumstances would I ever want to set the 'O' bit so that a device does > not > use all available mechanisms to obtain other configuration information? If we want to drop bits, I would rather drop the 'M' bit, to reflect the consensus that autonomous allocation of addresses is the norm (MUST implement) and that allocation through DHCP is an optional facility. -- 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 Wed Apr 14 14:03: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 OAA11447 for ; Wed, 14 Apr 2004 14:03: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 1BDoQt-00014k-SN for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 13:44:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EHiJLi004127 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 13:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoNm-0008Jd-Uq for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 13:41: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 NAA09985 for ; Wed, 14 Apr 2004 13:41:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDoNk-00030y-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 13:41:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDoMq-0002y7-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 13:40:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDoLy-0002w4-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 13:39:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDo7G-0003ae-3d; Wed, 14 Apr 2004 13: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 1BDnxd-00008Z-OZ for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 13:14: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 NAA07440 for ; Wed, 14 Apr 2004 13:14:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnxb-0000oL-00 for ipv6@ietf.org; Wed, 14 Apr 2004 13:14:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnwg-0000iB-00 for ipv6@ietf.org; Wed, 14 Apr 2004 13:13:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BDnvV-0000Wt-00 for ipv6@ietf.org; Wed, 14 Apr 2004 13:11:54 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 14 Apr 2004 10:22:43 -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 i3EHBKNP028523 for ; Wed, 14 Apr 2004 13:11:21 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-91.cisco.com [10.86.242.91]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHP09546; Wed, 14 Apr 2004 13:11:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20040414130305.02c438e0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Apr 2004 13:11:17 -0400 To: ipv6@ietf.org From: Ralph Droms Subject: Re: [rfc2462bis] what is the stateful configuration protocol In-Reply-To: <24E3F5F0-8E2E-11D8-A336-00039358A080@sun.com> References: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> <4.3.2.7.2.20040413155905.022eb4b0@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 Followup on the meaning of "stateless" - one way to interpret "stateless" in the context of DHCPv6 is: "does not require the maintenance of any dynamic state for individual clients" (RFC 3736). The server does, of course, maintain configuration state and can make decisions about the response sent to any specific client based on the server's configuration. (And, autonomous address assignment isn't "stateless" - the source of the RAs maintains configuration state, the host maintains state about the addresses it has selected.) So, "stateless" really is misleading. "Autonomous/managed" or "serverless/server-based" might be more correct... - Ralph At 09:09 AM 4/14/2004 -0700, Alain Durand wrote: >On Apr 14, 2004, at 3:48 AM, Ralph Droms wrote: > >>Jinmei-san, >> >>I think DHCPv6 ought to be cited as the protocol for other configuration >>information, as well. > >This is the logical extension. > >>However, it seems to me the phrase "stateful protocol for *other* >>configurations" is a little misleading. I think the word "stateful" could >>be dropped. > >Hummm, what about a DHCPv6 server that would return different values of >some config parameters >for different requesting nodes? > >I think the whole notion of stateful vs stateless is a bit >misleading/confusing anyway, so maybe you're right, >we should drop the word. > > - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 14 14:13: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 OAA12261 for ; Wed, 14 Apr 2004 14:13: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 1BDokQ-0006DV-Og for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 14:04:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EI4UBs023886 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 14:04:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDofH-0004ND-8u for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 13:59: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 NAA11241 for ; Wed, 14 Apr 2004 13:59:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDofE-0004Eb-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 13:59:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDoeH-0004Ai-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 13:58:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDodM-000488-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 13:57:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoOu-0000UB-4c; Wed, 14 Apr 2004 13:42:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoCC-0004aX-Df for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 13:29: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 NAA08997 for ; Wed, 14 Apr 2004 13:29:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDoCA-0002AC-00 for ipv6@ietf.org; Wed, 14 Apr 2004 13:29:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDoBG-000281-00 for ipv6@ietf.org; Wed, 14 Apr 2004 13:28:10 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BDoB4-00025i-00 for ipv6@ietf.org; Wed, 14 Apr 2004 13:27:58 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3EHRwHS011887 for ; Wed, 14 Apr 2004 11:27:58 -0600 (MDT) Received: from xpa-fe1 (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 <0HW6002LY8ILQG@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 14 Apr 2004 11:27:58 -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 <0HW60021K8IKVP@mail.sun.net> for ipv6@ietf.org; Wed, 14 Apr 2004 11:27:57 -0600 (MDT) Date: Wed, 14 Apr 2004 10:27:58 -0700 From: Alain Durand Subject: Re: [rfc2462bis] what is the stateful configuration protocol In-reply-to: To: Christian Huitema Cc: ipv6@ietf.org, Ralph Droms Message-id: <12E973D6-8E39-11D8-BED3-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: 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 Apr 14, 2004, at 9:19 AM, Christian Huitema wrote: > If we want to drop bits, I would rather drop the 'M' bit, to reflect > the > consensus that autonomous allocation of addresses is the norm (MUST > implement) and that allocation through DHCP is an optional facility. Actually, I never really understood those 2 bits... Why don't get rid of them both? Autonomous allocation is the default, and nodes can try DHCPv6 when/if they want... And site who only want centralized address allocation will just not advertize any prefix in the RAs... What would break if we were to make this simplification? - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 14 14:18: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 OAA12508 for ; Wed, 14 Apr 2004 14:18: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 1BDoky-0006kF-OF for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 14:05:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EI54af025920 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 14:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoj5-0005b2-HG for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 14:03: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 OAA11473 for ; Wed, 14 Apr 2004 14:03:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDoj3-0004Sb-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 14:03:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDoi8-0004Q0-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 14:02:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDohZ-0004OD-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 14:01:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoQb-00011b-J9; Wed, 14 Apr 2004 13: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 1BDoL3-0007Sq-NB for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 13:38: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 NAA09605 for ; Wed, 14 Apr 2004 13:38:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDoL1-0002ri-00 for ipv6@ietf.org; Wed, 14 Apr 2004 13:38:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDoK9-0002nm-00 for ipv6@ietf.org; Wed, 14 Apr 2004 13:37: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 1BDoJV-0002ke-00 for ipv6@ietf.org; Wed, 14 Apr 2004 13:36:41 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Apr 2004 13:35:57 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: [rfc2462bis] what is the stateful configuration protocol Date: Wed, 14 Apr 2004 13:35:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [rfc2462bis] what is the stateful configuration protocol Thread-Index: AcQiHwAUyEjRTcnORUClMwDBqeuXwgAJZ1/g From: "Soliman Hesham" To: "Ralph Droms" , X-OriginalArrivalTime: 14 Apr 2004 17:35:57.0558 (UTC) FILETIME=[F1F42160:01C42246] 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 Hi Ralph,=20 > I suggest dropping "stateful" from the description because=20 > of the potential > for confusion inherent in providing a "stateful protocol for *other* > configurations" with "stateless DHCPv6" [RFC 3736]. =3D> I don't find the words "stateful" and "stateless" confusing at all in this context. I think we should keep these words in the RFC. They're meaningful and accurate IMHO.=20 >=20 > This confusion arises from the unfortunate decision to differentiate > RFC 2462 address assignment from DHCP-based address assignment by > designating the former "stateless" and the latter "stateful". That > difference is more accurately captured in RFC 2461bis by=20 > describing RFC 2462 > address assignment as autonomous. But, "stateless address > autoconfiguration" is the accepted phrase with wide=20 > dissemination at this > point... =3D> Both "autonomous" and "stateless" are meaningful descriptions of this process of address config.=20 > In any event, perhaps the best way to simplify the protocol=20 > would be to drop > the "O" bit altogether. That is, make no attempt to control=20 > how a host goes > about finding the additional configuration information. =20 > There was a brief > discussion about this issue at an IPv6 WG interim meeting=20 > (Aug 2002?). If > I remember correctly, and at the risk of over-simplification, the > point of the discussion was that, if I'm a network=20 > administrator, under what > circumstances would I ever want to set the 'O' bit so that a=20 > device does not > use all available mechanisms to obtain other configuration=20 > information? =3D> I find it difficult to agree with statements that=20 use "never". If the function is already implemented and interoperable, I don't see any reason for removing it unless it's harmful. I don't see any harm in this. Given the immaturity of IPv6 deployment, I don't think we should make categorical decisions about=20 what administrators might do.=20 FWIW I think (1) and X are good ways to go=20 (in Jinmei's email). Hesham=20 >=20 > - Ralph >=20 > At 01:20 PM 4/14/2004 +0200, Iljitsch van Beijnum wrote: > >On 14-apr-04, at 12:48, Ralph Droms wrote: > > > >>I think DHCPv6 ought to be cited as the protocol for other=20 > configuration > >>information, as well. > > > >>However, it seems to me the phrase "stateful protocol for *other* > >>configurations" is a little misleading. I think the word=20 > "stateful" could > >>be dropped. > > > >And terminally confuse everyone who has ever read RFC2462? > > > >It seems to me that having one bit to indicate the protocol=20 > to be used for=20 > >configuration isn't all that much. Why not expand both=20 > fields to 4 bits,=20 > >and then have the IANA maintain a registry? This could look=20 > something like: > > > >0000 =3D RA > >0001 - 0111 =3D TBD, fall back on RA (extra bits could be=20 > ignored as per=20 > >RFC2641) > >1000 =3D DHCPv6, handling of RA undefined > >1001 =3D DHCPv6, RA is ignored > >1010 =3D DHCPv6 + RA > >1011 - 1111 =3D TBD >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=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 Wed Apr 14 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 OAA14092 for ; Wed, 14 Apr 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 1BDpBy-0005nc-83 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 14:32:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EIWwae022279 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 14:32:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDp3V-0003aS-QM for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 14:24: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 OAA12883 for ; Wed, 14 Apr 2004 14:24:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDp3T-00061b-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 14:24:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDp2e-0005zG-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 14:23:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDp2D-0005w0-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 14:22:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDotf-0000UZ-AW; Wed, 14 Apr 2004 14:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDokR-0006E1-CT for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 14:04: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 OAA11612 for ; Wed, 14 Apr 2004 14:04:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDokO-0004dX-00 for ipv6@ietf.org; Wed, 14 Apr 2004 14:04:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDojN-0004Wc-00 for ipv6@ietf.org; Wed, 14 Apr 2004 14:03:25 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BDoit-0004RV-00 for ipv6@ietf.org; Wed, 14 Apr 2004 14:02:55 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3EI2tHS002140 for ; Wed, 14 Apr 2004 12:02:55 -0600 (MDT) Received: from xpa-fe1 (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 <0HW600266A4UQG@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 14 Apr 2004 12:02:55 -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 <0HW6002O7A4TVQ@mail.sun.net> for ipv6@ietf.org; Wed, 14 Apr 2004 12:02:54 -0600 (MDT) Date: Wed, 14 Apr 2004 11:02:56 -0700 From: Alain Durand Subject: Re: [rfc2462bis] what is the stateful configuration protocol In-reply-to: <4.3.2.7.2.20040414130305.02c438e0@flask.cisco.com> To: Ralph Droms Cc: ipv6@ietf.org 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: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> <4.3.2.7.2.20040414130305.02c438e0@flask.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 Apr 14, 2004, at 10:11 AM, Ralph Droms wrote: > Followup on the meaning of "stateless" - one way to interpret > "stateless" in > the context of DHCPv6 is: "does not require the maintenance of any > dynamic > state for individual clients" (RFC 3736). The server does, of course, > maintain configuration state and can make decisions about the response > sent > to any specific client based on the server's configuration. Now the words "dynamic state" introduce even more confusion. A DHCPv6 server that has a pre-computed table to assign parameters to client is then stateless, the same server that compute this dynamically (maybe using a simple hash) is still stateless, but if that server decides to cache this information, it becomes stateful... And a router sending RAs that keeps track of who it send them to is by this definition also stateful! Clearly stateless vs stateful is the wrong way to describe the dichotomy between RA & DHCP based configuration, and this vocabulary should be removed from RFC2462. > (And, > autonomous address assignment isn't "stateless" - the source of the RAs > maintains configuration state, the host maintains state about the > addresses > it has selected.) So, "stateless" really is misleading. > "Autonomous/managed" or "serverless/server-based" might be more > correct... serverless/serverbased is incorrect too. A router sending and RA in response to an RS is a server. Autonomous vs managed is IMHO the best terminology. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 14 15:07: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 PAA15655 for ; Wed, 14 Apr 2004 15:07: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 1BDpbR-00086n-5I for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 14:59:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EIxHnV031169 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 14:59:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpQt-0000WM-Ee for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 14:48: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 OAA14356 for ; Wed, 14 Apr 2004 14:48:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDpQq-0007bq-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 14:48:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDpPz-0007Yg-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 14:47:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDpPY-0007UP-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 14:47:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpC4-0005uL-7t; Wed, 14 Apr 2004 14: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 1BDp2R-0003Ou-J7 for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 14:23: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 OAA12787 for ; Wed, 14 Apr 2004 14:23:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDp2P-0005x3-00 for ipv6@ietf.org; Wed, 14 Apr 2004 14:23:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDp1T-0005tB-00 for ipv6@ietf.org; Wed, 14 Apr 2004 14:22:08 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDp0h-0005oN-00 for ipv6@ietf.org; Wed, 14 Apr 2004 14:21:19 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3EIL71C083698; Wed, 14 Apr 2004 20:21:08 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <4.3.2.7.2.20040414080754.022e8848@flask.cisco.com> References: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> <4.3.2.7.2.20040414080754.022e8848@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7D4B6DB1-8E40-11D8-8FC8-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: [rfc2462bis] what is the stateful configuration protocol Date: Wed, 14 Apr 2004 20:21:03 +0200 To: Ralph Droms 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 On 14-apr-04, at 14:35, Ralph Droms wrote: > I suggest dropping "stateful" from the description because of the > potential > for confusion inherent in providing a "stateful protocol for *other* > configurations" with "stateless DHCPv6" [RFC 3736]. > This confusion arises from the unfortunate decision to differentiate > RFC 2462 address assignment from DHCP-based address assignment by > designating the former "stateless" and the latter "stateful". You can't fix this by pretending it didn't happen. This terminology has been in use since 1996, so if we want to get rid of it now we need to spell the issue out letter for letter. > That > difference is more accurately captured in RFC 2461bis by describing > RFC 2462 > address assignment as autonomous. People may think you're talking about AS numbers... > In any event, perhaps the best way to simplify the protocol would be > to drop > the "O" bit altogether. I don't believe any host implementation that's already out there really cares about whether the O and M bits are set. So I guess deprecating either or both wouldn't really make any difference to existing implementations, and obviously not to non-existing ones either. Thus the question becomes: what is it that we want to accomplish? One thing we absolutely want is to skip DHCP if we know there is no DHCP server. Whether or not we care in advance whether a DHCP server is going to give us address information, additional config or both is something I can't answer, maybe someone who implements IPv6 in hosts can. However, I think we might be painting ourselves in a corner by assuming RA and DHCP will be the only discovery/configuration options we'll ever need. *NOW* is the last time we get to change anything in this regard without having to deal with backward compatibility. As soon as OSes are released with DHCPv6 support this will no longer be the case. Another thing that we may want to consider is a few bits that indicate to hosts whether any address/configuration information has changed. This way, connected hosts know they should initiate a new discovery/configuration cycle, and hosts that have been disconnected for a few moments, hours (even days?) know the configuration they used when they were last connected is still valid so they can immediately start communicating while going through a slower d/c cycle to refresh the info (to be on the safe side). This should also avoid configuration storms after outages. > That is, make no attempt to control how a host goes > about finding the additional configuration information. So always try DHCP even if we know often there will be no DHCP server? This means people will have/want to turn off DHCP support manually to get rid of the delay and the unnecessary traffic. (IPv6 is already on the chatty side on the link anyway.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 14 15:08: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 PAA15725 for ; Wed, 14 Apr 2004 15:08: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 1BDpbZ-00088w-Jy for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 14:59:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EIxPEl031297 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 14:59:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpUj-0006OD-CV for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 14:52: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 OAA14496 for ; Wed, 14 Apr 2004 14:52:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDpUg-00000C-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 14:52:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDpTi-0007ky-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 14:51:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDpTP-0007hs-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 14: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 1BDpC6-0005um-Cg; Wed, 14 Apr 2004 14:33:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDp4R-0003nJ-Q6 for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 14:25: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 OAA12911 for ; Wed, 14 Apr 2004 14:25:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDp4P-00064f-00 for ipv6@ietf.org; Wed, 14 Apr 2004 14:25:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDp3V-000624-00 for ipv6@ietf.org; Wed, 14 Apr 2004 14:24:14 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BDp3B-0005zU-00 for ipv6@ietf.org; Wed, 14 Apr 2004 14:23:53 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3EINEU10545; Wed, 14 Apr 2004 11:23:14 -0700 X-mProtect: <200404141823> 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 smtpd89fD2j; Wed, 14 Apr 2004 11:23:12 PDT Message-ID: <407D8198.5000901@iprg.nokia.com> Date: Wed, 14 Apr 2004 11:23:20 -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: Ralph Droms CC: ipv6@ietf.org Subject: Re: [rfc2462bis] what is the stateful configuration protocol References: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> <4.3.2.7.2.20040414130305.02c438e0@flask.cisco.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 Ralph Droms wrote: > "Autonomous/managed" or "serverless/server-based" might be more > correct... If asked to vote on one of these two proposals, I would select "autonomous/managed"; a node that is "autonomous" in terms of address configuration might be a "server" for some other function unrealted to address configuration. 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 Wed Apr 14 15:23: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 PAA17540 for ; Wed, 14 Apr 2004 15:23: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 1BDprY-0005xp-BL for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 15:15:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EJFuLA022921 for ipv6-archive@odin.ietf.org; Wed, 14 Apr 2004 15:15:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpi8-0007Nc-Av for ipv6-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 15:06: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 PAA15488 for ; Wed, 14 Apr 2004 15:06:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDpi5-0000qw-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 15:06:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDphE-0000nH-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 15:05:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDpgT-0000kD-00 for ipv6-web-archive@ietf.org; Wed, 14 Apr 2004 15:04:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpWU-0006rh-6o; Wed, 14 Apr 2004 14:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpJq-0004Nz-6W for ipv6@optimus.ietf.org; Wed, 14 Apr 2004 14:41: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 OAA13860 for ; Wed, 14 Apr 2004 14:41:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDpJn-0006yg-00 for ipv6@ietf.org; Wed, 14 Apr 2004 14:41:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDpIt-0006wp-00 for ipv6@ietf.org; Wed, 14 Apr 2004 14:40:07 -0400 Received: from [4.16.92.133] (helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1BDpIK-0006vS-00 for ipv6@ietf.org; Wed, 14 Apr 2004 14:39:32 -0400 Received: from eaglet (127.0.0.1:3094) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 14 Apr 2004 11:35:54 -0700 From: "Tony Hain" To: "'Pekka Savola'" Cc: "'Dan Lanciani'" , Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Date: Wed, 14 Apr 2004 11:39:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcQgj7FJlDotAVC8RNSeh1Hss5FHtgBvZjaw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 That is not a 3rd party scenario. The network manager is serving 2 sets of customers. Therefore the network manager is required to keep the services to those independent customer sets straight. If the 'outsider' (party 1) gets back unusable addresses it is the network manager's (party 2) problem. There is no 3rd party. It is worth noting that this might happen if the customers are served from the same database, and network managers need to be aware of what they put in the DNS servers for each customer set, but in no way does it justify a MUST NOT. That is a local policy decision based on local needs. It is not something the IETF gets to decide. Tony > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, April 12, 2004 6:15 AM > To: Tony Hain > Cc: 'Dan Lanciani'; ipv6@ietf.org > Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr- > 03.txt > > On Mon, 12 Apr 2004, Tony Hain wrote: > > Again, > > unless there is impact to a 3rd party, putting local use addresses in > the > > global DNS is none of the IETF's business. > > If you look at the case 1) below, that for certainty is a case which > would impact third parties. > > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: Friday, April 09, 2004 10:57 PM > > > To: Tony Hain > > > Cc: 'Dan Lanciani'; ipv6@ietf.org > > > Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local- > addr- > > > 03.txt > > > > > > On Fri, 9 Apr 2004, Tony Hain wrote: > > > > I agree with Dan. Unless someone can show explicit harm to a third > party > > > by > > > > putting them in the global DNS, there is no reason to even discuss > their > > > > presence or absence in the global DNS. > > > > > > I think there are two (operational -- can't be checked by the > > > implementation) cases here: > > > > > > 1) putting in local addresses to global DNS names which are expected > > > to be used by outsiders who are not interested of local > > > addresses, or to whom local addresses could even mean a > > > service degradation. (e.g., www.example.com, smtp.example.com, > > > etc.etc.) > > > > > > 2) putting in local addresses for names which are not expected to be > > > used (e.g., "canada.vpn.example.com", to perform some kind of > > > "auto-discovery" functions) except who know which hostnames those > > > are and know what they're doing. > > > > > > In the former, adding them makes very little sense. In the latter, > > > adding them might be beneficial, while I'm not sure I can see the > > > scenario as I think one might want to use global addresses instead.. > > > > > > > > -----Original Message----- > > > > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf > Of > > > Dan > > > > > Lanciani > > > > > Sent: Friday, April 09, 2004 1:16 PM > > > > > To: ipv6@ietf.org > > > > > Subject: Re: Response to AD comments on draft-ietf-ipv6-unique- > local- > > > addr- > > > > > 03.txt > > > > > > > > > > Kurt Erik Lindqvist wrote: > > > > > > > > > > |> |=> At least you and I agree FWIW :) > > > > > |> |Perhaps I missed this discussion, but I can't see > > > > > |> |why they should be put in the global DNS. > > > > > |> > > > > > |> One might want to build an overlay network where consenting > sites > > > know > > > > > |> how > > > > > |> to reach each other by constructing dynamic tunnels based on > some > > > (yet > > > > > |> to > > > > > |> be defined) mapping function. Thus the addresses may well be > > > > > |> reachable in > > > > > |> some sense. > > > > > | > > > > > |But is this reason enough to have them in the global DNS tree. > > > > > > > > > > Certainly. If they are in the global DNS then the overlay network > can > > > be > > > > > handled entirely by routers (or even stub hosts) that know how to > look > > > up > > > > > the > > > > > mapping and create the tunnels. This is the approach I intend to > use > > > if > > > > > unique > > > > > addresses become a reality. If the addresses are not allowed in > the > > > > > global DNS > > > > > then multi-faced or multi-rooted DNS (or worse) hacks are required > to > > > > > allow > > > > > applications to see the addresses in the first place. > > > > > > > > > > I strongly object to restricting unique addresses from the global > DNS. > > > It > > > > > seriously compromises their utility and it does nothing to make > > > anyone's > > > > > life easier. Applications must already deal with the case of > > > addresses > > > > > that > > > > > are not reachable because of filters. There is no reason to > single > > > these > > > > > addresses out for second-class treatment. > > > > > > > > > > Dan Lanciani > > > > > ddl@danlan.*com > > > > > > > > > > ------------------------------------------------------------------ > -- > > > > > 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 > > > > -------------------------------------------------------------------- > > > > > > > > > > -- > > > 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 > > -------------------------------------------------------------------- > > > > -- > 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 Thu Apr 15 02:45:36 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 CAA05409 for ; Thu, 15 Apr 2004 02:45: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 1BE0Y2-0002g6-EL for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 02:40:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F6eUPO010287 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 02:40:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0Pt-0000Dq-90 for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 02:32: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 CAA04871 for ; Thu, 15 Apr 2004 02:32:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE0Pp-0000Hq-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 02:32:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE0Oo-00004x-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 02:30:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BE0NN-0007XK-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 02:29:29 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BE08Z-00029G-7y for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 02:14:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE02d-0003fI-4Z; Thu, 15 Apr 2004 02:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDzui-00072n-U1 for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 01:59: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 BAA19656 for ; Thu, 15 Apr 2004 01:59:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDzuf-0005Tf-00 for ipv6@ietf.org; Thu, 15 Apr 2004 01:59:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDzth-0005RD-00 for ipv6@ietf.org; Thu, 15 Apr 2004 01:58:50 -0400 Received: from mx.uom.ac.mu ([202.60.7.12]) by ietf-mx with esmtp (Exim 4.12) id 1BDztA-0005NI-00 for ipv6@ietf.org; Thu, 15 Apr 2004 01:58:17 -0400 Received: from localhost ([]) by mx.uom.ac.mu (Merak 7.2.0) with SMTP id DWA74278 for ; Thu, 15 Apr 2004 09:57:38 +0400 Date: Thu, 15 Apr 2004 09:57:38 +0400 From: Boodhoo Avinash To: ipv6@ietf.org Subject: ipv6 Message-ID: X-Mailer: IceWarp Web Mail 5.2.2 X-Originating-IP: 172.22.28.36 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit IPv6 needs a better encoding than IPv4. What type of encoding can we put in IPv6? Mr Avinash Boodhoo Researcher in Ipv6 University of Mauritius. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 15 03:23: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 DAA07451 for ; Thu, 15 Apr 2004 03:23: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 1BE1A5-0006nm-Ns for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 03:19:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F7JnnZ026130 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 03:19:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE12i-0004Ml-Kt for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 03:12: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 DAA06849 for ; Thu, 15 Apr 2004 03:12:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE12g-0003Cd-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 03:12:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE11l-00037A-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 03:11:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE11L-00031z-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 03:10:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0wn-0001wI-8P; Thu, 15 Apr 2004 03:06:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0p3-0008IO-OD for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 02:58: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 CAA06144 for ; Thu, 15 Apr 2004 02:58:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE0oz-00026v-00 for ipv6@ietf.org; Thu, 15 Apr 2004 02:58:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE0oJ-00023Y-00 for ipv6@ietf.org; Thu, 15 Apr 2004 02:57:19 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BE0nZ-0001xI-00 for ipv6@ietf.org; Thu, 15 Apr 2004 02:56:34 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 39FC715210; Thu, 15 Apr 2004 15:56:28 +0900 (JST) Date: Thu, 15 Apr 2004 15:56:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman Hesham" Cc: "Subramonia Pillai - CTD, Chennai" , Subject: Re: RFC 2461 : Neighbor Discovery In-Reply-To: <68C9DA8F50019B4E8622C53811BEE1D6B83E57@kavithai.ctd.hcltech.com> 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, 14 Apr 2004 06:17:18 -0400, >>>>> "Soliman Hesham" said: >> From router point of view, global address can be get from >> Configuration. So >> I am still thinking, for router case do we need ND? > => Do you think hosts connected to your router > will need the information I mentioned in the last > email? If yes, they will send RSs. > I don't know what you're using the router for but > I don't know of any case where I can categorically > say don't implement RFC 2461. I think that it's > basically always needed. If for nothing else, a host > might want to use NUD for reachability confirmation. I think the original question is rather vague: >>>>> On Wed, 14 Apr 2004 11:01:37 +0530, >>>>> "Subramonia Pillai - CTD, Chennai" said: > My doubt is "Should I run ND on PPP links in addition?" Can any one please > tell me with the reason? about which part of ND the question is asking (RFC2461 or RFC2462, which part of each spec, etc). Additionally, from the latter part of this thread, there seems to be another confusion on whether we are only concentrating on routers, only on hosts, or on both. For further constructive discussion, these points should be clarified in the first place, 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 Thu Apr 15 03:46:55 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 DAA08877 for ; Thu, 15 Apr 2004 03:46: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 1BE1Te-0005HB-6t for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 03:40:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F7e1QW020260 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 03:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1Qz-0004K2-Oa for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 03:37: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 DAA08348 for ; Thu, 15 Apr 2004 03:37:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE1Qx-0005R5-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 03:37:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE1Oj-000524-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 03:34:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE1MZ-0004bY-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 03:32:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1DF-00080F-Ek; Thu, 15 Apr 2004 03:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE19Q-0006aY-SV for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 03:19: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 DAA07285 for ; Thu, 15 Apr 2004 03:19:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE19O-0003sJ-00 for ipv6@ietf.org; Thu, 15 Apr 2004 03:19:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE18a-0003ol-00 for ipv6@ietf.org; Thu, 15 Apr 2004 03:18:17 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BE17y-0003gV-00 for ipv6@ietf.org; Thu, 15 Apr 2004 03:17:38 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <2LW9V0GT>; Thu, 15 Apr 2004 12:47:03 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D6BABCB6@kavithai.ctd.hcltech.com> From: "Subramonia Pillai - CTD, Chennai" To: JINMEI Tatuya / ???? , Soliman Hesham Cc: "Subramonia Pillai - CTD, Chennai" , ipv6@ietf.org Subject: RE: RFC 2461 : Neighbor Discovery Date: Thu, 15 Apr 2004 12:47:05 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" 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 JINMEI and Hesham, I am looking for $B!H(JRouter to Router$B!I(J connected by PPP links (POS) running IPV6CP. Since ND is a union of (ARP, ICMP Rotuer Discovery, ICMP Redirect and others), which part of ND is needed (or has to be implemented) in both Routers. Thanks in advance, Subu -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Thursday, April 15, 2004 12:26 PM To: Soliman Hesham Cc: Subramonia Pillai - CTD, Chennai; ipv6@ietf.org Subject: Re: RFC 2461 : Neighbor Discovery >>>>> On Wed, 14 Apr 2004 06:17:18 -0400, >>>>> "Soliman Hesham" said: >> From router point of view, global address can be get from >> Configuration. So >> I am still thinking, for router case do we need ND? > => Do you think hosts connected to your router > will need the information I mentioned in the last > email? If yes, they will send RSs. > I don't know what you're using the router for but > I don't know of any case where I can categorically > say don't implement RFC 2461. I think that it's > basically always needed. If for nothing else, a host > might want to use NUD for reachability confirmation. I think the original question is rather vague: >>>>> On Wed, 14 Apr 2004 11:01:37 +0530, >>>>> "Subramonia Pillai - CTD, Chennai" said: > My doubt is "Should I run ND on PPP links in addition?" Can any one please > tell me with the reason? about which part of ND the question is asking (RFC2461 or RFC2462, which part of each spec, etc). Additionally, from the latter part of this thread, there seems to be another confusion on whether we are only concentrating on routers, only on hosts, or on both. For further constructive discussion, these points should be clarified in the first place, 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 Thu Apr 15 04:45:43 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 EAA11689 for ; Thu, 15 Apr 2004 04:45: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 1BE2Ty-0007zW-1o for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 04:44:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F8iQoO030714 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 04:44:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2Po-0006fW-2s for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 04:40: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 EAA11443 for ; Thu, 15 Apr 2004 04:40:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Pl-0002Jj-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 04:40:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2Ot-0002GD-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 04:39:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE2OZ-0002C3-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 04:38:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2Iv-00048E-Fi; Thu, 15 Apr 2004 04:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2Fx-0003G5-Ol for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 04:29: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 EAA11022 for ; Thu, 15 Apr 2004 04:29:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Fu-0001YG-00 for ipv6@ietf.org; Thu, 15 Apr 2004 04:29:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2Ex-0001VP-00 for ipv6@ietf.org; Thu, 15 Apr 2004 04:28:55 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BE2ER-0001TI-00 for ipv6@ietf.org; Thu, 15 Apr 2004 04:28:24 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D120D1521B for ; Thu, 15 Apr 2004 17:28:23 +0900 (JST) Date: Thu, 15 Apr 2004 17:28:23 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Re: [rfc2462bis] what is the stateful configuration protocol 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 Tue, 13 Apr 2004 22:53:07 +0900, >>>>> JINMEI Tatuya said: > Regarding issue 277 of rfc2462bis (Semantics of M/O flags), one > controversial issue is how clearly we should specify the stateful > address configuration protocol. > The question actually consists of the following two sub-questions: > Question A: how should rfc2462bis specify the stateful protocol? Thank you all who responded. On this particular topic, the consensus in this thread seems that we should 1. clearly say that stateful address configuration is DHCPv6 and X. add an informative reference to RFC3315 (but not to the node-req document) I know there was a different opinion, particularly on the first point, to reduce dependencies, but the number of people supporting the idea of 1+X seems sufficiently large to make a decision. I hope others can accept this path. 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 Apr 15 04:52:53 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 EAA11957 for ; Thu, 15 Apr 2004 04:52: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 1BE2ad-0001eb-Vb for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 04:51:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F8pJnQ006339 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 04:51:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2Un-000073-Ar for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 04:45: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 EAA11680 for ; Thu, 15 Apr 2004 04:45:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Uk-0002kU-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 04:45:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2Tl-0002eg-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 04:44:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE2TJ-0002ZU-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 04:43:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2Kt-0004Zr-KB; Thu, 15 Apr 2004 04:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2I1-0003sa-CC for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 04:32: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 EAA11130 for ; Thu, 15 Apr 2004 04:32:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Hy-0001iR-00 for ipv6@ietf.org; Thu, 15 Apr 2004 04:32:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2H7-0001et-00 for ipv6@ietf.org; Thu, 15 Apr 2004 04:31:10 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Gh-0001aV-00 for ipv6@ietf.org; Thu, 15 Apr 2004 04:30:44 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3F8UV1C098300; Thu, 15 Apr 2004 10:30:33 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <68C9DA8F50019B4E8622C53811BEE1D6BABCB6@kavithai.ctd.hcltech.com> References: <68C9DA8F50019B4E8622C53811BEE1D6BABCB6@kavithai.ctd.hcltech.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <26436E48-8EB7-11D8-A74E-000A95CD987A@muada.com> Content-Transfer-Encoding: quoted-printable Cc: "" From: Iljitsch van Beijnum Subject: Re: RFC 2461 : Neighbor Discovery Date: Thu, 15 Apr 2004 10:30:27 +0200 To: "Subramonia Pillai - CTD, Chennai" X-Mailer: Apple Mail (2.613) 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 On 15-apr-04, at 9:17, Subramonia Pillai - CTD, Chennai wrote: > I am looking for =93Router to Router=94 connected by PPP links (POS)=20= > running > IPV6CP. > Since ND is a union of (ARP, ICMP Rotuer Discovery, ICMP Redirect and > others), which part of ND is needed (or has to be implemented) in both > Routers. The use of these types of mechanisms with PPP is already less than=20 clear with IPv4. The whole address negotiation thing is there so a=20 router or dial-up aggregator can assign an address to a dial-up user.=20 When PPP is used on a fixed link between two routers, this=20 functionality isn't really needed, as generally this information is=20 configured on both ends. Now in IPv4, it is necessary that the routers=20= on both ends of a (PPP) link agree on the address range (subnet) that=20 is used for this link, as routing protocols won't work if the routers=20 have different ideas about the addresses on the link. However, in IPv6=20= this isn't necessary, as routing protocols can simply use link local=20 addresses. Or routers may learn from other routers what additional=20 address ranges are on-link. Note though that these mechanisms are=20 clearly intended (at least in RFC2461) to be used by hosts. However, there is one other thing you should consider. In IPv6, we're=20 supposed to use /64s for pretty much all subnets. So it's not=20 inconceivable that router A sends a packet to one of those 2^64=20 addresses belonging to the PPP subnet that _isn't_ an address for=20 router B. A naive implemenation may result in such a packet being=20 returned to router A by router B and a routing loop (that attackers can=20= use to attack the routers because of the multiplication effect) is=20 born. Since it's unlikely a router only has PPP interfaces, the full ND=20= code must be in there anyway, so it makes sense to use regular neighbor=20= discovery / unreachability to avoid this situation. On the other hand,=20= discovering the addresses on both sides using IPV6CP and then=20 blackholing the other 2^64-2 addresses may be preferable as this makes=20= it impossible for attackers to cause ND storms. (Using a /127 would do=20= this too, but this clashes with some anycast addresses (that nobody=20 uses anyway).)= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 15 06:25:48 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 GAA15485 for ; Thu, 15 Apr 2004 06:25: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 1BE413-0003hL-Mo for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 06:22:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FAMfMb014210 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 06:22:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3up-00022Y-0Y for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 06:16: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 GAA15027 for ; Thu, 15 Apr 2004 06:16:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE3uk-0001WP-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 06:16:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE3ty-0001RN-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 06:15:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE3t1-0001Mz-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 06:14:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3g7-000500-UR; Thu, 15 Apr 2004 06:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3X1-0002ZN-3A for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 05:51: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 FAA14150 for ; Thu, 15 Apr 2004 05:51:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE3Wx-0007cH-00 for ipv6@ietf.org; Thu, 15 Apr 2004 05:51:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE3VW-0007Wc-00 for ipv6@ietf.org; Thu, 15 Apr 2004 05:50:07 -0400 Received: from imhotep.hursley.ibm.com ([195.212.14.170] helo=mail-gw2.hursley.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1BE3V8-0007SM-00 for ipv6@ietf.org; Thu, 15 Apr 2004 05:49:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1BE3Uf-0000no-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:49:13 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1BE3Uf-0000nj-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:49:13 +0100 Received: from zurich.ibm.com (dhcp222-93.zurich.ibm.com [9.4.222.93]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i3F9nDF122912 for ; Thu, 15 Apr 2004 10:49:13 +0100 Message-ID: <407E3B91.322DCC66@zurich.ibm.com> Date: Thu, 15 Apr 2004 09:36:49 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt References: <200404090519.BAA16640@ss10.danlan.com> <56124720-8A07-11D8-8D01-000A95928574@kurtis.pp.se> <029001c41ec7$1780d1e0$6401a8c0@stephen> Content-Type: text/plain; charset=us-ascii 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 Stephen Sprunk wrote: ... > Suggested text for 7.0: > > AAAA and PTR records for Local IPv6 addresses MAY be installed in the global > DNS at the option of the site to which they are assigned. It is expected > that most sites will not make use of this option, but some sites may find > benefits in doing so. Can we just say yes to this, rather than arguing endlessly about who would or wouldn't do so? Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 15 06:26: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 GAA15528 for ; Thu, 15 Apr 2004 06:26: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 1BE414-0003hg-2t for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 06:22:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FAMgWU014232 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 06:22:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3ur-00024B-4N for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 06:16: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 GAA15036 for ; Thu, 15 Apr 2004 06:16:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE3un-0001Wm-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 06:16:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE3u2-0001Rn-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 06:15:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE3tB-0001N5-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 06:14:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3g9-00050C-0K; Thu, 15 Apr 2004 06: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 1BE3X9-0002bB-MC for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 05:51: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 FAA14155 for ; Thu, 15 Apr 2004 05:51:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE3X6-0007cp-00 for ipv6@ietf.org; Thu, 15 Apr 2004 05:51:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE3VX-0007Wl-00 for ipv6@ietf.org; Thu, 15 Apr 2004 05:50:07 -0400 Received: from imhotep.hursley.ibm.com ([195.212.14.170] helo=mail-gw2.hursley.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1BE3V9-0007SN-00 for ipv6@ietf.org; Thu, 15 Apr 2004 05:49:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1BE3Ug-0000nw-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:49:14 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1BE3Ug-0000nr-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:49:14 +0100 Received: from zurich.ibm.com (dhcp222-93.zurich.ibm.com [9.4.222.93]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i3F9nEF122914 for ; Thu, 15 Apr 2004 10:49:14 +0100 Message-ID: <407E3C5D.1AAEE8E9@zurich.ibm.com> Date: Thu, 15 Apr 2004 09:40:13 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt References: <407538D1.1070803@innovationslab.net> <029101c41ec7$1b203fc0$6401a8c0@stephen> Content-Type: text/plain; charset=us-ascii 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 Stephen Sprunk wrote: > > Thus spake "Brian Haberman" > > Margaret Wasserman wrote: > > > This would appear to be incompatible with the IANA considerations > > > section that says: > > > > > >> If deemed > > >> appropriate, the authority may also consist of multiple > organizations > > >> performing the authority duties. > > How about: > > IANA MAY delegate assignment capabilities to more than one entity. If this > occurs, the various entities must assign addresses using a method that is > indistinguishable from that of a single entity. Specifically, the method > MUST prevent collisions between assignments by different entities and MUST > NOT rely on subdividing the assignable address space in a manner that > promotes or resembles any aggregation scheme. I don't think we need to say this. The simple fix s/source/authority/ in the earlier text puts the whole matter in IANA's hands, where it belongs. For the record, I agree with all Brian H's proposals except for the DNS bit that needs to be fixed. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 15 07:12:50 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 HAA17100 for ; Thu, 15 Apr 2004 07:12: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 1BE4m3-0001Pa-CJ for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 07:11:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FBBFdZ005422 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 07:11:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE4k3-0000jY-87 for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 07:09: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 HAA16852 for ; Thu, 15 Apr 2004 07:09:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE4jz-0005YM-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 07:09:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE4j2-0005U4-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 07:08:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE4ih-0005Q9-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 07:07:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE4bD-0005wY-TU; Thu, 15 Apr 2004 07:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE4YM-0005AM-8v for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 06:57: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 GAA16530 for ; Thu, 15 Apr 2004 06:57:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE4YI-0004Y6-00 for ipv6@ietf.org; Thu, 15 Apr 2004 06:57:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE4XP-0004Uj-00 for ipv6@ietf.org; Thu, 15 Apr 2004 06:56:07 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BE4WX-0004RF-00 for ipv6@ietf.org; Thu, 15 Apr 2004 06:55:13 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id ED55315210; Thu, 15 Apr 2004 19:55:07 +0900 (JST) Date: Thu, 15 Apr 2004 19:55:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] what is the stateful configuration protocol In-Reply-To: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> References: <4.3.2.7.2.20040413155905.022eb4b0@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, 14 Apr 2004 06:48:57 -0400, >>>>> Ralph Droms said: > I think DHCPv6 ought to be cited as the protocol for other configuration > information, as well. > However, it seems to me the phrase "stateful protocol for *other* > configurations" is a little misleading. I think the word "stateful" could > be dropped. You're running too fast despite the prior notice:-) But anyway, this thread is surely useful for rfc2462bis. Thanks for raising this topic. (I won't try to make a response to each follow-up in this sub-thread, but I've read all of them.) It seems to me that we are discussing two (almost) different issues: 1. whether "stateless" is an appropriate word to describe the address autoconfiguration mechanism specified in RFC2462 (and bis) 2. whether we need the M/O flags in the first place Regarding issue 1, I personally think "stateless" is appropriate, at least in the sense that we don't have to reword it in rfc2462bis. In fact, RFC2462 clearly says what "stateless" means in that document. For example, it says in Introduction: Stateless autoconfiguration requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. which means it's a "third-party-serverless" mechanism. Also, the following sentence clearly shows that it is an "autonomous" configuration mechanism: The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. If we are making a brand-new specification, it might make sense to reconsider the wording from the scratch. However, "stateless address autoconfiguration" has been used for quite a long period (almost for 10 years?), and is used in many documents, including in the title of RFC2462 itself. So, I don't think the advantage of rewording is worth the expected confusion. Issue 2 is a big question...it may even affect the "consensus" we just made in the first (and original) part of this thread. I'm going to make a separate thread for this. 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 Apr 15 09:01: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 JAA20895 for ; Thu, 15 Apr 2004 09:01: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 1BE6Jo-0005TP-BL for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 08:50:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FCoCbh021022 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 08:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6B7-0001yP-5U for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 08:41: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 IAA19888 for ; Thu, 15 Apr 2004 08:41:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6B6-00056Y-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 08:41:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6AD-0004ys-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 08:40:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE69c-0004sN-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 08:39:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE5ur-00044V-Vk; Thu, 15 Apr 2004 08:24:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE5Fq-00018Z-Cq for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 07:42: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 HAA18088 for ; Thu, 15 Apr 2004 07:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE5Fp-0000VJ-00 for ipv6@ietf.org; Thu, 15 Apr 2004 07:42:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE5Ev-0000Ry-00 for ipv6@ietf.org; Thu, 15 Apr 2004 07:41:05 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BE5E7-0000Os-00 for ipv6@ietf.org; Thu, 15 Apr 2004 07:40:15 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 10E6215210 for ; Thu, 15 Apr 2004 20:40:14 +0900 (JST) Date: Thu, 15 Apr 2004 20:40:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis] whether we need 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 As I just said in a separate message, one big question had been raised about rfc2462bis. It was, in my understanding, whether we need the M/O flags for the "stateful" protocol(s) in the first place. (Actually, different people used different representation related to this issue, but, in my understanding, we can simply summarize the essential part of the question as above). I know this is probably highly controversial, but I tend to agree on removing (or deprecating) these bits. The main reasons have already been shown in the thread starting at the following URL: http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg02262.html One additional point is that I'm not sure if we can really recycle rfc2462bis as a draft standard with keeping these bits. If we keep them, we'll probably need to find running implementations regarding these bits that are interoperable. (If so) can we really make it soon? As far as I know, no host implementation supports the M flag. Regarding the O flag, I've implemented the host side of the flag, which invokes a DHCPv6 client upon receiving an RA with the O bit. But I've never heard of other implementations. This also means one obvious problem when we remove these bits is actually a non-issue. That is, we do not have to worry about the problem that we may make serious loss of compatibility. Another possible disadvantage is that we'll lose the ability to trigger DHCPv6 (or, if you like a general wording, trigger a stateful protocol). I admit this can be a problem. A rough idea to deal with this is to provide a different, more general way to provide the ability as a separate document. For example, a separate ND option which can trigger a particular protocol (including DHCPv6) for a particular purpose (e.g., to get "additional" configuration information) might make sense to implement the idea. In fact, an extension to ND to re-invoke a protocol for "other information" has already been proposed: draft-vijay-ipv6-icmp-refresh-otherconf-00.txt. I know this is probably too radical to make a concrete proposal at this stage, but if we can really agree on the basic idea of this path, I'd probably do the followings in rfc2462: - remove all references to "stateful" protocols - deprecate the M and O flags, that is, + reserve the fields and clarify that they must not be used (this may affect rfc2461bis, too) + remove all the usages regarding these flags Any comments/suggestions/objections are welcome. Thanks in advance, 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 Apr 15 09:01: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 JAA20913 for ; Thu, 15 Apr 2004 09:01: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 1BE6K4-0005hK-Av for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 08:50:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FCoSr5021898 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 08:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6E7-00033V-8c for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 08:44: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 IAA20052 for ; Thu, 15 Apr 2004 08:44:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6E5-0005Rk-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 08:44:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6D9-0005K4-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 08:43:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE6By-0005Cy-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 08:42:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE5uu-00045D-8d; Thu, 15 Apr 2004 08:24:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE5Ki-0002O5-Rp for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 07:47: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 HAA18168 for ; Thu, 15 Apr 2004 07:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE5Ki-0000oD-00 for ipv6@ietf.org; Thu, 15 Apr 2004 07:47:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE5Jm-0000l6-00 for ipv6@ietf.org; Thu, 15 Apr 2004 07:46:06 -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 1BE5JM-0000hs-00 for ipv6@ietf.org; Thu, 15 Apr 2004 07:45:41 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2004 03:55:41 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3FBj78C025663; Thu, 15 Apr 2004 04:45:08 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-91.cisco.com [10.86.242.91]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHP66570; Thu, 15 Apr 2004 07:45:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20040415071105.02c5a9e8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Apr 2004 07:45:04 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [rfc2462bis] what is the stateful configuration protocol Cc: ipv6@ietf.org In-Reply-To: References: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> <4.3.2.7.2.20040413155905.022eb4b0@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 Jinmei-san - I distracted the conversation a little with my posting ... I think we have come to consensus as you describe in http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg02280.html and we can consider the question of "how clearly we should specify the stateful address configuration protocol" closed. "stateless address autoconfiguration" is the widely-accepted term and there is no need to change it. I had intended only to make the suggestion that "stateful" be dropped from the phrase "other stateful configuration" (in RFC 2461) , because of the potential confusion between "other stateful configuration" and "stateless DHCP" (in RFC 3736). There is also potential confusion because there is no "stateless" counterpart to "other stateful configuration". I also wanted to recall a conversation that taken place at the IPv6 interim meeting about the usefulness of the 'O' bit ... however, if this conversation is out-of-scope to the revision of RFC 2461, that's fine and we can drop it. - Ralph At 07:55 PM 4/15/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Wed, 14 Apr 2004 06:48:57 -0400, > >>>>> Ralph Droms said: > > > I think DHCPv6 ought to be cited as the protocol for other configuration > > information, as well. > > > However, it seems to me the phrase "stateful protocol for *other* > > configurations" is a little misleading. I think the word "stateful" could > > be dropped. > >You're running too fast despite the prior notice:-) But anyway, this >thread is surely useful for rfc2462bis. Thanks for raising this >topic. > >(I won't try to make a response to each follow-up in this sub-thread, >but I've read all of them.) > >It seems to me that we are discussing two (almost) different issues: > >1. whether "stateless" is an appropriate word to describe the address > autoconfiguration mechanism specified in RFC2462 (and bis) >2. whether we need the M/O flags in the first place > >Regarding issue 1, I personally think "stateless" is appropriate, at >least in the sense that we don't have to reword it in rfc2462bis. > >In fact, RFC2462 clearly says what "stateless" means in that >document. For example, it says in Introduction: > > Stateless autoconfiguration requires no manual > configuration of hosts, minimal (if any) configuration of routers, > and no additional servers. > >which means it's a "third-party-serverless" mechanism. Also, the >following sentence clearly shows that it is an "autonomous" >configuration mechanism: > > The stateless mechanism allows a host to > generate its own addresses using a combination of locally available > information and information advertised by routers. > >If we are making a brand-new specification, it might make sense to >reconsider the wording from the scratch. However, "stateless address >autoconfiguration" has been used for quite a long period (almost for >10 years?), and is used in many documents, including in the title of >RFC2462 itself. > >So, I don't think the advantage of rewording is worth the expected >confusion. > >Issue 2 is a big question...it may even affect the "consensus" we just >made in the first (and original) part of this thread. I'm going to >make a separate thread for this. > > 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 Apr 15 09:19:39 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 JAA22405 for ; Thu, 15 Apr 2004 09:19: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 1BE6dR-0006ch-2t for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 09:10:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FDATcj025454 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 09:10:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6b8-0005Fr-GD for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 09:08: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 JAA21663 for ; Thu, 15 Apr 2004 09:08:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6b6-00002R-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:08:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6aA-0007jV-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:07:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE6ZC-0007cU-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:06:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6La-0006K0-C8; Thu, 15 Apr 2004 08: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 1BE6Hx-0004gc-AH for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 08:48: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 IAA20381 for ; Thu, 15 Apr 2004 08:48:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6Hv-0005sn-00 for ipv6@ietf.org; Thu, 15 Apr 2004 08:48:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6H2-0005oc-00 for ipv6@ietf.org; Thu, 15 Apr 2004 08:47:20 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BE6GV-0005ja-00 for ipv6@ietf.org; Thu, 15 Apr 2004 08:46:47 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CF5BA15210; Thu, 15 Apr 2004 21:46:45 +0900 (JST) Date: Thu, 15 Apr 2004 21:46:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] what is the stateful configuration protocol In-Reply-To: <4.3.2.7.2.20040415071105.02c5a9e8@flask.cisco.com> References: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> <4.3.2.7.2.20040415071105.02c5a9e8@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 Thu, 15 Apr 2004 07:45:04 -0400, >>>>> Ralph Droms said: > I had intended only to make the suggestion that "stateful" be dropped from > the phrase "other stateful configuration" (in RFC 2461) , because of the > potential confusion between "other stateful configuration" and "stateless > DHCP" (in RFC 3736). There is also potential confusion because there is > no "stateless" counterpart to "other stateful configuration". Okay, thanks for the clarification. I had actually intended to propose a similar change, but the discussion have started earlier than I expected:-) > I also wanted to recall a conversation that taken place at the IPv6 interim > meeting about the usefulness of the 'O' bit ... however, if this > conversation is out-of-scope to the revision of RFC 2461, that's fine and we > can drop it. (You meant the revison of RFC 2462?) I think it is in the scope of this work, but do you have a concrete reference to the conversation? Which interim meeting are you talking about? The latest ipv6 interim meeting I remember is the one held in Sep/Oct 1999. I've roughly gone through the meeting minutes at http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-Sep99.txt but I could not find a discussion relevant to this topic. 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 Apr 15 09:24:49 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 JAA22720 for ; Thu, 15 Apr 2004 09:24: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 1BE6n2-0001GF-EC for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 09:20:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FDKOod004842 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 09:20:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6hE-000840-Mj for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 09:14: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 JAA22146 for ; Thu, 15 Apr 2004 09:14:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6hD-0000nL-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:14:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6gR-0000hw-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:13:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE6fq-0000aw-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09: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 1BE6c2-0005dS-By; Thu, 15 Apr 2004 09:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6Lf-0006Ob-Lv for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 08:52: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 IAA20567 for ; Thu, 15 Apr 2004 08:52:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6Le-00067Y-00 for ipv6@ietf.org; Thu, 15 Apr 2004 08:52:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6Kh-000649-00 for ipv6@ietf.org; Thu, 15 Apr 2004 08:51:08 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BE6K1-0005xZ-00 for ipv6@ietf.org; Thu, 15 Apr 2004 08:50:25 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 08:49:54 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: [rfc2462bis] whether we need the M/O flags Date: Thu, 15 Apr 2004 08:49:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQi5qeMvor5HiRFTS2HHsMdmOAVqQAAAelg From: "Soliman Hesham" To: "JINMEI Tatuya / ????" , X-OriginalArrivalTime: 15 Apr 2004 12:49:54.0051 (UTC) FILETIME=[261E8D30:01C422E8] 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 > As I just said in a separate message, one big question had=20 > been raised > about rfc2462bis. It was, in my understanding,=20 =3D> The question you raise affects 2461 and as a consequence it affects = 2462. FWIW, I really think that there is no point in going round and round = again in this discussion when there is no harm done by keeping them.=20 Removing them is not backward compatible for 2461 anyway.=20 So I recommend we leave them as defined. Hesham >=20 > whether we need the M/O flags for the "stateful" protocol(s) in the > first place. >=20 > (Actually, different people used different representation related to > this issue, but, in my understanding, we can simply summarize the > essential part of the question as above). >=20 > I know this is probably highly controversial, but I tend to agree on > removing (or deprecating) these bits. >=20 > The main reasons have already been shown in the thread=20 > starting at the > following URL: > http://www1.ietf.org/mail-archive/working-groups/ipv6/current /msg02262.html One additional point is that I'm not sure if we can really recycle rfc2462bis as a draft standard with keeping these bits. If we keep them, we'll probably need to find running implementations regarding these bits that are interoperable. (If so) can we really make it soon? As far as I know, no host implementation supports the M flag. Regarding the O flag, I've implemented the host side of the flag, which invokes a DHCPv6 client upon receiving an RA with the O bit. But I've never heard of other implementations. This also means one obvious problem when we remove these bits is actually a non-issue. That is, we do not have to worry about the problem that we may make serious loss of compatibility. Another possible disadvantage is that we'll lose the ability to trigger DHCPv6 (or, if you like a general wording, trigger a stateful protocol). I admit this can be a problem. A rough idea to deal with this is to provide a different, more general way to provide the ability as a separate document. For example, a separate ND option which can trigger a particular protocol (including DHCPv6) for a particular purpose (e.g., to get "additional" configuration information) might make sense to implement the idea. In fact, an extension to ND to re-invoke a protocol for "other information" has already been proposed: draft-vijay-ipv6-icmp-refresh-otherconf-00.txt. I know this is probably too radical to make a concrete proposal at this stage, but if we can really agree on the basic idea of this path, I'd probably do the followings in rfc2462: - remove all references to "stateful" protocols - deprecate the M and O flags, that is, + reserve the fields and clarify that they must not be used (this may affect rfc2461bis, too) + remove all the usages regarding these flags Any comments/suggestions/objections are welcome. Thanks in advance, 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 -------------------------------------------------------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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 Apr 15 09:44: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 JAA23570 for ; Thu, 15 Apr 2004 09:44: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 1BE71d-0005P6-Oq for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 09:35:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FDZTVR020767 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 09:35:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6xO-0003wx-83 for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 09: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 JAA22989 for ; Thu, 15 Apr 2004 09:31:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6xM-0002Ma-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:31:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6wN-0002GE-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:30:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE6vQ-00029q-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:29:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6ng-0001V9-70; Thu, 15 Apr 2004 09: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 1BE6iv-0008Gy-M7 for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 09:16: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 JAA22214 for ; Thu, 15 Apr 2004 09:16:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6it-0000wv-00 for ipv6@ietf.org; Thu, 15 Apr 2004 09:16:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6i4-0000t2-00 for ipv6@ietf.org; Thu, 15 Apr 2004 09:15:17 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BE6hO-0000oT-00 for ipv6@ietf.org; Thu, 15 Apr 2004 09:14:34 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5DC1115214; Thu, 15 Apr 2004 22:14:33 +0900 (JST) Date: Thu, 15 Apr 2004 22:14:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] what is the stateful configuration protocol In-Reply-To: References: <4.3.2.7.2.20040413155905.022eb4b0@flask.cisco.com> <4.3.2.7.2.20040415071105.02c5a9e8@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 Thu, 15 Apr 2004 21:46:46 +0900, >>>>> JINMEI Tatuya said: >> I also wanted to recall a conversation that taken place at the IPv6 interim >> meeting about the usefulness of the 'O' bit ... however, if this >> conversation is out-of-scope to the revision of RFC 2461, that's fine and we >> can drop it. > (You meant the revison of RFC 2462?) I think it is in the scope of > this work, but do you have a concrete reference to the conversation? > Which interim meeting are you talking about? The latest ipv6 interim > meeting I remember is the one held in Sep/Oct 1999. I've roughly gone > through the meeting minutes at > http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-Sep99.txt > but I could not find a discussion relevant to this topic. Sorry, I was not careful enough: the latest one should be the one in May/Jun 2001. I do remember the meeting, but in my poor memory it was an ngtrans interim meeting (not a joint meeting). Still, I could not find a useful reference from the minutes: http://playground.sun.com/pub/ipng/html/minutes/ipng-meeting-may2001.txt 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 Apr 15 09:51:13 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 JAA23964 for ; Thu, 15 Apr 2004 09:51: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 1BE7DX-0002T9-N3 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 09:47:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FDllWe009483 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 09:47:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE785-0000GJ-UN for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 09: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 JAA23452 for ; Thu, 15 Apr 2004 09:42:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE784-0003HM-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:42:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE77B-0003Cs-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:41:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE76d-00038q-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:40:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE71C-000581-Hq; Thu, 15 Apr 2004 09: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 1BE6ra-0002dV-5c for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 09:25: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 JAA22741 for ; Thu, 15 Apr 2004 09:25:03 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6rY-0001pF-00 for ipv6@ietf.org; Thu, 15 Apr 2004 09:25:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6qZ-0001k6-00 for ipv6@ietf.org; Thu, 15 Apr 2004 09:24:04 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BE6pc-0001eT-00 for ipv6@ietf.org; Thu, 15 Apr 2004 09:23:04 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FDMtn13361; Thu, 15 Apr 2004 16:22:55 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 16:22:23 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3FDMNeF025111; Thu, 15 Apr 2004 16:22:23 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00dJu051; Thu, 15 Apr 2004 16:22:22 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FDM4s09949; Thu, 15 Apr 2004 16:22:04 +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); Thu, 15 Apr 2004 16:14:57 +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-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [rfc2462bis] whether we need the M/O flags Date: Thu, 15 Apr 2004 16:14:57 +0300 Message-ID: Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQi5qeMvor5HiRFTS2HHsMdmOAVqQAAAelgAAE1WgA= To: , , X-OriginalArrivalTime: 15 Apr 2004 13:14:57.0781 (UTC) FILETIME=[A6698A50:01C422EB] 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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, > > As I just said in a separate message, one big question had been raised > > about rfc2462bis. It was, in my understanding, > > => The question you raise affects 2461 and as a consequence it affects 2462. > FWIW, I really think that there is no point in going round and round again > in this discussion when there is no harm done by keeping them. > Removing them is not backward compatible for 2461 anyway. > So I recommend we leave them as defined. I agree with Hesham. Unless they are doing harm, I don't think they should be removed & create compatability problems. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 15 09:56:23 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 JAA24225 for ; Thu, 15 Apr 2004 09:56:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7FC-00037I-A0 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 09:49:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FDnU1k011974 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 09:49:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7A5-00016C-Cq for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 09:44: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 JAA23554 for ; Thu, 15 Apr 2004 09:44:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7A3-0003S6-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:44:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE790-0003Mr-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:43:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE783-0003HH-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 09:42:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE71E-000591-OO; Thu, 15 Apr 2004 09:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6uo-0003VN-GX for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 09:28: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 JAA22886 for ; Thu, 15 Apr 2004 09:28:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6um-00026M-00 for ipv6@ietf.org; Thu, 15 Apr 2004 09:28:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6te-0001zw-00 for ipv6@ietf.org; Thu, 15 Apr 2004 09:27:15 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BE6t1-0001vb-00 for ipv6@ietf.org; Thu, 15 Apr 2004 09:26:35 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 58C401521E; Thu, 15 Apr 2004 22:26:31 +0900 (JST) Date: Thu, 15 Apr 2004 22:26:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman Hesham" Cc: Subject: Re: [rfc2462bis] whether we need the M/O flags 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, 15 Apr 2004 08:49:53 -0400, >>>>> "Soliman Hesham" said: >> As I just said in a separate message, one big question had >> been raised >> about rfc2462bis. It was, in my understanding, > => The question you raise affects 2461 and as a consequence it affects 2462. Yes, I know. I tried to explain that in my previous message, but I'd apologize if I was not clear enough. > FWIW, I really think that there is no point in going round and round again > in this discussion when there is no harm done by keeping them. > Removing them is not backward compatible for 2461 anyway. > So I recommend we leave them as defined. I see your points, and I actually expected this type of responses. I do not necessarily stick to introducing the radical change. However, it seems to me that the actual effects on 2461 is minimum. RFC2461 basically only defines some syntaxes of the M/O bits, and leaves almost all the details of the semantics to RFC2462. So, we could even keep the wording in RFC2461(bis), and only deprecate the usage in RFC2462. (Again, I'd like to emphasize that I'm not insisting on introducing the change. I'm saying this only when we could ever agree on the changes from RFC2462's perspective (i.e., the usage side)). 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 Apr 15 10:48: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 KAA28280 for ; Thu, 15 Apr 2004 10:48: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 1BE83G-0002Wk-1K for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 10:41:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FEfEUt009710 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 10: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 1BE7ua-0007QT-AB for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 10: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 KAA27334 for ; Thu, 15 Apr 2004 10:32:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7uY-00008y-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 10:32:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7tm-000047-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 10:31:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7tB-0007nI-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 10:30:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7go-0001T4-4F; Thu, 15 Apr 2004 10: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 1BE7bD-0006pZ-9I for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 10:12: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 KAA25599 for ; Thu, 15 Apr 2004 10:12:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7bA-000655-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:12:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7aM-000610-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:11:23 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BE7Zi-0005u4-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:10:42 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 10:10:08 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message Subject: RE: [rfc2462bis] whether we need the M/O flags Date: Thu, 15 Apr 2004 10:10:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Message-ID: Content-Transfer-Encoding: quoted-printable Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQi7UT0rY5b4oduSiu+91fSJ+izBAABDX+g From: "Soliman Hesham" To: "JINMEI Tatuya / ????" CC: X-OriginalArrivalTime: 15 Apr 2004 14:10:08.0593 (UTC) FILETIME=[5BCF5C10:01C422F3] 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 > > FWIW, I really think that there is no point in going round=20 > and round again > > in this discussion when there is no harm done by keeping them.=20 > > Removing them is not backward compatible for 2461 anyway.=20 > > So I recommend we leave them as defined. >=20 > I see your points, and I actually expected this type of responses. I > do not necessarily stick to introducing the radical change. However, > it seems to me that the actual effects on 2461 is minimum. RFC2461 > basically only defines some syntaxes of the M/O bits, and leaves > almost all the details of the semantics to RFC2462. So, we=20 > could even > keep the wording in RFC2461(bis), and only deprecate the usage in > RFC2462. (Again, I'd like to emphasize that I'm not insisting on > introducing the change. I'm saying this only when we could=20 > ever agree > on the changes from RFC2462's perspective (i.e., the usage side)). =3D> I'm not personally worried about the amount of work involved in = updating 2461. It can be done in a few minutes. The reasons I oppose this are: - We should stop revisiting design decisions unless there is a clear danger in the current spec. I don't see any. I realise that you're not = driving this change I'm trying to address the whole thread. It seems counter productive = to me. - It's not a backward compatible change, so I actually think it's more harmful to remove them.=20 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 Apr 15 10:53: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 KAA28490 for ; Thu, 15 Apr 2004 10:53: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 1BE84p-0003Mk-R9 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 10:42:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FEgpQl012933 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 10:42:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7wY-0000JX-RD for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 10:34: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 KAA27506 for ; Thu, 15 Apr 2004 10:34:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7wW-0000ML-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 10:34:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7vh-0000Gc-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 10:33:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7uy-0000Ao-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 10:32:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7gp-0001Tj-EU; Thu, 15 Apr 2004 10:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7c4-0007CP-PM for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 10:13: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 KAA25673 for ; Thu, 15 Apr 2004 10:13:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7c2-000698-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:13:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7bB-00065G-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:12:14 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BE7aW-00061F-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:11:33 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5F3C915210; Thu, 15 Apr 2004 23:11:25 +0900 (JST) Date: Thu, 15 Apr 2004 23:11:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Soliman Hesham , Brian Haberman , Margaret Wasserman , Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt In-Reply-To: <40759205.9060803@innovationslab.net> 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 Fri, 9 Apr 2004 08:08:49 +0300 (EEST), >>>>> Pekka Savola said: > Note that the latter paragraph intentionally excludes the discussion > of other kinds of limited-scope addresses from discussion, i.e., it > only mentions why adding link-locals is bad. Yeah, I know. The intention in my original message was that there had been a discussion on the publication of limited-scope address in the global DNS, and dnsop people have apparently reached a consensus, particularly in response to the following part in this thread: >>>>> On Thu, 08 Apr 2004 13:55:17 -0400, >>>>> Brian Haberman said: > That is why it is stated as "are not expected to be in the global DNS". > There will be issues caused by them being advertised yet not reachable. > Would you rather see a stronger statement against inclusion in the > global DNS? > My personal opinion is that they should never be in the global DNS, but > that didn't seem to be the consensus of the WG. > The discussion of site-locals is deferred to an appendix. The > relevant text from there is: Still, I should have referred to the accurate place in the dns-issues draft to avoid confusion. Not having done so was my fault...sorry about that. And, > Would it make sense to also include the discussion of these new unique > local addresses? I've hesitated to do so, because they've been a > moving target, and I'd like to avoid adding anything there which could > become invalid if the document is changed prior to IESG approval. at least I didn't intend to propose including the new unique addresses in the dnsop-ipv6-dns-issues draft. IMO, it should ship without waiting for the discussion about unique-local addresses. 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 Apr 15 11:16:37 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 LAA29903 for ; Thu, 15 Apr 2004 11:16:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8Fp-0007VO-78 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 10:54:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FEsDMq028843 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 10:54:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8A5-0005io-KD for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 10:48: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 KAA28308 for ; Thu, 15 Apr 2004 10:48:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8A3-0001cx-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 10:48:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE896-0001X9-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 10:47:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE88I-0001Rz-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 10:46:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE80A-0001T0-HJ; Thu, 15 Apr 2004 10:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7ra-0006Fb-Db for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 10:29: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 KAA27100 for ; Thu, 15 Apr 2004 10:29:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7rX-0007hi-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:29:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7qg-0007dO-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:28:15 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BE7ps-0007Ti-00 for ipv6@ietf.org; Thu, 15 Apr 2004 10:27:24 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3FEQmY11269; Thu, 15 Apr 2004 07:26:48 -0700 X-mProtect: <200404151426> Nokia Silicon Valley Messaging Protection Received: from dhcp64-134-203-245.nyme.phl.wayport.net (64.134.203.245, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdChdtxv; Thu, 15 Apr 2004 07:26:45 PDT Message-Id: <4.3.2.7.2.20040415072314.0323b608@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Apr 2004 07:25:16 -0700 To: Brian E Carpenter From: Bob Hinden Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Cc: ipv6@ietf.org In-Reply-To: <407E3B91.322DCC66@zurich.ibm.com> References: <200404090519.BAA16640@ss10.danlan.com> <56124720-8A07-11D8-8D01-000A95928574@kurtis.pp.se> <029001c41ec7$1780d1e0$6401a8c0@stephen> 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 Brian, At 12:36 AM 4/15/2004, Brian E Carpenter wrote: >Stephen Sprunk wrote: >... > > Suggested text for 7.0: > > > > AAAA and PTR records for Local IPv6 addresses MAY be installed in the > global > > DNS at the option of the site to which they are assigned. It is expected > > that most sites will not make use of this option, but some sites may find > > benefits in doing so. > >Can we just say yes to this, rather than arguing endlessly about who would >or wouldn't do so? This works for me. I think going beyond this moves it into operational aspects that might be better discussed elsewhere. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 15 13:05:43 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 NAA05188 for ; Thu, 15 Apr 2004 13:05: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 1BEAEs-0006oF-Sd for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 13:01:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FH1M1p026175 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 13:01:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEA72-0004fz-HF for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 12:53: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 MAA04238 for ; Thu, 15 Apr 2004 12:53:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEA70-0006e3-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 12:53:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEA63-0006Vr-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 12:52:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEA4z-0006I7-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 12:51:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9vB-00007F-U3; Thu, 15 Apr 2004 12:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9in-00050q-To for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 12:28: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 MAA02826 for ; Thu, 15 Apr 2004 12:28:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9im-0003bx-00 for ipv6@ietf.org; Thu, 15 Apr 2004 12:28:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9hs-0003XK-00 for ipv6@ietf.org; Thu, 15 Apr 2004 12:27:16 -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 1BE9gz-0003Q1-00 for ipv6@ietf.org; Thu, 15 Apr 2004 12:26:22 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2004 08:36:25 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3FGPn7t028754 for ; Thu, 15 Apr 2004 09:25:49 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHP90796; Thu, 15 Apr 2004 12:25:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20040415121416.02cdbf00@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Apr 2004 12:25:46 -0400 To: ipv6@ietf.org From: Ralph Droms Subject: Re: [rfc2462bis] whether we need the M/O flags 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 At 08:40 PM 4/15/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >[...] As far as I know, no host implementation supports the M flag. >Regarding the O flag, I've implemented the host side of the flag, >which invokes a DHCPv6 client upon receiving an RA with the O bit. >But I've never heard of other implementations. Here's another data point: The Cisco IPv6 stack implements the host behavior for the O bit, initiating an Information-request exchange when an RA with the O bit set causes OtherConfigFlag to change from FALSE to TRUE. The stack ignores the M bit because there is no code for DHCPv6 address assignment. The RA code in the Cisco stack can be configured to send RAs with the M and O bits cleared or set. - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 15 13:49:41 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 NAA08613 for ; Thu, 15 Apr 2004 13:49: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 1BEAse-0008LR-M4 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 13:42:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FHgSGM032073 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 13:42:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAkk-0006SF-K9 for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 13:34: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 NAA07786 for ; Thu, 15 Apr 2004 13:34:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAki-000362-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 13:34:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEAjq-00030M-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 13:33:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEAj4-0002vA-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 13:32:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAXv-0003Em-SC; Thu, 15 Apr 2004 13: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 1BEATK-00024o-2G for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 13:16: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 NAA05703 for ; Thu, 15 Apr 2004 13:16:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEATH-0001P5-00 for ipv6@ietf.org; Thu, 15 Apr 2004 13:16:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEAST-0001LC-00 for ipv6@ietf.org; Thu, 15 Apr 2004 13:15:26 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1BEARq-0001Gm-00 for ipv6@ietf.org; Thu, 15 Apr 2004 13:14:46 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3FHEhWo010531 for ; Thu, 15 Apr 2004 11:14:43 -0600 (MDT) Received: from xpa-fe1 (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 <0HW8005HL2KJTI@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Thu, 15 Apr 2004 11:14:43 -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 <0HW800BZK2KIGV@mail.sun.net> for ipv6@ietf.org; Thu, 15 Apr 2004 11:14:42 -0600 (MDT) Date: Thu, 15 Apr 2004 10:14:41 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Cc: ipv6@ietf.org Message-id: <61DA14AD-8F00-11D8-BB4F-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: 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 think that deprecating the O & M bits will be good. I'm not too worried about incompatibility, as most code do not support those bits anyway. Also, it is mostly an operational issue. All we need to do is to publish a BCP saying essentially: "Do not set the O & M bits in RA" and we are done. In terms of harm, I think leaving O & M is harmful, as it keeps confusing people. A good design is not one where there is no extra feature to remove, not one where there is no new feature to add. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 15 14:07: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 OAA10132 for ; Thu, 15 Apr 2004 14:07: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 1BEBFK-0006fH-Ip for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 14:05:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FI5sY6025615 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 14:05:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEB5S-00032B-MR for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 13:55: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 NAA08911 for ; Thu, 15 Apr 2004 13:55:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEB5Q-0005Dm-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 13:55:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEB4S-00057K-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 13:54:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEB3l-00051q-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 13:53:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAy2-00015S-AJ; Thu, 15 Apr 2004 13: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 1BEApj-0007sT-TI for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 13:39: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 NAA08039 for ; Thu, 15 Apr 2004 13:39:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAph-0003Yr-00 for ipv6@ietf.org; Thu, 15 Apr 2004 13:39:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEAou-0003Tz-00 for ipv6@ietf.org; Thu, 15 Apr 2004 13:38:37 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BEAoR-0003Np-00 for ipv6@ietf.org; Thu, 15 Apr 2004 13:38:07 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3FHc7HS010257 for ; Thu, 15 Apr 2004 11:38:07 -0600 (MDT) Received: from xpa-fe1 (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 <0HW800B0R3NIPI@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Thu, 15 Apr 2004 11:38:07 -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 <0HW800B5U3NHGI@mail.sun.net> for ipv6@ietf.org; Thu, 15 Apr 2004 11:38:06 -0600 (MDT) Date: Thu, 15 Apr 2004 10:38:03 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: <61DA14AD-8F00-11D8-BB4F-00039376A6AA@sun.com> To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , 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: <61DA14AD-8F00-11D8-BB4F-00039376A6AA@sun.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 Apr 15, 2004, at 10:14 AM, Alain Durand wrote: > A good design is not one where there is no extra feature to remove, > not one where there is no new feature to add. This of course should read: > A good design is one where there is no extra feature to remove, > not one where there is no new feature to add. Sorry for the confusion. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 15 14:32:25 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 OAA11124 for ; Thu, 15 Apr 2004 14:32: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 1BEBXZ-0002zJ-L8 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 14:24:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FIOjnj011480 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 14:24:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEBPx-0001VI-Fx for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 14:16: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 OAA10535 for ; Thu, 15 Apr 2004 14:16:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEBPv-0006V6-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 14:16:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEBOy-0006Ow-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 14:15:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEBOb-0006N0-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 14:15:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEBFT-0006jt-Si; Thu, 15 Apr 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 1BEB6Z-0003AN-3B for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 13:56: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 NAA08966 for ; Thu, 15 Apr 2004 13:56:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEB6W-0005JZ-00 for ipv6@ietf.org; Thu, 15 Apr 2004 13:56:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEB6D-0005HI-00 for ipv6@ietf.org; Thu, 15 Apr 2004 13:56:30 -0400 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1BEB5J-0005CX-00 for ipv6@ietf.org; Thu, 15 Apr 2004 13:55:33 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel8.hp.com (Postfix) with ESMTP id A65581C01E49; Thu, 15 Apr 2004 13:55:30 -0400 (EDT) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i3FHdUj19939; Thu, 15 Apr 2004 23:09:30 +0530 (IST) Message-ID: <407ECC74.8030500@india.hp.com> Date: Thu, 15 Apr 2004 23:25:00 +0530 From: Vijayabhaskar A K User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: JINMEI Tatuya / ???? , ipv6@ietf.org Subject: Re: [rfc2462bis] whether we need the M/O flags References: In-Reply-To: Content-Type: text/plain; charset=us-ascii 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 I am not sure whether this is a deficiency in this model. Currently, even if M/O is turned off, the nodes which had triggered stateful protocol will continue using it. Unless or otherwise you reboot all the nodes in the link, you cannot make the nodes to switch to stateless autoconf. This could be solved by carrying some more information in the RAs rather than a single bit. ~Vijay Soliman Hesham wrote: > > > FWIW, I really think that there is no point in going round > > and round again > > > in this discussion when there is no harm done by keeping them. > > > Removing them is not backward compatible for 2461 anyway. > > > So I recommend we leave them as defined. > > > > I see your points, and I actually expected this type of responses. I > > do not necessarily stick to introducing the radical change. However, > > it seems to me that the actual effects on 2461 is minimum. RFC2461 > > basically only defines some syntaxes of the M/O bits, and leaves > > almost all the details of the semantics to RFC2462. So, we > > could even > > keep the wording in RFC2461(bis), and only deprecate the usage in > > RFC2462. (Again, I'd like to emphasize that I'm not insisting on > > introducing the change. I'm saying this only when we could > > ever agree > > on the changes from RFC2462's perspective (i.e., the usage side)). > >=> I'm not personally worried about the amount of work involved in updating >2461. It can be done in a few minutes. The reasons I oppose this are: > > - We should stop revisiting design decisions unless there is a clear >danger > in the current spec. I don't see any. I realise that you're not driving >this change > I'm trying to address the whole thread. It seems counter productive to >me. > > - It's not a backward compatible change, so I actually think it's more >harmful > to remove them. > > >Hesham > > > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, > > Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > > >======================================================== >This email may contain confidential and privileged material for the sole >use of the intended recipient. Any review or distribution by others is >strictly prohibited. If you are not the intended recipient please contact >the sender and delete all copies. >======================================================== > > >-------------------------------------------------------------------- >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 Thu Apr 15 15:48: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 PAA21889 for ; Thu, 15 Apr 2004 15:48: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 1BECow-00060U-L1 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 15:46:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FJkkGf023082 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 15:46:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BECkD-0004yK-NZ for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 15:41: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 PAA20403 for ; Thu, 15 Apr 2004 15:41: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 1BECkC-0005RI-B3 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 15:41:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BECie-0005Ln-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 15:40:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BECi5-0005JO-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 15:39:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BECW2-0001vd-0v; Thu, 15 Apr 2004 15:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BECUl-0001Oy-Tx for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 15:25: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 PAA16162 for ; Thu, 15 Apr 2004 15:25:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BECUk-0003ls-00 for ipv6@ietf.org; Thu, 15 Apr 2004 15:25:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BECEK-0002Jd-00 for ipv6@ietf.org; Thu, 15 Apr 2004 15:08:57 -0400 Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx with esmtp (Exim 4.12) id 1BECDZ-0002E7-00 for ipv6@ietf.org; Thu, 15 Apr 2004 15:08:09 -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 i3FJ7ul10929 for ; Thu, 15 Apr 2004 12:07:57 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id i3FJ7wH07541 for ; Thu, 15 Apr 2004 12:07:58 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id MAA01305 for ipv6@ietf.org; Thu, 15 Apr 2004 12:08:44 -0700 (PDT) Date: Thu, 15 Apr 2004 12:08:44 -0700 (PDT) From: Tim Hartrick Message-Id: <200404151908.MAA01305@feller.mentat.com> To: ipv6@ietf.org Subject: Re: [rfc2462bis] whether we need the M/O flags X-Sun-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=none autolearn=no version=2.60 All, I believe that it is entirely too late in the life of this protocol to be removing these bits. If there is in fact confusion over their usage then the usage should be clarified. The original intent of this revision was to clarify portions of the specification which were not clear, not to open every feature for the full-scale debate and revision. There is running, shipping code that makes use of these bits. What, exactly, is the upside in breaking that code? Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 15 16:45: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 QAA25831 for ; Thu, 15 Apr 2004 16:45: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 1BEDei-00089C-Fv for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 16:40:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FKeGXM031314 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 16:40:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDdQ-0007hs-68 for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 16:38: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 QAA25422 for ; Thu, 15 Apr 2004 16:38: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 1BEDdO-0000gd-A6 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 16:38:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDcT-0000er-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 16:37:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEDbj-0000dB-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 16:37:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDTs-0005Pa-3n; Thu, 15 Apr 2004 16:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDQT-0004nB-Fb for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 16: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 QAA24706 for ; Thu, 15 Apr 2004 16:25: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 1BEDQR-00004h-LO for ipv6@ietf.org; Thu, 15 Apr 2004 16:25:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDOt-0007mW-00 for ipv6@ietf.org; Thu, 15 Apr 2004 16:23:55 -0400 Received: from oak1a.cats.ohiou.edu ([132.235.8.45]) by ietf-mx with esmtp (Exim 4.12) id 1BEDOV-0007lI-00 for ipv6@ietf.org; Thu, 15 Apr 2004 16:23:31 -0400 Received: from 132.235.232.96 by pm6 (PureMessage); Thu Apr 15 16:12:45 2004 Received: from hkruse2003a (dhcp-232-096.cns.ohiou.edu [132.235.232.96]) (authenticated bits=0) by oak3a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id i3FKCiDV2083497 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 15 Apr 2004 16:12:44 -0400 (EDT) Date: Thu, 15 Apr 2004 16:11:27 -0400 From: Hans Kruse To: ipv6@ietf.org Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt Message-ID: <86322921.1082045487@hkruse2003a> In-Reply-To: <407E3B91.322DCC66@zurich.ibm.com> References: <200404090519.BAA16640@ss10.danlan.com> <56124720-8A07-11D8-8D01-000A95928574@kurtis.pp.se> <029001c41ec7$1780d1e0$6401a8c0@stephen> <407E3B91.322DCC66@zurich.ibm.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Stop: Thu Apr 15 16:12:45 2004 X-PMX-Start: Thu Apr 15 16:12:45 2004 X-PMX-Version: 4.5.0.92886, Antispam-Core: 4.0.4.93542, Antispam-Data: 2004.4.15.97529 (pm6) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report='__TO_MALFORMED_2 0, __HAS_MSGID 0, __SANE_MSGID 0, __IN_REP_TO 0, __REFERENCES 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __CD 0, __UNUSABLE_MSGID 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0' 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 The suggested language seems fine to me (aka just say yes...). --On Thursday, April 15, 2004 09:36 +0200 Brian E Carpenter wrote: > Stephen Sprunk wrote: > .... >> Suggested text for 7.0: >> >> AAAA and PTR records for Local IPv6 addresses MAY be installed in the >> global DNS at the option of the site to which they are assigned. It is >> expected that most sites will not make use of this option, but some >> sites may find benefits in doing so. > > Can we just say yes to this, rather than arguing endlessly about who > would or wouldn't do so? > > Brian > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 15 21:18:55 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 VAA15431 for ; Thu, 15 Apr 2004 21:18: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 1BEHzL-0003zX-4k for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 21:17:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G1HpXF015338 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 21:17:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEHlc-0001Fs-N0 for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 21:03: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 VAA14347 for ; Thu, 15 Apr 2004 21:03: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 1BEHla-0003gT-8k for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 21:03:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEHke-0003bF-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 21:02:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEHjl-0003YD-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 21:01:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEHcN-0007TY-1N; Thu, 15 Apr 2004 20:54:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEHWC-00069g-Hd for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 20:47: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 UAA13780 for ; Thu, 15 Apr 2004 20:47: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 1BEHWA-0002uu-1y for ipv6@ietf.org; Thu, 15 Apr 2004 20:47:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEHVG-0002sl-00 for ipv6@ietf.org; Thu, 15 Apr 2004 20:46:46 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BEHUf-0002qV-00 for ipv6@ietf.org; Thu, 15 Apr 2004 20:46:09 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3G0kAHS022924 for ; Thu, 15 Apr 2004 18:46:10 -0600 (MDT) Received: from xpa-fe1 (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 <0HW800BWMNGXPI@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Thu, 15 Apr 2004 18:46:10 -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 <0HW8002VGNGWVP@mail.sun.net> for ipv6@ietf.org; Thu, 15 Apr 2004 18:46:09 -0600 (MDT) Date: Thu, 15 Apr 2004 17:46:06 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: <200404151908.MAA01305@feller.mentat.com> To: Tim Hartrick Cc: ipv6@ietf.org Message-id: <71F1495C-8F3F-11D8-B3FE-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: <200404151908.MAA01305@feller.mentat.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 Ok, what would break if we were to declare the O & M bit historic and issue a BCP recommending not to set them in RA? It is unclear to me what part of existing code would break.... - Alain. On Apr 15, 2004, at 12:08 PM, Tim Hartrick wrote: > > I believe that it is entirely too late in the life of this protocol > to be removing these bits. If there is in fact confusion over their > usage > then the usage should be clarified. The original intent of this > revision was > to clarify portions of the specification which were not clear, not to > open every > feature for the full-scale debate and revision. There is running, > shipping > code that makes use of these bits. What, exactly, is the upside in > breaking > that code? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 15 23:20:34 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 XAA22705 for ; Thu, 15 Apr 2004 23:20: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 1BEJry-00063D-Az for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 23:18:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G3IMam023252 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 23:18:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJpE-0005QB-8r for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 23:15: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 XAA22454 for ; Thu, 15 Apr 2004 23:15: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 1BEJpC-0005XG-3Q for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 23:15:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEJme-0005Dc-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 23:12:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BEJiS-0004lr-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 23:08:32 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BEJWf-0003wu-Gd for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 22:56:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJQY-0000QG-DZ; Thu, 15 Apr 2004 22: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 1BEJMR-00083F-De for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 22:45: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 WAA21121 for ; Thu, 15 Apr 2004 22:45: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 1BEJMN-0003fE-QY for ipv6@ietf.org; Thu, 15 Apr 2004 22:45:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEJLU-0003cr-00 for ipv6@ietf.org; Thu, 15 Apr 2004 22:44:48 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BEJLC-0003a5-00 for ipv6@ietf.org; Thu, 15 Apr 2004 22:44:30 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:1437:2a85:279b:b4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D237C15210; Fri, 16 Apr 2004 11:44:23 +0900 (JST) Date: Fri, 16 Apr 2004 11:44:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Hartrick Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] whether we need the M/O flags In-Reply-To: <200404151908.MAA01305@feller.mentat.com> References: <200404151908.MAA01305@feller.mentat.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, 15 Apr 2004 12:08:44 -0700 (PDT), >>>>> Tim Hartrick said: > I believe that it is entirely too late in the life of this protocol > to be removing these bits. If there is in fact confusion over their usage > then the usage should be clarified. The original intent of this revision was > to clarify portions of the specification which were not clear, not to open every > feature for the full-scale debate and revision. There is running, shipping > code that makes use of these bits. What, exactly, is the upside in breaking > that code? Just out of curiosity, what exactly do you mean by "running, shipping code that makes use of these bits." In particular, are you referring to particular implementations that - invoke DHCPv6 on the reception of an RA with the M flag being set - invoke DHCPv6 or (so called) stateless-DHCPv6 on the reception of an RA with the O flag being set ? If so, could you tell me which implementations do? Once again, I'm not necessarily pushing the idea of "deprecating" the M/O flags. Also, breaking existing code is the last thing I want to do. 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 Apr 15 23:40: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 XAA23950 for ; Thu, 15 Apr 2004 23:40: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 1BEKBC-0001St-Rm for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 23:38:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G3cEU7005626 for ipv6-archive@odin.ietf.org; Thu, 15 Apr 2004 23:38:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEK2P-0008C6-IY for ipv6-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 23:29: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 XAA23470 for ; Thu, 15 Apr 2004 23:29: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 1BEK2N-0006p5-Nv for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 23:29:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEK1Y-0006gj-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 23:28:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEK0C-0006Rb-00 for ipv6-web-archive@ietf.org; Thu, 15 Apr 2004 23:26:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJta-0006L9-VP; Thu, 15 Apr 2004 23: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 1BEJqc-0005hl-Sx for ipv6@optimus.ietf.org; Thu, 15 Apr 2004 23:16: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 XAA22586 for ; Thu, 15 Apr 2004 23:16: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 1BEJqa-0005eT-QM for ipv6@ietf.org; Thu, 15 Apr 2004 23:16:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEJpR-0005aC-00 for ipv6@ietf.org; Thu, 15 Apr 2004 23:15:45 -0400 Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx with esmtp (Exim 4.12) id 1BEJno-0005Hv-00 for ipv6@ietf.org; Thu, 15 Apr 2004 23:14:04 -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 i3G3Dsl21071; Thu, 15 Apr 2004 20:13:54 -0700 (PDT) Received: from hercule (hercule [192.88.122.127]) by leo.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id i3G3DsH14191; Thu, 15 Apr 2004 20:13:54 -0700 (PDT) Subject: Re: [rfc2462bis] whether we need the M/O flags From: Tim Hartrick Reply-To: tim@mentat.com To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= Cc: Tim Hartrick , ipv6@ietf.org In-Reply-To: References: <200404151908.MAA01305@feller.mentat.com> Content-Type: text/plain Organization: Mentat Inc. Message-Id: <1082042010.2976.5.camel@hercule> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 15 Apr 2004 08:13:33 -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.3 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jinmei, > > > I believe that it is entirely too late in the life of this protocol > > to be removing these bits. If there is in fact confusion over their usage > > then the usage should be clarified. The original intent of this revision was > > to clarify portions of the specification which were not clear, not to open every > > feature for the full-scale debate and revision. There is running, shipping > > code that makes use of these bits. What, exactly, is the upside in breaking > > that code? > > Just out of curiosity, what exactly do you mean by "running, shipping > code that makes use of these bits." In particular, are you referring > to particular implementations that > > - invoke DHCPv6 on the reception of an RA with the M flag being set > - invoke DHCPv6 or (so called) stateless-DHCPv6 on the reception of > an RA with the O flag being set > > ? If so, could you tell me which implementations do? > > Once again, I'm not necessarily pushing the idea of "deprecating" the > M/O flags. Also, breaking existing code is the last thing I want to > do. I don't know of any implementations which depend on these bits for DHCPv6 invocation or termination. That doesn't mean that none exist. There are multiple router implementations which allow these bits to be advertised. What is the upside in making these implementations obsolete at this late date? Unless we are planning on doing a complete survey of all implementations to make sure that there is no dependency on these bits I just don't see why we need or even want to deprecate them. Are we so short of other work that we need to waste time on breaking things which are already working? I don't get it. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 16 00:36:04 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 AAA26576 for ; Fri, 16 Apr 2004 00:36: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 1BEL0q-0002cP-P8 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 00:31:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G4VaH3010060 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 00:31:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEKyc-0002IJ-Ar for ipv6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 00:29: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 AAA26137 for ; Fri, 16 Apr 2004 00:29: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 1BEKyZ-0003Je-OE for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 00:29:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEKxX-0003DU-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 00:28:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEKwl-00035g-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 00:27:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEKrZ-0000wm-Bz; Fri, 16 Apr 2004 00: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 1BEKqO-0000ly-QQ for ipv6@optimus.ietf.org; Fri, 16 Apr 2004 00: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 AAA25625 for ; Fri, 16 Apr 2004 00: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 1BEKqM-0002S2-Bt for ipv6@ietf.org; Fri, 16 Apr 2004 00:20:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEKpR-0002OR-00 for ipv6@ietf.org; Fri, 16 Apr 2004 00:19:50 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BEKoq-0002Hr-00 for ipv6@ietf.org; Fri, 16 Apr 2004 00:19:12 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Apr 2004 00:18:28 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message Subject: RE: [rfc2462bis] whether we need the M/O flags Date: Fri, 16 Apr 2004 00:18:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Message-ID: Content-Transfer-Encoding: quoted-printable Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQjD4+BBQ+lZXOVSRaTsHTLFNglDgAWJRwg From: "Soliman Hesham" To: "Alain Durand" , "JINMEI Tatuya / ????" CC: X-OriginalArrivalTime: 16 Apr 2004 04:18:28.0992 (UTC) FILETIME=[DECFE000:01C42369] 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 think that deprecating the O & M bits will be good. > I'm not too worried about incompatibility, as most code > do not support those bits anyway.=20 =3D> I'm sorry, "most" is not good enough. If there is one = implementation that supports it then we have _no_ right to do this. This is not the intention of the revision. We don't know what every implementation does and we can't just keep playing around with specs forever. > In terms of harm, I think leaving O & M is harmful, as it keeps=20 > confusing people. =3D> Instead of removing them and writing another BCP, I have an = alternative: isn't it easier to clarify the confusion in the text? this is already = done in 2461bis. If we don't start taking IPv6 DSs seriously no one else will. 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 Fri Apr 16 01:19: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 BAA28087 for ; Fri, 16 Apr 2004 01:19: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 1BELgv-0002NO-1z for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 01:15:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G5F5VC009126 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 01:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BELcP-0001jj-0U for ipv6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 01:10: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 BAA27804 for ; Fri, 16 Apr 2004 01:10: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 1BELcM-0006NV-6c for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 01:10:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BELbQ-0006G7-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 01:09:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BELaR-000684-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 01:08:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BELRO-0007If-P0; Fri, 16 Apr 2004 00:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BELQO-0006yH-1h for ipv6@optimus.ietf.org; Fri, 16 Apr 2004 00:58: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 AAA27410 for ; Fri, 16 Apr 2004 00:57: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 1BELQL-0005Ql-89 for ipv6@ietf.org; Fri, 16 Apr 2004 00:57:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BELPK-0005Mh-00 for ipv6@ietf.org; Fri, 16 Apr 2004 00:56:55 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BELOs-0005J2-00 for ipv6@ietf.org; Fri, 16 Apr 2004 00:56:26 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:a404:9bbb:9c9:3ca1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C84A315210; Fri, 16 Apr 2004 13:56:25 +0900 (JST) Date: Fri, 16 Apr 2004 13:56:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] whether we need the M/O flags In-Reply-To: <1082042010.2976.5.camel@hercule> References: <200404151908.MAA01305@feller.mentat.com> <1082042010.2976.5.camel@hercule> 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 15 Apr 2004 08:13:33 -0700, >>>>> Tim Hartrick said: >> Just out of curiosity, what exactly do you mean by "running, shipping >> code that makes use of these bits." In particular, are you referring >> to particular implementations that >> >> - invoke DHCPv6 on the reception of an RA with the M flag being set >> - invoke DHCPv6 or (so called) stateless-DHCPv6 on the reception of >> an RA with the O flag being set >> >> ? If so, could you tell me which implementations do? >> >> Once again, I'm not necessarily pushing the idea of "deprecating" the >> M/O flags. Also, breaking existing code is the last thing I want to >> do. > I don't know of any implementations which depend on these bits for > DHCPv6 invocation or termination. Okay, thanks. > That doesn't mean that none exist. Of course not, I know. > There are multiple router implementations which allow these bits to be > advertised. True, but without having hosts depending on it, deprecating these flags does not break anything (see a message from Alain). (Just to avoid unnecessary flame) I'm not insisting we should deprecate the flags, and in particular, not just because of this. One thing we may have to care, however, is that the lack of implementation might be a barrier of recycling the spec as a DS, since we'd need to show interoperable implementations. > What is the upside in making these implementations obsolete > at this late date? Unless we are planning on doing a complete survey of > all implementations to make sure that there is no dependency on these > bits I just don't see why we need or even want to deprecate them. Are > we so short of other work that we need to waste time on breaking things > which are already working? I don't get it. (I still don't understand what you mean by "things which are already working", but anyway) you're correct in that we do not deprecate the flags unless we have a clear and strong reason to do so. In particular, I understand we should not deprecate them just because there is almost no implementation (especially at the host side) depending on them. I do not forget the original intention of the rfc2462bis work: recycling the existing document as a draft standard. The default decision on a controversial issue should thus be conservative. Right now, I'm listening to opinions of others, collecting information to decide whether this path makes sense or not. I've already known yours and I understand the 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 Fri Apr 16 02:35:53 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 CAA15600 for ; Fri, 16 Apr 2004 02:35: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 1BEMof-0005yz-2U for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 02:27:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G6R9UV022997 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 02:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEMoR-0005pG-BT for ipv6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 02:26: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 CAA14991 for ; Fri, 16 Apr 2004 02:26: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 1BEMoN-0005Lt-Dp for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 02:26:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEMnQ-0005HZ-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 02:25:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEMmV-0005DT-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 02:24:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEMdx-0001YB-CM; Fri, 16 Apr 2004 02:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEMau-000817-S2 for ipv6@optimus.ietf.org; Fri, 16 Apr 2004 02:12: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 CAA13446 for ; Fri, 16 Apr 2004 02:12: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 1BEMar-0004MI-2x for ipv6@ietf.org; Fri, 16 Apr 2004 02:12:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEMa2-0004I8-00 for ipv6@ietf.org; Fri, 16 Apr 2004 02:12:02 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BEMZ8-00046v-00 for ipv6@ietf.org; Fri, 16 Apr 2004 02:11:06 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Apr 2004 02:10:29 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message Subject: RE: [rfc2462bis] whether we need the M/O flags Date: Fri, 16 Apr 2004 02:10:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Message-ID: Content-Transfer-Encoding: quoted-printable Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQjcNKoNYEGOilFSI62oJH5D4gA0AABy8dg From: "Soliman Hesham" To: "JINMEI Tatuya / ????" , CC: X-OriginalArrivalTime: 16 Apr 2004 06:10:29.0680 (UTC) FILETIME=[84A77B00:01C42379] 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 > One thing we may have to care, however, is that the lack of > implementation might be a barrier of recycling the spec as a=20 > DS, since > we'd need to show interoperable implementations. =3D> Good point. It would be good to get some clarification on whether this is an issue though. I mean, considering that both RFCs are already = DS. My understanding was that this is more of an issue for a PS going to DS. > (I still don't understand what you mean by "things which are already > working", but anyway) you're correct in that we do not deprecate the > flags unless we have a clear and strong reason to do so. In > particular, I understand we should not deprecate them just because > there is almost no implementation (especially at the host side) > depending on them. >=20 > I do not forget the original intention of the rfc2462bis work: > recycling the existing document as a draft standard. The default > decision on a controversial issue should thus be conservative. >=20 =3D> Agreed. 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 Fri Apr 16 02:42: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 CAA16064 for ; Fri, 16 Apr 2004 02:42: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 1BEN0G-0000KZ-0P for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 02:39:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G6d7Cg001263 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 02: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 1BEMy8-00086F-4t for ipv6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 02: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 CAA15686 for ; Fri, 16 Apr 2004 02: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 1BEMy4-0006PV-9f for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 02:36:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEMx3-0006IR-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 02:35:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEMw4-0006Bx-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 02:34:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEMoe-0005yQ-N1; Fri, 16 Apr 2004 02:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEMlW-0004Ra-Mg for ipv6@optimus.ietf.org; Fri, 16 Apr 2004 02:23: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 CAA14868 for ; Fri, 16 Apr 2004 02:23: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 1BEMlS-00058L-Vk for ipv6@ietf.org; Fri, 16 Apr 2004 02:23:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEMkY-00054x-00 for ipv6@ietf.org; Fri, 16 Apr 2004 02:22:54 -0400 Received: from [208.246.215.201] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1BEMkK-00051F-00 for ipv6@ietf.org; Fri, 16 Apr 2004 02:22:40 -0400 Received: from avici.com (swdev110.avici.com [10.2.21.110]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i3G6M9nG007997 for ; Fri, 16 Apr 2004 02:22:09 -0400 Message-Id: <200404160622.i3G6M9nG007997@mailhost.avici.com> From: Markus Jork To: ipv6@ietf.org In-reply-to: Your message of "Thu, 15 Apr 2004 10:30:27 +0200." <26436E48-8EB7-11D8-A74E-000A95CD987A@muada.com> Date: Fri, 16 Apr 2004 02:22:08 -0400 X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean Subject: Re: RFC 2461 : Neighbor Discovery 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 > > However, there is one other thing you should consider. In IPv6, we're > supposed to use /64s for pretty much all subnets. So it's not > inconceivable that router A sends a packet to one of those 2^64 > addresses belonging to the PPP subnet that _isn't_ an address for > router B. A naive implemenation may result in such a packet being > returned to router A by router B and a routing loop (that attackers can > use to attack the routers because of the multiplication effect) is > born. Since it's unlikely a router only has PPP interfaces, the full ND > code must be in there anyway, so it makes sense to use regular neighbor > discovery / unreachability to avoid this situation. On the other hand, > discovering the addresses on both sides using IPV6CP and then > blackholing the other 2^64-2 addresses may be preferable as this makes > it impossible for attackers to cause ND storms. (Using a /127 would do > this too, but this clashes with some anycast addresses (that nobody > uses anyway).) > If there is an implementation choice to use or not use the NS/NA mechanism on PPP interfaces, that sounds like a recipe for interoperability problems to me. If one implementation sends a NS and expects to see a NA before sending the first message to the neighbors address but the other implementation doesn't use NS/NA messages on the PPP link, there is a problem. Is there any plan to address this in the upcoming PPP spec revision (and how)? Or do you think there is no interop issue? Markus -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 16 08:43:50 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 IAA04756 for ; Fri, 16 Apr 2004 08:43: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 1BESf5-00015p-Sr for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 08:41:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GCfdOd004197 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 08:41:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESZh-00087P-Ff for ipv6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 08:36: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 IAA04292 for ; Fri, 16 Apr 2004 08:36: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 1BESZg-0007Ox-8B for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 08:36:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BESYh-0007Fa-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 08:35:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BESXj-00077Q-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 08:34:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESQw-00062h-7c; Fri, 16 Apr 2004 08:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESII-0004Us-23 for ipv6@optimus.ietf.org; Fri, 16 Apr 2004 08:18: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 IAA03578 for ; Fri, 16 Apr 2004 08:18: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 1BESIG-00057H-Vp for ipv6@ietf.org; Fri, 16 Apr 2004 08:18:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BESHJ-00050R-00 for ipv6@ietf.org; Fri, 16 Apr 2004 08:17:05 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BESGL-0004oX-00 for ipv6@ietf.org; Fri, 16 Apr 2004 08:16:05 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3GCG01C027455; Fri, 16 Apr 2004 14:16:00 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1082042010.2976.5.camel@hercule> References: <200404151908.MAA01305@feller.mentat.com> <1082042010.2976.5.camel@hercule> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "" From: Iljitsch van Beijnum Subject: Re: [rfc2462bis] whether we need the M/O flags Date: Fri, 16 Apr 2004 14:15:57 +0200 To: tim@mentat.com 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 On 15-apr-04, at 17:13, Tim Hartrick wrote: > I don't know of any implementations which depend on these bits for > DHCPv6 invocation or termination. That doesn't mean that none exist. Also, the whole "other config" issue is still very much in a state of flux. Since those mechanisms haven't been defined yet, we can't be sure whether the M and especially O bits would be benificial to those mechanisms. So removing them *now* would be premature if nothing else. (For instance, if we settle on well-known addresses for DNS + DHCPv6, then having the O bit will presumably be a good thing, as an unset O bit indicates that a host can just go to the WKA DNS immediately. Without the O bit it would either have query a DHCP server and time out if there are none available, or use the WKA DNS while querying the DHCP server and possibly the DNS query will time out if the well known addresses are unavailable.) > There are multiple router implementations which allow these bits to be > advertised. What is the upside in making these implementations > obsolete > at this late date? I assert there is no upside. Just look at the whole ip6.int / ip6.arpa thing. Changing stuff that's out there in the real world just to make the specs look prettier is a very bad idea. > Are we so short of other work that we need to waste time on breaking > things > which are already working? I don't get it. Agree 100%. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 16 08:51: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 IAA05167 for ; Fri, 16 Apr 2004 08:51: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 1BESmd-0002LX-7K for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 08:49:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GCnRZg009011 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 08:49:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESfi-0001Hg-9z for ipv6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 08:42: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 IAA04551 for ; Fri, 16 Apr 2004 08:42: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 1BESfh-0000RS-0C for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 08:42:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BESec-0000Hy-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 08:41:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BESdk-00009c-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 08:40:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESTs-0006oR-1w; Fri, 16 Apr 2004 08:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESO9-0005dM-Eh for ipv6@optimus.ietf.org; Fri, 16 Apr 2004 08:24: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 IAA03796 for ; Fri, 16 Apr 2004 08:24: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 1BESO8-0005ty-7Q for ipv6@ietf.org; Fri, 16 Apr 2004 08:24:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BESND-0005lY-00 for ipv6@ietf.org; Fri, 16 Apr 2004 08:23:11 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BESMG-0005eK-00 for ipv6@ietf.org; Fri, 16 Apr 2004 08:22:12 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3GCLS1C027555; Fri, 16 Apr 2004 14:21:28 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200404160622.i3G6M9nG007997@mailhost.avici.com> References: <200404160622.i3G6M9nG007997@mailhost.avici.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9498A16A-8FA0-11D8-AA90-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: RFC 2461 : Neighbor Discovery Date: Fri, 16 Apr 2004 14:21:25 +0200 To: Markus Jork 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 On 16-apr-04, at 8:22, Markus Jork wrote: > If there is an implementation choice to use or not use the NS/NA > mechanism on PPP interfaces, that sounds like a recipe for > interoperability problems to me. That's not good. > Is there any plan to address this in the upcoming PPP spec > revision (and how)? Or do you think there is no interop issue? I think you're right and there is an issue. So I guess we should let the PPP people know in case they didn't think of this themselves. Iljitsch -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 16 12:54: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 MAA21406 for ; Fri, 16 Apr 2004 12:54: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 1BEWRx-000382-B4 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 12:44:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GGiLYZ012022 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 12:44:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWHI-0008CV-4a for ipv6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 12:33: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 MAA19822 for ; Fri, 16 Apr 2004 12:33: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 1BEWHG-0001yj-N0 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 12:33:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEWGV-0001vb-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 12:32:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEWFs-0001rU-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 12:31:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEW8L-00069E-OE; Fri, 16 Apr 2004 12:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVq3-0000PS-5g for ipv6@optimus.ietf.org; Fri, 16 Apr 2004 12:05: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 MAA18149 for ; Fri, 16 Apr 2004 12:05: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 1BEVq1-0007ZS-Mx for ipv6@ietf.org; Fri, 16 Apr 2004 12:05:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEVp3-0007Vb-00 for ipv6@ietf.org; Fri, 16 Apr 2004 12:04:10 -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 1BEVo6-0007Pv-00 for ipv6@ietf.org; Fri, 16 Apr 2004 12:03:10 -0400 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id A8B7D8202 for ; Fri, 16 Apr 2004 18:03:07 +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 16049-13 for ; Fri, 16 Apr 2004 18:02:58 +0200 (CEST) Received: from dhcp70-109.zurich.ibm.com (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 506D47F4D for ; Fri, 16 Apr 2004 18:02:58 +0200 (CEST) Subject: RFC 2385 on IPv6 From: Jeroen Massar To: ipv6@ietf.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7e9VeFhiv2q2IgxoWXwN" Organization: Unfix Message-Id: <1082131376.18432.56.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Apr 2004 18:02:56 +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 --=-7e9VeFhiv2q2IgxoWXwN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, With the current advent of sudden rise of MD5'd BGP requests due to something not be undisclosed apparently I was looking at what routers support this for IPv6 and apparently at least both Cisco and Juniper can do this.=20 But what draft/rfc/doc/... are they using? In IPv6 we have this nice thing called extension headers. If the RFC2385 scheme would be implemented on IPv6 I would expect it to be a Destination Option. In IPv4 it looks like: no-md5: [ipv4 + tcp + data] md5'ed: [ipv4 + tcp + md5hash + data] Thus the 16 byte hash is stuck in the data part. If a unsuspecting host gets this packet it expects data in the portion where the hash now is in place. For BGP this is not much of a problem, but it isn't very applicable to other protocols. In IPv6 we have the Destination Option where we could stick the md5hash: no-md5: [ipv6 + tcp + data] md5'ed: [ipv6 + dstop-md5hash + tcp + data] This would even allow one to configure a host to do: - when there has never been a md5hash, don't use it - if we've once seen a md5hash use it. Allowing BGP sessions to be reconfigured on the fly even out of sync of eachother as long as they use the same passwords of course. Is such a scheme documented somewhere, is this in use or should we just play dirty and stick the md5hash in front of the data section and let the host fight it out. Greets, Jeroen --=-7e9VeFhiv2q2IgxoWXwN 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/ iD8DBQBAgAOwKaooUjM+fCMRAktFAKCKDnSKe0yC4pXP8/IVGp60Rzd7igCgtmlK Nm0FE51Me57V9vB6lr0zGa4= =5YDI -----END PGP SIGNATURE----- --=-7e9VeFhiv2q2IgxoWXwN-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 16 15:18: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 PAA29775 for ; Fri, 16 Apr 2004 15:18: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 1BEYjH-00049k-Tn for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 15:10:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GJANFP015967 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 15:10:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYVi-0001qa-1Y for ipv6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 14:56: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 OAA27487 for ; Fri, 16 Apr 2004 14:56: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 1BEYVf-0005IJ-7R for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 14:56:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYUm-0005Dv-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 14:55:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEYTz-0005A4-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 14:54:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYMh-0007iv-P2; Fri, 16 Apr 2004 14: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 1BEY9v-0001ov-S7 for ipv6@optimus.ietf.org; Fri, 16 Apr 2004 14:33:52 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26199 for ; Fri, 16 Apr 2004 14:33:48 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BEY7W-0001A9-OG; Fri, 16 Apr 2004 14:31:22 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , ipv6 mailing list , ipv6 chair , ipv6 chair Subject: Protocol Action: 'Deprecating Site Local Addresses' to Proposed Standard Message-Id: Date: Fri, 16 Apr 2004 14:31:22 -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 IESG has approved the following document: - 'Deprecating Site Local Addresses ' as a Proposed Standard This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary This document describes the issues surrounding the use of IPv6 site- local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented. Working Group Summary The IPv6 working group has done extensive review of this document and this document reflects the consensus of the group. Protocol Quality This document has been reviewed by members of the ipv6@ietf.org mailing list and by the IPv6 WG chairs. This document was reviewed for the IESG by Margaret Wasserman. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 16 15:30:53 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 PAA00556 for ; Fri, 16 Apr 2004 15:30: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 1BEZ19-0002nU-3y for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 15:28:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GJSpi1010752 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 15:28:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYr1-0008BC-MP for ipv6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 15:18: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 PAA29760 for ; Fri, 16 Apr 2004 15:18:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEYr0-00071X-EP for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 15:18:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYq6-0006y1-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 15:17:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEYpo-0006tu-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 15:17:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYiz-0003za-W5; Fri, 16 Apr 2004 15: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 1BEYUn-0001bj-Dc for ipv6@optimus.ietf.org; Fri, 16 Apr 2004 14:55: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 OAA27444 for ; Fri, 16 Apr 2004 14:55:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEYUk-0005DX-C4 for ipv6@ietf.org; Fri, 16 Apr 2004 14:55:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYTr-00059k-00 for ipv6@ietf.org; Fri, 16 Apr 2004 14:54:27 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEYTF-00055g-00 for ipv6@ietf.org; Fri, 16 Apr 2004 14:53:49 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3GIrh1C034304; Fri, 16 Apr 2004 20:53:43 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1082131376.18432.56.camel@segesta.zurich.ibm.com> References: <1082131376.18432.56.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6071EB93-8FD7-11D8-AA90-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: RFC 2385 on IPv6 Date: Fri, 16 Apr 2004 20:53:40 +0200 To: Jeroen Massar 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 On 16-apr-04, at 18:02, Jeroen Massar wrote: > With the current advent of sudden rise of MD5'd BGP requests due to > something not be undisclosed apparently I was looking at what routers > support this for IPv6 and apparently at least both Cisco and Juniper > can do this. > But what draft/rfc/doc/... are they using? RFC2385. But you already knew that... The RFC doesn't mention IPv6, but nothing is specific to IPv4 so there shouldn't be any issues implementing it for IPv6. (Also note that there is nothing stopping anyone from exchanging IPv6 routing information over IPv4 transport.) > In IPv6 we have this nice thing called extension headers. > If the RFC2385 scheme would be implemented on IPv6 I would > expect it to be a Destination Option. RFC2385 specifies a TCP option. I don't think it makes much sense to define a new option, as RFC2385 is already implemented and if something better is desired, why not simply use IPsec? > In IPv4 it looks like: > no-md5: [ipv4 + tcp + data] > md5'ed: [ipv4 + tcp + md5hash + data] > Thus the 16 byte hash is stuck in the data part. > If a unsuspecting host gets this packet it expects > data in the portion where the hash now is in place. First of all, the hash is in the TCP header (I think you're confused by the description of the hash calculation), and second this mechanism must always be manually configured between two hosts so the "unsuspection host" scenario doesn't apply. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 16 19:00: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 TAA17918 for ; Fri, 16 Apr 2004 19:00: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 1BEc6e-0003Fc-N6 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 18:46:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GMkiCl012491 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 18:46:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEc1a-0001ee-Aw for ipv6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 18:41: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 SAA17097 for ; Fri, 16 Apr 2004 18:41: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 1BEc1X-00000V-Ab for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 18:41:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEc0f-0007l6-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 18:40:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEbzo-0007i0-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 18:39:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbsT-0006cv-9a; Fri, 16 Apr 2004 18:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbo6-0004Cd-1z for ipv6@optimus.ietf.org; Fri, 16 Apr 2004 18:27: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 SAA16007 for ; Fri, 16 Apr 2004 18:27: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 1BEbo3-0006lq-1Y for ipv6@ietf.org; Fri, 16 Apr 2004 18:27:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEbn8-0006h5-00 for ipv6@ietf.org; Fri, 16 Apr 2004 18:26:34 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BEbmA-0006dz-00 for ipv6@ietf.org; Fri, 16 Apr 2004 18:25:34 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3GMPYHS018335 for ; Fri, 16 Apr 2004 16:25:34 -0600 (MDT) Received: from fe8 (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 <0HWA00MI1BMLTX@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Fri, 16 Apr 2004 16:25:34 -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 <0HWA00CC1BMKE1@mail.sun.net> for ipv6@ietf.org; Fri, 16 Apr 2004 16:25:33 -0600 (MDT) Date: Fri, 16 Apr 2004 15:25:30 -0700 From: Alain Durand Subject: question on rfc2462bis: stateful mechanisms is a MUST? To: IPv6 Mailing List Cc: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= 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 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 The following language from RFC2462 is still in 2462bis: 5.5 Creation of Global Addresses Global addresses are formed by appending an interface identifier to a prefix of appropriate length. Prefixes are obtained from Prefix Information options contained in Router Advertisements. Creation of global addresses and configuration of other parameters as described in this section SHOULD be locally configurable. However, the processing described below MUST be enabled by default. 5.5.2 Absence of Router Advertisements If a link has no routers, a host MUST attempt to use stateful autoconfiguration to obtain addresses and other configuration information. An implementation MAY provide a way to disable the invocation of stateful autoconfiguration in this case, but the default SHOULD be enabled. ==> Now that we are saying the stateful mechanism is DHCPv6, does this implies that a host implementation that does not support DHCPv6 client is not conformant? What about an implementation that does only support DHCPv6-lite for DNS discovery? If I do not support DHCPv6, can I make the claim that this is my way to "disable the invocation of sateful autoconfiguration" ? Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 16 23:42:42 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 XAA01899 for ; Fri, 16 Apr 2004 23:42: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 1BEggc-0005ds-Rb for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 23:40:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H3eA6V021682 for ipv6-archive@odin.ietf.org; Fri, 16 Apr 2004 23:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEgf6-0005FJ-Jn for ipv6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 23:38: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 XAA01669 for ; Fri, 16 Apr 2004 23:38: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 1BEgf3-0003OV-41 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 23:38:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEgcg-0003DD-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 23:36:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEgbE-00036a-00 for ipv6-web-archive@ietf.org; Fri, 16 Apr 2004 23:34:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEgTx-0001BP-Aa; Fri, 16 Apr 2004 23: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 1BEgPk-0008Hb-8B for ipv6@optimus.ietf.org; Fri, 16 Apr 2004 23:22: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 XAA01021 for ; Fri, 16 Apr 2004 23:22: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 1BEgPh-0002OD-Ru for ipv6@ietf.org; Fri, 16 Apr 2004 23:22:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEgOf-0002KJ-00 for ipv6@ietf.org; Fri, 16 Apr 2004 23:21:38 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BEgNx-0002Cp-00 for ipv6@ietf.org; Fri, 16 Apr 2004 23:20:53 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Apr 2004 23:20:21 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message Subject: RE: RFC 2385 on IPv6 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Apr 2004 23:20:21 -0400 Message-ID: Thread-Topic: RFC 2385 on IPv6 Thread-Index: AcQj50mF7WzIzvkiQN6rHfsgTIC1aAAQhjGw From: "Soliman Hesham" To: "Iljitsch van Beijnum" , "Jeroen Massar" CC: X-OriginalArrivalTime: 17 Apr 2004 03:20:21.0228 (UTC) FILETIME=[EA5B12C0:01C4242A] 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 > > Thus the 16 byte hash is stuck in the data part. > > If a unsuspecting host gets this packet it expects > > data in the portion where the hash now is in place. >=20 > First of all, the hash is in the TCP header (I think you're=20 > confused by=20 > the description of the hash calculation), and second this mechanism=20 > must always be manually configured between two hosts so the=20 > "unsuspection host" scenario doesn't apply. =3D> I suspect that it must be configured all the time to avoid something similar to a bidding down attack where MITM sends unauthenticated packets. So the manual config acts like an SPD does for IPsec. Hesham >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=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 Sat Apr 17 00:52: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 AAA05207 for ; Sat, 17 Apr 2004 00:52: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 1BEhmf-0008T5-Bl for ipv6-archive@odin.ietf.org; Sat, 17 Apr 2004 00:50:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H4oTV8032547 for ipv6-archive@odin.ietf.org; Sat, 17 Apr 2004 00:50:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEhlt-0008AA-7o for ipv6-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 00:49: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 AAA05107 for ; Sat, 17 Apr 2004 00:49: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 1BEhlq-00017d-E1 for ipv6-web-archive@ietf.org; Sat, 17 Apr 2004 00:49:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEhkv-00014Y-00 for ipv6-web-archive@ietf.org; Sat, 17 Apr 2004 00:48:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEhkh-00011O-00 for ipv6-web-archive@ietf.org; Sat, 17 Apr 2004 00:48:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEhcY-0004uh-Ni; Sat, 17 Apr 2004 00:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEhYQ-0003qi-9z for ipv6@optimus.ietf.org; Sat, 17 Apr 2004 00:35: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 AAA04510 for ; Sat, 17 Apr 2004 00:35: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 1BEhYN-0007mq-Ae for ipv6@ietf.org; Sat, 17 Apr 2004 00:35:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEhXN-0007iS-00 for ipv6@ietf.org; Sat, 17 Apr 2004 00:34:41 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BEhX4-0007f1-00 for ipv6@ietf.org; Sat, 17 Apr 2004 00:34:22 -0400 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id i3H4XhS04289; Fri, 16 Apr 2004 21:33:43 -0700 (PDT) From: Bill Manning Message-Id: <200404170433.i3H4XhS04289@boreas.isi.edu> Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt To: H.Soliman@flarion.com (Soliman Hesham) Date: Fri, 16 Apr 2004 21:33:43 -0700 (PDT) Cc: brian@innovationslab.net (Brian Haberman), margaret@thingmagic.com (Margaret Wasserman), ipv6@ietf.org In-Reply-To: from "Soliman Hesham" at Apr 08, 2004 02:00:06 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: bmanning 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 % => At least you and I agree FWIW :) % Perhaps I missed this discussion, but I can't see % why they should be put in the global DNS. Unless % people are trying to prove that these local addresses % don't require a two face DNS. It's a lost cause I think ;) % % Hesham of course, it is impossible to dictate what people can and can not place into the DNS. It is useful to remember that DNS lookups are useful for a number of different things and having all addresses in use being instanced in the DNS is a -VERY- useful operational activity. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Apr 17 05:38: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 FAA29715 for ; Sat, 17 Apr 2004 05:38: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 1BEmFN-0000zb-Hx for ipv6-archive@odin.ietf.org; Sat, 17 Apr 2004 05:36:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H9aPoE003808 for ipv6-archive@odin.ietf.org; Sat, 17 Apr 2004 05:36:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEmDq-0008Ol-U1 for ipv6-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 05:34: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 FAA29526 for ; Sat, 17 Apr 2004 05:34: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 1BEmDn-0001tV-G2 for ipv6-web-archive@ietf.org; Sat, 17 Apr 2004 05:34:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEmCs-0001ny-00 for ipv6-web-archive@ietf.org; Sat, 17 Apr 2004 05:33:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEmCP-0001iS-00 for ipv6-web-archive@ietf.org; Sat, 17 Apr 2004 05:33:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEm2Q-0005QZ-Rs; Sat, 17 Apr 2004 05: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 1BElyO-0004Xk-3C for ipv6@optimus.ietf.org; Sat, 17 Apr 2004 05:18: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 FAA28954 for ; Sat, 17 Apr 2004 05:18: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 1BElyK-0000H6-LC for ipv6@ietf.org; Sat, 17 Apr 2004 05:18:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BElxK-0000CL-00 for ipv6@ietf.org; Sat, 17 Apr 2004 05:17:47 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BElx1-00007d-00 for ipv6@ietf.org; Sat, 17 Apr 2004 05:17:28 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 552AE15210; Sat, 17 Apr 2004 18:17:27 +0900 (JST) Date: Sat, 17 Apr 2004 18:17:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Alain Durand Cc: IPv6 Mailing List Subject: Re: question on rfc2462bis: stateful mechanisms is a MUST? 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 Fri, 16 Apr 2004 15:25:30 -0700, >>>>> Alain Durand said: > The following language from RFC2462 is still in 2462bis: > 5.5 Creation of Global Addresses > Global addresses are formed by appending an interface identifier to a > prefix of appropriate length. Prefixes are obtained from Prefix > Information options contained in Router Advertisements. Creation of > global addresses and configuration of other parameters as described > in this section SHOULD be locally configurable. However, the > processing described below MUST be enabled by default. > 5.5.2 Absence of Router Advertisements > If a link has no routers, a host MUST attempt to use stateful > autoconfiguration to obtain addresses and other configuration > information. An implementation MAY provide a way to disable the > invocation of stateful autoconfiguration in this case, but the > default SHOULD be enabled. > ==> Now that we are saying the stateful mechanism is DHCPv6, does this > implies > that a host implementation that does not support DHCPv6 client > is not conformant? > What about an implementation that does only support DHCPv6-lite > for DNS discovery? > If I do not support DHCPv6, can I make the claim that this is > my way to "disable the > invocation of sateful autoconfiguration" ? Before continuing the discussion, please read the following message I sent last week. https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg02227.html I've not seen any responses to this message...I'm not sure if this means an agreement, but if so, the proposed change will affect your above question. 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 Apr 18 00:33: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 AAA16469 for ; Sun, 18 Apr 2004 00:33: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 1BF3mr-0003gS-HX for ipv6-archive@odin.ietf.org; Sun, 18 Apr 2004 00:20:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3I4K9Ha014152 for ipv6-archive@odin.ietf.org; Sun, 18 Apr 2004 00:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF3mJ-0003Op-HD for ipv6-web-archive@optimus.ietf.org; Sun, 18 Apr 2004 00:19: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 AAA14973 for ; Sun, 18 Apr 2004 00:19: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 1BF3mH-00051S-3d for ipv6-web-archive@ietf.org; Sun, 18 Apr 2004 00:19:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF3lI-0004sM-00 for ipv6-web-archive@ietf.org; Sun, 18 Apr 2004 00:18:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BF3kv-0004jn-00 for ipv6-web-archive@ietf.org; Sun, 18 Apr 2004 00:18:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF3b8-0008NV-N0; Sun, 18 Apr 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 1BF3Wp-0006qk-8y for ipv6@optimus.ietf.org; Sun, 18 Apr 2004 00:03: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 AAA14449 for ; Sun, 18 Apr 2004 00:03: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 1BF3Wm-0002Rv-UK for ipv6@ietf.org; Sun, 18 Apr 2004 00:03:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF3Vu-0002Bq-00 for ipv6@ietf.org; Sun, 18 Apr 2004 00:02:39 -0400 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1BF3U7-0001pu-00 for ipv6@ietf.org; Sun, 18 Apr 2004 00:00:47 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id D37C632D for ; Sun, 18 Apr 2004 00:00:17 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 18 Apr 2004 00:00:17 -0400 Message-Id: <20040418040017.D37C632D@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 --------+------+--------+----------+------------------------ 17.11% | 13 | 16.86% | 63445 | jinmei@isl.rdc.toshiba.co.jp 11.84% | 9 | 13.50% | 50781 | h.soliman@flarion.com 10.53% | 8 | 9.11% | 34277 | alain.durand@sun.com 9.21% | 7 | 8.56% | 32192 | iljitsch@muada.com 6.58% | 5 | 7.00% | 26334 | rdroms@cisco.com 5.26% | 4 | 4.02% | 15122 | subramoniap@ctd.hcltech.com 3.95% | 3 | 4.71% | 17722 | john.loughney@nokia.com 3.95% | 3 | 3.56% | 13410 | kurtis@kurtis.pp.se 2.63% | 2 | 4.41% | 16595 | alh-ietf@tndh.net 2.63% | 2 | 2.29% | 8602 | tim@mentat.com 2.63% | 2 | 2.20% | 8294 | brc@zurich.ibm.com 2.63% | 2 | 2.00% | 7514 | bob.hinden@nokia.com 1.32% | 1 | 2.28% | 8592 | ipng-incoming@danlan.com 1.32% | 1 | 2.06% | 7768 | pekkas@netcore.fi 1.32% | 1 | 1.76% | 6624 | natpp00@kornet.net 1.32% | 1 | 1.59% | 5973 | mccann@zk3.dec.com 1.32% | 1 | 1.56% | 5881 | vijayak@india.hp.com 1.32% | 1 | 1.40% | 5269 | jeroen@unfix.org 1.32% | 1 | 1.32% | 4981 | kruse@ohio.edu 1.32% | 1 | 1.30% | 4891 | volz@cisco.com 1.32% | 1 | 1.28% | 4829 | jayabharathi@samsung.com 1.32% | 1 | 1.25% | 4694 | huitema@windows.microsoft.com 1.32% | 1 | 1.19% | 4486 | mjork@avici.com 1.32% | 1 | 1.12% | 4216 | sra+ipng@hactrn.net 1.32% | 1 | 1.00% | 3771 | bmanning@isi.edu 1.32% | 1 | 0.98% | 3678 | ftemplin@iprg.nokia.com 1.32% | 1 | 0.91% | 3425 | iesg-secretary@ietf.org 1.32% | 1 | 0.76% | 2855 | boodhooa@mx.uom.ac.mu --------+------+--------+----------+------------------------ 100.00% | 76 |100.00% | 376221 | 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 Apr 18 00:42: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 AAA17048 for ; Sun, 18 Apr 2004 00:42: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 1BF43r-0008LE-3G for ipv6-archive@odin.ietf.org; Sun, 18 Apr 2004 00:37:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3I4bhoq032048 for ipv6-archive@odin.ietf.org; Sun, 18 Apr 2004 00:37:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF3zF-0006Xn-8n for ipv6-web-archive@optimus.ietf.org; Sun, 18 Apr 2004 00:32: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 AAA16409 for ; Sun, 18 Apr 2004 00:32: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 1BF3zC-0007WF-Rm for ipv6-web-archive@ietf.org; Sun, 18 Apr 2004 00:32:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF3y1-0007FE-00 for ipv6-web-archive@ietf.org; Sun, 18 Apr 2004 00:31:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BF3vz-0006ku-00 for ipv6-web-archive@ietf.org; Sun, 18 Apr 2004 00:29:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF3mn-0003fe-QS; Sun, 18 Apr 2004 00: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 1BF3gW-000173-0I for ipv6@optimus.ietf.org; Sun, 18 Apr 2004 00:13: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 AAA14827 for ; Sun, 18 Apr 2004 00:13: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 1BF3gT-00044W-IQ for ipv6@ietf.org; Sun, 18 Apr 2004 00:13:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF3fd-0003vJ-00 for ipv6@ietf.org; Sun, 18 Apr 2004 00:12:42 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1BF3eu-0003lZ-00 for ipv6@ietf.org; Sun, 18 Apr 2004 00:11:56 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 66573531D; Sun, 18 Apr 2004 00:11:57 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 18 Apr 2004 00:11:57 -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: question on rfc2462bis: stateful mechanisms is a MUST? Date: Sun, 18 Apr 2004 00:11:53 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612C359@tayexc13.americas.cpqcorp.net> Thread-Topic: question on rfc2462bis: stateful mechanisms is a MUST? Thread-Index: AcQkXmjbWxfO6ONBSHS/JuYhs+cbtwAjmjYg From: "Bound, Jim" To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= , "Alain Durand" Cc: "IPv6 Mailing List" X-OriginalArrivalTime: 18 Apr 2004 04:11:57.0176 (UTC) FILETIME=[4A18FF80:01C424FB] 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TXkgdmlldyBpcyBhcyBmb2xsb3dzIGFuZCB3YXMgZ29pbmcgdG8gd2FpdCB0aWxsIGxhc3QgY2Fs bCBidXQgd2lsbCBnaXZlIGl0IHRvIHlvdSBub3cuICBUaGUgImVudGlyZSIgNS41LjIgc2VjdGlv biBpcyBiZWxvdyBvZiAyNDYyLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo1LjUuMi4gIEFic2VuY2Ugb2YgUm91dGVyIEFk dmVydGlzZW1lbnRzDQoNCiAgIElmIGEgbGluayBoYXMgbm8gcm91dGVycywgYSBob3N0IE1VU1Qg YXR0ZW1wdCB0byB1c2Ugc3RhdGVmdWwNCiAgIGF1dG9jb25maWd1cmF0aW9uIHRvIG9idGFpbiBh ZGRyZXNzZXMgYW5kIG90aGVyIGNvbmZpZ3VyYXRpb24NCiAgIGluZm9ybWF0aW9uLiBBbiBpbXBs ZW1lbnRhdGlvbiBNQVkgcHJvdmlkZSBhIHdheSB0byBkaXNhYmxlIHRoZQ0KICAgaW52b2NhdGlv biBvZiBzdGF0ZWZ1bCBhdXRvY29uZmlndXJhdGlvbiBpbiB0aGlzIGNhc2UsIGJ1dCB0aGUNCiAg IGRlZmF1bHQgU0hPVUxEIGJlIGVuYWJsZWQuICBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZg0KICAg YXV0b2NvbmZpZ3VyYXRpb24sIGEgbGluayBoYXMgbm8gcm91dGVycyBpZiBubyBSb3V0ZXIgQWR2 ZXJ0aXNlbWVudHMNCiAgIGFyZSByZWNlaXZlZCBhZnRlciBoYXZpbmcgc2VudCBhIHNtYWxsIG51 bWJlciBvZiBSb3V0ZXIgU29saWNpdGF0aW9ucw0KICAgYXMgZGVzY3JpYmVkIGluIFtESVNDT1ZF UlldLiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQpUaGlzIHNlY3Rpb24gaW4gMjQ2MiBzaG91bGQgYmUgZGVsZXRlZC4g IEl0IGlzIG5vdCBuZWNlc3NhcnkuICAyNDYyIG9ubHkgYXBwbGllcyBvciBzaG91bGQgb25seSBh cHBseSBpZiB0aGVyZSBhcmUgcm91dGVycyBvbiB0aGUgbmV0d29yay4NCg0KQnV0IGlmIHdlIHdh bnQgdG8ga2VlcCB0aGUgc2VjdGlvbiBNVVNUIHNob3VsZCBiZWNvbWUgYSBNQVkuICBCdXQgSSBh ZHZpc2Ugc3Ryb25nbHkgYWdhaW5zdCB0aGlzIGFuZCBqdXN0IHJlbW92ZSB0aGUgc2VjdGlvbi4g IEl0IGlzIHN1cGVyZmx1b3VzIHdvcmRpbmcgaW4gdGhlIHNwZWNpZmljYXRpb24sIGluIGhpbmQg c2l0ZSwgYXMgSSBzdXBwb3J0ZWQgaXQgZHVyaW5nIDI0NjIgZGVsaWJlcmF0aW9ucyBhcyBvdGhl cnMuICBUaHVzIHdlIGxlYXJuIDotLSkNCg0KV2l0aG91dCByb3V0ZXJzIG9uIHRoZSBsaW5rIDI0 NjIgYmVjb21lcyBhIG1vb3QgcG9pbnQgYW5kIG5vdCByZWxldmFudCBleGNlcHQgZm9yIHNvbWUg dmVyeSBtaW5vciBwYXJ0cy4gIFdlIG1pZ2h0IGV2ZW4gd2FudCB0byBzdGF0ZSBpbiB0aGUgaW50 cm9kdWN0aW9uIHRvIDI0NjIgaXQgb25seSBhcHBsaWVzIHdoZW4gcm91dGVycyBhcmUgaW4gZmFj dCBvbiB0aGUgbGluay4NCg0KTm93IHRoZXJlIGlzIHRoZSBleGNlcHRpb24uIEkgaGF2ZSB0d28g dGhhdCBhIG1pc3Npb24gY3JpdGljYWwgY3VzdG9tZXIgaXMgdXNpbmcgYXMgYW5vdGhlciBtZWFu cyB0byB1c2UgSVB2NiBvbiBsaW5rcy4gDQoNCkV4YW1wbGUgMToNCg0KTGluayBjb21lcyBsaXZl IGFuZCBubyByb3V0ZXIgYXBwZWFycyBidXQgdGhpcyBoYXMgYmVlbiBhbnRpY2lwYXRlZCBhbmQg b25lIG9mIHRoZSBub2RlcyBvbiB0aGUgbGluayBoYXMgYSBkaXJlY3QgaW50ZXJmYWNlIHRvIGFu b3RoZXIgbmV0d29yaywgd2hpY2ggaXQgY2Fubm90IGFkdmVydGlzZSBhcyByb3V0ZXIgZm9yIHBv bGljeSByZWFzb25zIChlLmcuIFNhdGNvbSwgVDEpLiAgVGhlIG9ubGluayBub2RlcyBrbm93IHdo ZW4gdGhleSBkb24ndCBoZWFyIGEgcm91dGVyIHRoZXkgYWxsIHNlbmQgcGFja2V0cyBwZWVyLTIt cGVlciB0byB0aGUgbm9kZSB0aGF0IGhhcyB0aGUgbGluaywgYW5kIHRoaXMgd291bGQgYmUgcGFy dCBvZiBhIHByb3ByaWV0YXJ5IGNvbmZpZyBzY3JpcHQgb24gZWFjaCBub2RlIHdoZW4gbm8gcm91 dGVycyBhcmUgc2VlbiBvciBhcyBhIGZvcm0gb2YgaW50ZXJuYWwga25vd24gcG9saWN5IGJhc2Vk IGNvbW11bmljYXRpb25zLiAgVGhlIG5vZGVzIHN0aWxsIG5lZWQgbGluayBhbmQgY29uZmlndXJh dGlvbiBpbmZvcm1hdGlvbiBhbmQgd2FudCB0byBnZXQgaXQgZnJvbSBESENQdjYgU2VydmVyIGFu ZCB0aHVzIHdpbGwgc2VuZCBESENQdjYgc29saWNpdCBtZXNzYWdlcy4NCg0KRXhhbXBsZSAyOg0K DQpMaW5rIGNvbWVzIGxpdmUgYW5kIG5vIHJvdXRlcnMgYXBwZWFyLiAgQW4gb3BlcmF0aW9uYWwg ZmFzdCBwYXRoIHRvIGJlIHByZXBhcmVkIGlzIHRvIHNlbmQgREhDUHY2IHNvbGljaXQgdG8gZ2V0 IGFsbCBjb25maWcgcmVxdWlyZWQgc28gd2hlbiB0aGUgcm91dGVyIGFwcGVhcnMgdGhlIG5vZGVz IGFyZSBjb25maWd1cmVkIHdpdGggaW5mb3JtYXRpb24gdG8gYmVnaW4gY29tbXVuaWNhdGlvbnMg dXBvbiByb3V0ZXIgY29tbXVuaWNhdGlvbnMgb24gdGhlIGxpbmsuICBJbiB0aGlzIGV4YW1wbGUg dGhlIGlkZWEgaXMgYW4gb3B0aW1pemVkIHByZXBhcmF0aW9uIGZvciB3aGVuIHRoZSByb3V0ZXIg YXBwZWFycy4NCg0KDQpSZWdhcmRzLA0KL2ppbQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IGlwdjYtYWRtaW5AaWV0Zi5vcmcgW21haWx0bzppcHY2LWFkbWluQGlldGYu b3JnXSBPbiANCj4gQmVoYWxmIE9mIEpJTk1FSSBUYXR1eWEgLyA/Pz8/DQo+IFNlbnQ6IFNhdHVy ZGF5LCBBcHJpbCAxNywgMjAwNCA1OjE4IEFNDQo+IFRvOiBBbGFpbiBEdXJhbmQNCj4gQ2M6IElQ djYgTWFpbGluZyBMaXN0DQo+IFN1YmplY3Q6IFJlOiBxdWVzdGlvbiBvbiByZmMyNDYyYmlzOiBz dGF0ZWZ1bCBtZWNoYW5pc21zIGlzIGEgTVVTVD8NCj4gDQo+ID4+Pj4+IE9uIEZyaSwgMTYgQXBy IDIwMDQgMTU6MjU6MzAgLTA3MDAsIEFsYWluIER1cmFuZCANCj4gPj4+Pj4gPEFsYWluLkR1cmFu ZEBTdW4uQ09NPiBzYWlkOg0KPiANCj4gPiBUaGUgZm9sbG93aW5nIGxhbmd1YWdlIGZyb20gUkZD MjQ2MiBpcyBzdGlsbCBpbiAyNDYyYmlzOg0KPiA+IDUuNSBDcmVhdGlvbiBvZiBHbG9iYWwgQWRk cmVzc2VzDQo+IA0KPiA+ICAgICBHbG9iYWwgYWRkcmVzc2VzIGFyZSBmb3JtZWQgYnkgYXBwZW5k aW5nIGFuIGludGVyZmFjZSANCj4gaWRlbnRpZmllciB0byBhDQo+ID4gICAgIHByZWZpeCBvZiBh cHByb3ByaWF0ZSBsZW5ndGguIFByZWZpeGVzIGFyZSBvYnRhaW5lZCBmcm9tIFByZWZpeA0KPiA+ ICAgICBJbmZvcm1hdGlvbiBvcHRpb25zIGNvbnRhaW5lZCBpbiBSb3V0ZXIgQWR2ZXJ0aXNlbWVu dHMuIA0KPiBDcmVhdGlvbiBvZg0KPiA+ICAgICBnbG9iYWwgYWRkcmVzc2VzIGFuZCBjb25maWd1 cmF0aW9uIG9mIG90aGVyIHBhcmFtZXRlcnMgDQo+IGFzIGRlc2NyaWJlZA0KPiA+ICAgICBpbiB0 aGlzIHNlY3Rpb24gU0hPVUxEIGJlIGxvY2FsbHkgY29uZmlndXJhYmxlLiBIb3dldmVyLCB0aGUN Cj4gPiAgICAgcHJvY2Vzc2luZyBkZXNjcmliZWQgYmVsb3cgTVVTVCBiZSBlbmFibGVkIGJ5IGRl ZmF1bHQuDQo+IA0KPiANCj4gPiA1LjUuMiBBYnNlbmNlIG9mIFJvdXRlciBBZHZlcnRpc2VtZW50 cw0KPiANCj4gPiAgICAgSWYgYSBsaW5rIGhhcyBubyByb3V0ZXJzLCBhIGhvc3QgTVVTVCBhdHRl bXB0IHRvIHVzZSBzdGF0ZWZ1bA0KPiA+ICAgICBhdXRvY29uZmlndXJhdGlvbiB0byBvYnRhaW4g YWRkcmVzc2VzIGFuZCBvdGhlciBjb25maWd1cmF0aW9uDQo+ID4gICAgIGluZm9ybWF0aW9uLiBB biBpbXBsZW1lbnRhdGlvbiBNQVkgcHJvdmlkZSBhIHdheSB0byBkaXNhYmxlIHRoZQ0KPiA+ICAg ICBpbnZvY2F0aW9uIG9mIHN0YXRlZnVsIGF1dG9jb25maWd1cmF0aW9uIGluIHRoaXMgY2FzZSwg YnV0IHRoZQ0KPiA+ICAgICBkZWZhdWx0IFNIT1VMRCBiZSBlbmFibGVkLg0KPiANCj4gPiA9PT4g Tm93IHRoYXQgd2UgYXJlIHNheWluZyB0aGUgc3RhdGVmdWwgbWVjaGFuaXNtIGlzIA0KPiBESENQ djYsIGRvZXMgdGhpcyANCj4gPiBpbXBsaWVzDQo+ID4gICAgICAgICAgdGhhdCBhIGhvc3QgaW1w bGVtZW50YXRpb24gdGhhdCBkb2VzIG5vdCBzdXBwb3J0IERIQ1B2NiANCj4gPiBjbGllbnQgaXMg bm90IGNvbmZvcm1hbnQ/DQo+ID4gICAgICAgICAgV2hhdCBhYm91dCBhbiBpbXBsZW1lbnRhdGlv biB0aGF0IGRvZXMgb25seSBzdXBwb3J0IA0KPiA+IERIQ1B2Ni1saXRlIGZvciBETlMgZGlzY292 ZXJ5Pw0KPiA+ICAgICAgICAgIElmIEkgZG8gbm90IHN1cHBvcnQgREhDUHY2LCBjYW4gSSBtYWtl IHRoZSBjbGFpbSANCj4gdGhhdCB0aGlzIGlzIA0KPiA+IG15IHdheSB0byAiZGlzYWJsZSB0aGUN Cj4gPiAgICAgICAgICBpbnZvY2F0aW9uIG9mIHNhdGVmdWwgYXV0b2NvbmZpZ3VyYXRpb24iID8N Cj4gDQo+IEJlZm9yZSBjb250aW51aW5nIHRoZSBkaXNjdXNzaW9uLCBwbGVhc2UgcmVhZCB0aGUg Zm9sbG93aW5nIA0KPiBtZXNzYWdlIEkgc2VudCBsYXN0IHdlZWsuDQo+IA0KPiBodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dvcmtpbmctZ3JvdXBzL2lwdjYvY3VycmVudA0KPiAv bXNnMDIyMjcuaHRtbA0KPiANCj4gSSd2ZSBub3Qgc2VlbiBhbnkgcmVzcG9uc2VzIHRvIHRoaXMg bWVzc2FnZS4uLkknbSBub3Qgc3VyZSBpZiANCj4gdGhpcyBtZWFucyBhbiBhZ3JlZW1lbnQsIGJ1 dCBpZiBzbywgdGhlIHByb3Bvc2VkIGNoYW5nZSB3aWxsIA0KPiBhZmZlY3QgeW91ciBhYm92ZSBx dWVzdGlvbi4NCj4gDQo+IAkJCQkJSklOTUVJLCBUYXR1eWENCj4gCQkJCQlDb21tdW5pY2F0aW9u IFBsYXRmb3JtIExhYi4NCj4gCQkJCQlDb3Jwb3JhdGUgUiZEIENlbnRlciwgDQo+IFRvc2hpYmEg Q29ycC4NCj4gCQkJCQlqaW5tZWlAaXNsLnJkYy50b3NoaWJhLmNvLmpwDQo+IA0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRm Lm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Apr 19 14:16: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 OAA29105 for ; Mon, 19 Apr 2004 14:16: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 1BFdGL-0005Ps-4L for ipv6-archive@odin.ietf.org; Mon, 19 Apr 2004 14:12:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JICvbv020816 for ipv6-archive@odin.ietf.org; Mon, 19 Apr 2004 14:12:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFdDk-0004vF-9d for ipv6-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 14:10: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 OAA28691 for ; Mon, 19 Apr 2004 14:10: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 1BFdDh-0003k0-TH for ipv6-web-archive@ietf.org; Mon, 19 Apr 2004 14:10:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFdCp-0003VC-00 for ipv6-web-archive@ietf.org; Mon, 19 Apr 2004 14:09:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFdC3-0003GD-00 for ipv6-web-archive@ietf.org; Mon, 19 Apr 2004 14: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 1BFd1u-00028t-8K; Mon, 19 Apr 2004 13:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFcuJ-00018T-Ux for ipv6@optimus.ietf.org; Mon, 19 Apr 2004 13:50: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 NAA27149 for ; Mon, 19 Apr 2004 13:50: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 1BFcuH-0006fD-K3 for ipv6@ietf.org; Mon, 19 Apr 2004 13:50:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFctL-0006Ra-00 for ipv6@ietf.org; Mon, 19 Apr 2004 13:49:11 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BFcsM-0006DC-00 for ipv6@ietf.org; Mon, 19 Apr 2004 13:48:10 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3JHmAO3001590 for ; Mon, 19 Apr 2004 11:48:10 -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 <0HWF00JDWIS9LY@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 19 Apr 2004 11:48:10 -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 <0HWF0060YIS8CC@mail.sun.net> for ipv6@ietf.org; Mon, 19 Apr 2004 11:48:09 -0600 (MDT) Date: Mon, 19 Apr 2004 10:48:07 -0700 From: Alain Durand Subject: Re: question on rfc2462bis: stateful mechanisms is a MUST? In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B0612C359@tayexc13.americas.cpqcorp.net> To: "Bound, Jim" Cc: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , 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: <9C422444DE99BC46B3AD3C6EAFC9711B0612C359@tayexc13.americas.cpqcorp.net> 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 agree with Jim, section 5.5.2 should be deleted. Let implementations decide what to do if there is no router. If you decide to keep 5.5.2, you will need to add some text to analyze the performance impact of doing DHCPv6 when there is no IPv6 at all. - Alain. On Apr 17, 2004, at 9:11 PM, Bound, Jim wrote: > My view is as follows and was going to wait till last call but will > give it > to you now. The "entire" 5.5.2 section is below of 2462. > > ------------------------------------------------------------- > 5.5.2. Absence of Router Advertisements > > If a link has no routers, a host MUST attempt to use stateful > autoconfiguration to obtain addresses and other configuration > information. An implementation MAY provide a way to disable the > invocation of stateful autoconfiguration in this case, but the > default SHOULD be enabled. 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 [DISCOVERY]. > --------------------------------------------------------------- > > This section in 2462 should be deleted. It is not necessary. 2462 > only > applies or should only apply if there are routers on the network. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Apr 19 15:54:25 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 PAA05800 for ; Mon, 19 Apr 2004 15:54: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 1BFeo7-0007pI-IM for ipv6-archive@odin.ietf.org; Mon, 19 Apr 2004 15:51:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JJptqK030080 for ipv6-archive@odin.ietf.org; Mon, 19 Apr 2004 15:51:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFemt-0007O7-AF for ipv6-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 15:50: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 PAA05424 for ; Mon, 19 Apr 2004 15:50: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 1BFemr-0004ft-KZ for ipv6-web-archive@ietf.org; Mon, 19 Apr 2004 15:50:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFem1-0004Np-00 for ipv6-web-archive@ietf.org; Mon, 19 Apr 2004 15:49:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFel9-00047D-00 for ipv6-web-archive@ietf.org; Mon, 19 Apr 2004 15:48:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeYn-0004ji-28; Mon, 19 Apr 2004 15: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 1BFeUA-0003vg-6h for ipv6@optimus.ietf.org; Mon, 19 Apr 2004 15:31: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 PAA04285 for ; Mon, 19 Apr 2004 15:31: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 1BFeU8-00002k-SO for ipv6@ietf.org; Mon, 19 Apr 2004 15:31:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFeTA-0007aN-00 for ipv6@ietf.org; Mon, 19 Apr 2004 15:30:17 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1BFeS9-00076J-00 for ipv6@ietf.org; Mon, 19 Apr 2004 15:29:13 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3JJSgnr573142 for ; Mon, 19 Apr 2004 15:28:42 -0400 Received: from d03nm118.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3JJSfZc142144 for ; Mon, 19 Apr 2004 13:28:41 -0600 To: ipv6@ietf.org MIME-Version: 1.0 Subject: Question about Routing Headers X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 From: Lori Napoli Message-ID: Date: Mon, 19 Apr 2004 15:28:39 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 04/19/2004 13:28:40, Serialize complete at 04/19/2004 13:28:40 Content-Type: multipart/alternative; boundary="=_alternative 006AF6C185256E7B_=" 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.4 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 006AF6C185256E7B_= Content-Type: text/plain; charset="US-ASCII" I have a question about Routing Headers (type 0), more specifically what happens when we receive an ICMPv6 msg where the offending packet contained a routing header. From RFC 3542, a routing header can contain 127 IPv6 next hop addresses. Therefore, if a packet specified the maximum number of entries in a routing header, the routing header alone would exceed 1280 bytes. Now, if an intermediate node needed to drop this packet and generate an ICMPv6 msg, the ICMPv6 msg can only contain as much of the offending packet as will fit within minimum MTU (1280 bytes). Therefore it is possible for the offending packet within the ICMPv6 msg to not contain the entire routing header. This ICMPv6 msg will be sent to the original source of the packet, but the source address of the ICMPv6 msg will not be the original destination address of the packet since the destination address in the IPv6 header changes when there is a routing header. So, how does the originating node correlate this ICMPv6 packet with the correct socket? Since we can't rely on the entire routing header being present in the offending packet, we can't even rebuild what the original destination would have been. My second question is that for IPv6, the Type 0 Routing header can contain 127 addresses. This routing header is considered non-fragmentable. If your interface is Ethernet with a standard 1492 MTU, this packet cannot be sent on that interface since the routing header alone would exceed 1492. It seems inconsistent to me to allow such a large non-fragmentable header. Lori e-mail: lanapoli@us.ibm.com --=_alternative 006AF6C185256E7B_= Content-Type: text/html; charset="US-ASCII"
I have a question about Routing Headers (type 0), more specifically what happens when we receive an ICMPv6 msg where the offending packet contained a routing header.  From RFC 3542,  a routing header can contain 127 IPv6 next hop addresses.  Therefore, if a packet specified the maximum number of entries in a routing header, the routing header alone would exceed 1280 bytes.   Now, if an intermediate node needed to drop this packet and generate an ICMPv6 msg,  the ICMPv6 msg can only contain as much of the offending packet as will fit within minimum MTU (1280 bytes).  Therefore it is possible for the offending packet within the ICMPv6 msg to not contain the entire routing header.  This ICMPv6 msg will be sent to the original source of the packet, but the source address of the ICMPv6 msg will not be the original destination address of the packet since the destination address in the IPv6 header changes when there is a routing header.  So, how does the originating node correlate this ICMPv6 packet with the correct socket?  Since we can't rely on the entire routing header being present in the offending packet, we can't even rebuild what the original destination would have been.

My second question is that for IPv6, the Type 0 Routing header can contain 127 addresses.  This routing header is considered non-fragmentable.  If your interface is Ethernet with a standard 1492 MTU, this packet cannot be sent on that interface since the routing header alone would exceed 1492.  It seems inconsistent to me to allow such a large non-fragmentable header.  


Lori
e-mail: lanapoli@us.ibm.com --=_alternative 006AF6C185256E7B_=-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 20 04:35: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 EAA01647 for ; Tue, 20 Apr 2004 04:35: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 1BFqfi-0000Mf-V9 for ipv6-archive@odin.ietf.org; Tue, 20 Apr 2004 04:32:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K8W2JQ001397 for ipv6-archive@odin.ietf.org; Tue, 20 Apr 2004 04:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFqX0-0006We-1e for ipv6-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 04:23: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 EAA01173 for ; Tue, 20 Apr 2004 04:23: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 1BFqWx-0001cE-6I for ipv6-web-archive@ietf.org; Tue, 20 Apr 2004 04:22:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFqVx-0001N1-00 for ipv6-web-archive@ietf.org; Tue, 20 Apr 2004 04:21:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFqVb-00017I-00 for ipv6-web-archive@ietf.org; Tue, 20 Apr 2004 04:21:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFqMM-0004Et-Bz; Tue, 20 Apr 2004 04:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFqHM-0002hm-PD for ipv6@optimus.ietf.org; Tue, 20 Apr 2004 04:06: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 EAA00156 for ; Tue, 20 Apr 2004 04:06:50 -0400 (EDT) From: sharma.tarun@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFqHK-00058a-0x for ipv6@ietf.org; Tue, 20 Apr 2004 04:06:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFqGO-0004tQ-00 for ipv6@ietf.org; Tue, 20 Apr 2004 04:05:53 -0400 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1BFqFg-0004O6-00 for ipv6@ietf.org; Tue, 20 Apr 2004 04:05:08 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i3K84Znp026261 for ; Tue, 20 Apr 2004 13:34:35 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Tue, 20 Apr 2004 13:34:34 +0530 Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 13:34:33 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C426AE.1D3F7194" Subject: One Question Date: Tue, 20 Apr 2004 13:34:33 +0530 Message-ID: Thread-Topic: One Question Thread-Index: AcQmrh0p2YBzE7CFRn2j6zWtKxIY/A== To: X-OriginalArrivalTime: 20 Apr 2004 08:04:33.0135 (UTC) FILETIME=[1D52D7F0:01C426AE] 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=HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C426AE.1D3F7194 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, First of all sorry for asking non relevent question but somehow it = belongs to IP. So hopefully I will get a reply for this question. Actually long back when I just started the work on IP then i came across = one problem. As for my company we have IP addresses in our LAN and we have = one entry for default IP address which is used if our destination IP address = doesnt match with anyone in our ARP cache. Now router decides whether this IP address = belongs to outer world or not based upon its net address and routes it = accordingly. Now the question was if the source IP address remains same as my host = address in LAN or it is replaced by router's IP address. If it remains the same = then it gives a logical picture and packet can travel from destination to = source(reverse path). But if it is replaced by router's address then how can packets = come to source address. According to my understanding source IP address doesnt = change and it works in a unique fashion. But it this is the case then why we = give only one IP address to corporates. We give it because we dont want to use so = many IP addresses for a corporate and IP addresses are limited. Even this is one of the reason we are going towards IPv6. Please give me some clear picture of this. Thanks and excuse me of non relevent question. But this is the place = where I can get best answer. Regards Tarun Sharma ------_=_NextPart_001_01C426AE.1D3F7194 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable One Question

Hi,
First of all sorry for asking non relevent question but somehow it = belongs to
IP. So hopefully I will get a reply for this question.
Actually long back when I just started the work on IP then i came across = one
problem. As for my company we have IP addresses in our LAN and we have = one entry
for default IP address which is used if our destination IP address = doesnt match
with anyone in our ARP cache. Now router decides whether this IP address = belongs
to outer world or not based upon its net address and routes it = accordingly.
Now the question was if the source IP address remains same as my host = address in
LAN or it is replaced by router's IP address. If it remains the same = then it
gives a logical picture and packet can travel from destination to = source(reverse
path). But if it is replaced by router's address then how can packets = come to
source address. According to my understanding source IP address doesnt = change
and it works in a unique fashion. But it this is the case then why we = give only
one IP address to corporates. We give it because we dont want to use so = many
IP addresses for a corporate and IP addresses are limited.
Even this is one of the reason we are going towards IPv6.

Please give me some clear picture of this.
Thanks and excuse me of non relevent question. But this is the place = where I can
get best answer.

Regards
Tarun Sharma

------_=_NextPart_001_01C426AE.1D3F7194-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 20 04:58:23 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 EAA02940 for ; Tue, 20 Apr 2004 04:58:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFqvQ-0005CN-Dz for ipv6-archive@odin.ietf.org; Tue, 20 Apr 2004 04:48:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K8mGlA019979 for ipv6-archive@odin.ietf.org; Tue, 20 Apr 2004 04:48:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFqtz-0004gw-C7 for ipv6-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 04:46: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 EAA02440 for ; Tue, 20 Apr 2004 04:46: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 1BFqtw-0000Li-Cb for ipv6-web-archive@ietf.org; Tue, 20 Apr 2004 04:46:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFqsx-00004P-00 for ipv6-web-archive@ietf.org; Tue, 20 Apr 2004 04:45:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFqru-0007Ll-00 for ipv6-web-archive@ietf.org; Tue, 20 Apr 2004 04:44:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFqhd-0000vq-OF; Tue, 20 Apr 2004 04:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFq5d-0008HO-2R for ipv6@optimus.ietf.org; Tue, 20 Apr 2004 03:54: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 DAA29635 for ; Tue, 20 Apr 2004 03:54: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 1BFq5a-0001z2-Fw for ipv6@ietf.org; Tue, 20 Apr 2004 03:54:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFq4b-0001ht-00 for ipv6@ietf.org; Tue, 20 Apr 2004 03:53:42 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BFq3f-0001SZ-00 for ipv6@ietf.org; Tue, 20 Apr 2004 03:52:43 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3K7qZQP007226 for ; Tue, 20 Apr 2004 09:52:35 +0200 Received: from alcatel.be ([138.203.84.21]) by bemail04.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042009523440:2338 ; Tue, 20 Apr 2004 09:52:34 +0200 From: "Tarun Kr. Sharma" Message-ID: <4084D6C2.D5C5F774@alcatel.be> Date: Tue, 20 Apr 2004 09:52:34 +0200 From: Tarun_KUMAR/BE/ALCATEL@ALCATEL.cnri.reston.va.us Organization: Alcatel Bell, Antwerp, Belgium X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipv6@ietf.org Subject: One Question References: X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/20/2004 09:52:34, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/20/2004 09:52:35, Serialize complete at 04/20/2004 09:52:35 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes 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 Hi, First of all sorry for asking non relevent question but somehow it belongs to IP. So hopefully I will get a reply for this question. Actually long back when I just started the work on IP then i came across one problem. As for my company we have IP addresses in our LAN and we have one entry for default IP address which is used if our destination IP address doesnt match with anyone in our ARP cache. Now router decides whether this IP address belongs to outer world or not based upon its net address and routes it accordingly. Now the question was if the source IP address remains same as my host address in LAN or it is replaced by router's IP address. If it remains the same then it gives a logical picture and packet can travel from destination to source(reverse path). But if it is replaced by router's address then how can packets come to source address. According to my understanding source IP address doesnt change and it works in a unique fashion. But it this is the case then why we give only one IP address to corporates. We give it because we dont want to use so many IP addresses for a corporate and IP addresses are limited. Even this is one of the reason we are going towards IPv6. Please give me some clear picture of this. Thanks and excuse me of non relevent question. But this is the place where I can get best answer. Regards Tarun Sharma -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 20 07:27:38 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 HAA10088 for ; Tue, 20 Apr 2004 07:27: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 1BFtJM-00031v-C9 for ipv6-archive@odin.ietf.org; Tue, 20 Apr 2004 07:21:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KBL8mw011641 for ipv6-archive@odin.ietf.org; Tue, 20 Apr 2004 07: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 1BFtIC-0002b6-MH for ipv6-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 07:19: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 HAA09688 for ; Tue, 20 Apr 2004 07:19: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 1BFtIC-00026y-1h for ipv6-web-archive@ietf.org; Tue, 20 Apr 2004 07:19:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFtHG-0001qt-00 for ipv6-web-archive@ietf.org; Tue, 20 Apr 2004 07:18:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFtGW-0001bJ-00 for ipv6-web-archive@ietf.org; Tue, 20 Apr 2004 07:18:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFt6i-0000SQ-78; Tue, 20 Apr 2004 07:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFt4t-00086r-OR for ipv6@optimus.ietf.org; Tue, 20 Apr 2004 07: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 HAA08321 for ; Tue, 20 Apr 2004 07:06:09 -0400 (EDT) From: sharma.tarun@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFt4p-0005rf-98 for ipv6@ietf.org; Tue, 20 Apr 2004 07:06:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFt3w-0005Xh-00 for ipv6@ietf.org; Tue, 20 Apr 2004 07:05:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BFt2z-0005GB-02 for ipv6@ietf.org; Tue, 20 Apr 2004 07:04:13 -0400 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BFsoa-0008NI-8h for ipv6@ietf.org; Tue, 20 Apr 2004 06:49:20 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i3KAmcnp028544 for ; Tue, 20 Apr 2004 16:18:38 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Tue, 20 Apr 2004 16:18:38 +0530 Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 16:18:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C426C5.05D2D840" Subject: Re: One Question Date: Tue, 20 Apr 2004 16:18:32 +0530 Message-ID: Thread-Topic: Re: One Question Thread-Index: AcQmxQXJdR2DH1pdSDiD6w9W6v5BTA== To: X-OriginalArrivalTime: 20 Apr 2004 10:48:37.0150 (UTC) FILETIME=[08D053E0:01C426C5] 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,HTML_40_50,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C426C5.05D2D840 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is what is written in RFC for NAT(1631). Which is confusing me.=20 For instance, in the example of figure 2, both stubs A and B=20 internally use class A address 10.0.0.0. Stub A's NAT is assigned the = class C address 198.76.29.0, and Stub B's NAT is assigned the class C = address 198.76.28.0. The class C addresses are globally unique no=20 other NAT boxes can use them.=20 \ | /=20 +---------------+=20 |Regional Router|=20 +---------------+=20 WAN | | WAN=20 | |=20 Stub A .............|.... ....|............ Stub B=20 | |=20 {s=3D198.76.29.7,^ | | = v{s=3D198.76.29.7,=20 d=3D198.76.28.4}^ | | v = d=3D198.76.28.4}=20 +-----------------+ +-----------------+=20 |Stub Router w/NAT| |Stub Router w/NAT|=20 +-----------------+ +-----------------+=20 | |=20 | LAN LAN |=20 ------------- -------------=20 | |=20 {s=3D10.33.96.5, ^ | | = v{s=3D198.76.29.7,=20 d=3D198.76.28.4}^ +--+ +--+ v = d=3D10.81.13.22}=20 |--| |--|=20 /____\ /____\=20 10.33.96.5 10.81.13.22=20 Figure 2: Basic NAT Operation=20 When stub A host 10.33.96.5 wishes to send a packet to stub B host=20 10.81.13.22, it uses the globally unique address 198.76.28.4 as=20 destination, and sends the packet to it's primary router. The stub=20 router has a static route for net 198.76.0.0 so the packet is=20 forwarded to the WAN-link. However, NAT translates the source address = 10.33.96.5 of the IP header with the globally unique 198.76.29.7=20 Now I am bit more confused. Suppose I am sitting in A network and I want = to communicate with the host in B network. Now if my IP address is 10.33.96.5, and the other's address is 10.81.13.22. Now = what would be my destination address in my packet. 10.81.13.22 or 198.76.28.4. Now if i use class C address then How will that router know = that for which of its host this packet belongs. There could be N host in that LAN. I dont know the solution to this problem=20 regards=20 -tarun=20 ------_=_NextPart_001_01C426C5.05D2D840 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Re: One Question

This is what is written in RFC for NAT(1631). Which is = confusing me.

   For instance, in the example of figure 2, both stubs A and = B
   internally use class A address 10.0.0.0. Stub A's NAT is = assigned the
   class C address 198.76.29.0, and Stub B's NAT is assigned = the class C
   address 198.76.28.0. The class C addresses are globally = unique no
   other NAT boxes can use them.

            &= nbsp;           &n= bsp;           &nb= sp;  \ | /
            &= nbsp;           &n= bsp;            = +---------------+
            &= nbsp;           &n= bsp;            = |Regional Router|
            &= nbsp;           &n= bsp;            = +---------------+
            &= nbsp;           &n= bsp;          WAN = |           | WAN
            &= nbsp;           &n= bsp;           &nb= sp;  |           = |
            &= nbsp;      Stub A = .............|....   ....|............ Stub B
            &= nbsp;           &n= bsp;           &nb= sp;  |           = |
            &= nbsp;        {s=3D198.76.29.7,^  = |           |  = v{s=3D198.76.29.7,
            &= nbsp;         = d=3D198.76.28.4}^  = |           |  v = d=3D198.76.28.4}
            &= nbsp;          = +-----------------+       = +-----------------+
            &= nbsp;          |Stub Router = w/NAT|       |Stub Router w/NAT|
            &= nbsp;          = +-----------------+       = +-----------------+
            &= nbsp;           &n= bsp;    = |            =              = |
            &= nbsp;           &n= bsp;    |  = LAN           &nbs= p;   LAN  |
            &= nbsp;          = -------------          =    -------------
            &= nbsp;           &n= bsp;        = |            =      |
            &= nbsp;  {s=3D10.33.96.5, ^  = |            =      |  v{s=3D198.76.29.7,
            &= nbsp;   d=3D198.76.28.4}^ = +--+           &nb= sp; +--+ v d=3D10.81.13.22}
            &= nbsp;           &n= bsp;       = |--|           &nb= sp; |--|
            &= nbsp;           &n= bsp;      = /____\           = /____\
            &= nbsp;           &n= bsp;    10.33.96.5       = 10.81.13.22

            &= nbsp;        Figure 2: Basic NAT = Operation

   When stub A host 10.33.96.5 wishes to send a packet to stub = B host
   10.81.13.22, it uses the globally unique address = 198.76.28.4 as
   destination, and sends the packet to it's primary router. = The stub
   router has a static route for net 198.76.0.0 so the packet = is
   forwarded to the WAN-link. However, NAT translates the = source address
   10.33.96.5 of the IP header with the globally unique = 198.76.29.7

Now I am bit more confused. Suppose I am sitting in A network and I want = to communicate with the host in B network. Now if my
IP address is 10.33.96.5, and the other's address is 10.81.13.22. Now = what would be my destination address in my packet. 10.81.13.22 or
198.76.28.4. Now if i use class C address then How will that router know = that for which of its host this packet belongs. There could be
N host in that LAN. I dont know the solution to this problem

regards
-tarun

------_=_NextPart_001_01C426C5.05D2D840-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 21 20:21:42 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 UAA04041 for ; Wed, 21 Apr 2004 20:21: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 1BGRsy-0001J2-4b for ipv6-archive@odin.ietf.org; Wed, 21 Apr 2004 20:16:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M0GCuV005020 for ipv6-archive@odin.ietf.org; Wed, 21 Apr 2004 20:16:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRjX-0003G9-OT for ipv6-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 20:06: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 UAA02706 for ; Wed, 21 Apr 2004 20:06: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 1BGRjV-0006SW-Mz for ipv6-web-archive@ietf.org; Wed, 21 Apr 2004 20:06:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGRiU-0006FY-00 for ipv6-web-archive@ietf.org; Wed, 21 Apr 2004 20:05:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGRha-00063g-00 for ipv6-web-archive@ietf.org; Wed, 21 Apr 2004 20:04:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGROr-0002o7-PR; Wed, 21 Apr 2004 19:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRKM-00005u-BR for ipv6@optimus.ietf.org; Wed, 21 Apr 2004 19:40: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 TAA01084 for ; Wed, 21 Apr 2004 19:40: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 1BGRKK-0001El-G9 for ipv6@ietf.org; Wed, 21 Apr 2004 19:40:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGRJL-00011z-00 for ipv6@ietf.org; Wed, 21 Apr 2004 19:39:24 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BGRIe-0000i6-00 for ipv6@ietf.org; Wed, 21 Apr 2004 19:38:41 -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 <0HWJ00E0OOBLQI@mailout1.samsung.com> for ipv6@ietf.org; Thu, 22 Apr 2004 08:38:09 +0900 (KST) Received: from ep_mmp1 (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 <0HWJ007H6OB8PG@mailout1.samsung.com> for ipv6@ietf.org; Thu, 22 Apr 2004 08:37:56 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWJ00I53OB89F@mmp1.samsung.com> for ipv6@ietf.org; Thu, 22 Apr 2004 08:37:56 +0900 (KST) Date: Thu, 22 Apr 2004 08:38:22 +0900 From: "S. Daniel Park" Subject: I-D ACTION:draft-daniel-ipv6-over-wifi-00.txt To: ipv6@ietf.org Message-id: <008701c427f9$bbe7d810$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_bJ+zqfxT9mZ1usij2lRB2A)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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.4 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_bJ+zqfxT9mZ1usij2lRB2A) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT fyi. comments/feedbacks are highly welcome. - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: i-d-announce-admin@ietf.org > [mailto:i-d-announce-admin@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, April 22, 2004 4:38 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-daniel-ipv6-over-wifi-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Transmission of IPv6 Packets over WiFi Networks > Author(s) : S. Park, et al. > Filename : draft-daniel-ipv6-over-wifi-00.txt > Pages : 12 > Date : 2004-4-21 > > This document describes the transmission of IPv6 packets over IEEE > 802.11 specification called WiFi and several considerations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-daniel-ipv6-over-wifi-00.txt > > > --Boundary_(ID_bJ+zqfxT9mZ1usij2lRB2A) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7BIT I-D ACTION:draft-daniel-ipv6-over-wifi-00.txt

fyi. comments/feedbacks are highly welcome.

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics.

> -----Original Message-----
> From: i-d-announce-admin@ietf.org
> [mailto:i-d-announce-admin@ietf.org] On Behalf Of
> Internet-Drafts@ietf.org
> Sent: Thursday, April 22, 2004 4:38 AM
> To: i-d-announce@ietf.org
> Subject: I-D ACTION:draft-daniel-ipv6-over-wifi-00.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
>       Title           : Transmission of IPv6 Packets over WiFi Networks
>       Author(s)       : S. Park, et al.
>       Filename        : draft-daniel-ipv6-over-wifi-00.txt
>       Pages           : 12
>       Date            : 2004-4-21
>      
> This document describes the transmission of IPv6 packets over IEEE
>      802.11 specification called WiFi and several considerations.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-daniel-ipv6-over-wifi-00.txt
>
>
>

--Boundary_(ID_bJ+zqfxT9mZ1usij2lRB2A)-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 22 01:37: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 BAA18067 for ; Thu, 22 Apr 2004 01:37: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 1BGWs8-0004Ur-Hd for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 01:35:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M5ZeCx017281 for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 01:35:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGWkH-0001Kn-MP for ipv6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 01:27: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 BAA17863 for ; Thu, 22 Apr 2004 01:27: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 1BGWkE-0000v0-K6 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 01:27:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGWjG-0000iY-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 01:26:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGWiF-0000QL-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 01:25:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGWc4-0006Yi-It; Thu, 22 Apr 2004 01:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGWbc-00069m-2d for ipv6@optimus.ietf.org; Thu, 22 Apr 2004 01:18: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 BAA17523 for ; Thu, 22 Apr 2004 01:18: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 1BGWbZ-0006ua-1z for ipv6@ietf.org; Thu, 22 Apr 2004 01:18:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGWae-0006jM-00 for ipv6@ietf.org; Thu, 22 Apr 2004 01:17:37 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BGWaL-0006Y1-00 for ipv6@ietf.org; Thu, 22 Apr 2004 01:17:17 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:3855:cf50:dec5:18f1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A26A615210; Thu, 22 Apr 2004 14:17:11 +0900 (JST) Date: Thu, 22 Apr 2004 14:17:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman Hesham" Cc: , Subject: Re: [rfc2462bis] whether we need the M/O flags 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 Fri, 16 Apr 2004 02:10:29 -0400, >>>>> "Soliman Hesham" said: >> One thing we may have to care, however, is that the lack of >> implementation might be a barrier of recycling the spec as a >> DS, since >> we'd need to show interoperable implementations. > => Good point. It would be good to get some clarification on whether > this is an issue though. RFC2026 says in Section 4.1.2 that: 4.1.2 Draft Standard [...] The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. My honest impression from this text is that RFC2462 should have not advanced to a DS...I don't know (remember) why it was accepted, but I suspect it was by an accident. Considering the fact that an error can always occur, I'd respectfully say the following is a bit naive: > I mean, considering that both RFCs are already DS. > My understanding was that this is more of an issue for a PS going to DS. Of course, I may be wrong. Hopefully someone can clarify how RFC2462 could advance to the DS level despite the fact that there were probably no interoperable implementations regarding the M/O flags. (Note: I'm particularly speaking about a general procedure, separately from how we should deal with the M/O flags in rfc2462bis.) 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 Apr 22 02:23:38 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 CAA04509 for ; Thu, 22 Apr 2004 02:23: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 1BGXYq-0006Fr-Lq for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 02:19:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M6JmK2024028 for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 02:19:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXUm-0003Di-Ge for ipv6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 02:15: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 CAA03425 for ; Thu, 22 Apr 2004 02:15: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 1BGXUj-0003ew-0v for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 02:15:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGXTj-0003RO-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 02:14:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGXSh-00034x-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 02:13:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXJa-0002Ga-2O; Thu, 22 Apr 2004 02:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXHH-0008Hj-2v for ipv6@optimus.ietf.org; Thu, 22 Apr 2004 02:01: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 CAA21642 for ; Thu, 22 Apr 2004 02:01: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 1BGXHD-0000on-G1 for ipv6@ietf.org; Thu, 22 Apr 2004 02:01:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGXGM-0000cQ-00 for ipv6@ietf.org; Thu, 22 Apr 2004 02:00:44 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BGXFc-0000Qc-00 for ipv6@ietf.org; Thu, 22 Apr 2004 01:59:57 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:3855:cf50:dec5:18f1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 6058115210; Thu, 22 Apr 2004 14:59:57 +0900 (JST) Date: Thu, 22 Apr 2004 15:00:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Tarun Kr. Sharma" , Tarun_KUMAR/BE/ALCATEL@ALCATEL.cnri.reston.va.us Cc: ipv6@ietf.org Subject: Re: One Question In-Reply-To: <4084D6C2.D5C5F774@alcatel.be> 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, 20 Apr 2004 09:52:34 +0200, >>>>> "Tarun Kr. Sharma" , Tarun_KUMAR/BE/ALCATEL@ALCATEL.cnri.reston.va.us said: > First of all sorry for asking non relevent question but somehow it belongs to > IP. So hopefully I will get a reply for this question. You seem to ask how NATs work and complain about how NATs are bad...I'm afraid this list is not the appropriate place to bring such a thing to. (Of course, someone in the list may have the answer to the question, but I guess this is the reason for the silence so far). 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 Apr 22 02:53: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 CAA06472 for ; Thu, 22 Apr 2004 02:53: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 1BGY4F-0006Qz-1O for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 02:52:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M6qFIf024734 for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 02:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGY0u-0004n2-Sh for ipv6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 02:48: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 CAA06204 for ; Thu, 22 Apr 2004 02:48: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 1BGY0q-00033J-WD for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 02:48:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGXzq-0002oQ-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 02:47:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGXyv-0002aW-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 02:46:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXkg-0005Ty-9Z; Thu, 22 Apr 2004 02:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXjL-0004d4-4x for ipv6@optimus.ietf.org; Thu, 22 Apr 2004 02:30: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 CAA04997 for ; Thu, 22 Apr 2004 02:30: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 1BGXjH-000773-79 for ipv6@ietf.org; Thu, 22 Apr 2004 02:30:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGXiM-0006kg-00 for ipv6@ietf.org; Thu, 22 Apr 2004 02:29:39 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BGXhS-0006Ww-00 for ipv6@ietf.org; Thu, 22 Apr 2004 02:28:42 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:3855:cf50:dec5:18f1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5FF7C15210; Thu, 22 Apr 2004 15:28:42 +0900 (JST) Date: Thu, 22 Apr 2004 15:28:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Lori Napoli Cc: ipv6@ietf.org Subject: Re: Question about Routing Headers 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, 19 Apr 2004 15:28:39 -0400, >>>>> Lori Napoli said: > I have a question about Routing Headers (type 0), more specifically what > happens when we receive an ICMPv6 msg where the offending packet contained > a routing header. From RFC 3542, a routing header can contain 127 IPv6 > next hop addresses. I first would like to note that the RFC3542 specification is not the essential part of this discussion. RFC3542 simply allows the maximum number based on the protocol specification, and this is rather a protocol issue. > Therefore, if a packet specified the maximum number > of entries in a routing header, the routing header alone would exceed 1280 > bytes. Now, if an intermediate node needed to drop this packet and > generate an ICMPv6 msg, the ICMPv6 msg can only contain as much of the > offending packet as will fit within minimum MTU (1280 bytes). Therefore > it is possible for the offending packet within the ICMPv6 msg to not > contain the entire routing header. This ICMPv6 msg will be sent to the > original source of the packet, but the source address of the ICMPv6 msg > will not be the original destination address of the packet since the > destination address in the IPv6 header changes when there is a routing > header. So, how does the originating node correlate this ICMPv6 packet > with the correct socket? Since we can't rely on the entire routing header > being present in the offending packet, we can't even rebuild what the > original destination would have been. I think your concern is valid, but this is mostly not specific to routing headers. If we want to deliver an ICMPv6 error to a particular socket(s), the inner packet of the error message should contain the upper layer header such as a TCP header. However, we cannot always guarantee this due to the existence of intermediate extension headers. And, this does not only apply to routing headers, but also to all other kinds of extension headers. But I don't think this issue requires an update on the spec. After all, ICMPv6 error messages basically only work in a best-effort manner. The only problematic case, as far as I can see, would be ICMPv6 too big messages for path MTU discovery. In this case, however, we can still update the MTU information gradually; we first update the MTU information to the intermediate destination stored in the destination address field of the inner IPv6 packet. Then succeeding packets will go farther. And, eventually, we can at least reach at the intermediate destination without seeing an ICMPv6 too big error. Then the IPv6 destination address will be updated to the next intermediate destination (which might be the final one), and we can still reach there by the similar steps. > My second question is that for IPv6, the Type 0 Routing header can contain > 127 addresses. This routing header is considered non-fragmentable. If > your interface is Ethernet with a standard 1492 MTU, this packet cannot be > sent on that interface since the routing header alone would exceed 1492. > It seems inconsistent to me to allow such a large non-fragmentable header. This is also true, but this is not specific to routing headers either. And, again, I don't see this is a bug of protocol specification to be fixed. First, this would still work for links with a larger link MTU. Secondly, at least IMO, it is not unfair to say it's the sender's responsibility to keep the unfragmentable part not exceeding the path MTU (if not, the sender can detect the error, at least theoretically). 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 Apr 22 09:28: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 JAA25589 for ; Thu, 22 Apr 2004 09:28: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 1BGe3p-0002Oe-6x for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 09:16:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MDGDNU009207 for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 09:16:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdr8-0006TV-4T for ipv6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 09:03: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 JAA24313 for ; Thu, 22 Apr 2004 09:02: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 1BGdr0-0006k1-VB for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 09:02:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdq0-0006Tz-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 09:01:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGdp5-0006FG-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 09:00:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdbb-0000hA-2v; Thu, 22 Apr 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 1BGdUq-0006zI-CM for ipv6@optimus.ietf.org; Thu, 22 Apr 2004 08:40: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 IAA22973 for ; Thu, 22 Apr 2004 08:39: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 1BGdUj-0000eH-FW for ipv6@ietf.org; Thu, 22 Apr 2004 08:39:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdTl-0000Qa-00 for ipv6@ietf.org; Thu, 22 Apr 2004 08:38:58 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 1BGdTO-0000Bd-00 for ipv6@ietf.org; Thu, 22 Apr 2004 08:38:34 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3MCc5pj369878 for ; Thu, 22 Apr 2004 08:38:05 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3MCc4cM346196 for ; Thu, 22 Apr 2004 06:38:04 -0600 To: ipv6@ietf.org MIME-Version: 1.0 Subject: Fw: Question about Routing Headers X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 From: Lori Napoli Message-ID: Date: Thu, 22 Apr 2004 08:25:08 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 04/22/2004 06:38:04, Serialize complete at 04/22/2004 06:38:04 Content-Type: multipart/alternative; boundary="=_alternative 0044024485256E7E_=" 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,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 0044024485256E7E_= Content-Type: text/plain; charset="US-ASCII" > The only problematic case, as far as I can see, would be ICMPv6 too > big messages for path MTU discovery. In this case, however, we can > still update the MTU information gradually; we first update the MTU > information to the intermediate destination stored in the destination > address field of the inner IPv6 packet. Then succeeding packets will > go farther. And, eventually, we can at least reach at the > intermediate destination without seeing an ICMPv6 too big error. Then > the IPv6 destination address will be updated to the next intermediate > destination (which might be the final one), and we can still reach > there by the similar steps. Thanks for your reply however I still think there is an issue with Path MTU. If I send a packet outbound, typically I use the MTU associated with the destination to which I am sending the packet. In the case of routing headers this will be the first hop (call it A). Say that works fine, but now that node (A) sends the packet to another router (call it B) (so the destination address in the IP header has changed). When this node tries to send the packet it out would need to fragment it so it generates an ICMPv6 msg back to the originator. The inner IP header has the original source and some intermediate destination address (node B would have changed the destination address in the IP header when it processed the routing header before it realized it needed to fragment the packet so the destination address now would be C). So when the originating host receives this it will adjust it's MTU to get to this intermediate node (node C). But I don't think we will look at this information unless we are sending a packet to this node (node C) -- and in the case of routing headers we aren't - we're sending to some other node (in this case node A). Lori E-mail: lanapoli@us.ibm.com --=_alternative 0044024485256E7E_= Content-Type: text/html; charset="US-ASCII"

> The only problematic case, as far as I can see, would be ICMPv6 too
> big messages for path MTU discovery.  In this case, however, we can
> still update the MTU information gradually; we first update the MTU
> information to the intermediate destination stored in the destination
> address field of the inner IPv6 packet.  Then succeeding packets will
> go farther.  And, eventually, we can at least reach at the
> intermediate destination without seeing an ICMPv6 too big error.  Then
> the IPv6 destination address will be updated to the next intermediate
> destination (which might be the final one), and we can still reach
> there by the similar steps.

Thanks for your reply however I still think there is an issue with Path MTU.   If I send a packet outbound, typically I use the MTU associated with the destination to which I am sending the packet.  In the case of routing headers this will be the first hop (call it A).  Say that works fine, but now that node (A) sends the packet to another router (call it B) (so the destination address in the IP header has changed).    When this node tries to send the packet it out would need to fragment it so it generates an ICMPv6 msg back to the originator.   The inner IP header has the original source and some intermediate destination address (node B would have changed the destination address in the IP header when it processed the routing header before it realized it needed to fragment the packet so the destination address now would be C).  So when the originating host receives this it will adjust it's MTU to get to this intermediate node (node C).  But I don't think we will look at this information unless we are sending a packet to this node (node C) -- and in the case of routing headers we aren't - we're sending to some other node (in this case node A).

Lori
E-mail: lanapoli@us.ibm.com

--=_alternative 0044024485256E7E_=-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 22 10:41: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 KAA01218 for ; Thu, 22 Apr 2004 10:41: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 1BGf9l-0004xY-8Y for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 10:26:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MEQPmt019064 for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 10:26:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGf1r-0000w8-4U for ipv6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 10:18: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 KAA29500 for ; Thu, 22 Apr 2004 10:18: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 1BGf1j-0002rK-2G for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 10:18:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGf0t-0002bW-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 10:17:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGf03-0002LA-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 10:16:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGemE-0008Mz-84; Thu, 22 Apr 2004 10:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeZd-0003b9-4y for ipv6@optimus.ietf.org; Thu, 22 Apr 2004 09:49: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 JAA26889 for ; Thu, 22 Apr 2004 09:48: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 1BGeZV-00030G-Fo for ipv6@ietf.org; Thu, 22 Apr 2004 09:48:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeYa-0002lN-00 for ipv6@ietf.org; Thu, 22 Apr 2004 09:48:01 -0400 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1BGeXo-0002HE-00 for ipv6@ietf.org; Thu, 22 Apr 2004 09:47:12 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3MDkb87712214 for ; Thu, 22 Apr 2004 09:46:37 -0400 Received: from d03nm118.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3MDkZnZ089400 for ; Thu, 22 Apr 2004 07:46:36 -0600 In-Reply-To: To: Lori Napoli Cc: ipv6@ietf.org MIME-Version: 1.0 Subject: Re: Fw: Question about Routing Headers X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 04/22/2004 09:46:15 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 04/22/2004 09:46:15 AM, Serialize complete at 04/22/2004 09:46:15 AM, S/MIME Sign failed at 04/22/2004 09:46:15 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 04/22/2004 07:46:36, Serialize complete at 04/22/2004 07:46:36 Message-ID: Date: Thu, 22 Apr 2004 09:46:29 -0400 Content-Type: multipart/alternative; boundary="=_alternative 004BA55F85256E7E_=" 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=HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 004BA55F85256E7E_= Content-Type: text/plain; charset="US-ASCII" > > The only problematic case, as far as I can see, would be ICMPv6 too > > big messages for path MTU discovery. In this case, however, we can > > still update the MTU information gradually; we first update the MTU > > information to the intermediate destination stored in the destination > > address field of the inner IPv6 packet. Then succeeding packets will > > go farther. And, eventually, we can at least reach at the > > intermediate destination without seeing an ICMPv6 too big error. Then > > the IPv6 destination address will be updated to the next intermediate > > destination (which might be the final one), and we can still reach > > there by the similar steps. > > Thanks for your reply however I still think there is an issue with Path > MTU. If I send a packet outbound, typically I use the MTU associated > with the destination to which I am sending the packet. In the case of > routing headers this will be the first hop (call it A). Say that works > fine, but now that node (A) sends the packet to another router (call it > B) (so the destination address in the IP header has changed). When this > node tries to send the packet it out would need to fragment it so it > generates an ICMPv6 msg back to the originator. The inner IP header has > the original source and some intermediate destination address (node B > would have changed the destination address in the IP header when it > processed the routing header before it realized it needed to fragment > the packet so the destination address now would be C). So when the > originating host receives this it will adjust it's MTU to get to this > intermediate node (node C). But I don't think we will look at this > information unless we are sending a packet to this node (node C) -- and > in the case of routing headers we aren't - we're sending to some other > node (in this case node A). When using a routing header, why not use the minimum of the PMTU for the initial first-hop and every hop in the routing header? You are, after all, sending the packet to each of the intermediate destinations, albeit in a circuitous manner. Doing that, you use the minimum of the PMTU to (A), (B) and (C). Roy --=_alternative 004BA55F85256E7E_= Content-Type: text/html; charset="US-ASCII"
> > The only problematic case, as far as I can see, would be ICMPv6 too
> > big messages for path MTU discovery.  In this case, however, we can
> > still update the MTU information gradually; we first update the MTU
> > information to the intermediate destination stored in the destination
> > address field of the inner IPv6 packet.  Then succeeding packets will
> > go farther.  And, eventually, we can at least reach at the
> > intermediate destination without seeing an ICMPv6 too big error.  Then
> > the IPv6 destination address will be updated to the next intermediate
> > destination (which might be the final one), and we can still reach
> > there by the similar steps.
>
> Thanks for your reply however I still think there is an issue with Path
> MTU.  If I send a packet outbound, typically I use the MTU associated
> with the destination to which I am sending the packet.  In the case of
> routing headers this will be the first hop (call it A).  Say that works
> fine, but now that node (A) sends the packet to another router (call it
> B) (so the destination address in the IP header has changed).  When this
> node tries to send the packet it out would need to fragment it so it
> generates an ICMPv6 msg back to the originator.  The inner IP header has
> the original source and some intermediate destination address (node B
> would have changed the destination address in the IP header when it
> processed the routing header before it realized it needed to fragment
> the packet so the destination address now would be C).  So when the
> originating host receives this it will adjust it's MTU to get to this
> intermediate node (node C).  But I don't think we will look at this
> information unless we are sending a packet to this node (node C) -- and
> in the case of routing headers we aren't - we're sending to some other
> node (in this case node A).  

When using a routing header, why not use the minimum of the PMTU for the initial first-hop and every hop in the routing header?  You are, after all, sending the packet to each of the intermediate destinations, albeit in a circuitous manner.  Doing that, you use the minimum of the PMTU to (A), (B) and (C).

Roy --=_alternative 004BA55F85256E7E_=-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 22 10:46: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 KAA01555 for ; Thu, 22 Apr 2004 10:46: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 1BGfBT-0005VT-5K for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 10:28:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MESBYO021159 for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 10:28:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGf8S-0004FQ-QN for ipv6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 10:25: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 KAA29959 for ; Thu, 22 Apr 2004 10:24: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 1BGf8K-0004dO-NE for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 10:24:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGf7M-0004Mh-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 10:23:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGf6L-00046H-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 10:22:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGenA-0001NO-2x; Thu, 22 Apr 2004 10:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeiH-0005xE-5z for ipv6@optimus.ietf.org; Thu, 22 Apr 2004 09:58: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 JAA27160 for ; Thu, 22 Apr 2004 09:57: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 1BGei9-0005EY-Dw for ipv6@ietf.org; Thu, 22 Apr 2004 09:57:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeh9-0004yH-00 for ipv6@ietf.org; Thu, 22 Apr 2004 09:56:52 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1BGeg5-0004VZ-00 for ipv6@ietf.org; Thu, 22 Apr 2004 09:55:47 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3MDtGcw475594 for ; Thu, 22 Apr 2004 09:55:16 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3MDtAnZ136810 for ; Thu, 22 Apr 2004 07:55:12 -0600 In-Reply-To: To: ipv6@ietf.org MIME-Version: 1.0 Subject: Re: Fw: Question about Routing Headers X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 From: Lori Napoli Message-ID: Date: Thu, 22 Apr 2004 09:55:09 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 04/22/2004 07:55:11, Serialize complete at 04/22/2004 07:55:11 Content-Type: multipart/alternative; boundary="=_alternative 004C35B685256E7E_=" 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,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 004C35B685256E7E_= Content-Type: text/plain; charset="US-ASCII" Roy Brabson/Raleigh/IBM wrote on 04/22/2004 09:46:15 AM: > > > The only problematic case, as far as I can see, would be ICMPv6 too > > > big messages for path MTU discovery. In this case, however, we can > > > still update the MTU information gradually; we first update the MTU > > > information to the intermediate destination stored in the destination > > > address field of the inner IPv6 packet. Then succeeding packets will > > > go farther. And, eventually, we can at least reach at the > > > intermediate destination without seeing an ICMPv6 too big error. Then > > > the IPv6 destination address will be updated to the next intermediate > > > destination (which might be the final one), and we can still reach > > > there by the similar steps. > > > > Thanks for your reply however I still think there is an issue with Path > > MTU. If I send a packet outbound, typically I use the MTU associated > > with the destination to which I am sending the packet. In the case of > > routing headers this will be the first hop (call it A). Say that works > > fine, but now that node (A) sends the packet to another router (call it > > B) (so the destination address in the IP header has changed). When this > > node tries to send the packet it out would need to fragment it so it > > generates an ICMPv6 msg back to the originator. The inner IP header has > > the original source and some intermediate destination address (node B > > would have changed the destination address in the IP header when it > > processed the routing header before it realized it needed to fragment > > the packet so the destination address now would be C). So when the > > originating host receives this it will adjust it's MTU to get to this > > intermediate node (node C). But I don't think we will look at this > > information unless we are sending a packet to this node (node C) -- and > > in the case of routing headers we aren't - we're sending to some other > > node (in this case node A). > > When using a routing header, why not use the minimum of the PMTU for the initial > first-hop and every hop in the routing header? You are, after all, sending the > packet to each of the intermediate destinations, albeit in a circuitous manner. > Doing that, you use the minimum of the PMTU to (A), (B) and (C). > That is definitely doable albeit VERY expensive since you would need to lookup the MTU for ALL the entries in the routing header for EACH send since they could change. Lori --=_alternative 004C35B685256E7E_= Content-Type: text/html; charset="US-ASCII"
Roy Brabson/Raleigh/IBM wrote on 04/22/2004 09:46:15 AM:

> > > The only problematic case, as far as I can see, would be ICMPv6 too
> > > big messages for path MTU discovery.  In this case, however, we can
> > > still update the MTU information gradually; we first update the MTU
> > > information to the intermediate destination stored in the destination
> > > address field of the inner IPv6 packet.  Then succeeding packets will
> > > go farther.  And, eventually, we can at least reach at the
> > > intermediate destination without seeing an ICMPv6 too big error.  Then
> > > the IPv6 destination address will be updated to the next intermediate
> > > destination (which might be the final one), and we can still reach
> > > there by the similar steps.
> >
> > Thanks for your reply however I still think there is an issue with Path
> > MTU.  If I send a packet outbound, typically I use the MTU associated
> > with the destination to which I am sending the packet.  In the case of
> > routing headers this will be the first hop (call it A).  Say that works
> > fine, but now that node (A) sends the packet to another router (call it
> > B) (so the destination address in the IP header has changed).  When this
> > node tries to send the packet it out would need to fragment it so it
> > generates an ICMPv6 msg back to the originator.  The inner IP header has
> > the original source and some intermediate destination address (node B
> > would have changed the destination address in the IP header when it
> > processed the routing header before it realized it needed to fragment
> > the packet so the destination address now would be C).  So when the
> > originating host receives this it will adjust it's MTU to get to this
> > intermediate node (node C).  But I don't think we will look at this
> > information unless we are sending a packet to this node (node C) -- and
> > in the case of routing headers we aren't - we're sending to some other
> > node (in this case node A).  
>
> When using a routing header, why not use the minimum of the PMTU for the initial
> first-hop and every hop in the routing header?  You are, after all, sending the
> packet to each of the intermediate destinations, albeit in a circuitous manner.  
> Doing that, you use the minimum of the PMTU to (A), (B) and (C).
>

That is definitely doable albeit VERY expensive since you would need to lookup the MTU for ALL the entries in the routing header for EACH send since they could change.

Lori --=_alternative 004C35B685256E7E_=-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 22 12:57:16 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 MAA10264 for ; Thu, 22 Apr 2004 12:57: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 1BGhOa-00014y-UU for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 12:49:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MGnqxS004144 for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 12:49:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhGG-00065J-Gc for ipv6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 12:41: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 MAA09463 for ; Thu, 22 Apr 2004 12:41: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 1BGhGC-0003ee-Is for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 12:41:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhFL-0003OC-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 12:40:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGhEZ-00036r-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 12:39:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGh4S-0002CM-IR; Thu, 22 Apr 2004 12:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgn2-0004Ho-UM for ipv6@optimus.ietf.org; Thu, 22 Apr 2004 12:11: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 MAA07901 for ; Thu, 22 Apr 2004 12:11: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 1BGgmz-000319-En for ipv6@ietf.org; Thu, 22 Apr 2004 12:11:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgm1-0002mZ-00 for ipv6@ietf.org; Thu, 22 Apr 2004 12:10:02 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1BGglM-0002JI-00 for ipv6@ietf.org; Thu, 22 Apr 2004 12:09:20 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3MG8jcw434584; Thu, 22 Apr 2004 12:08:45 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3MG8fcM362244; Thu, 22 Apr 2004 10:08:42 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id i3MG8fdP002923; Thu, 22 Apr 2004 12:08:41 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i3MG8W6E002918; Thu, 22 Apr 2004 12:08:32 -0400 Message-Id: <200404221608.i3MG8W6E002918@rotala.raleigh.ibm.com> To: Alain Durand cc: Margaret Wasserman , Brian Haberman , IETF IPv6 Mailing List , "'Bob Hinden'" Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" In-Reply-To: Message from Alain.Durand@Sun.COM of "Fri, 27 Feb 2004 14:53:09 PST." Date: Thu, 22 Apr 2004 12:08:31 -0400 From: Thomas Narten 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 Alain, This note summarizes the outcome of a conference call regarding your appeal to the INT ADs of the IPv6 WG's decision to advance draft-ietf-ipv6-unique-local-addr-03.txt. Attendees on the call included the INT ADs (Margaret and myself), the IPv6 chairs (Brian and Bob) as well as yourself. Your appeal raised two points: Alain Durand writes: > For the reasons stated above, I still believe that the wg is making > an incorrect decision by allowing this document to progress as is > and I maintain my appeal to our AD. > Dear ADs, consider this mail as my second step in the appeal chain. > Specifically, the part I object to are: > - under the FD00::/8 prefix (Locally assigned): using the 'all zero' > pattern instead of random bits would have the exact same effect as > using the 'site local' address: it would create ambiguous > addresses. The ipv6 wg spend over a year deprecating 'site local' > addresses for that reason. It is the duty of this wg to document > that using that particular pattern can be harmful. There was subsequent discussion on the mailing list regarding this point, including a post from Tim Chown suggesting specific text. We all agreed that Tim's text seemed reasonable and that the document (if it didn't already) should include it (or something like it). The authors will be asked to attempt to fit Tim's wording into the document. This step addresses the first point of your appeal. > -under the FC00::/8 prefix (Centrally assigned:) > the document says that: > " The requirements for centrally assigned global ID allocations are: > - Available to anyone in an unbiased manner. > - Permanent with no periodic fees. > - Allocation on a permanent basis, without any need for renewal > and without any procedure for de-allocation." > I object that there is any technical requirement to mandate that the > allocations have to be permanent. There is a requirement to make > those addresses stable in time, but this is very different from > permanent allocation. > Also, the entity managing the allocations should have the > possibility to reclaim addresses under circumstances to be > determined. > But more important, the IETF should stick to protocol design and > should not wander in economic/business model territory by mandating > any kind of fee structure. The general issue of permanence is an important one that should be given serious consideration in the WG, and the ADs believe that it would be better for all to have this matter resolved in the WG rather than through a formal appeal. As was pointed out on the call, there have been preliminary discussions between IESG members and the RIR community regarding this draft and some feedback from the RIR community will be made available to the WG shortly. The general topic of permanance will almost certainly come up during those discussions. Given that there will be further discussions on the topic you have raised, withdrawing your appeal at this point would actually facilitate the resolution of the issue in the WG. Based on the above, my understanding is that your appeal has now been resolved. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 22 13:03:50 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 NAA10908 for ; Thu, 22 Apr 2004 13:03: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 1BGhV6-0003DT-8d for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 12:56:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MGuaJ4012357 for ipv6-archive@odin.ietf.org; Thu, 22 Apr 2004 12:56:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhNu-0000mH-7Q for ipv6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 12:49: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 MAA09807 for ; Thu, 22 Apr 2004 12:49: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 1BGhNq-0005n6-DJ for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 12:49:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhMx-0005X7-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 12:48:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGhMM-0005H3-00 for ipv6-web-archive@ietf.org; Thu, 22 Apr 2004 12:47:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGh4Y-0002EG-2g; Thu, 22 Apr 2004 12:29:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgwk-0007iT-Qb for ipv6@optimus.ietf.org; Thu, 22 Apr 2004 12:21: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 MAA08207 for ; Thu, 22 Apr 2004 12:21: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 1BGgwh-0005dc-8P for ipv6@ietf.org; Thu, 22 Apr 2004 12:21:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgvl-0005NW-00 for ipv6@ietf.org; Thu, 22 Apr 2004 12:20:05 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BGgut-00056E-00 for ipv6@ietf.org; Thu, 22 Apr 2004 12:19:11 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3MGJ7dc026162 for ; Thu, 22 Apr 2004 10:19:07 -0600 (MDT) Received: from fe8 (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 <0HWK00CGHYNVGP@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Thu, 22 Apr 2004 10:19:07 -0600 (MDT) Received: from [192.168.1.100] ([129.150.18.78]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HWK00FE1YNT46@mail.sun.net> for ipv6@ietf.org; Thu, 22 Apr 2004 10:19:07 -0600 (MDT) Date: Thu, 22 Apr 2004 09:19:03 -0700 From: Alain Durand Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" In-reply-to: <200404221608.i3MG8W6E002918@rotala.raleigh.ibm.com> To: Thomas Narten Cc: Brian Haberman , IETF IPv6 Mailing List , Margaret Wasserman , "'Bob Hinden'" 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: <200404221608.i3MG8W6E002918@rotala.raleigh.ibm.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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Apr 22, 2004, at 9:08 AM, Thomas Narten wrote: > Based on the above, my understanding is that your appeal has now been > resolved. Thomas, Thank you for organizing the con-call that enable us to make those progress. The steps you mentioned address fully my concerns and resolve my appeal. I'm particularly happy to see the RIRs involved in the discussion at this point and I look forward hearing from them. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 23 00:27:49 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 AAA26801 for ; Fri, 23 Apr 2004 00:27: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 1BGsGp-0006Qx-SC for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 00:26:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N4QZ7I024723 for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 00:26:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsFr-0005uL-Cg for ipv6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 00:25: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 AAA26628 for ; Fri, 23 Apr 2004 00:25: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 1BGsFm-0007Nj-P3 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 00:25:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGsEn-00077T-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 00:24:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGsDp-0006re-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 00:23:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGrzt-0000Ud-D1; Fri, 23 Apr 2004 00:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGrtg-0006EG-4p for ipv6@optimus.ietf.org; Fri, 23 Apr 2004 00:02: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 AAA25537 for ; Fri, 23 Apr 2004 00:02: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 1BGrtb-0001CA-Kh for ipv6@ietf.org; Fri, 23 Apr 2004 00:02:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGrsb-0000w1-00 for ipv6@ietf.org; Fri, 23 Apr 2004 00:01:34 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1BGrsA-0000gS-00 for ipv6@ietf.org; Fri, 23 Apr 2004 00:01:06 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i3N40cfX024773; Thu, 22 Apr 2004 23:00:39 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Apr 2004 23:00:18 -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 2RBY0405; Fri, 23 Apr 2004 00:00:31 -0400 Date: Fri, 23 Apr 2004 00:00:33 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: Lori Napoli cc: ipv6@ietf.org Subject: Re: Fw: Question about Routing Headers In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830D8F6CBE@eammlex037.lmc.ericsson.se> 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 Lori, Find my comments inline Regards Suresh On Thu, 22 Apr 2004, Lori Napoli wrote: >Thanks for your reply however I still think there is an issue with Path >MTU. If I send a packet outbound, typically I use the MTU associated >with the destination to which I am sending the packet. In the case of This is not a requirement for PMTU discovery. The PMTU should ideally be associated with the path used in the routing header rather than with the destination address. In fact this is stated in RFC1981 section 5.2. Storing PMTU information | For source routed packets (i.e. packets containing an IPv6 Routing | header [IPv6-SPEC]), the source route may further qualify the local | representation of a path. In particular, a packet containing a type | 0 Routing header in which all bits in the Strict/Loose Bit Map are | equal to 1 contains a complete path specification. An implementation | could use source route information in the local representation of a | path. I see your point, though. I haven't yet seen an implementation store PMTU in this manner. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 23 05:07: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 FAA23582 for ; Fri, 23 Apr 2004 05:07: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 1BGwcV-0003UX-Eb for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 05:05:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N95F0E013415 for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 05:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwYH-0002cx-U7 for ipv6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 05:00: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 FAA23375 for ; Fri, 23 Apr 2004 05:00: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 1BGwYC-000564-Pb for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 05:00:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGwXF-0004q0-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 04:59:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGwWe-0004aP-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 04:59:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwRe-0000lr-3W; Fri, 23 Apr 2004 04:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwQU-0000Hv-Gs for ipv6@optimus.ietf.org; Fri, 23 Apr 2004 04:52: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 EAA22872 for ; Fri, 23 Apr 2004 04:52: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 1BGwQP-0002nQ-8M for ipv6@ietf.org; Fri, 23 Apr 2004 04:52:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGwPX-0002VZ-00 for ipv6@ietf.org; Fri, 23 Apr 2004 04:51:51 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1BGwOk-0001zQ-00 for ipv6@ietf.org; Fri, 23 Apr 2004 04:51:02 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i3N8oYMp017128 for ; Fri, 23 Apr 2004 08:50:34 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 i3N8oQO9125498 for ; Fri, 23 Apr 2004 10:50:26 +0200 Received: from zurich.ibm.com (dyn-9-159-99-45.bw.ch.ibm.com [9.159.99.45]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA28000; Fri, 23 Apr 2004 10:50:24 +0200 Message-ID: <4088B350.45201154@zurich.ibm.com> Date: Fri, 23 Apr 2004 08:10:24 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Lori Napoli CC: ipv6@ietf.org Subject: Re: Fw: Question about Routing Headers References: Content-Type: text/plain; charset=us-ascii 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 Lori Napoli wrote: > > Roy Brabson/Raleigh/IBM wrote on 04/22/2004 09:46:15 AM: > > > > > The only problematic case, as far as I can see, would be ICMPv6 too > > > > big messages for path MTU discovery. In this case, however, we can > > > > still update the MTU information gradually; we first update the MTU > > > > information to the intermediate destination stored in the destination > > > > address field of the inner IPv6 packet. Then succeeding packets will > > > > go farther. And, eventually, we can at least reach at the > > > > intermediate destination without seeing an ICMPv6 too big error. Then > > > > the IPv6 destination address will be updated to the next intermediate > > > > destination (which might be the final one), and we can still reach > > > > there by the similar steps. > > > > > > Thanks for your reply however I still think there is an issue with Path > > > MTU. If I send a packet outbound, typically I use the MTU associated > > > with the destination to which I am sending the packet. In the case of > > > routing headers this will be the first hop (call it A). Say that works > > > fine, but now that node (A) sends the packet to another router (call it > > > B) (so the destination address in the IP header has changed). When this > > > node tries to send the packet it out would need to fragment it so it > > > generates an ICMPv6 msg back to the originator. The inner IP header has > > > the original source and some intermediate destination address (node B > > > would have changed the destination address in the IP header when it > > > processed the routing header before it realized it needed to fragment > > > the packet so the destination address now would be C). So when the > > > originating host receives this it will adjust it's MTU to get to this > > > intermediate node (node C). But I don't think we will look at this > > > information unless we are sending a packet to this node (node C) -- and > > > in the case of routing headers we aren't - we're sending to some other > > > node (in this case node A). > > > > When using a routing header, why not use the minimum of the PMTU for the initial > > first-hop and every hop in the routing header? You are, after all, sending the > > packet to each of the intermediate destinations, albeit in a circuitous manner. > > Doing that, you use the minimum of the PMTU to (A), (B) and (C). > > > > That is definitely doable albeit VERY expensive since you would need to lookup the MTU for ALL the entries in the routing > header for EACH send since they could change. Firstly there is a small misstatement above When this node tries to send the packet it out would need to fragment it so it generates an ICMPv6 msg back to the originator. Routers don't fragment packets in IPv6 (RFC 2460 section 4.5), so the node will drop it, not fragment it. And I don't see why it would return an ICMPv6 packet except during MTU discovery, in which case the problem doesn't arise, because MTU discovery will tell you the MTU that *does* work end to end. If you want to play safe, always use MTU 1280 when using a routing header. That has to work in all cases (RFC 2460 section 5). Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 23 07:12:22 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 HAA27927 for ; Fri, 23 Apr 2004 07: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 1BGyY8-0002e3-Sx for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 07:08:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NB8qKi010162 for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 07:08:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGyUN-0001N5-90 for ipv6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 07:04: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 HAA27657 for ; Fri, 23 Apr 2004 07:04: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 1BGyUG-0006TR-Vd for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 07:04:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGyTK-0006DR-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 07:03:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGySW-0005xq-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 07:03:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGyLj-0007mM-1C; Fri, 23 Apr 2004 06:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGyFq-0006IG-QH for ipv6@optimus.ietf.org; Fri, 23 Apr 2004 06:49: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 GAA27143 for ; Fri, 23 Apr 2004 06:49: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 1BGyFk-0002Ye-Dg for ipv6@ietf.org; Fri, 23 Apr 2004 06:49:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGyEp-0002Id-00 for ipv6@ietf.org; Fri, 23 Apr 2004 06:48:55 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BGyEF-00022m-00 for ipv6@ietf.org; Fri, 23 Apr 2004 06:48:19 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:3855:ef7a:dffd:f9f5]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BDAAB15214; Fri, 23 Apr 2004 19:48:15 +0900 (JST) Date: Fri, 23 Apr 2004 19:48:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Alain Durand Cc: "Bound, Jim" , IPv6 Mailing List Subject: Re: question on rfc2462bis: stateful mechanisms is a MUST? In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B0612C359@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 Mon, 19 Apr 2004 10:48:07 -0700, >>>>> Alain Durand said: > I agree with Jim, section 5.5.2 should be deleted. Let implementations > decide > what to do if there is no router. > If you decide to keep 5.5.2, you will need to add some text to analyze > the performance impact of doing DHCPv6 when there is no IPv6 at all. Jim and Alain, thanks for the input. I'll go back to this thread when we complete the bigger one about the M/O flags (because the result will be likely to affect this issue as well). 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 Apr 23 11:34:25 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 LAA14991 for ; Fri, 23 Apr 2004 11:34: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 1BH2YR-0000AJ-Nv for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 11:25:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NFPRYf000631 for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 11:25:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2TE-0006pD-8W for ipv6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 11:20: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 LAA14180 for ; Fri, 23 Apr 2004 11:20: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 1BH2TD-0004uK-DI for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 11:20:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2SJ-0004g2-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 11:19:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2RV-0004Rl-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 11:18:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2IX-00048K-TH; Fri, 23 Apr 2004 11: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 1BH2Ei-0002vW-HD for ipv6@optimus.ietf.org; Fri, 23 Apr 2004 11:05: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 LAA13266 for ; Fri, 23 Apr 2004 11:04: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 1BH2Ef-0000ql-Ry for ipv6@ietf.org; Fri, 23 Apr 2004 11:05:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2Df-0000aa-00 for ipv6@ietf.org; Fri, 23 Apr 2004 11:04:00 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 1BH2Cb-00007o-00 for ipv6@ietf.org; Fri, 23 Apr 2004 11:02:53 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3NF2Mpj017860 for ; Fri, 23 Apr 2004 11:02:22 -0400 Received: from d03nm118.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3NF2IP3168692 for ; Fri, 23 Apr 2004 09:02:18 -0600 To: ipv6@ietf.org MIME-Version: 1.0 Subject: Routing Header scenario ...... X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 From: Lori Napoli Message-ID: Date: Fri, 23 Apr 2004 11:02:16 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 04/23/2004 09:02:18, Serialize complete at 04/23/2004 09:02:18 Content-Type: multipart/alternative; boundary="=_alternative 0052647E85256E7F_=" 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,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 0052647E85256E7F_= Content-Type: text/plain; charset="US-ASCII" Thanks for the feedback on my routing header questions. I think it would be meaningful to include an example of what I was referring to in my original question.. Original source A First hop B 2nd hop C 3rd hop D Final Dest E * A sends packet out with a routing header so the source = A, dest = B when the packet goes outbound. * B processes routing header and changes dest = C and forwards the packet. * C processes routing header and changes dest = D. When he attempts to forward packet he can't due to fragmentation. So C generates ICMPv6 msg to send back to A. The inner header has source = A and dest = D. * When A gets this ICMPv6 msg it updates it MTU to get to D. So, the packet A originally sent never makes it to E. What will make A realize the MTU needs to be adjusted for this send and that a Packet too Big msg received for destination D is relevant? Here are some options: * This could be done having the sending side look at the MTU values to ALL of the entries in the routing header but I would contend that this is very expensive since all the lookups would need to be done on each send since any MTU value could change, and a routing header supports 127 entries. * This could be done by always using 1280 MTU when sending a packet that contains a routing header but since the RFC states that you can have 127 entries in the routing header that would be inconsistent since then the routing header would exceed 1280 bytes and it is unfragmentable. * This could be done by having the node receiving the IMCPv6 msg reconstruct the original inner header but this is impossible since the routing header can exceed 1280 bytes and an ICMPv6 msg can only be a max of 1280 bytes. Therefore you are not guaranteed to have the entire routing header in the imbedded packet. * This could be done by having the node that generates the ICMPv6 msg encode the original destination address so when the ICMPv6 msg is received by the originator it can determine who the original destination of the packet was. This would have to be agreed upon and standardized so all implementations follow the same rules. Any other thoughts/opinions on what should be done for this scenario? What do other implementations do? Thanks Lori E-mail: lanapoli@us.ibm.com --=_alternative 0052647E85256E7F_= Content-Type: text/html; charset="US-ASCII"
Thanks for the feedback on my routing header questions.  I think it would be meaningful to include an example of what I was referring to in my original question..

Original source         A
First hop              B
2nd hop                C
3rd hop                D
Final Dest             E

* A sends packet out with a routing header so the source = A, dest = B when the packet goes outbound.
* B processes routing header and changes dest = C and forwards the packet.
* C processes routing header and changes dest = D.  When he attempts to forward packet he can't due to fragmentation.  So C generates ICMPv6 msg to send back to A.  The inner header has source = A and dest = D.
* When A gets this ICMPv6 msg it updates it MTU to get to D.

So, the packet A originally sent never makes it to E.  What will make A realize the MTU needs to be adjusted for this send and that a Packet too Big msg received for destination D is relevant?

Here are some options:

* This could be done having the sending side look at the MTU values to ALL of the entries in the routing header but I would contend that this is very expensive since all the lookups would need to be done on each send since any MTU value could change, and a routing header supports 127 entries.

* This could be done by always using 1280 MTU when sending a packet that contains a routing header but since the RFC states that you can have 127 entries in the routing header that would be inconsistent since then the routing header would exceed 1280 bytes and it is unfragmentable.

* This could be done by having the node receiving the IMCPv6 msg reconstruct the original inner header but this is impossible since the routing header can exceed 1280 bytes and an ICMPv6 msg can only be a max of 1280 bytes.  Therefore you are not guaranteed to have the entire routing header in the imbedded packet.

* This could be done by having the node that generates the ICMPv6 msg encode the original destination address so when the ICMPv6 msg is received by the originator it can determine who the original destination of the packet was.  This would have to be agreed upon and standardized so all implementations follow the same rules.

Any other thoughts/opinions on what should be done for this scenario?  What do other implementations do?

Thanks
Lori



E-mail: lanapoli@us.ibm.com --=_alternative 0052647E85256E7F_=-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 23 11:47:50 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 LAA15635 for ; Fri, 23 Apr 2004 11:47: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 1BH2ki-0003SS-Sz for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 11:38:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NFc80c013287 for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 11:38:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2Z7-0000T7-UK for ipv6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 11:26: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 LAA14450 for ; Fri, 23 Apr 2004 11:26: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 1BH2Z7-0006S7-2T for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 11:26:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2YA-0006BV-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 11:25:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2XD-0005uL-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 11:24:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2PN-0005wZ-IS; Fri, 23 Apr 2004 11:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2HL-0003f8-PQ for ipv6@optimus.ietf.org; Fri, 23 Apr 2004 11:07: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 LAA13460 for ; Fri, 23 Apr 2004 11:07: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 1BH2HJ-0001UC-4l for ipv6@ietf.org; Fri, 23 Apr 2004 11:07:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2G7-0001BR-00 for ipv6@ietf.org; Fri, 23 Apr 2004 11:06:33 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BH2FH-0000tj-00 for ipv6@ietf.org; Fri, 23 Apr 2004 11:05:39 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:3855:ef7a:dffd:f9f5]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 23B0915210 for ; Sat, 24 Apr 2004 00:05:37 +0900 (JST) Date: Sat, 24 Apr 2004 00:05:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Re: [rfc2462bis] whether we need the M/O flags 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, 15 Apr 2004 20:40:14 +0900, >>>>> JINMEI Tatuya said: > As I just said in a separate message, one big question had been raised > about rfc2462bis. It was, in my understanding, > whether we need the M/O flags for the "stateful" protocol(s) in the > first place. > I know this is probably highly controversial, but I tend to agree on > removing (or deprecating) these bits. (Note: In this message, I'm basically speaking just as an individual in this list. I'll propose an action as a 2462bis editor after the entire discussion; it may or may not be same as what I'm going to say below) (Another note: this is a long message, sorry about it. But I hope all who are interested in this topic will read the entire message and comment it.) Thanks for all the input. Going through the thread so far, I've been thinking about this issue closer...and, I personally still have the same opinion. Some people commented that we needed to clarify what's bad with the M/O flags if we want to deprecate (or remove) them. That's a fair comment. My points are as follows (some of which have already been shown in the thread): - the lack of interoperable implementation (or the fact that there are very few implementations) regarding the flags, at the host side particularly, will probably be a barrier to recycle the document as a DS. From my honest impression on Section 4.1.2 of RFC2026, even 2462 should have not become a DS document. I've still not heard why they could make it at that time, so I know I may be wrong. - each flag can only convey information of a single-bit, causing several problems: + we'd need to specify a single protocol corresponding to each flag in order to avoid combination mess and interoperability problems. For the M flag, it's probably okay, because we seem to have agreed on the protocol is DHCPv6 (RFC3315). For the O flag, however, I'm not sure if the situation is mature enough. Stateless DHCPv6 (RFC3736) is likely to be a candidate (and I'd personally take it), but can we really agree on it? Aren't there other possibilities? For example, the full DHCPv6 protocol (RFC3315) can also work as the protocol for the O flag. Others may want to propose non DHCPv6 protocols like SLP...then, are we really sure we won't want to introduce flexibility by a separate mechanism allowing a particular protocol? + there is no way to turn off the use of "stateful" protocols. (Note that changing the flag from set to clear does not mean turning off the protocol) + if we adopt stateless DHCPv6 as the protocol for the O flag, we'll need a separate trick to handle renumbering events, e.g., as proposed in draft-vijay-ipv6-icmp-refresh-otherconf-00.txt. Of course, we'd probably be able to separate this as a future extension, but then why can't we reconsider the purpose of the O flag from the beginning? (If you're going to say "because it will break existing work", please see below first). Now let's think about cons of deprecating these flags. The obvious one is that this action may break existing implementations. In fact, this is the most typical objection I've seen in this thread. To discuss this point precisely, I'd fist like to talk about the host side. That is, implementations that A. invoke some "stateful" protocol on the reception of an RA with the M flag being set B. invoke some "stateful" protocol on the reception of an RA with the O flag being set As far as I know, there is no type-A implementation. And, as far as I know, there are only two type-B implementations: Cisco's host implementation, and the one implemented by KAME (that I myself wrote): both of them (can) invoke an RFC3736 client in this case. I don't know how Cisco would feel if the O flag were deprecated. Perhaps Ralph can comment on it. If they strongly want to keep this flag, of course it will be a strong reason to do so. Regarding KAME's implementation, at least the implementor (myself) is okay to deprecate the flags. Also, it's just an experimental implementation to identify issues, so this feature (invoking an RFC3736 client) is disabled by default in the implementation and is not officially released in the BSD community. In fact, I'm tempted to deprecate the flags based on my experiments with the implementation, identifying the issues described above. Of course, as someone said in the thread, this does not mean there are no implementors who have an implementation that would be broken by deprecating the flags and thus would complain about it. However, I'd respectfully say this argument is unfair, considering the scale of this mailing list and the number of participants in this particular thread. Actually, (at least) 7 people from different organizations have commented, and none of them could show concrete examples except the above two. In general, it is hard to prove the non-existence of something, and I think it's almost impossible in this kind of topic (you could always say "someone in an isolated island only with computers and RFCs might have implemented this feature" - no one can refute this argument). For me, the discussion so far indicates there is actually nothing broken by deprecating the flags in a practical sense (believe me, I'm trying to be fair in this sentence), as long as Cisco is okay for their host side implementation. Regarding the Cisco case, I'd like to hear from Ralph about his opinion. Meanwhile, please do not forget the original specification in RFC2462 was very unclear about these flags, which might break something if we want to clarify the behavior, even keeping the flags. For example, it even does not specify a particular protocol (at least not clearly) to be invoked by the flags. So, what if someone has a host side implementation that invokes a proprietary "stateful" protocol upon receiving the M flag and claims "my implementation perfectly working under RFC2462 will be broken if you specify DHCPv6 as the 'stateful' protocol". Can this be a reason for not making the specification clear on this? I hope not, and if we can agree on this point, then it seems to me that this discussion shows that the current specification is too unclear to worry about breaking "something" working so far with it. So far, I've discussed the host case. Let's move on to the router case. Yes, there are many router implementations that have the ability to set the M/O flags. However, as long as we can agree on deprecating the flags from hosts's point of view (as discussed so far), I believe we can still deprecate the flags without breaking implementations. In fact, setting these flags at the router has had no effects so far in a practical sense. So, nothing in the router implementations will be broken unless we reuse these bits for different purposes. Now, I've dumped what I have. Hopefully I've made several things clear. Still, I expect different opinions (actually, I still expect objections). So, please speak up. I'd particularly want to have a *concrete* counter example that will be broken with the deprecation (not just "*something* that might have been working well and will be broken"). Also, I'd really like to know if the lack of interoperable implementation can be an issue or not. I'm going to wear a hat of 2462bis editor, collecting opinions again, and would like to make a concrete proposal next week based on the result. 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 Apr 23 12:36: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 MAA18241 for ; Fri, 23 Apr 2004 12:36: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 1BH3bT-0003CS-FV for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:32:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NGWdDr012295 for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:32:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3YK-0001fU-Tm for ipv6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 12:29: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 MAA17564 for ; Fri, 23 Apr 2004 12:29: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 1BH3YJ-00071A-Eh for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 12:29:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3XE-0006Xr-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 12:28:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH3W0-00069Y-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 12:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Dh-000348-Fv; Fri, 23 Apr 2004 12:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH309-00074X-CT for ipv6@optimus.ietf.org; Fri, 23 Apr 2004 11:54: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 LAA16077 for ; Fri, 23 Apr 2004 11:54:02 -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 1BH308-00064L-6a for ipv6@ietf.org; Fri, 23 Apr 2004 11:54:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2zB-0005oF-00 for ipv6@ietf.org; Fri, 23 Apr 2004 11:53:05 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BH2yD-0005YQ-00 for ipv6@ietf.org; Fri, 23 Apr 2004 11:52:06 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NFpxB12105; Fri, 23 Apr 2004 18:51:59 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 18:51:46 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3NFpkvs017423; Fri, 23 Apr 2004 18:51:46 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 0018CBHQ; Fri, 23 Apr 2004 18:51:46 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NFpfs29676; Fri, 23 Apr 2004 18:51:41 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 18:51:45 +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-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [rfc2462bis] whether we need the M/O flags Date: Fri, 23 Apr 2004 18:51:44 +0300 Message-ID: Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQpR2UWxI3HqR36TkeQIAXAZejpwQAA0umQ To: , X-OriginalArrivalTime: 23 Apr 2004 15:51:45.0158 (UTC) FILETIME=[E0F35A60:01C4294A] 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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jinmei, > Now let's think about cons of deprecating these flags. > > The obvious one is that this action may break existing > implementations. In fact, this is the most typical objection I've > seen in this thread. I'd like to withdraw my original objection to this. I had a chance to discuss with the guys who implemented some IPv6 stacks internally & deprecating the flags won't break the implementations. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 23 15:32:36 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 PAA03107 for ; Fri, 23 Apr 2004 15:32: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 1BH6Ew-0003Fx-75 for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 15:21:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NJLYoi012509 for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 15:21:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH65w-0005QU-E8 for ipv6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 15:12: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 PAA01033 for ; Fri, 23 Apr 2004 15:12: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 1BH65v-0005OU-9O for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 15:12:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH62n-0004Zv-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 15:09:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH5zA-0003lr-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 15:05:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5lP-00067S-BV; Fri, 23 Apr 2004 14: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 1BH5IT-0001s9-RV for ipv6@optimus.ietf.org; Fri, 23 Apr 2004 14:21: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 OAA24843 for ; Fri, 23 Apr 2004 14:21: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 1BH5IR-0006N1-6z for ipv6@ietf.org; Fri, 23 Apr 2004 14:21:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5HT-00068F-00 for ipv6@ietf.org; Fri, 23 Apr 2004 14:20:07 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BH5GV-0005tS-00 for ipv6@ietf.org; Fri, 23 Apr 2004 14:19:07 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3NIJ7dc001728 for ; Fri, 23 Apr 2004 12:19:07 -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 <0HWM00IHCYVV9O@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Fri, 23 Apr 2004 12:19:07 -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 <0HWM003G7YVUL5@mail.sun.net> for ipv6@ietf.org; Fri, 23 Apr 2004 12:19:07 -0600 (MDT) Date: Fri, 23 Apr 2004 11:19:04 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Cc: ipv6@ietf.org 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: 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 agree with your analysis, except that I'm not so much worried about breaking somebody's assumption in designing an hypothetical client dealing with the O/M bits. The definition of those bits was obscure in 2462 anyway. I would be more worried if this was to result in demonstrated operational problems. I honestly believe that there won't be any as deprecating O & M will end up being equivalent to today's most common practice where those bits are not set. Nothing breaks today under those circumstances, so I do not see what should break tomorrow if we were to deprecate those 2 bits! Of course, if someone could point to a real case scenario where this would be a problem, that could change my opinion... - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 23 17:16:38 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 RAA12680 for ; Fri, 23 Apr 2004 17:16: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 1BH7rI-00077h-1L for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 17:05:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NL5FnH027372 for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 17:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7SX-00045h-2z for ipv6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 16:39: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 QAA09763 for ; Fri, 23 Apr 2004 16:39: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 1BH7SV-0001E6-0n for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 16:39:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7Rd-0000vZ-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 16:38:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BH7Qk-0000d4-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 16:37:50 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BH7Qk-0007t8-0i for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 16:37:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6dZ-00057U-EQ; Fri, 23 Apr 2004 15: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 1BH6Zf-0003R3-Sw for ipv6@optimus.ietf.org; Fri, 23 Apr 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 PAA04643 for ; Fri, 23 Apr 2004 15:42: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 1BH6Ze-0006wy-EM for ipv6@ietf.org; Fri, 23 Apr 2004 15:42:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6YH-0006YQ-00 for ipv6@ietf.org; Fri, 23 Apr 2004 15:41:34 -0400 Received: from mclean-vscan1.bah.com ([156.80.3.61]) by ietf-mx with esmtp (Exim 4.12) id 1BH6Vf-0005Ta-00 for ipv6@ietf.org; Fri, 23 Apr 2004 15:38:51 -0400 Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by mclean-vscan1.bah.com (8.11.0/8.11.0) with SMTP id i3NJcK724237 for ; Fri, 23 Apr 2004 15:38:20 -0400 (EDT) Received: from mclean6-mail.usae.bah.com ([156.80.5.102]) by mclean-vscan1.bah.com (NAVGW 2.5.2.12) with SMTP id M2004042315382007371 for ; Fri, 23 Apr 2004 15:38:20 -0400 Received: from XYZComputer3 ([198.253.78.125]) by mclean6-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HWN2JW00.5EJ; Fri, 23 Apr 2004 15:38:20 -0400 From: "Russell Brian" To: "Alain Durand" , =?US-ASCII?B?SklOTUVJIFRhdHV5YSAvID9fLT8nQj9B?= Cc: Subject: RE: [rfc2462bis] whether we need the M/O flags Date: Fri, 23 Apr 2004 12:38:08 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: 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, We have actually designed a large-scale system making use of the M flag as it was a large part of RFC 2462 and we were not aware that IETF would be considering deprecating it. Please take this into consideration in your discussions. Regards, Brian Russell Systems Engineer -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of Alain Durand Sent: Friday, April 23, 2004 11:19 AM To: JINMEI Tatuya / ?_-?'B?A Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] whether we need the M/O flags Jinmei, I agree with your analysis, except that I'm not so much worried about breaking somebody's assumption in designing an hypothetical client dealing with the O/M bits. The definition of those bits was obscure in 2462 anyway. I would be more worried if this was to result in demonstrated operational problems. I honestly believe that there won't be any as deprecating O & M will end up being equivalent to today's most common practice where those bits are not set. Nothing breaks today under those circumstances, so I do not see what should break tomorrow if we were to deprecate those 2 bits! Of course, if someone could point to a real case scenario where this would be a problem, that could change my opinion... - Alain. -------------------------------------------------------------------- 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 Apr 23 17:43: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 RAA15063 for ; Fri, 23 Apr 2004 17:43: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 1BH8FR-0000yH-2J for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 17:30:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NLUDR9003724 for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 17:30:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7v7-00026z-Kc for ipv6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 17:09: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 RAA12031 for ; Fri, 23 Apr 2004 17:09: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 1BH7v5-0001qN-Fm for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 17:09:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7ty-0001Sy-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 17:08:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH7sm-00014c-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 17:06:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7TH-0004eT-Dz; Fri, 23 Apr 2004 16:40:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6rh-0002rr-9F for ipv6@optimus.ietf.org; Fri, 23 Apr 2004 16:01: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 QAA05896 for ; Fri, 23 Apr 2004 16:01: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 1BH6rf-0004XA-Ld for ipv6@ietf.org; Fri, 23 Apr 2004 16:01:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6qp-0004EI-00 for ipv6@ietf.org; Fri, 23 Apr 2004 16:00:43 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1BH6px-0003uO-00 for ipv6@ietf.org; Fri, 23 Apr 2004 15:59:49 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3NJxnMu020479 for ; Fri, 23 Apr 2004 13:59:49 -0600 (MDT) Received: from fe8 (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 <0HWN00IE93JORD@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Fri, 23 Apr 2004 13:59:48 -0600 (MDT) Received: from [192.168.1.102] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HWN00CFO3JNE1@mail.sun.net> for ipv6@ietf.org; Fri, 23 Apr 2004 13:59:48 -0600 (MDT) Date: Fri, 23 Apr 2004 12:59:44 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: To: Russell Brian Cc: ipv6@ietf.org, "JINMEI Tatuya / ?_-?'B?A" 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: 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 Brian, Could you provide more details? Which host implementation are you using? - Alain. On Apr 23, 2004, at 12:38 PM, Russell Brian wrote: > Hello, > > We have actually designed a large-scale system making use of the M > flag as > it was a large part of RFC 2462 and we were not aware that IETF would > be > considering deprecating it. Please take this into consideration in > your > discussions. > > Regards, > > Brian Russell > Systems Engineer > > > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of > Alain > Durand > Sent: Friday, April 23, 2004 11:19 AM > To: JINMEI Tatuya / ?_-?'B?A > Cc: ipv6@ietf.org > Subject: Re: [rfc2462bis] whether we need the M/O flags > > > Jinmei, > > I agree with your analysis, except that I'm not so much worried about > breaking somebody's assumption in designing an hypothetical client > dealing with the O/M bits. The definition of those bits was obscure > in 2462 anyway. > I would be more worried if this was to result in demonstrated > operational > problems. I honestly believe that there won't be any as deprecating O & > M > will end up being equivalent to today's most common practice where > those bits are not set. Nothing breaks today under those circumstances, > so I do not see what should break tomorrow if we were to deprecate > those 2 bits! > > Of course, if someone could point to a real case scenario where > this would be a problem, that could change my opinion... > > - Alain. > > > -------------------------------------------------------------------- > 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 Apr 23 18:16:12 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 SAA17897 for ; Fri, 23 Apr 2004 18: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 1BH8pT-00014B-Q4 for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 18:07:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NM7R1k004093 for ipv6-archive@odin.ietf.org; Fri, 23 Apr 2004 18:07:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8d5-0002jK-O2 for ipv6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 17:54: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 RAA15905 for ; Fri, 23 Apr 2004 17:54: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 1BH8d3-0006KM-0v for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 17:54:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH8c2-00060g-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 17:53:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH8b0-0005iw-00 for ipv6-web-archive@ietf.org; Fri, 23 Apr 2004 17:52:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8NC-0004Wb-HH; Fri, 23 Apr 2004 17:38:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8Bg-0007lO-Cq for ipv6@optimus.ietf.org; Fri, 23 Apr 2004 17:26: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 RAA13975 for ; Fri, 23 Apr 2004 17:26: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 1BH8Bd-0006Hz-Ud for ipv6@ietf.org; Fri, 23 Apr 2004 17:26:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH8Ak-00063Y-00 for ipv6@ietf.org; Fri, 23 Apr 2004 17:25:23 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BH89u-0005nZ-00 for ipv6@ietf.org; Fri, 23 Apr 2004 17:24:30 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3NLOI1C008084; Fri, 23 Apr 2004 23:24:18 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: [rfc2462bis] whether we need the M/O flags Date: Fri, 23 Apr 2004 23:24:19 +0200 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= 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 On 23-apr-04, at 17:05, JINMEI Tatuya / $B?@L@C#:H(B wrote: > Some people commented that we needed to clarify what's bad with the > M/O flags if we want to deprecate (or remove) them. You only discuss "what would break if we deprecate these flags". I have no problems with the text that follows, but I DO have a very big problem with changing these flags. You can't just go around and change protocol specifications every few years just because it looks better that way. Besides, NOW is certainly not the time to do it, as DHCPv6 is finally there, but hasn't seen much if any real-life experience yet, and additional "other configuration" mechanisms are still under discussion for at least one very important configuration item: recursive DNS server addresses. I implore this wg to venture out into the real world and ask operators what they need to be able to use IPv6 rather than regurgitate the same RFCs over and over. This goes double for v6ops. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Apr 24 02:06: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 CAA17348 for ; Sat, 24 Apr 2004 02:06: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 1BHGHf-0001Wd-3b for ipv6-archive@odin.ietf.org; Sat, 24 Apr 2004 02:05:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O653rE005851 for ipv6-archive@odin.ietf.org; Sat, 24 Apr 2004 02:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHGAf-000521-P5 for ipv6-web-archive@optimus.ietf.org; Sat, 24 Apr 2004 01:57: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 BAA10492 for ; Sat, 24 Apr 2004 01:57: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 1BHGAc-0004ax-Jo for ipv6-web-archive@ietf.org; Sat, 24 Apr 2004 01:57:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHG9j-0004Ir-00 for ipv6-web-archive@ietf.org; Sat, 24 Apr 2004 01:56:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHG8h-00041n-00 for ipv6-web-archive@ietf.org; Sat, 24 Apr 2004 01:55:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHFvP-00019S-Hn; Sat, 24 Apr 2004 01:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHFsD-0000MH-5m for ipv6@optimus.ietf.org; Sat, 24 Apr 2004 01:38: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 BAA09897 for ; Sat, 24 Apr 2004 01:38: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 1BHFs9-0007YR-Vl for ipv6@ietf.org; Sat, 24 Apr 2004 01:38:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHFrN-0007IG-00 for ipv6@ietf.org; Sat, 24 Apr 2004 01:37:54 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BHFqY-0006uW-00 for ipv6@ietf.org; Sat, 24 Apr 2004 01:37:02 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 24 Apr 2004 01:36:29 -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] whether we need the M/O flags Date: Sat, 24 Apr 2004 01:36:29 -0400 Message-ID: Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQpRvD4yL0gP8lMSC+a/jBLtKrUcgAc1fNw From: "Soliman Hesham" To: "JINMEI Tatuya / ????" , X-OriginalArrivalTime: 24 Apr 2004 05:36:29.0772 (UTC) FILETIME=[181438C0:01C429BE] 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 As a general comment, IMHO we're wasting cycles on this discussion and I agree with Iljitsch's email on this.=20 Specific comments below > Some people commented that we needed to clarify what's bad with the > M/O flags if we want to deprecate (or remove) them. That's a fair > comment. My points are as follows (some of which have already been > shown in the thread): >=20 > - the lack of interoperable implementation (or the fact that=20 > there are > very few implementations) regarding the flags, at the host side > particularly, will probably be a barrier to recycle the document as > a DS. From my honest impression on Section 4.1.2 of RFC2026, even > 2462 should have not become a DS document. I've still not=20 > heard why > they could make it at that time, so I know I may be wrong. =3D> FWIW this is a valid point but not against the M/O flags. This is=20 a point of discussion about the process. It _is_ a DS now. We can discuss whether that's a mistake if we want to make it a PS.=20 I'm not sure what this achieves though. >=20 > - each flag can only convey information of a single-bit, causing > several problems: > + we'd need to specify a single protocol corresponding to each flag > in order to avoid combination mess and interoperability problems. > For the M flag, it's probably okay, because we seem to=20 > have agreed > on the protocol is DHCPv6 (RFC3315). For the O flag,=20 > however, I'm > not sure if the situation is mature enough. Stateless DHCPv6 > (RFC3736) is likely to be a candidate (and I'd personally take > it), but can we really agree on it? Aren't there other > possibilities? For example, the full DHCPv6 protocol (RFC3315) > can also work as the protocol for the O flag. Others may want to > propose non DHCPv6 protocols like SLP...then, are we really sure > we won't want to introduce flexibility by a separate mechanism > allowing a particular protocol? =3D> Sure there are other possibilites, but there is also plenty of=20 space for new options. So if there is a need for more space to indicate which protocols should be used and at some point in future there are no more flags, then a new option will do. >=20 > + there is no way to turn off the use of "stateful" protocols. > (Note that changing the flag from set to clear does not mean > turning off the protocol) =3D> How does this argue for removing the flags though? What would be=20 the new way of turning off "stateful" that cannot be done today with the flags? >=20 > + if we adopt stateless DHCPv6 as the protocol for the O=20 > flag, we'll > need a separate trick to handle renumbering events, e.g., as > proposed in draft-vijay-ipv6-icmp-refresh-otherconf-00.txt. Of > course, we'd probably be able to separate this as a future > extension, but then why can't we reconsider the purpose of the O > flag from the beginning? (If you're going to say "because it > will break existing work", please see below first). =3D> I don't understand how this is a "+". But anyway, it's not a big = issue. > The obvious one is that this action may break existing > implementations. In fact, this is the most typical objection I've > seen in this thread. >=20 > To discuss this point precisely, I'd fist like to talk about the host > side. That is, implementations that >=20 > A. invoke some "stateful" protocol on the reception of an=20 > RA with the > M flag being set > B. invoke some "stateful" protocol on the reception of an=20 > RA with the > O flag being set >=20 > As far as I know, there is no type-A implementation. And,=20 > as far as I > know, there are only two type-B implementations: Cisco's host > implementation, and the one implemented by KAME (that I=20 > myself wrote): > both of them (can) invoke an RFC3736 client in this case. >=20 > I don't know how Cisco would feel if the O flag were deprecated. > Perhaps Ralph can comment on it. If they strongly want to keep this > flag, of course it will be a strong reason to do so. >=20 > Regarding KAME's implementation, at least the implementor (myself) is > okay to deprecate the flags. Also, it's just an experimental > implementation to identify issues, so this feature (invoking an > RFC3736 client) is disabled by default in the implementation and is > not officially released in the BSD community. In fact, I'm=20 > tempted to > deprecate the flags based on my experiments with the implementation, > identifying the issues described above. >=20 > Of course, as someone said in the thread, this does not mean=20 > there are > no implementors who have an implementation that would be broken by > deprecating the flags and thus would complain about it. However, I'd > respectfully say this argument is unfair, considering the scale of > this mailing list and the number of participants in this particular > thread. Actually, (at least) 7 people from different organizations > have commented, and none of them could show concrete examples except > the above two. In general, it is hard to prove the non-existence of > something, and I think it's almost impossible in this kind of topic > (you could always say "someone in an isolated island only with > computers and RFCs might have implemented this feature" - no one can > refute this argument). =3D> A final comment on the above text and the whole issue: First of all, since the point of "existing implementations" has been = raised several times, I think the onus is on people who want to remove this feature to do a survey of all existing implementations and prove that=20 nothing will be affected. Of course it's very hard to do that but how = else do we make sure that we're not stuffing people around ? Is it enough to note that Cisco and KAME are happy to remove it? I don't think so. There are many other router, host, and embedded systems vendors that have their own implementations and I haven't heard anything=20 from them about this. =20 Second, given the above discussion, what is the bottom line, concrete=20 reason for doing this? It seems to me like "it's cleaner" or "it's = better this way". I can think of many more significant improvements to both RFCs, for example due to MIPv6 that the WG didn't want to solve because it was "too much" or "out of scope for this update". Given that, if we = try to use the same standards, then these changes are not needed and are definitely out of scope for this update. =20 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 Sat Apr 24 02:07:26 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 CAA18433 for ; Sat, 24 Apr 2004 02:07: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 1BHGHw-0001l5-Bv for ipv6-archive@odin.ietf.org; Sat, 24 Apr 2004 02:05:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O65KnP006753 for ipv6-archive@odin.ietf.org; Sat, 24 Apr 2004 02:05:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHGGX-0000Wv-5J for ipv6-web-archive@optimus.ietf.org; Sat, 24 Apr 2004 02:03: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 CAA14745 for ; Sat, 24 Apr 2004 02:03: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 1BHGGT-0006BR-ND for ipv6-web-archive@ietf.org; Sat, 24 Apr 2004 02:03:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHGFX-0005ux-00 for ipv6-web-archive@ietf.org; Sat, 24 Apr 2004 02:02:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHGEr-0005eg-00 for ipv6-web-archive@ietf.org; Sat, 24 Apr 2004 02:02:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHG8x-0004cF-PU; Sat, 24 Apr 2004 01:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHG1o-0002Mq-3a for ipv6@optimus.ietf.org; Sat, 24 Apr 2004 01:48: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 BAA10238 for ; Sat, 24 Apr 2004 01:48: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 1BHG1k-0002Kt-U0 for ipv6@ietf.org; Sat, 24 Apr 2004 01:48:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHG0p-00025R-00 for ipv6@ietf.org; Sat, 24 Apr 2004 01:47:39 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BHFzy-0001qO-00 for ipv6@ietf.org; Sat, 24 Apr 2004 01:46:47 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:3855:ef7a:dffd:f9f5]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C3BD815210; Sat, 24 Apr 2004 14:46:40 +0900 (JST) Date: Sat, 24 Apr 2004 14:46:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Iljitsch van Beijnum Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] whether we need the M/O flags In-Reply-To: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.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 Fri, 23 Apr 2004 23:24:19 +0200, >>>>> Iljitsch van Beijnum said: >> Some people commented that we needed to clarify what's bad with the >> M/O flags if we want to deprecate (or remove) them. > You only discuss "what would break if we deprecate these flags". I have > no problems with the text that follows, but I DO have a very big > problem with changing these flags. You can't just go around and change > protocol specifications every few years just because it looks better > that way. Sorry, I don't understand the comment...I still have a feeling that I see an attempt to impose a negative impression on a concrete proposal based on a practical analysis by making a general comment that no one can disagree. It's probably true that "you (we) can't just go around and change protocol specifications every few years just because it looks better," but how does this apply to my proposal? I tried to describe what is wrong with the current specification, tried to describe what can be broken by deprecating the flags, and tried to explain the breakage won't be a problem in a practical sense (at least IMO). If this discussion is convincing but still can be regarded as "just saying it looks better that way", can't we ever deprecate anything? For example, if we can buy this kind of argument, how could we deprecate site-local addresses? Also, what do you mean by "every few years" in this particular discussion? RFC2462 was published in 1998, and we are now trying to make the specification clearer, fixing known problems and clarifying the details based on 5-6 years of experience. Are you saying this activity as "changing protocol specifications every few years"? Honestly, I'm willing to withdraw the proposal if someone makes a concrete, convincing couter argument...but, yours seems too general, abstract, and unfair (sorry, I can't find a better word) to convince me on this particular topic. (But I don't think this paragraph is your main point, and if I'm correct, let's just focus on the rest of your message) > Besides, NOW is certainly not the time to do it, as DHCPv6 is finally > there, but hasn't seen much if any real-life experience yet, and > additional "other configuration" mechanisms are still under discussion > for at least one very important configuration item: recursive DNS > server addresses. So are you proposing to keep the flags but leave the semantics (e.g., what the "stateful" protocol is) unclear as currently is? If so, I disagree for two reasons. First, it will easily cause confusion and interoperability problems to leave it unclear. In fact, we have seen the confusion due to the unclear specification since RFC2462 (or even since RFC1970), and this is exactly the reason why we are now trying to clarify this point. Secondly, if the situation is that immature, why can't we simply deprecate the flags for now and leave the flexibility for future extension? This way, we can clearly avoid confusion due to the unclear specification and the misuse of the flags based on the confusion, as well as leave the possibility to adopt the best way as the situation becomes mature. We'll even be able to revive the same flags at that time. > I implore this wg to venture out into the real world and ask operators > what they need to be able to use IPv6 rather than regurgitate the same > RFCs over and over. This goes double for v6ops. A general comment, again...so what exactly are you proposing for this particular issue? Even though main subscribers in this list are implementors, I'm quite sure that we also have many operators here. In fact, I'm running IPv6 networks of my own. I also know operators working for major ISPs subscribe to this list. And I'm asking everyone in this list, including operators of course, on this issue. If you're requiring to bring this discussion to the v6ops wg and ask them what they think, that's fine. But I'm quite sure many vocal members there subscribe to this list as well. 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 Sat Apr 24 05:45:21 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 FAA04927 for ; Sat, 24 Apr 2004 05:45: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 1BHJhg-00088M-1y for ipv6-archive@odin.ietf.org; Sat, 24 Apr 2004 05:44:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O9i8Cw031261 for ipv6-archive@odin.ietf.org; Sat, 24 Apr 2004 05: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 1BHJcs-0006e5-15 for ipv6-web-archive@optimus.ietf.org; Sat, 24 Apr 2004 05:39: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 FAA04675 for ; Sat, 24 Apr 2004 05:39: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 1BHJco-00003g-Gt for ipv6-web-archive@ietf.org; Sat, 24 Apr 2004 05:39:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHJbc-0007bd-00 for ipv6-web-archive@ietf.org; Sat, 24 Apr 2004 05:37:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHJap-0007MY-00 for ipv6-web-archive@ietf.org; Sat, 24 Apr 2004 05:37:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHJU2-0003jk-BJ; Sat, 24 Apr 2004 05: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 1BHJPv-0002Lf-Mi for ipv6@optimus.ietf.org; Sat, 24 Apr 2004 05:25: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 FAA04241 for ; Sat, 24 Apr 2004 05: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 1BHJPs-0004Wa-ER for ipv6@ietf.org; Sat, 24 Apr 2004 05:25:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHJOu-0004FQ-00 for ipv6@ietf.org; Sat, 24 Apr 2004 05:24:45 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BHJNz-0003tQ-00 for ipv6@ietf.org; Sat, 24 Apr 2004 05:23:47 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3O9Nc1C018952; Sat, 24 Apr 2004 11:23:38 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: [rfc2462bis] whether we need the M/O flags Date: Sat, 24 Apr 2004 11:23:39 +0200 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= 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 On 24-apr-04, at 7:46, JINMEI Tatuya / $B?@L@C#:H(B wrote: >> You only discuss "what would break if we deprecate these flags". I >> have >> no problems with the text that follows, but I DO have a very big >> problem with changing these flags. You can't just go around and change >> protocol specifications every few years just because it looks better >> that way. > Sorry, I don't understand the comment...I still have a feeling that I > see an attempt to impose a negative impression on a concrete proposal > based on a practical analysis by making a general comment that no one > can disagree. I apologize for the negativity. However, when I first got involved with the IETF not all that long ago, I was shocked to learn how much work is (still) going on on so many aspects of IPv6. I have since then learned that a good deal of this work is very necessary, but I still also believe that a lot of it isn't. The very first question I ask myself whenever I read an a draft or a proposal that changes something is: "what would go horribly wrong without this change?" If the answer is "nothing" this means we should probably not make the change, since even the slightest change introduces very real costs with regard to modifying code, testing and training. Remember that nothing ever dies on the web. There are still people who think the flow label is 24 bits because the documents that say this is are still online and indexed by Google. > It's probably true that "you (we) can't just go around and change > protocol specifications every few years just because it looks better," > but how does this apply to my proposal? Your text makes a good case that there won't be any implementation problems by removing the bits. However, you don't really explain why it is a good idea to do so. (Or I must have overlooked it.) > If this discussion is convincing but still can be > regarded as "just saying it looks better that way", can't we ever > deprecate anything? For example, if we can buy this kind of argument, > how could we deprecate site-local addresses? This is different, as we've determined that there are serious problems with the use of site locals. But how about the change from ip6.int to ip6.arpa. I wasn't there when this was decided, but whatever the rationale, I have a very hard time believing it was worth the confusion and operational problems that were caused. >> Besides, NOW is certainly not the time to do it, as DHCPv6 is finally >> there, but hasn't seen much if any real-life experience yet, and >> additional "other configuration" mechanisms are still under discussion >> for at least one very important configuration item: recursive DNS >> server addresses. > So are you proposing to keep the flags but leave the semantics (e.g., > what the "stateful" protocol is) unclear as currently is? If so, I > disagree for two reasons. > First, it will easily cause confusion and interoperability problems to > leave it unclear. In fact, we have seen the confusion due to the > unclear specification since RFC2462 (or even since RFC1970), and this > is exactly the reason why we are now trying to clarify this point. Can you elaborate? I agree that some confusion is possible, but since there are many interoperable implementations, I don't see how this can lead to real-world problems. > Secondly, if the situation is that immature, why can't we simply > deprecate the flags for now and leave the flexibility for future > extension? Good question. I believe that some information in RAs that guides the discovery and configuration process is probably necessary in the future. We have these two bits now. Suppose we remove them from the spec, and then in a few years we really know what we need and introduce a new, better mechanism. This gives us nine combinations of implementations to worry about: hosts according to RFC 2462, 2462bis and 2462ter on the one hand, and routes according to RFC 2462, 2462bis and 2462ter on the other hand. Worse, we probably have to support at least coexistance of hosts with different implementations on the same link at the same time for a significant number of years. Now consider the situation where we don't change the bits right now but they are changed at some point in the future. This only gives us four combinations to worry about: old host + old router, old host + new router, new host + old router and new host + new router. That's less than half the combinations. Also, if we are to change the bits, new implementations would still have to recognize them to be backward compatible so the change doesn't make any difference to code that is cut any time soon. Now lets focus our attention on what we want to accomplish operationally. In theory, the bits aren't necessary as we can simply always do RA and DHCP and see which one succeeds. The network operator can then decide to either turn on RAs, turn on DHCP or do both. However, there are two problems with this: - For other configuration, waiting for a DHCP reply that isn't forthcoming wastes time. Having the O flag mean "don't bother with stateful other configuration as it isn't going to succeed anyway" would be beneficial here. (For instance, if a host needs to look up a name and any statically configured DNS resolvers (well known or otherwise) may or may not be reachable, and a DHCP server may or may not be available. So if the host does the DNS request using the statically configured DNS it may incur a timeout, but if it first tries to configure DNS resolvers through DHCP it may also incur a timeout. The O flag can provide guidance in this case.) - A network operator may prefer that hosts use DHCP for address configuration. However, turning off RAs is probably infeasible because there may be hosts that don't support DHCP. So if we take the M flag to mean "don't do stateless autoconfiguration unless stateful configuration fails" the operator gets to support hosts that don't support DHCP while at the same time avoiding that hosts that do support it use RA-based addresses. In other words: M = 0, O = 0: Do stateless address configuration and start to communicate. If DHCP is done, it's in the background. DHCP complements static and RA other configuration. M = 0, O = 1: Do stateless address configuration and complete DHCP before initiating communication that requires other configuration. DHCP overwrites static and RA other configuration. M = 1, O = 0: Do DHCP. If DHCP succeeds, don't do stateless address configuration. Start to communicate after DHCP succeeds or after DHCP fails and stateless address configuration succeeds. Static and RA other configuration complement DHCP. M = 1, O = 1: Do DHCP. If DHCP succeeds, don't do stateless address configuration. Start to communicate after DHCP succeeds or after DHCP fails and stateless address configuration succeeds. DHCP overwrites static and RA other configuration. Where "complements" means that information is added to other configuration information, but with a lower priority. For instance, if with M = 0, O = 0 resolv.conf has the address 192.0.2.1 and DHCP supplies 240.240.240.240, the list becomes "192.0.2.1, 240.240.240.240" in that order. "Overwrites" means that old information is replaced when the other protocol supplies information of the same type. So if 192.0.2.1 is present and the new information is 240.240.240.240 the result is just "240.240.240.240". However, if no replacement DNS resolvers were supplied 192.0.2.1 would continue to be used. (RA other configuration listed for completeness.) I don't have a problem with the fact that DHCPv6 isn't explicitly made the stateful protocol that the existing RFCs talk about. It should be the default one, but some networks may prefer to use something other than DHCP for this. I'm just saying "DHCP" above to save myself some typing. > This way, we can clearly avoid confusion due to the > unclear specification and the misuse of the flags based on the > confusion, I agree that the current specs aren't as clear as they could (and possibly should) be. But I think it's better to leave the bits as they are and describe what they do or should do more clearly than removing them. >> I implore this wg to venture out into the real world and ask operators >> what they need to be able to use IPv6 rather than regurgitate the same >> RFCs over and over. This goes double for v6ops. > A general comment, again...so what exactly are you proposing for this > particular issue? Even though main subscribers in this list are > implementors, I'm quite sure that we also have many operators here. > In fact, I'm running IPv6 networks of my own. I also know operators > working for major ISPs subscribe to this list. If you compare the various IPv6-related lists (this one, v6ops and even dnsops) with interdomain routing related ones such as grow and even idr, it is apparent that most of the focus with IPv6 is on building specifications based on theoretical considerations. I see very little operational feedback. This is especially apparent with regard to the DNS configuration issue. > If you're requiring to bring this discussion to the v6ops wg and ask > them what they think, that's fine. No, I don't think that will make a difference. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Apr 25 00:33: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 AAA24203 for ; Sun, 25 Apr 2004 00:33: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 1BHbGe-0004fL-3X for ipv6-archive@odin.ietf.org; Sun, 25 Apr 2004 00:29:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3P4TOlc017931 for ipv6-archive@odin.ietf.org; Sun, 25 Apr 2004 00:29:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHbB1-00030A-VJ for ipv6-web-archive@optimus.ietf.org; Sun, 25 Apr 2004 00: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 AAA23867 for ; Sun, 25 Apr 2004 00: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 1BHbAz-0002UX-IO for ipv6-web-archive@ietf.org; Sun, 25 Apr 2004 00:23:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHbA1-0002GJ-00 for ipv6-web-archive@ietf.org; Sun, 25 Apr 2004 00:22:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHb97-00022M-00 for ipv6-web-archive@ietf.org; Sun, 25 Apr 2004 00:21:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHb2m-0008BH-F9; Sun, 25 Apr 2004 00:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHarp-0003tg-W8 for ipv6@optimus.ietf.org; Sun, 25 Apr 2004 00:03: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 AAA23230 for ; Sun, 25 Apr 2004 00:03: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 1BHarn-0005bS-4j for ipv6@ietf.org; Sun, 25 Apr 2004 00:03:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHaqq-0005MD-00 for ipv6@ietf.org; Sun, 25 Apr 2004 00:02:45 -0400 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1BHapC-0004im-00 for ipv6@ietf.org; Sun, 25 Apr 2004 00:01:02 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 2E5CE25A for ; Sun, 25 Apr 2004 00:00:28 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 25 Apr 2004 00:00:28 -0400 Message-Id: <20040425040028.2E5CE25A@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 --------+------+--------+----------+------------------------ 20.69% | 6 | 18.63% | 37590 | jinmei@isl.rdc.toshiba.co.jp 13.79% | 4 | 16.16% | 32615 | lanapoli@us.ibm.com 13.79% | 4 | 9.13% | 18422 | alain.durand@sun.com 6.90% | 2 | 10.37% | 20920 | sharma.tarun@wipro.com 6.90% | 2 | 8.22% | 16594 | iljitsch@muada.com 3.45% | 1 | 5.16% | 10404 | jim.bound@hp.com 3.45% | 1 | 5.11% | 10310 | h.soliman@flarion.com 3.45% | 1 | 4.55% | 9175 | rbrabson@us.ibm.com 3.45% | 1 | 4.47% | 9023 | soohong.park@samsung.com 3.45% | 1 | 3.37% | 6808 | narten@us.ibm.com 3.45% | 1 | 3.26% | 6575 | brc@zurich.ibm.com 3.45% | 1 | 2.50% | 5048 | russell_brian@bah.com 3.45% | 1 | 2.40% | 4850 | tarun.kumar@alcatel.be 3.45% | 1 | 2.38% | 4807 | sra+ipng@hactrn.net 3.45% | 1 | 2.19% | 4419 | suresh.krishnan@ericsson.ca 3.45% | 1 | 2.10% | 4234 | john.loughney@nokia.com --------+------+--------+----------+------------------------ 100.00% | 29 |100.00% | 201794 | 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 Apr 25 01:35: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 BAA27147 for ; Sun, 25 Apr 2004 01:35: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 1BHcH9-0000Ip-Bn for ipv6-archive@odin.ietf.org; Sun, 25 Apr 2004 01:34:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3P5Xxa6001156 for ipv6-archive@odin.ietf.org; Sun, 25 Apr 2004 01:33:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHcA9-0006hR-2b for ipv6-web-archive@optimus.ietf.org; Sun, 25 Apr 2004 01:26: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 BAA26838 for ; Sun, 25 Apr 2004 01:26: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 1BHcA6-00028b-2o for ipv6-web-archive@ietf.org; Sun, 25 Apr 2004 01:26:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHc92-0001qm-00 for ipv6-web-archive@ietf.org; Sun, 25 Apr 2004 01:25:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHc7x-0001Q7-00 for ipv6-web-archive@ietf.org; Sun, 25 Apr 2004 01:24:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHbyo-0002sH-He; Sun, 25 Apr 2004 01:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHbuh-0001yf-RO for ipv6@optimus.ietf.org; Sun, 25 Apr 2004 01: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 BAA26430 for ; Sun, 25 Apr 2004 01:10: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 1BHbue-00069g-Ur for ipv6@ietf.org; Sun, 25 Apr 2004 01:10:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHbti-0005vi-00 for ipv6@ietf.org; Sun, 25 Apr 2004 01:09:47 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BHbsy-0005XA-00 for ipv6@ietf.org; Sun, 25 Apr 2004 01:09:00 -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); Sat, 24 Apr 2004 22:07:46 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 24 Apr 2004 22:08:30 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 24 Apr 2004 22:08:43 -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); Sat, 24 Apr 2004 22:08:31 -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); Sat, 24 Apr 2004 22:08:24 -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] whether we need the M/O flags Date: Sat, 24 Apr 2004 22:08:28 -0700 Message-ID: Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQpwUpkTYvmE4UlTzKzc+ILxR6mlgAwZJpA From: "Christian Huitema" To: =?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 25 Apr 2004 05:08:25.0073 (UTC) FILETIME=[56554E10:01C42A83] 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 > >> Some people commented that we needed to clarify what's bad with the > >> M/O flags if we want to deprecate (or remove) them. The normal IETF practice is that when a document progresses from PS do DS and then to standard, parts of the specification that are not actually present in implementations get removed from the spec. As much as I can tell, we don't have much actual implementation of the M/O bits. If we follow the logic of the process, we should remove the corresponding sections from the spec. -- 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 Sun Apr 25 01:58: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 BAA28391 for ; Sun, 25 Apr 2004 01:58: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 1BHccu-0007KW-1e for ipv6-archive@odin.ietf.org; Sun, 25 Apr 2004 01:56:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3P5uSNE028171 for ipv6-archive@odin.ietf.org; Sun, 25 Apr 2004 01:56:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHcZJ-0006XR-0Q for ipv6-web-archive@optimus.ietf.org; Sun, 25 Apr 2004 01: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 BAA28146 for ; Sun, 25 Apr 2004 01:52: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 1BHcZF-0000oO-Q1 for ipv6-web-archive@ietf.org; Sun, 25 Apr 2004 01:52:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHcYM-0000aU-00 for ipv6-web-archive@ietf.org; Sun, 25 Apr 2004 01:51:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHcXu-0000M4-00 for ipv6-web-archive@ietf.org; Sun, 25 Apr 2004 01:51:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHcRs-0003qC-Gx; Sun, 25 Apr 2004 01:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHcNf-0002Pe-Hb for ipv6@optimus.ietf.org; Sun, 25 Apr 2004 01:40: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 BAA27427 for ; Sun, 25 Apr 2004 01:40: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 1BHcNc-0005Uj-C4 for ipv6@ietf.org; Sun, 25 Apr 2004 01:40:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHcMs-0005H3-00 for ipv6@ietf.org; Sun, 25 Apr 2004 01:39:54 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BHcM6-00051k-00 for ipv6@ietf.org; Sun, 25 Apr 2004 01:39:07 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:fc4e:9796:c94:68ac]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BE89B15210; Sun, 25 Apr 2004 14:39:04 +0900 (JST) Date: Sun, 25 Apr 2004 14:39:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Christian Huitema" Cc: Subject: Re: [rfc2462bis] whether we need the M/O flags 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 Sat, 24 Apr 2004 22:08:28 -0700, >>>>> "Christian Huitema" said: >> >> Some people commented that we needed to clarify what's bad with the >> >> M/O flags if we want to deprecate (or remove) them. (folding a long line) > The normal IETF practice is that when a document progresses from PS > do DS and then to standard, parts of the specification that are not > actually present in implementations get removed from the spec. As > much as I can tell, we don't have much actual implementation of the > M/O bits. If we follow the logic of the process, we should remove > the corresponding sections from the spec. Wearing 2462bis editor's hat, I'd really like to know what we should do with this, process wise (i.e. whether I prefer or not prefer to deprecate the M/O flags in a technical sense). We first need to know if we really do not have much actual implementation of these flags (particularly at the host side), but it's quite likely the case (again, trying to be fair as a 2462bis editor). Then, where can I ask the correct behavior, process-wise? Working group chairs? Internet area directors? 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 Apr 26 04:51: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 EAA04521 for ; Mon, 26 Apr 2004 04:51: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 1BI1nD-0002B6-At for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 04:48:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q8mlYE008366 for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 04:48:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1jO-00016T-Fd for ipv6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 04:44: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 EAA04011 for ; Mon, 26 Apr 2004 04:44: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 1BI1jL-000021-GI for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 04:44:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1iQ-0007d0-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 04:43:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI1ht-0007RM-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 04:43:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1Yx-0005y6-GG; Mon, 26 Apr 2004 04:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1V4-0004ty-RB for ipv6@optimus.ietf.org; Mon, 26 Apr 2004 04:30: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 EAA02745 for ; Mon, 26 Apr 2004 04:29: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 1BI1V1-0004QR-Lv for ipv6@ietf.org; Mon, 26 Apr 2004 04:29:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1U3-0004Cx-00 for ipv6@ietf.org; Mon, 26 Apr 2004 04:29: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 1BI1Tc-0003zg-00 for ipv6@ietf.org; Mon, 26 Apr 2004 04:28:32 -0400 Received: from kummerog.uni-muenster.de (kummerog.ipv6.uni-muenster.de [IPv6:2001:638:500:200:210:5aff:fe4c:cfd1]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.11/8.12.9) with ESMTP id i3Q8SLvg026296 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 26 Apr 2004 10:28:27 +0200 (CEST) Subject: Re: [rfc2462bis] whether we need 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; charset=iso-8859-15 Organization: JOIN-Team, WWU-Muenster Message-Id: <1082968095.27019.34.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 26 Apr 2004 10:28:16 +0200 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ovaron.join.uni-muenster.de id i3Q8SLvg026296 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 > (Note: In this message, I'm basically speaking just as an individual > in this list. I'll propose an action as a 2462bis editor after the > entire discussion; it may or may not be same as what I'm going to say > below) I think your approach to look at the two sides of the medal is very useful, but I don't find either argument (pro & con) very convincing at this particular point of time. However, what I can clearly read from the discussion is that the definition of the use / function of the M/O bits needs an update. Including a reference to existing protocols would be useful to explain the use of the flags, for example. I would like to remind you that for example many DHCPv6 implementations are quite young and still need to evolve in terms of functionality (that includes the use of M/O bits). It would be great if we could postpone the discussion to a later time when we can actually see if those implementation can make use of the M/O bits in a way that makes sense. As the development of the implementation progresses, I'm sure that the number of scenarios where M/O bits are useful will increase. Baseline is, it would be good to postpone the deprecation discussion and at the same time update the definition of the use of the M/O bits. I can think of scenarios where M/O is useful but the mental picture of these is not clear enough yet to really make a point. Deciding upon deprecation or not would be premature at this point of time, IMHO. Cheers, Christian=20 --=20 JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westf=E4lische Wilhelms-Universit=E4t M=FC= nster http://www.join.uni-muenster.de Zentrum f=FCr Informationsverarbeitung Team: join@uni-muenster.de R=F6ntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 M=FCnster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31= 653 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Apr 26 13:12:12 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 NAA03530 for ; Mon, 26 Apr 2004 13:12: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 1BI9Xf-0008Ez-TM for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 13:05:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QH5FRI031672 for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 13:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9Pw-0005Lz-RH for ipv6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 12:57: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 MAA02405 for ; Mon, 26 Apr 2004 12:57: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 1BI9Pv-0005VG-1b for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 12:57:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9Os-0005Mh-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 12:56:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI9Ns-0005G0-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 12:55:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI99J-0000Xd-FE; Mon, 26 Apr 2004 12:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI91V-0005Kf-Lt for ipv6@optimus.ietf.org; Mon, 26 Apr 2004 12:32: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 MAA00920 for ; Mon, 26 Apr 2004 12:31: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 1BI91U-0003SY-0J for ipv6@ietf.org; Mon, 26 Apr 2004 12:32:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI90c-0003Ps-00 for ipv6@ietf.org; Mon, 26 Apr 2004 12:31:07 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BI8zt-0003Js-00 for ipv6@ietf.org; Mon, 26 Apr 2004 12:30:22 -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); Mon, 26 Apr 2004 09:29:30 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Apr 2004 09:29:50 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Apr 2004 09:29:43 -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); Mon, 26 Apr 2004 09:29:40 -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, 26 Apr 2004 09:29:49 -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] whether we need the M/O flags Date: Mon, 26 Apr 2004 09:29:51 -0700 Message-ID: Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQrac+ZL6Jg1HsKRKa2HHwSaOrPOQAQWSMQ From: "Christian Huitema" To: "Christian Strauf \(JOIN\)" , =?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Cc: X-OriginalArrivalTime: 26 Apr 2004 16:29:49.0718 (UTC) FILETIME=[B1E4CB60:01C42BAB] 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 > Baseline is, it would be good to postpone the deprecation discussion and > at the same time update the definition of the use of the M/O bits. I can > think of scenarios where M/O is useful but the mental picture of these > is not clear enough yet to really make a point. Deciding upon > deprecation or not would be premature at this point of time, IMHO. I am sorry, but I draw the opposite conclusion. The progression along the standard track is supposed to reflect implementation experience (DS) and wide interoperability (IS). As you mention in your mail, implementers have barely started implementing the M/O bit, if at all. As such, the M/O part of the spec does not have the level of maturity required for a full standard, and just does not belong in 2462bis. The proper procedure would be to remove it from 2642bis, and to progress it if needed in a separate effort. -- 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 Apr 26 14:04:27 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 OAA06211 for ; Mon, 26 Apr 2004 14:04: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 1BIAD6-00058b-Uv for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 13:48:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QHm40h019748 for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 13:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIA82-0000gW-34 for ipv6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 13:42: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 NAA05030 for ; Mon, 26 Apr 2004 13:42: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 1BIA7z-00016k-VP for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 13:42:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIA72-0000xP-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 13:41:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIA5q-0000og-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 13:40:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9rm-0006YJ-H6; Mon, 26 Apr 2004 13: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 1BI9i6-0003HK-6m for ipv6@optimus.ietf.org; Mon, 26 Apr 2004 13:16: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 NAA03654 for ; Mon, 26 Apr 2004 13:15: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 1BI9i4-00074b-2r for ipv6@ietf.org; Mon, 26 Apr 2004 13:16:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9h5-000714-00 for ipv6@ietf.org; Mon, 26 Apr 2004 13:15:00 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1BI9gC-0006ym-00 for ipv6@ietf.org; Mon, 26 Apr 2004 13:14:04 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3QHE3Mu007621 for ; Mon, 26 Apr 2004 11:14:03 -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 <0HWS00DHMFVELM@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 26 Apr 2004 11:14:03 -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 <0HWS00KTLFVD3N@mail.sun.net> for ipv6@ietf.org; Mon, 26 Apr 2004 11:14:02 -0600 (MDT) Date: Mon, 26 Apr 2004 10:14:02 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: <1082968095.27019.34.camel@kummerog.uni-muenster.de> To: IETF IPv6 Mailing List , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Message-id: <1D60A11E-97A5-11D8-A69D-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: <1082968095.27019.34.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 Let me try to explain why I, as an implementor, do not like the M/O bits very much. It is not that DHCPv6 cannot be made secure, it is that the M/O bits are an automatic and insecure way to trigger an external configuration mechanism. The are security implication for the hosts in implementing those bits. They are received in RA, which are mostly insecure (anyone can send a "valid" RA) The current text says a host should turn stateful autoconf when receiving those bits. So one could mount an attack fairly easily by introducing a rogue DHCPv6 server on a network that had no DHCPv6 so far and send a fake RA with the M/O bits on. The host will then configure itself using data coming from the new rogue DHCPv6 server. 2462 says "host should invoke the stateful address autoconfiguration protocol" and not "MUST invoke", so there are already provision for not obeying the M/O bits. But if those bits are not mandatory to execute, why are they here in the first place? To give a hint that DHCPv6 is present? Host should not blindly believe this unless the RA are secured. Also, there are no such bits in IPv4, and host implementations that chose to turn DHCPv4 on simply try it. Why is is not good for IPv6? - 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 Apr 26 17:42:21 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 RAA25809 for ; Mon, 26 Apr 2004 17:42: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 1BIDZK-00011y-K3 for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 17:23:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLNEEK003958 for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 17:23:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDMp-0005pN-3L for ipv6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:10: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 RAA23236 for ; Mon, 26 Apr 2004 17:10: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 1BIDMn-00049I-0J for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 17:10:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDLE-0003xG-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 17:08:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDJT-0003d0-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 17:06:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDBD-0001hH-St; Mon, 26 Apr 2004 16: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 1BICxP-0005i4-Ij for ipv6@optimus.ietf.org; Mon, 26 Apr 2004 16:44: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 QAA17615 for ; Mon, 26 Apr 2004 16:44: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 1BICxN-0007MY-Fc for ipv6@ietf.org; Mon, 26 Apr 2004 16:44:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICm5-0005NE-00 for ipv6@ietf.org; Mon, 26 Apr 2004 16:32:22 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BICR7-0004RB-00 for ipv6@ietf.org; Mon, 26 Apr 2004 16:10:41 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3QKAP1C073251; Mon, 26 Apr 2004 22:10:25 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1D60A11E-97A5-11D8-A69D-00039376A6AA@sun.com> References: <1082968095.27019.34.camel@kummerog.uni-muenster.de> <1D60A11E-97A5-11D8-A69D-00039376A6AA@sun.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List From: Iljitsch van Beijnum Subject: Re: [rfc2462bis] whether we need the M/O flags Date: Mon, 26 Apr 2004 22:10:27 +0200 To: Alain Durand 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 On 26-apr-04, at 19:14, Alain Durand wrote: > Let me try to explain why I, as an implementor, do not like the M/O > bits very much. > It is not that DHCPv6 cannot be made secure, it is that the M/O bits > are > an automatic and insecure way to trigger an external configuration > mechanism. So you object to the security level of DHCPv6 rather than that of the M and O bits? > So one could mount an attack fairly easily by introducing a rogue > DHCPv6 > server on a network that had no DHCPv6 so far and send a fake RA with > the M/O bits on. The host will then configure itself using data coming > from the new rogue DHCPv6 server. So what is the alternative? If there are no M and O bits, people implementing DHCPv6 will have to perform DHCP *always* so there is no protection against a rogue DHCPv6 server over the situation you describe. If you want people to enable DHCPv6 manually: ok, no problem. But why would the M and O bits be in the way in that case? Just ignore them. > 2462 says "host should invoke the stateful address autoconfiguration > protocol" > and not "MUST invoke", so there are already provision for not obeying > the M/O bits. But if those bits are not mandatory to execute, why are > they here in the first place? Maybe because the IETF has no business to tell people in which way they should run their network, but only to provide them guidance on how a certain task can be performed in an interoperable way IF and WHEN the operator decides they want this task to be performed in the first place. > To give a hint that DHCPv6 is present? Don't you consider this useful? > Host should not blindly believe this unless the RA are secured. So what kind of bad stuff is going to happen when hosts start querying a rogue DHCPv6 server? I think the main problem is that traffic can be redirected through a rogue router which then has the opportunity to perform man in the middle attacks. However, the rogue system can just as easily perform the same thing using just RAs. > Also, there are no such bits in IPv4, and host implementations that > chose to turn DHCPv4 on simply try it. Why is is not good for IPv6? The difference is that in IPv4 you have the choice between manual configuration and DHCP, so absense of the former implies that the latter must be used. There is no such dichotomy in IPv6: absense of manual address configuration doesn't mean DHCPv6 should be used. IPv6 hosts have enjoyed the benefits of stateless address configuration for years and it's very likely that huge numbers of people running IPv6 networks will never want to run DHCPv6. So requiring hosts to always try DHCPv6 doesn't make any sense. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Apr 26 17:59:36 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 RAA26914 for ; Mon, 26 Apr 2004 17:59: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 1BIDuv-0006Nj-R3 for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 17:45:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLjXbT024527 for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 17:45:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDl9-0003Xh-N5 for ipv6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:35: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 RAA25548 for ; Mon, 26 Apr 2004 17:35: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 1BIDl7-0006bj-9J for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 17:35:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDkT-0006YM-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 17:34:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDjZ-0006TI-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 17:33:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDYk-0000s6-Sz; Mon, 26 Apr 2004 17:22:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDIG-0004ES-DC for ipv6@optimus.ietf.org; Mon, 26 Apr 2004 17:05: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 RAA22358 for ; Mon, 26 Apr 2004 17:05: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 1BIDIE-0003RA-3t for ipv6@ietf.org; Mon, 26 Apr 2004 17:05:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDDW-0002ae-00 for ipv6@ietf.org; Mon, 26 Apr 2004 17:00:43 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BID6j-0001O2-00 for ipv6@ietf.org; Mon, 26 Apr 2004 16:53:42 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3QKrfdc027463 for ; Mon, 26 Apr 2004 14:53:41 -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 <0HWS00DUXQ1GLP@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 26 Apr 2004 14:53:41 -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 <0HWS003ERQ1FL2@mail.sun.net> for ipv6@ietf.org; Mon, 26 Apr 2004 14:53:40 -0600 (MDT) Date: Mon, 26 Apr 2004 13:53:37 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: To: Iljitsch van Beijnum 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: <1082968095.27019.34.camel@kummerog.uni-muenster.de> <1D60A11E-97A5-11D8-A69D-00039376A6AA@sun.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 Apr 26, 2004, at 1:10 PM, Iljitsch van Beijnum wrote: > On 26-apr-04, at 19:14, Alain Durand wrote: > >> Let me try to explain why I, as an implementor, do not like the M/O >> bits very much. > >> It is not that DHCPv6 cannot be made secure, it is that the M/O bits >> are >> an automatic and insecure way to trigger an external configuration >> mechanism. > > So you object to the security level of DHCPv6 rather than that of the > M and O bits? You should read what I just said above before commenting too quickly. I have nothing against DHCPv6, but against insecure commands that trigger a configuration mechanism, any configuration mechanisms. >> So one could mount an attack fairly easily by introducing a rogue >> DHCPv6 >> server on a network that had no DHCPv6 so far and send a fake RA with >> the M/O bits on. The host will then configure itself using data coming >> from the new rogue DHCPv6 server. > > So what is the alternative? If there are no M and O bits, people > implementing DHCPv6 will have to perform DHCP *always* so there is no > protection against a rogue DHCPv6 server over the situation you > describe. Again you commented without reading what I wrote. People who run DHCPv4 on the client side decide to do so, it is not that DHCPv4 client is triggered by a remote mechanism. I never said that if you implement DHCPv6 you MUST always turn it on. This is a decision that has to be made by the person configuring the host. > If you want people to enable DHCPv6 manually: ok, no problem. But why > would the M and O bits be in the way in that case? Just ignore them. Because the specs says I should (lower case) obey M & O. Read what I wrote. >> 2462 says "host should invoke the stateful address autoconfiguration >> protocol" >> and not "MUST invoke", so there are already provision for not obeying >> the M/O bits. But if those bits are not mandatory to execute, why are >> they here in the first place? > > Maybe because the IETF has no business to tell people in which way > they should run their network, but only to provide them guidance on > how a certain task can be performed in an interoperable way IF and > WHEN the operator decides they want this task to be performed in the > first place. This is a general statement that nobody can disagree with but has no relevance to the discussion. Sorry. >> To give a hint that DHCPv6 is present? > > Don't you consider this useful? Ah, this is a very good question, actually, at the core of the discussion. Thank you for asking it. I'm not sure this is useful. You seem to think it is. Please tell me which problem it solves. >> Host should not blindly believe this unless the RA are secured. > > So what kind of bad stuff is going to happen when hosts start querying > a rogue DHCPv6 server? I think the main problem is that traffic can be > redirected through a rogue router which then has the opportunity to > perform man in the middle attacks. However, the rogue system can just > as easily perform the same thing using just RAs. Not only that. A host might have been previously configured with the address of a DNS server. There is a risk that the O bit will trigger a query to find out the DNS server, and a corrupt entry will either override or complement the correct one. This way the attacker could redirect part or all of my web traffic wherever he wants without having to mess with the routers. Of course DNSsec will help, but it is not there yet. >> Also, there are no such bits in IPv4, and host implementations that >> chose to turn DHCPv4 on simply try it. Why is is not good for IPv6? > > The difference is that in IPv4 you have the choice between manual > configuration and DHCP, so absense of the former implies that the > latter must be used. There is no such dichotomy in IPv6: absense of > manual address configuration doesn't mean DHCPv6 should be used. IPv6 > hosts have enjoyed the benefits of stateless address configuration for > years and it's very likely that huge numbers of people running IPv6 > networks will never want to run DHCPv6. So requiring hosts to always > try DHCPv6 doesn't make any sense. You obviously did not talk to the same IT folks in large enterprises I do. Many do not like stateless autoconf much and would like to run DHCPv6 for address allocation. There are a number of very good reasons for that, especially for servers. And again, "requiring hosts to always try DHCPv6" is not what I want. I'm saying, if a host wants to try DHCPv6 for its configuration, that is fine, but this is a configuration decision, and there are many situations where it is not wise to have DHCPv6 triggered automatically by insecure messages on the network. - 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 Apr 26 18:28:36 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 SAA00131 for ; Mon, 26 Apr 2004 18:28: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 1BIERs-0003Dx-4k for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 18:19:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QMJau5012387 for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 18:19:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEMp-0000Z4-Ox for ipv6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 18:14: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 SAA28745 for ; Mon, 26 Apr 2004 18:14: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 1BIEMn-0001cS-0W for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 18:14:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIELs-0001Yp-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 18:13:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIEL8-0001VW-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 18:12:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEDn-00042q-TJ; Mon, 26 Apr 2004 18:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIE1X-00083n-QA for ipv6@optimus.ietf.org; Mon, 26 Apr 2004 17:52: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 RAA26485 for ; Mon, 26 Apr 2004 17:52: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 1BIE1V-00001J-4J for ipv6@ietf.org; Mon, 26 Apr 2004 17:52:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIE0d-0007ls-00 for ipv6@ietf.org; Mon, 26 Apr 2004 17:51:28 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1BIE01-0007fG-00 for ipv6@ietf.org; Mon, 26 Apr 2004 17:50:49 -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 i3QLoIL15014 for ; Mon, 26 Apr 2004 14:50:18 -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 i3QM6h4J020534 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 26 Apr 2004 15:06:47 -0700 Message-ID: <408D840B.4030903@innovationslab.net> Date: Mon, 26 Apr 2004 17:50:03 -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: Re: [rfc2462bis] whether we need the M/O flags 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit JINMEI wrote: >>>>>>On Sat, 24 Apr 2004 22:08:28 -0700, >>>>>>"Christian Huitema" said: > > >>>>>Some people commented that we needed to clarify what's bad with the >>>>>M/O flags if we want to deprecate (or remove) them. > > > (folding a long line) > > >>The normal IETF practice is that when a document progresses from PS >>do DS and then to standard, parts of the specification that are not >>actually present in implementations get removed from the spec. As >>much as I can tell, we don't have much actual implementation of the >>M/O bits. If we follow the logic of the process, we should remove >>the corresponding sections from the spec. > > > Wearing 2462bis editor's hat, I'd really like to know what we should > do with this, process wise (i.e. whether I prefer or not prefer to > deprecate the M/O flags in a technical sense). > > We first need to know if we really do not have much actual > implementation of these flags (particularly at the host side), but > it's quite likely the case (again, trying to be fair as a 2462bis > editor). > > Then, where can I ask the correct behavior, process-wise? Working > group chairs? Internet area directors? The current goal of 2462bis is to clean-up the specification, not make major changes. At this time, the chairs believe that there is code that sets the M&O bits and at least one implementation that reads and acts on these bits. In addition, DHCPv6 is now in the early stages of deployment and we expect people to begin taking more advantage of these bits. It seems to us to be the wrong time to remove them. We also do not sense a consensus for or see a benefit of making changes to 2462 with respect to the M&O bits. There may be work needed at the system level to clarify issues with their use, but that is outside the scope of 2462bis. So, the chairs do not see a need for removing the M&O bits from 2462 at this time and request that Jinmei proceed without this change. 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 Mon Apr 26 20: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 UAA06669 for ; Mon, 26 Apr 2004 20: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 1BIGgs-0006HW-B0 for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 20:43:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R0hETW024140 for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 20:43:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIGdc-0005z1-Ae for ipv6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 20:39: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 UAA06398 for ; Mon, 26 Apr 2004 20:39: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 1BIGda-0005pm-3Y for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 20:39:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIGcX-0005hJ-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 20:38:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIGbp-0005Zs-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 20:38:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIGX0-0004NO-1q; Mon, 26 Apr 2004 20:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIGTU-00046i-Gf for ipv6@optimus.ietf.org; Mon, 26 Apr 2004 20:29: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 UAA05914 for ; Mon, 26 Apr 2004 20:29: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 1BIGTS-0004sO-6a for ipv6@ietf.org; Mon, 26 Apr 2004 20:29:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIGSe-0004o6-00 for ipv6@ietf.org; Mon, 26 Apr 2004 20:28:33 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1BIGSE-0004jK-00 for ipv6@ietf.org; Mon, 26 Apr 2004 20:28:06 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3R0S6Mu029601 for ; Mon, 26 Apr 2004 18:28:06 -0600 (MDT) Received: from fe8 (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 <0HWS00D4LZYUC6@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 26 Apr 2004 18:28:06 -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 <0HWS00C8GZYSE1@mail.sun.net> for ipv6@ietf.org; Mon, 26 Apr 2004 18:28:06 -0600 (MDT) Date: Mon, 26 Apr 2004 17:28:02 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: <408D840B.4030903@innovationslab.net> To: Brian Haberman Cc: ipv6@ietf.org 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: <408D840B.4030903@innovationslab.net> 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 Apr 26, 2004, at 2:50 PM, Brian Haberman wrote: > At this time, the chairs believe that there is code that > sets the M&O bits and at least one implementation that reads and acts > on these bits. This is certainly not enough to claim interoperability. - 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 Apr 26 22:16:48 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 WAA10930 for ; Mon, 26 Apr 2004 22:16: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 1BII7g-0000uc-8J for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 22:15:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R2F0kc003502 for ipv6-archive@odin.ietf.org; Mon, 26 Apr 2004 22:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BII0S-0008Gn-MC for ipv6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 22:07: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 WAA10521 for ; Mon, 26 Apr 2004 22:07: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 1BII0P-0007Q0-Ne for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 22:07:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHzT-0007J6-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 22:06:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIHye-0007CI-00 for ipv6-web-archive@ietf.org; Mon, 26 Apr 2004 22:05:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHtD-0006uQ-JK; Mon, 26 Apr 2004 22:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHpq-0006Yv-UT for ipv6@optimus.ietf.org; Mon, 26 Apr 2004 21:56: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 VAA09979 for ; Mon, 26 Apr 2004 21:56: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 1BIHpn-00068H-Vq for ipv6@ietf.org; Mon, 26 Apr 2004 21:56:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHou-00062I-00 for ipv6@ietf.org; Mon, 26 Apr 2004 21:55:37 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BIHoZ-0005w9-00 for ipv6@ietf.org; Mon, 26 Apr 2004 21:55:16 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 21:54:32 -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] whether we need the M/O flags Date: Mon, 26 Apr 2004 21:54:32 -0400 Message-ID: Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQrtV1nSu7K4u+ORiOmp2YtgUUxUwAQ4uSg From: "Soliman Hesham" To: "Alain Durand" , "IETF IPv6 Mailing List" , "JINMEI Tatuya / ????" X-OriginalArrivalTime: 27 Apr 2004 01:54:32.0611 (UTC) FILETIME=[95ABF730:01C42BFA] 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 Your point about security is valid but is relevant to securing RAs in general, and is not specific to the M/O bits. If you want to be sure they're=20 secure just use SEND.=20 Hesham > -----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 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 fake RA with > the M/O bits on. The host will then configure itself using=20 > data coming > from the new rogue DHCPv6 server. >=20 > 2462 says "host should invoke the stateful address autoconfiguration=20 > protocol" > and not "MUST invoke", so there are already provision for 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 secured. > Also, there are no such bits in IPv4, and host implementations that=20 > chose to turn > DHCPv4 on simply try it. Why is is not good for IPv6? >=20 > - Alain. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=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 Tue Apr 27 01:29:57 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 BAA21071 for ; Tue, 27 Apr 2004 01:29: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 1BIL2V-0008Py-EP for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 01:21:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R5LpTj032351 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 01:21:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKzc-00086i-CY for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 01:18: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 BAA20554 for ; Tue, 27 Apr 2004 01:18: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 1BIKzZ-0001mj-F7 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 01:18:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIKyl-0001dM-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 01:17:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIKyA-0001TE-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 01:17:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKp8-0005zG-Gd; Tue, 27 Apr 2004 01: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 1BIKlw-00058j-NJ for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 01: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 BAA19861 for ; Tue, 27 Apr 2004 01: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 1BIKlt-0007Mh-Pw for ipv6@ietf.org; Tue, 27 Apr 2004 01:04:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIKky-0007Ex-00 for ipv6@ietf.org; Tue, 27 Apr 2004 01:03:45 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIKkM-00074Z-00 for ipv6@ietf.org; Tue, 27 Apr 2004 01:03:07 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWT00501CO6MH@mailout2.samsung.com> for ipv6@ietf.org; Tue, 27 Apr 2004 14:02:30 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWT00NV3CO542@mailout2.samsung.com> for ipv6@ietf.org; Tue, 27 Apr 2004 14:02:30 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWT00KZFCO5LU@mmp1.samsung.com> for ipv6@ietf.org; Tue, 27 Apr 2004 14:02:29 +0900 (KST) Date: Tue, 27 Apr 2004 14:02:58 +0900 From: "S. Daniel Park" Subject: RE: [rfc2462bis] whether we need the M/O flags In-reply-to: To: "'Alain Durand'" , "'Iljitsch van Beijnum'" Cc: "'IETF IPv6 Mailing List'" Message-id: <00e601c42c14$e8c6d790$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 > >> To give a hint that DHCPv6 is present? > > > > Don't you consider this useful? I have no hard stance whether to remove M&O bits or not at this stage, however if we remove it, I guess somebody will sporadically define similar flags into the RA repeatly so as to perform that kind of operations. Of course it can be a separate document. Nevertheless, M&O bits (or newly defined flags outside RFC2462) is useful to trigger DHCP operation to the host and we need it. e.g., recursive DNS server configuration. - 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 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 27 01:46:36 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 BAA21793 for ; Tue, 27 Apr 2004 01:46: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 1BILHO-0001rN-O8 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 01:37:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R5bEIp007144 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 01:37:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILB3-0001CE-8y for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 01:30: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 BAA21120 for ; Tue, 27 Apr 2004 01:30: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 1BILB0-0003YS-5Y for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 01:30:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BILA1-0003Mf-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 01:29:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIL9H-0003E5-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 01:28:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKzm-00088g-Of; Tue, 27 Apr 2004 01: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 1BIKsX-0006rO-Rj for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 01:11: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 BAA20253 for ; Tue, 27 Apr 2004 01:11: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 1BIKsU-0000kp-VH for ipv6@ietf.org; Tue, 27 Apr 2004 01:11:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIKrZ-0000c6-00 for ipv6@ietf.org; Tue, 27 Apr 2004 01:10:34 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BIKqh-0000Ru-00 for ipv6@ietf.org; Tue, 27 Apr 2004 01:09:41 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:88f7:1261:35e5:fc3d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E529415210; Tue, 27 Apr 2004 14:09:37 +0900 (JST) Date: Tue, 27 Apr 2004 14:09:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Alain Durand Cc: Brian Haberman , ipv6@ietf.org Subject: Re: [rfc2462bis] whether we need the M/O flags In-Reply-To: References: <408D840B.4030903@innovationslab.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 Mon, 26 Apr 2004 17:28:02 -0700, >>>>> Alain Durand said: >> At this time, the chairs believe that there is code that >> sets the M&O bits and at least one implementation that reads and acts >> on these bits. > This is certainly not enough to claim interoperability. Moreover, this (what Brian said) is not correct, as far as I know. The facts are: 1. there is code that sets the M&O bits. (router implementations) 2. there are at least two implementations that read and act on the O bit. These two implementations both invoke stateless DHCPv6 as the action. 3. there is no known implementation that reads and acts on the M bit. As I repeatedly said, I don't stick to deprecating these bits. However, we at least need to discuss things on the correct information. My biggest question is: can we recycle rfc2462bis as DS despite fact 3? 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 Apr 27 01:56:38 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 BAA22303 for ; Tue, 27 Apr 2004 01:56: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 1BILV9-0004CP-IU for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 01:51:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R5pRhf016135 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 01:51:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILRU-0003ku-9t for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 01:47: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 BAA21837 for ; Tue, 27 Apr 2004 01:47: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 1BILRR-00069W-4S for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 01:47:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BILQW-0005yV-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 01:46:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BILPl-0005pr-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 01:45:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILFF-0001Xy-SZ; Tue, 27 Apr 2004 01:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILA3-0000xx-9m for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 01:29: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 BAA21066 for ; Tue, 27 Apr 2004 01:29: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 1BILA0-0003MN-84 for ipv6@ietf.org; Tue, 27 Apr 2004 01:29:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIL96-0003Dm-00 for ipv6@ietf.org; Tue, 27 Apr 2004 01:28:40 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1BIL8a-00035y-00 for ipv6@ietf.org; Tue, 27 Apr 2004 01:28:08 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3R5S9Mu000032 for ; Mon, 26 Apr 2004 23:28:09 -0600 (MDT) Received: from xpa-fe1 (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 <0HWT00DT7DUWC6@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 26 Apr 2004 23:28:09 -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 <0HWT00BVHDUVGI@mail.sun.net> for ipv6@ietf.org; Mon, 26 Apr 2004 23:28:08 -0600 (MDT) Date: Mon, 26 Apr 2004 22:28:05 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: 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: multipart/alternative; boundary="Boundary_(ID_bC8XTQH5EPNW35NFM69DaA)" References: <408D840B.4030903@innovationslab.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.0 required=5.0 tests=AWL autolearn=no version=2.60 --Boundary_(ID_bC8XTQH5EPNW35NFM69DaA) Content-type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7BIT On Apr 26, 2004, at 10:09 PM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > My biggest question is: can we recycle rfc2462bis as DS despite fact > 3? I failed to see what is wrong with the unused feature elimination Christian described when moving along the standard track. - Alain. --Boundary_(ID_bC8XTQH5EPNW35NFM69DaA) Content-type: text/enriched; charset=ISO-2022-JP Content-Transfer-Encoding: 7BIT On Apr 26, 2004, at 10:09 PM, JINMEI Tatuya / Hiragino Kaku Gothic Pro$B?@L@C#:H(B wrote: My biggest question is: can we recycle rfc2462bis as DS despite fact 3? I failed to see what is wrong with the unused feature elimination Christian described when moving along the standard track. - Alain. --Boundary_(ID_bC8XTQH5EPNW35NFM69DaA)-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 27 01:57: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 BAA22422 for ; Tue, 27 Apr 2004 01:57: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 1BILYh-0004Ym-Ip for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 01:55:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R5t77l017524 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 01:55:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILSi-0003w1-TP for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 01: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 BAA21962 for ; Tue, 27 Apr 2004 01:48: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 1BILSf-0006N0-NY for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 01:48:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BILRk-0006CU-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 01:47:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BILQz-00061q-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 01:47:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILIB-0002F6-63; Tue, 27 Apr 2004 01:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILBO-0001DN-MR for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 01: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 BAA21173 for ; Tue, 27 Apr 2004 01:31: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 1BILBL-0003ag-Kc for ipv6@ietf.org; Tue, 27 Apr 2004 01:30:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BILAI-0003P7-00 for ipv6@ietf.org; Tue, 27 Apr 2004 01:29:54 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BIL9m-0003El-00 for ipv6@ietf.org; Tue, 27 Apr 2004 01:29:23 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3R5TNdc013100 for ; Mon, 26 Apr 2004 23:29:23 -0600 (MDT) Received: from xpa-fe1 (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 <0HWT00DXRDWZC6@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 26 Apr 2004 23:29:23 -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 <0HWT00BAADWXGV@mail.sun.net> for ipv6@ietf.org; Mon, 26 Apr 2004 23:29:22 -0600 (MDT) Date: Mon, 26 Apr 2004 22:29:20 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: <00e601c42c14$e8c6d790$67cadba8@LocalHost> To: "S. Daniel Park" Cc: "'IETF IPv6 Mailing List'" , "'Iljitsch van Beijnum'" 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: <00e601c42c14$e8c6d790$67cadba8@LocalHost> 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 Apr 26, 2004, at 10:02 PM, S. Daniel Park wrote: >>>> To give a hint that DHCPv6 is present? >>> >>> Don't you consider this useful? > > I have no hard stance whether to remove M&O bits > or not at this stage, however if we remove it, I > guess somebody will sporadically define similar > flags into the RA repeatly so as to perform that > kind of operations. Of course it can be a separate > document. Nevertheless, M&O bits (or newly > defined flags outside RFC2462) is useful to trigger > DHCP operation to the host and we need it. > e.g., recursive DNS server configuration. > I think you are making a good case for moving O&M out of 2462bis into a separate experimental RFC. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 27 02:55:01 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 CAA08948 for ; Tue, 27 Apr 2004 02:55:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMQt-0002bX-30 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 02:51:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R6p7li010006 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 02:51:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMJi-0001iF-PP for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 02:43: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 CAA08017 for ; Tue, 27 Apr 2004 02:43: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 1BIMJf-0007dn-3d for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 02:43:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMIm-0007Uz-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 02:42:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIMIH-0007Lf-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 02:42:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMBK-0000AF-Sx; Tue, 27 Apr 2004 02: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 1BIM87-00088J-9c for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 02:31: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 CAA07208 for ; Tue, 27 Apr 2004 02:31: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 1BIM83-0005Xz-GB for ipv6@ietf.org; Tue, 27 Apr 2004 02:31:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIM7C-0005OX-00 for ipv6@ietf.org; Tue, 27 Apr 2004 02:30:47 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BIM6L-00056M-00 for ipv6@ietf.org; Tue, 27 Apr 2004 02:29:53 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:88f7:1261:35e5:fc3d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7799F15210; Tue, 27 Apr 2004 15:29:49 +0900 (JST) Date: Tue, 27 Apr 2004 15:29:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Alain Durand Cc: IETF IPv6 Mailing List Subject: Re: [rfc2462bis] whether we need the M/O flags In-Reply-To: References: <408D840B.4030903@innovationslab.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 Mon, 26 Apr 2004 22:28:05 -0700, >>>>> Alain Durand said: > My biggest question is: can we recycle rfc2462bis as DS despite fact > 3? > I failed to see what is wrong with the unused feature elimination > Christian described > when moving along the standard track. Not sure if you're making an objection to what I said, so please let me clarify my point. I would first like to be sure if it is okay to recycle the document as DS even with the lack of implementation on a part of the protocol description (in this case, the receiving side of the M flag), *process-wise*. If it's not okay, all the discussion we are having is meaningless; Regardless of whether we prefer the idea of deprecating the flag, or whether what Christian said is valid or not, we have no other choice than deprecating/removing the feature (though there may be some compromise on the details of "deprecate"). If it's okay, then we can continue the discussion. I've been asking for an answer (if any), not an opinion, from someone very familiar to the standardization process, but unfortunately, I've never seen an answer. The wg chairs are probably the "someone", but as I pointed out, their answer based on incorrect information. Thus, I first corrected the information and then asked the same question. 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 Apr 27 04:57: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 EAA15165 for ; Tue, 27 Apr 2004 04:57: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 1BIONm-0002eO-Uo for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 04:56:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R8u2VJ010183 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 04: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 1BIOKt-0002AA-9H for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 04:53: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 EAA14927 for ; Tue, 27 Apr 2004 04:53: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 1BIOKq-0000mi-9A for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 04:53:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIOJt-0000Xs-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 04:52:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIOIt-0000Jy-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 04: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 1BIO7J-0000C6-QU; Tue, 27 Apr 2004 04:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINyQ-00073I-A1 for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 04: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 EAA13992 for ; Tue, 27 Apr 2004 04:29:47 -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 1BINyN-00049w-Aj for ipv6@ietf.org; Tue, 27 Apr 2004 04:29:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BINxl-0003zM-00 for ipv6@ietf.org; Tue, 27 Apr 2004 04:29:10 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BINwy-0003oL-00 for ipv6@ietf.org; Tue, 27 Apr 2004 04:28:21 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R8SLv20606 for ; Tue, 27 Apr 2004 11:28:21 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 11:27:50 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3R8RoXn024414 for ; Tue, 27 Apr 2004 11:27:50 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00kLeqAc; Tue, 27 Apr 2004 11:25:46 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R8PeJ12667 for ; Tue, 27 Apr 2004 11:25:40 +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, 27 Apr 2004 11:24:31 +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: Small bug in the node requirements Date: Tue, 27 Apr 2004 11:24:31 +0300 Message-ID: Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQsG83tkiID7UYZRYmZzhV0wdPWFAAFQoKg To: X-OriginalArrivalTime: 27 Apr 2004 08:24:31.0940 (UTC) FILETIME=[10C23840:01C42C31] 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 Someone just pointed out that the text: 5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147=20 =09 This specification MUST be supported if jumbograms are implemented = [RFC-2675]. =20 should be removed as 2147 is absoleted by 2675. I shall remove the = text. Otherwise, I'm still waiting to hear back from the Security AD if the = comments I sent on the security considerations text is sufficient or not. 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 Apr 27 05:24:25 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16305 for ; Tue, 27 Apr 2004 05:24: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 1BIOj6-0005CY-5N for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 05:18:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R9I4IT019989 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 05: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 1BIOdr-0004aa-Nf for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 05:12: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 FAA15708 for ; Tue, 27 Apr 2004 05:12: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 1BIOdo-0004SO-HG for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 05:12:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIOcg-00049l-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 05:11:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIObT-0003tC-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 05:10:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIOOk-0002nZ-2R; Tue, 27 Apr 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 1BIOK5-00021V-9e for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 04:52: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 EAA14885 for ; Tue, 27 Apr 2004 04:52: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 1BIOK2-0000Z9-6v for ipv6@ietf.org; Tue, 27 Apr 2004 04:52:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIOJ2-0000LK-00 for ipv6@ietf.org; Tue, 27 Apr 2004 04:51:09 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BIOIS-00007v-00 for ipv6@ietf.org; Tue, 27 Apr 2004 04:50:32 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 04:50:00 -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: whether we need the M flag ?? Date: Tue, 27 Apr 2004 04:50:00 -0400 Message-ID: Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQsGH39SZWdYSpUSeeMQZBDI03aYQAGnOsA From: "Soliman Hesham" To: "JINMEI Tatuya / ????" , "Alain Durand" CC: "Brian Haberman" , X-OriginalArrivalTime: 27 Apr 2004 08:50:01.0060 (UTC) FILETIME=[A02F6A40:01C42C34] 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 > The facts are: >=20 > 1. there is code that sets the M&O bits. (router implementations) > 2. there are at least two implementations that read and=20 > act on the O > bit. These two implementations both invoke stateless DHCPv6 as > the action. =3D> So based on 1) and 2) I suggest that people who want to continue this discussion, despite the chairs' recommendation should limit the=20 discussion to the M flag. If there are implementations that support the O flag then removing it should be out of the question. 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 Tue Apr 27 05:53:29 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17542 for ; Tue, 27 Apr 2004 05:53: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 1BIP8v-0000Rq-J5 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 05:44:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R9ijWE001714 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 05:44:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP4F-0008C6-Nl for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 05:39: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 FAA16945 for ; Tue, 27 Apr 2004 05:39: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 1BIP4C-00026y-95 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 05:39:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIP3C-0001v2-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 05:38:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIP2X-0001jm-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 05:38:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIOqo-0006JK-Ru; Tue, 27 Apr 2004 05: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 1BIOno-0005wZ-Vf for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 05:22: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 FAA16224 for ; Tue, 27 Apr 2004 05:22: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 1BIOnl-0006c5-H9 for ipv6@ietf.org; Tue, 27 Apr 2004 05:22:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIOms-0006QY-00 for ipv6@ietf.org; Tue, 27 Apr 2004 05:21:59 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BIOlz-0006FI-00 for ipv6@ietf.org; Tue, 27 Apr 2004 05:21:03 -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 i3R9L47s010552 for ; Tue, 27 Apr 2004 10:21:04 +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 KAA12253 for ; Tue, 27 Apr 2004 10:21:03 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i3R9L2l12042 for ipv6@ietf.org; Tue, 27 Apr 2004 10:21:02 +0100 Date: Tue, 27 Apr 2004 10:21:02 +0100 From: Tim Chown To: IETF IPv6 Mailing List Subject: Re: [rfc2462bis] whether we need the M/O flags Message-ID: <20040427092102.GD10666@login.ecs.soton.ac.uk> Mail-Followup-To: IETF IPv6 Mailing List References: <1082968095.27019.34.camel@kummerog.uni-muenster.de> <1D60A11E-97A5-11D8-A69D-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D60A11E-97A5-11D8-A69D-00039376A6AA@sun.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 Mon, Apr 26, 2004 at 10:14:02AM -0700, Alain Durand wrote: > Let me try to explain why I, as an implementor, do not like the M/O > bits very much. > ... Alain, Could you explain how the functionality of the O/M bits will be replaced within the ND/etc protocols? Or should they not be replaced? Until now, most people have not worried about DNS resolver discovery because they run dual-stack networks (and thus use IPv4 transport DNS), but hosts autoconfiguring in an IPv6-only environment need a method to get DNS and other configuration info. I agree they can just try DHCPv6, rather than being told to do so. So is your argument that the client should decide which protocols to try, as per IPv4, rather than be "forced" to use DHCPv6 when DHCPv6 may not be secure? But whether the client decides to use DHCP, or an RA tells it to do so, there is no way to know whether the DHCP response is from a real or malicious server (who uses authenticated DHCP? :). And if you're not using DHCP you trust the RA for the network settings anyway. So isn't SEND the answer to this, rather than deprecating flags? You either run in an authenticated/trusted environment, or you don't... At present I would agree with the WG chairs' view. 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 Apr 27 06:07:20 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19005 for ; Tue, 27 Apr 2004 06: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 1BIPNO-0002cg-VG for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 05:59:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R9xgYo010076 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 05:59:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPDu-00017M-Mf for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 05:49: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 FAA17370 for ; Tue, 27 Apr 2004 05:49: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 1BIPDr-00045u-5o for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 05:49:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPCq-0003sW-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 05:48:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIPBy-0003Xl-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 05:47:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP6M-0008Uz-Ch; Tue, 27 Apr 2004 05:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIOvN-0006jT-51 for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 05: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 FAA16534 for ; Tue, 27 Apr 2004 05:30: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 1BIOvJ-0000LB-OH for ipv6@ietf.org; Tue, 27 Apr 2004 05:30:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIOuL-00009H-00 for ipv6@ietf.org; Tue, 27 Apr 2004 05:29:41 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BIOtI-0007bL-00 for ipv6@ietf.org; Tue, 27 Apr 2004 05:28:37 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:55f5:b9b3:5cfe:65b3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3611115210; Tue, 27 Apr 2004 18:28:34 +0900 (JST) Date: Tue, 27 Apr 2004 18:28:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman Hesham" Cc: "Alain Durand" , "Brian Haberman" , Subject: Re: whether we need the M flag ?? 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 Tue, 27 Apr 2004 04:50:00 -0400, >>>>> "Soliman Hesham" said: >> 1. there is code that sets the M&O bits. (router implementations) >> 2. there are at least two implementations that read and >> act on the O >> bit. These two implementations both invoke stateless DHCPv6 as >> the action. > => So based on 1) and 2) I suggest that people who want to continue > this discussion, despite the chairs' recommendation should limit the > discussion to the M flag. If there are implementations that support > the O flag then removing it should be out of the question. Fair enough, in that this is the chair's recommendation. But please note that these implementations assume what is not described in RFC2462; they assume the protocol corresponding to the O flag is stateless DHCPv6 (RFC3736). So, *if* we need to remove the M flag due to the lack of implementation process-wise but we can keep the M flag because of these implementations, the description in rfc2462bis regarding the O flag should be consistent with the assumption, as a logical consequence. We should probably clarify in rfc2462bis that the protocol for the O flag is RFC3736, and nothing else. (For that matter, I'm happy with it.) In any event, I'd first like to clarify the general point before going to each detail to avoid further confusion. The question is: We do not have an implementation on some part of RFC2462. Can we still recycle rfc2462bis as DS (process-wise), keeping that part, despite the lack of implementation? If the answer is yes, we can concentrate on technical aspects of the discussion for both the M and O flags. If the answer is no, we need to somehow deprecate/remove the M flag, and then concentrate on issues about the O flag (as you suggested above). I simply do not understand the answer to the general question, and I think it's too early to suggest something at the moment, assuming the answer is "no". (I'm not intending to say this as a deal for "killing" the O flag as well. Rather, I'm saying this because we can even keep both flags if the answer is "yes".) Again, I'd really like to hear the answer to the general question from someone familiar with the process. 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 Tue Apr 27 06:16:49 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19705 for ; Tue, 27 Apr 2004 06:16: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 1BIPan-0005tM-Ce for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 06:13:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RADX47022641 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 06:13:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPPb-00038O-Uh for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 06:01: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 GAA18166 for ; Tue, 27 Apr 2004 06:01: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 1BIPPY-0006hc-Cr for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 06:01:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPOY-0006Rq-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 06:00:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIPNS-0006Cl-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 05:59:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP9F-0000WY-HI; Tue, 27 Apr 2004 05:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP6B-0008SJ-4J for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 05:41: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 FAA17011 for ; Tue, 27 Apr 2004 05:41: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 1BIP67-0002WV-FY for ipv6@ietf.org; Tue, 27 Apr 2004 05:41:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIP59-0002Jq-00 for ipv6@ietf.org; Tue, 27 Apr 2004 05:40:52 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BIP4H-00026t-00 for ipv6@ietf.org; Tue, 27 Apr 2004 05:39:57 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3R9dl1C086638; Tue, 27 Apr 2004 11:39:48 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <1082968095.27019.34.camel@kummerog.uni-muenster.de> <1D60A11E-97A5-11D8-A69D-00039376A6AA@sun.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List From: Iljitsch van Beijnum Subject: Re: [rfc2462bis] whether we need the M/O flags Date: Tue, 27 Apr 2004 11:39:50 +0200 To: Alain Durand 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 On 26-apr-04, at 22:53, Alain Durand wrote: >>> It is not that DHCPv6 cannot be made secure, it is that the M/O bits >>> are >>> an automatic and insecure way to trigger an external configuration >>> mechanism. >> So you object to the security level of DHCPv6 rather than that of the >> M and O bits? > You should read what I just said above before commenting too quickly. "It is not that DHCPv6 cannot be made secure" doesn't sound like a whole-hearted recommendation to me. > I have nothing against DHCPv6, but against insecure commands that > trigger a configuration mechanism, any configuration mechanisms. Ok. >> So what is the alternative? If there are no M and O bits, people >> implementing DHCPv6 will have to perform DHCP *always* so there is no >> protection against a rogue DHCPv6 server over the situation you >> describe. > Again you commented without reading what I wrote. I don't think so. > People who run DHCPv4 on the client side decide to do so, > it is not that DHCPv4 client is triggered by a remote mechanism. As I explained in my message, even though DHCPv4 and DHCPv6 in themselves are pretty much the same thing, their place in the order of things is very different because IPv6 also has stateless address configuration and IPv4 doesn't. > I never said that if you implement DHCPv6 you MUST always turn it on. > This is a decision that has to be made by the person configuring the > host. I agree in principle. I'm afraid that if DHCPv6 becomes widespread it will be turned on out of the box, though. So we should be prepared for that. >> If you want people to enable DHCPv6 manually: ok, no problem. But why >> would the M and O bits be in the way in that case? Just ignore them. > Because the specs says I should (lower case) obey M & O. Read what I > wrote. So then we make the spec not say that. >> Maybe because the IETF has no business to tell people in which way >> they should run their network, but only to provide them guidance on >> how a certain task can be performed in an interoperable way IF and >> WHEN the operator decides they want this task to be performed in the >> first place. > This is a general statement that nobody can disagree with but has no > relevance to the discussion. > Sorry. It has a lot of relevance. Obviously, when someone wants their hosts to be configured through RAs or through DHCP, then the implementation should follow the respective rules of the protocol in question. But which protocol (if any) someone wants to use to configure their hosts isn't something that should be standardized. This goes directly to your objection that when the M/O bits are set you should (lower case) do DHCP. >>> To give a hint that DHCPv6 is present? >> Don't you consider this useful? > Ah, this is a very good question, actually, at the core of the > discussion. > Thank you for asking it. > I'm not sure this is useful. You seem to think it is. Please tell me > which problem it solves. Ever since I got myself an IPv6-capable laptop I hardly leave the house without it. :-) Now at present, it doesn't support DHCPv6. But suppose in the next version of my favorite OS DHCPv6 is supported, and I decide I want to run it. So far so good. But if I now take my laptop to a place where there is no DHCPv6 server, I either have to reconfigure my network settings (always a drag) or I have to wait for DHCP to time out. It gets more complex when I really want hosts to use DHCP exclusively and not use stateless address configuration. Simple solution would be to turn off RAs, but then hosts that don't support DHCPv6 don't work anymore (and I don't have anything to fall back on when the DHCP server(s) are down). So in these cases I want RAs to be present, but have them be ignored by hosts that support DHCP. This can all be accommodated by changing the meaning of the M and O bits slightly (in a backward compatible manner) as I outlined in a message a few days ago. And even if we don't want to do this here and now, it's more useful to leave the bits in place and revisit the issue later in another document rather than remove or deprecate them. >>> Host should not blindly believe this unless the RA are secured. >> So what kind of bad stuff is going to happen when hosts start >> querying a rogue DHCPv6 server? I think the main problem is that >> traffic can be redirected through a rogue router which then has the >> opportunity to perform man in the middle attacks. However, the rogue >> system can just as easily perform the same thing using just RAs. > Not only that. A host might have been previously configured with the > address of a DNS server. There is a risk that the O bit will trigger a > query to find out the DNS server, and a corrupt entry will either > override or complement > the correct one. This way the attacker could redirect part or all of > my web traffic wherever he wants without having to mess with the > routers. Of course DNSsec will help, but it is not there yet. Ok. However, wouldn't this be an issue that is best addressed in DHCP? I can imagine DHCP info being protected using a certificate, and clients only accepting DHCP information from servers that they have a certificate for. >> IPv6 hosts have enjoyed the benefits of stateless address >> configuration for years and it's very likely that huge numbers of >> people running IPv6 networks will never want to run DHCPv6. So >> requiring hosts to always try DHCPv6 doesn't make any sense. > You obviously did not talk to the same IT folks in large enterprises I > do. Probably not, and certainly not about DHCPv6. I'm not saying DHCPv6 is useless and nobody wants it. What I'm saying is that it's perfectly possible to run an IPv6 network without DHCPv6 and many people will continue to do so. Whether this will be 10/90, 25/75, 50/50, 75/25 or 90/10 % doesn't matter much in the long run as even 10% of the networks running IPv6 is going to be a huge number in the long run. > Many do not like stateless autoconf much and would like to run DHCPv6 > for address allocation. There are a number of very good reasons for > that, especially for servers. Sure. There are also good reasons to not want to run DHCPv6, so we'll see people do both. (Quite possibly within a single network, too.) > And again, "requiring hosts to always try DHCPv6" is not what I want. > I'm saying, if a host wants to try DHCPv6 for its configuration, that > is fine, but this is a configuration decision, and there are many > situations where it is not wise to have DHCPv6 triggered automatically > by insecure messages on the network. I agree. However, there are situations when security isn't the first consideration (it's always _a_ consideration of course) and then having the bits as hints to avoid engaging in a protocol that will only time out will be very useful. Also, RAs are insecure today but that doesn't have to be so in the future. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 27 06:23:19 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20026 for ; Tue, 27 Apr 2004 06:23: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 1BIPcz-0006i5-Nx for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 06:15:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RAFnvN025781 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 06:15:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPZ8-0005Fc-BY for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 06:11: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 GAA19315 for ; Tue, 27 Apr 2004 06:11: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 1BIPZ4-000166-J7 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 06:11:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPY6-0000sl-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 06:10:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIPXF-0000gf-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 06:09:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPNj-0002rq-88; Tue, 27 Apr 2004 06:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPC4-0000zG-Ju for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 05:48: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 FAA17217 for ; Tue, 27 Apr 2004 05:47: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 1BIPC1-0003YV-1I for ipv6@ietf.org; Tue, 27 Apr 2004 05:47:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPA0-0003IJ-00 for ipv6@ietf.org; Tue, 27 Apr 2004 05:45:53 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BIP9O-000368-00 for ipv6@ietf.org; Tue, 27 Apr 2004 05:45:15 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 05:44:46 -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: whether we need the M flag ?? Date: Tue, 27 Apr 2004 05:44:46 -0400 Message-ID: Thread-Topic: whether we need the M flag ?? Thread-Index: AcQsOhINxeCeK6UgTZGpqIG34TcepwAAFR2A From: "Soliman Hesham" To: "JINMEI Tatuya / ????" CC: "Alain Durand" , "Brian Haberman" , X-OriginalArrivalTime: 27 Apr 2004 09:44:46.0503 (UTC) FILETIME=[46763B70:01C42C3C] 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> So based on 1) and 2) I suggest that people who want to = continue > > this discussion, despite the chairs' recommendation should=20 > limit the=20 > > discussion to the M flag. If there are implementations that support > > the O flag then removing it should be out of the question. >=20 > Fair enough, in that this is the chair's recommendation. >=20 > But please note that these implementations assume what is not > described in RFC2462; they assume the protocol corresponding to the O > flag is stateless DHCPv6 (RFC3736). So, *if* we need to remove the M > flag due to the lack of implementation process-wise but we can keep > the M flag because of these implementations, the description in > rfc2462bis regarding the O flag should be consistent with the > assumption, as a logical consequence. We should probably clarify in > rfc2462bis that the protocol for the O flag is RFC3736, and nothing > else. (For that matter, I'm happy with it.) =3D> I'm happy with that too. Associating the O flag with stateless DHCP is ok because that's all we have today. If later other options come up = then the RA can be extended further. But we don't need to worry about this = now for 2461/2 bis. > We do not have an implementation on some part of RFC2462. Can we > still recycle rfc2462bis as DS (process-wise), keeping that part, > despite the lack of implementation? >=20 > If the answer is yes, we can concentrate on technical aspects of the > discussion for both the M and O flags. >=20 > If the answer is no, we need to somehow deprecate/remove the M flag, > and then concentrate on issues about the O flag (as you suggested > above). >=20 > I simply do not understand the answer to the general question, and I > think it's too early to suggest something at the moment, assuming the > answer is "no". (I'm not intending to say this as a deal for > "killing" the O flag as well. Rather, I'm saying this because we can > even keep both flags if the answer is "yes".) >=20 > Again, I'd really like to hear the answer to the general question > from someone familiar with the process. Thanks, =3D> I guess that's outside my job description ;) this is something for = the=20 chairs/ADs. I saw one email from the chairs on this.=20 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 Tue Apr 27 06:57: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 GAA21888 for ; Tue, 27 Apr 2004 06:57: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 1BIQ8B-0003i1-9v for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 06:48:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RAm3MO014253 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 06:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQ4M-0002q2-11 for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 06:44: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 GAA21244 for ; Tue, 27 Apr 2004 06:44: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 1BIQ4H-0000Iv-Vn for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 06:44:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQ3J-000066-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 06:43:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIQ2m-0007gS-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 06:42:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPos-00008Z-R3; Tue, 27 Apr 2004 06: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 1BIPh5-0007LL-2m for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 06:20: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 GAA19894 for ; Tue, 27 Apr 2004 06:19: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 1BIPh1-0002yI-7O for ipv6@ietf.org; Tue, 27 Apr 2004 06:19:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPg3-0002lb-00 for ipv6@ietf.org; Tue, 27 Apr 2004 06:19:00 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1BIPfQ-0002Ww-00 for ipv6@ietf.org; Tue, 27 Apr 2004 06:18:20 -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 i3RAHoL22579 for ; Tue, 27 Apr 2004 03:17:50 -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 i3RAYI4J024485 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 27 Apr 2004 03:34:21 -0700 Message-ID: <408E3334.8020403@innovationslab.net> Date: Tue, 27 Apr 2004 06:17:24 -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: Re: [rfc2462bis] whether we need the M/O flags References: <408D840B.4030903@innovationslab.net> 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 Alain Durand wrote: > > On Apr 26, 2004, at 2:50 PM, Brian Haberman wrote: > >> At this time, the chairs believe that there is code that >> sets the M&O bits and at least one implementation that reads and acts >> on these bits. > > > This is certainly not enough to claim interoperability. No one is claiming interoperability. We are suggesting that there are implementations that use the bits and they need to be given the opportunity to do interoperability testing. Of interest is the IESG web page on interoperability for 2462/2461: http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt Please note that the report does not get down to the granularity of bits in messages. It concentrates on the behavior of each message (i.e. RA, RS, NA, NS). Regards, 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 Apr 27 06:57: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 GAA21934 for ; Tue, 27 Apr 2004 06:57: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 1BIQ8q-0003pX-VH for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 06:48:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RAmi7u014719 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 06:48:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQ6K-0003SB-SL for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 06:46: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 GAA21390 for ; Tue, 27 Apr 2004 06:46: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 1BIQ6G-0000n7-UF for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 06:46:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQ5M-0000Z6-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 06:45:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIQ4W-0000Kx-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 06:44:16 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIQ4W-0006A6-T9 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 06:44:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPud-0000py-1Y; Tue, 27 Apr 2004 06:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPlI-0007rg-VA for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 06:24: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 GAA20111 for ; Tue, 27 Apr 2004 06:24: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 1BIPlF-0003rI-2f for ipv6@ietf.org; Tue, 27 Apr 2004 06:24:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPk5-0003c7-00 for ipv6@ietf.org; Tue, 27 Apr 2004 06:23:09 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1BIPjG-0003M2-00 for ipv6@ietf.org; Tue, 27 Apr 2004 06:22:18 -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 i3RALnL22622 for ; Tue, 27 Apr 2004 03:21:49 -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 i3RAcH4J024494 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 27 Apr 2004 03:38:20 -0700 Message-ID: <408E3424.8070301@innovationslab.net> Date: Tue, 27 Apr 2004 06:21:24 -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 IPv6 Mailing List Subject: Re: [rfc2462bis] whether we need the M/O flags References: <408D840B.4030903@innovationslab.net> 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 wrote: >>>>>>On Mon, 26 Apr 2004 22:28:05 -0700, >>>>>>Alain Durand said: > > >>My biggest question is: can we recycle rfc2462bis as DS despite fact >>3? > > >>I failed to see what is wrong with the unused feature elimination >>Christian described >>when moving along the standard track. > > > Not sure if you're making an objection to what I said, so please let > me clarify my point. > > I would first like to be sure if it is okay to recycle the document as > DS even with the lack of implementation on a part of the protocol > description (in this case, the receiving side of the M flag), > *process-wise*. > > If it's not okay, all the discussion we are having is meaningless; > Regardless of whether we prefer the idea of deprecating the flag, or > whether what Christian said is valid or not, we have no other choice > than deprecating/removing the feature (though there may be some > compromise on the details of "deprecate"). > > If it's okay, then we can continue the discussion. > > I've been asking for an answer (if any), not an opinion, from someone > very familiar to the standardization process, but unfortunately, I've > never seen an answer. The wg chairs are probably the "someone", but > as I pointed out, their answer based on incorrect information. Thus, > I first corrected the information and then asked the same question. As a I stated in an earlier message, I believe it is okay to recycle at DS given the granularity of detail in the interoperability reports. http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt clearly shows that the interoperation is being measured at the message level and not at the bit level. Regards, 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 Apr 27 07:29:21 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 HAA23287 for ; Tue, 27 Apr 2004 07:29: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 1BIQjJ-00011K-Ix for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 07:26:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RBQPnx003917 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 07:26:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQh3-0000aK-0a for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 07:24: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 HAA23081 for ; Tue, 27 Apr 2004 07:24: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 1BIQgy-0001GM-Li for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 07:24:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQfq-0000ol-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 07:22:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIQe2-0000Rz-01 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 07:20:58 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIQPA-0006e7-1w for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 07:05:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQHp-000538-TM; Tue, 27 Apr 2004 06: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 1BIQ8T-0003mT-Th for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 06: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 GAA21580 for ; Tue, 27 Apr 2004 06: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 1BIQ8P-0001Ja-QD for ipv6@ietf.org; Tue, 27 Apr 2004 06:48:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQ7b-00014O-00 for ipv6@ietf.org; Tue, 27 Apr 2004 06:47:27 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BIQ6g-0000oE-00 for ipv6@ietf.org; Tue, 27 Apr 2004 06:46:30 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:55f5:b9b3:5cfe:65b3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id EBE8A15214; Tue, 27 Apr 2004 19:46:20 +0900 (JST) Date: Tue, 27 Apr 2004 19:46:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: IETF 59 IPv6 WG Document Status In-Reply-To: <4043DC42.2090905@innovationslab.net> References: <4043D345.5050800@innovationslab.net> <4043DC42.2090905@innovationslab.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 Just checking, what is the current status of draft-ietf-ipv6-scoping-arch-01.txt? According to the status tracker page, it's still in the "Ready for WG Last Call" state, and I don't think I've seen the 1-week last call you mentioned. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp >>>>> On Mon, 01 Mar 2004 19:58:42 -0500, >>>>> Brian Haberman said: > I was planning on doing a short (1 week) WG Last Call to allow > commenters a chance to review the changes. > Regards, > Brian > JINMEI wrote: >>>>>>> On Mon, 01 Mar 2004 19:20:21 -0500, >>>>>>> Brian Haberman said: >> >> >>> The chairs have decided to handle document status differently >>> at IETF 59. Rather than spending valuable meeting time on status, >>> we have created a webpage with the current status of all documents. >>> It is now available at: >> >> >>> http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.html >> >> >>> If you have questions or comments on the status, feel free to raise >>> them at the beginning of the meeting. >> >> >> Please let me make a quick check. According to the status page, >> draft-ietf-ipv6-scoping-arch-01.txt is in the status of "Ready for WG >> Last Call". Does this mean we'll need another cycle of wg last call >> for this draft? Actually the 01 revision was submitted in response to >> the previous wg last call. (If we need another one, then that's >> fine. I'm just trying to make it sure) >> >> 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 Tue Apr 27 08:09: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 IAA25197 for ; Tue, 27 Apr 2004 08:09: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 1BIRHl-0006e7-Pt for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 08:02:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RC211n025547 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 08:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIR56-0004QQ-L9 for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 07: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 HAA24009 for ; Tue, 27 Apr 2004 07:48: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 1BIR52-0006aP-1s for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 07:48:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIR41-0006JQ-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 07:47:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIR31-00064P-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 07:46:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQju-0001AL-SU; Tue, 27 Apr 2004 07:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQb5-0008MP-H3 for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 07:17: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 HAA22747 for ; Tue, 27 Apr 2004 07:17: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 1BIQb1-0007e7-4J for ipv6@ietf.org; Tue, 27 Apr 2004 07:17:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQa6-0007Rr-00 for ipv6@ietf.org; Tue, 27 Apr 2004 07:16:55 -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 1BIQZa-0007Fe-00 for ipv6@ietf.org; Tue, 27 Apr 2004 07:16:23 -0400 Received: from kummerog.uni-muenster.de (kummerog.ipv6.uni-muenster.de [IPv6:2001:638:500:200:210:5aff:fe4c:cfd1]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.11/8.12.9) with ESMTP id i3RBGCFR016086 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 27 Apr 2004 13:16:18 +0200 (CEST) Subject: Re: [rfc2462bis] whether we need the M/O flags From: "Christian Strauf (JOIN)" To: Alain Durand Cc: IETF IPv6 Mailing List In-Reply-To: <1D60A11E-97A5-11D8-A69D-00039376A6AA@sun.com> References: <1082968095.27019.34.camel@kummerog.uni-muenster.de> <1D60A11E-97A5-11D8-A69D-00039376A6AA@sun.com> Content-Type: text/plain Organization: JOIN-Team, WWU-Muenster Message-Id: <1083064567.31576.56.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 27 Apr 2004 13:16:07 +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 I fully agree with the chair's decision to leave the M/O bits unchanged for now. I would like to quickly address (comments inline) the security argument that was raised by Alain. Alain, > It is not that DHCPv6 cannot be made secure, it is that the M/O bits are > an automatic and insecure way to trigger an external configuration > mechanism. Well, but so is the whole method of sending RAs. Frankly, malicious DHCPv6 servers or RA "emitters" are easy to detect and I don't see any change in the threat level no matter if the M/O bits are there or not. An administrator needs to keep an eye on each broadcast domain where RAs are sent and where DHCPv6 is deployed anyhow to make sure that no malicious information is sent by rogue machines. If that is done, sending configuration hints to clients is a very useful feature in my eyes. > Host should not blindly believe this unless the RA are secured. That is true. But until this is achieved by some kind of additional mechanism, I don't see why having the M/O bits adds to the danger. Securing RAs is another issue. One final comment I would like to add to the implementation discussion (in parallel threads) is that NEC's DHCPv6 reference implementation also included support for M/O bits. And since this implementation was used for major DHCPv6 plug tests (e.g. by ETSI, etc.), we shouldn't neglect it. 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 Apr 27 08:11:28 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25361 for ; Tue, 27 Apr 2004 08:11: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 1BIRKq-0007CM-D0 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 08:05:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RC5CNH027666 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 08: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 1BIRCr-0005br-9s for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 07:56: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 HAA24483 for ; Tue, 27 Apr 2004 07:56: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 1BIRCm-0000fr-KN for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 07:56:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIRBn-0000RC-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 07:55:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIRAo-0000Cd-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 07:54:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIR4F-0004FM-5I; Tue, 27 Apr 2004 07:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQrV-0001qw-PE for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 07:34: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 HAA23400 for ; Tue, 27 Apr 2004 07:34: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 1BIQrR-0003Us-6K for ipv6@ietf.org; Tue, 27 Apr 2004 07:34:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQqT-0003Iz-00 for ipv6@ietf.org; Tue, 27 Apr 2004 07:33:50 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BIQph-0002vW-00 for ipv6@ietf.org; Tue, 27 Apr 2004 07:33:01 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3RBWPF14275; Tue, 27 Apr 2004 14:32:25 +0300 Date: Tue, 27 Apr 2004 14:32:25 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipv6@ietf.org Subject: interop requirements for DS [Re: whether we need the M flag ??] In-Reply-To: Message-ID: MIME-Version: 1.0 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.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 27 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > In any event, I'd first like to clarify the general point before going > to each detail to avoid further confusion. The question is: > > We do not have an implementation on some part of RFC2462. Can we > still recycle rfc2462bis as DS (process-wise), keeping that part, > despite the lack of implementation? > > If the answer is yes, we can concentrate on technical aspects of the > discussion for both the M and O flags. > > If the answer is no, we need to somehow deprecate/remove the M flag, > and then concentrate on issues about the O flag (as you suggested > above). This is a good question, and one for which you're not likely to get a definitive answers. In the past the implementation & interoperability reports have been more or less half-assed, and you could not really get a good feel on what's actually implemented and tested to interoperate. I've personally sensed a desire for a bit more detail, but not necessarily to all the gritty details. On the other hand, in Robert Elz's appeal, at least in that case, the IESG felt (or that's how I interpreted it at least) that it is traditionally not been required to demonstrate implementation and interoperability of even the smallest details of the spec: http://www.ietf.org/IESG/APPEALS/kre-ipngwg-addr-appeal-withdraw.txt [...] The IESG notes that the existing practice when advancing documents on the standards track has not involved having implementation reports include detailed verification that implementations enforce every statement as is implied above, in the absence of explicit text requiring that an implementation make such checks. [...] So, my personal feeling is, "yes, we should be stricter on what we accept as "implemented & interoperable", but whether that happens in practice is another thing. Hope this helps.. -- 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 Apr 27 08:38:18 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27527 for ; Tue, 27 Apr 2004 08:38: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 1BIRk3-0007Ll-LR for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 08:31:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RCVFCi028248 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 08:31:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRbK-00040j-4J for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 08: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 IAA26166 for ; Tue, 27 Apr 2004 08:22: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 1BIRbF-0006ko-76 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 08:22:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIRaF-0006VW-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 08:21:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIRZk-0006Gi-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 08:20:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRQU-00005X-PO; Tue, 27 Apr 2004 08:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRK5-00070e-0r for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 08:04: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 IAA24878 for ; Tue, 27 Apr 2004 08:04: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 1BIRK0-0002NN-7o for ipv6@ietf.org; Tue, 27 Apr 2004 08:04:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIRIt-000278-00 for ipv6@ietf.org; Tue, 27 Apr 2004 08:03:12 -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 1BIRI9-0001cG-00 for ipv6@ietf.org; Tue, 27 Apr 2004 08:02:25 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 27 Apr 2004 04:13:03 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3RC1JW9012319 for ; Tue, 27 Apr 2004 05:01:19 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-66.cisco.com [10.86.240.66]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHW98392; Tue, 27 Apr 2004 08:01:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20040427075722.01f4a410@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Apr 2004 08:01:15 -0400 To: ipv6@ietf.org From: Ralph Droms Subject: Re: interop requirements for DS [Re: whether we need the M flag ??] 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 agree 100% with Pekka's assessment of the current state of interoperability testing, reporting and requirements as applied to advancement of protocol standards. I also agree that we should be more precise in our acceptance of "implemented and interoperable". I fear that the current practice can be (and has been) applied selectively to allow advancement of some standards while holding back others. - Ralph At 02:32 PM 4/27/2004 +0300, Pekka Savola wrote: >On Tue, 27 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > In any event, I'd first like to clarify the general point before going > > to each detail to avoid further confusion. The question is: > > > > We do not have an implementation on some part of RFC2462. Can we > > still recycle rfc2462bis as DS (process-wise), keeping that part, > > despite the lack of implementation? > > > > If the answer is yes, we can concentrate on technical aspects of the > > discussion for both the M and O flags. > > > > If the answer is no, we need to somehow deprecate/remove the M flag, > > and then concentrate on issues about the O flag (as you suggested > > above). > >This is a good question, and one for which you're not likely to get a >definitive answers. > >In the past the implementation & interoperability reports have been >more or less half-assed, and you could not really get a good feel on >what's actually implemented and tested to interoperate. I've >personally sensed a desire for a bit more detail, but not necessarily >to all the gritty details. > >On the other hand, in Robert Elz's appeal, at least in that case, the >IESG felt (or that's how I interpreted it at least) that it is >traditionally not been required to demonstrate implementation and >interoperability of even the smallest details of the spec: > >http://www.ietf.org/IESG/APPEALS/kre-ipngwg-addr-appeal-withdraw.txt > >[...] > The IESG notes that the existing practice when advancing documents on > the standards track has not involved having implementation reports > include detailed verification that implementations enforce every > statement as is implied above, in the absence of explicit text > requiring that an implementation make such checks. >[...] > >So, my personal feeling is, "yes, we should be stricter on what we >accept as "implemented & interoperable", but whether that happens in >practice is another thing. > >Hope this helps.. > >-- >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 27 09:18: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 JAA29306 for ; Tue, 27 Apr 2004 09:18: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 1BISMe-0007Vk-Ok for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 09:11:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RDB8UP028866 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 09:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISHd-0006MC-4H for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 09:05: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 JAA28840 for ; Tue, 27 Apr 2004 09:05: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 1BISHX-0001oW-LK for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 09:05:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISGZ-0001Xm-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 09:04:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BISFY-0001BZ-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 09:03:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIS85-00044W-Mk; Tue, 27 Apr 2004 08:56:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIS1G-0002hv-Oa for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 08:49: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 IAA27924 for ; Tue, 27 Apr 2004 08:48:58 -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 1BIS1B-0005R7-FL for ipv6@ietf.org; Tue, 27 Apr 2004 08:48:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIS0D-0005DA-00 for ipv6@ietf.org; Tue, 27 Apr 2004 08:47:58 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BIRzQ-0004zZ-00 for ipv6@ietf.org; Tue, 27 Apr 2004 08:47:08 -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 i3RCkhJ01539; Tue, 27 Apr 2004 15:46:43 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 15:46:35 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3RCkZb4020478; Tue, 27 Apr 2004 15:46:35 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00C1XdKG; Tue, 27 Apr 2004 15:42:05 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 i3RCg5H05544; Tue, 27 Apr 2004 15:42:05 +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); Tue, 27 Apr 2004 15:41:49 +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: interop requirements for DS [Re: whether we need the M flag ??] Date: Tue, 27 Apr 2004 15:41:48 +0300 Message-ID: Thread-Topic: interop requirements for DS [Re: whether we need the M flag ??] Thread-Index: AcQsVD+ymg2Vz1rOTa+WMuuI2OPjTgAAIzpA X-Priority: 5 Priority: Non-Urgent importance: low To: , X-OriginalArrivalTime: 27 Apr 2004 12:41:49.0588 (UTC) FILETIME=[02505D40:01C42C55] 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.7 required=5.0 tests=AWL,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Ralph, > I also agree that we should be more precise in our acceptance of > "implemented and interoperable". I fear that the current practice can = be > (and has been) applied selectively to allow advancement of some = standards > while holding back others. I'm not sure that your point above is something that is within the IPv6 WGs scope. Perhaps this needs to be taken up with the IESG or = elsewhere. 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 Apr 27 12:58:11 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 MAA12774 for ; Tue, 27 Apr 2004 12:58: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 1BIVod-0000Tl-Bl for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:52:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RGqF3E001837 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVeK-0005Nn-7i for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 12:41: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 MAA10989 for ; Tue, 27 Apr 2004 12:41: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 1BIVeG-00033L-Kt for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 12:41:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVcC-0002ew-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 12:39:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIVbU-0002Xu-04 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 12:38: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 1BIVVe-0004Pi-Tv for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 12:32:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVOJ-0001Sj-1X; Tue, 27 Apr 2004 12:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV3r-0004Dh-Rq for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 12:03: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 MAA09259 for ; Tue, 27 Apr 2004 12:03: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 1BIV3o-0000cM-Ey for ipv6@ietf.org; Tue, 27 Apr 2004 12:03:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIV2p-0000Yb-00 for ipv6@ietf.org; Tue, 27 Apr 2004 12:02:52 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BIV1t-0000UX-00 for ipv6@ietf.org; Tue, 27 Apr 2004 12:01:53 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:55f5:b9b3:5cfe:65b3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id EAA7015210; Wed, 28 Apr 2004 01:01:52 +0900 (JST) Date: Wed, 28 Apr 2004 01:01:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman Cc: IETF IPv6 Mailing List Subject: Re: [rfc2462bis] whether we need the M/O flags In-Reply-To: <408E3424.8070301@innovationslab.net> References: <408D840B.4030903@innovationslab.net> <408E3424.8070301@innovationslab.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 Tue, 27 Apr 2004 06:21:24 -0400, >>>>> Brian Haberman said: > As a I stated in an earlier message, I believe it is okay to recycle > at DS given the granularity of detail in the interoperability reports. > http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt > clearly shows that the interoperation is being measured at the message > level and not at the bit level. Okay, thanks. Then it is probably okay to keep these flags in terms of the standardization process, even if we don't have the corresponding implementations at all. I personally would like to have a closer review process, but as Pekka said, this is apparently what we have, and I'm not intending to fight against it (at least for rfc2462bis). (wearing an editor's hat) through the discussion so far, it seems to me that we should keep both the flags. The reasons are: - there seems to be no process issue (about interoperable implementations) - the other points I raised to deprecate the flags were (apparently) not convincing enough - we may need some additional consideration for security concerns Alain raised, but I think we can deal with them without deprecating the flags: + as (implicitly?) described in the node requirements draft, it's optional to implement DHCPv6 in the first place, and the node req document warns administrators about the implication about turning on the M flag. Perhaps the node req draft could also add the security concerns, and/or rfc2462bis can describe the issues in its security consideration section. + after all, the entire autoconfiguration mechanism using RA (without SEND) is vulnerable to attacks from a malicious party in the same link. It might be true that the concerns raised by Alain increases the vulnerability, but I guess we can accept it by noting the concerns in the security consideration section. I hope this is acceptable for everyone. 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 Apr 27 13:09: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 NAA13835 for ; Tue, 27 Apr 2004 13:09: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 1BIVqI-0000zt-2N for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:53:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RGrw00003829 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVid-0006fp-6k for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 12:46: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 MAA12122 for ; Tue, 27 Apr 2004 12:45: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 1BIViZ-0003sR-Jf for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 12:45:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVhb-0003i3-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 12:45:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIVfs-0003NG-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 12:43:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVRC-0002IC-2y; Tue, 27 Apr 2004 12:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV7u-0005A8-PY for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 12:08: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 MAA09529 for ; Tue, 27 Apr 2004 12:08: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 1BIV7r-0000xr-6U for ipv6@ietf.org; Tue, 27 Apr 2004 12:08:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIV6u-0000to-00 for ipv6@ietf.org; Tue, 27 Apr 2004 12:07:04 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BIV60-0000p5-00 for ipv6@ietf.org; Tue, 27 Apr 2004 12:06:08 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3RG6Adc029865 for ; Tue, 27 Apr 2004 10:06:10 -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 <0HWU00G7X7E9BC@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Tue, 27 Apr 2004 10:06:09 -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 <0HWU00L1M7E8XL@mail.sun.net> for ipv6@ietf.org; Tue, 27 Apr 2004 10:06:09 -0600 (MDT) Date: Tue, 27 Apr 2004 09:06:06 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: 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: multipart/alternative; boundary="Boundary_(ID_cNdjpgI5a3rJuVyVa1zxug)" References: <408D840B.4030903@innovationslab.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.0 required=5.0 tests=AWL autolearn=no version=2.60 --Boundary_(ID_cNdjpgI5a3rJuVyVa1zxug) Content-type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7BIT On Apr 26, 2004, at 11:29 PM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > I would first like to be sure if it is okay to recycle the document as > DS even with the lack of implementation on a part of the protocol > description (in this case, the receiving side of the M flag), > *process-wise*. > > If it's not okay, all the discussion we are having is meaningless; > Regardless of whether we prefer the idea of deprecating the flag, or > whether what Christian said is valid or not, we have no other choice > than deprecating/removing the feature (though there may be some > compromise on the details of "deprecate"). > > If it's okay, then we can continue the discussion. Ok, thanks for the clarification. IMHO, it is not OK to keep the document as DS with O&M given the general lack of implementation. - Alain. --Boundary_(ID_cNdjpgI5a3rJuVyVa1zxug) Content-type: text/enriched; charset=ISO-2022-JP Content-Transfer-Encoding: 7BIT On Apr 26, 2004, at 11:29 PM, JINMEI Tatuya / Hiragino Kaku Gothic Pro$B?@L@C#:H(B wrote: I would first like to be sure if it is okay to recycle the document as DS even with the lack of implementation on a part of the protocol description (in this case, the receiving side of the M flag), *process-wise*. If it's not okay, all the discussion we are having is meaningless; Regardless of whether we prefer the idea of deprecating the flag, or whether what Christian said is valid or not, we have no other choice than deprecating/removing the feature (though there may be some compromise on the details of "deprecate"). If it's okay, then we can continue the discussion. Ok, thanks for the clarification. IMHO, it is not OK to keep the document as DS with O&M given the general lack of implementation. - Alain. --Boundary_(ID_cNdjpgI5a3rJuVyVa1zxug)-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 27 13:10: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 NAA14020 for ; Tue, 27 Apr 2004 13:10: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 1BIVsp-0001ap-B9 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:56:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RGuZNi006119 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:56:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVla-000883-Po for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 12:49: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 MAA12349 for ; Tue, 27 Apr 2004 12:49: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 1BIVlX-0004CI-1O for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 12:49:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVkZ-00045U-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 12:48:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIVjd-00040U-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 12:47:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVRH-0002M6-D2; Tue, 27 Apr 2004 12:28:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVFZ-0007XG-Km for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 12:16: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 MAA09799 for ; Tue, 27 Apr 2004 12:15: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 1BIVFW-0001NY-0T for ipv6@ietf.org; Tue, 27 Apr 2004 12:15:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVEW-0001KW-00 for ipv6@ietf.org; Tue, 27 Apr 2004 12:14:57 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BIVDY-0001HL-00 for ipv6@ietf.org; Tue, 27 Apr 2004 12:13:56 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3RGDwdc004425 for ; Tue, 27 Apr 2004 10:13:58 -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 <0HWU00BSN7R9RG@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Tue, 27 Apr 2004 10:13:58 -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 <0HWU00L6U7R8XL@mail.sun.net> for ipv6@ietf.org; Tue, 27 Apr 2004 10:13:57 -0600 (MDT) Date: Tue, 27 Apr 2004 09:13:55 -0700 From: Alain Durand Subject: Re: whether we need the M flag ?? In-reply-to: To: Soliman Hesham 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: 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 Apr 27, 2004, at 1:50 AM, Soliman Hesham wrote: > >> The facts are: >> >> 1. there is code that sets the M&O bits. (router implementations) >> 2. there are at least two implementations that read and >> act on the O >> bit. These two implementations both invoke stateless DHCPv6 as >> the action. > > => So based on 1) and 2) I suggest that people who want to continue > this discussion, despite the chairs' recommendation should limit the > discussion to the M flag. If there are implementations that support > the O flag then removing it should be out of the question. I disagree. There are only 2 known implementations of the O flag, and the author of one of them publicly said he was willing to deprecate it. He said: "Regarding KAME's implementation, at least the implementor (myself) is okay to deprecate the flags. Also, it's just an experimental implementation to identify issues, so this feature (invoking an RFC3736 client) is disabled by default in the implementation and is not officially released in the BSD community. In fact, I'm tempted to deprecate the flags based on my experiments with the implementation, identifying the issues described above." So I do not believe that the argument that say they are existing implementations of 'O' thus we cannot deprecate it is very strong - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 27 13:24:14 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 NAA15112 for ; Tue, 27 Apr 2004 13:24: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 1BIWB7-0006F2-PR for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 13:15:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RHFTZw023983 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 13:15:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIW5B-0004au-Gi for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 13:09: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 NAA13703 for ; Tue, 27 Apr 2004 13:09: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 1BIW57-0005yp-MH for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 13:09:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIW3G-0005ZG-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 13:07:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIW0A-00055Y-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 13:04: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 1BIVlB-0004pw-BG for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 12:48:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVSA-0002iP-8a; Tue, 27 Apr 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 1BIVNE-00012m-PE for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 12: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 MAA10079 for ; Tue, 27 Apr 2004 12:23: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 1BIVNB-0001mI-2y for ipv6@ietf.org; Tue, 27 Apr 2004 12:23:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVMD-0001it-00 for ipv6@ietf.org; Tue, 27 Apr 2004 12:22:54 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1BIVLI-0001fv-00 for ipv6@ietf.org; Tue, 27 Apr 2004 12:21:56 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3RGLvMu001846 for ; Tue, 27 Apr 2004 10:21:58 -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 <0HWU00BXJ84LRG@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Tue, 27 Apr 2004 10:21:57 -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 <0HWU003TL84KL2@mail.sun.net> for ipv6@ietf.org; Tue, 27 Apr 2004 10:21:57 -0600 (MDT) Date: Tue, 27 Apr 2004 09:21:54 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: To: Iljitsch van Beijnum 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: <1082968095.27019.34.camel@kummerog.uni-muenster.de> <1D60A11E-97A5-11D8-A69D-00039376A6AA@sun.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 Apr 27, 2004, at 2:39 AM, Iljitsch van Beijnum wrote: > Now at present, it doesn't support DHCPv6. But suppose in the next > version of my favorite OS DHCPv6 is supported, and I decide I want to > run it. So far so good. But if I now take my laptop to a place where > there is no DHCPv6 server, I either have to reconfigure my network > settings (always a drag) or I have to wait for DHCP to time out. I see your point, but I think a smart implementation will not have to wait for DHCPv6 timeout. You could start working with stateless autoconf, that will get you started, and if DHCPv6 kicks in, you will simply reconfigure dynamically. Not really different than receiving a second RA 1 or 2 seconds after the first one... - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Apr 27 16:55: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 QAA00793 for ; Tue, 27 Apr 2004 16:55: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 1BIZPf-00071e-2L for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 16:42:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RKghY9027001 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 16:42:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZEn-0001hQ-O3 for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 16:31: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 QAA28199 for ; Tue, 27 Apr 2004 16:31: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 1BIZEj-0004x1-TH for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 16:31:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIZDh-0004mn-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 16:30:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIZCk-0004cz-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 16:29:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYmV-0001kd-Rd; Tue, 27 Apr 2004 16:02:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYcL-0000PS-1s for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 15:51:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25405; Tue, 27 Apr 2004 15:51:42 -0400 (EDT) Message-Id: <200404271951.PAA25405@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-rfc2011-update-09.txt Date: Tue, 27 Apr 2004 15:51:42 -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 : Management Information Base for the Internet Protocol (IP) Author(s) : S. Routhier Filename : draft-ietf-ipv6-rfc2011-update-09.txt Pages : 134 Date : 2004-4-27 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465 and 2466. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-09.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-rfc2011-update-09.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-rfc2011-update-09.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-4-27161216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2011-update-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2011-update-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-27161216.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 Tue Apr 27 18:01: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 SAA04596 for ; Tue, 27 Apr 2004 18:01: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 1BIabi-0002eU-AQ for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 17:59:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RLxEJg010190 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 17:59:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaSG-0001eg-Uj for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 17: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 RAA04034 for ; Tue, 27 Apr 2004 17:49: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 1BIaSC-0007gG-Df for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 17:49:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIaRF-0007Xz-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 17:48:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIaQd-0007QW-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 17:47:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaGE-0007m2-63; Tue, 27 Apr 2004 17: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 1BIa7t-0006g6-Ou for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 17:28: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 RAA03044 for ; Tue, 27 Apr 2004 17:28: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 1BIa7p-0005My-84 for ipv6@ietf.org; Tue, 27 Apr 2004 17:28:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIa6w-0005H3-00 for ipv6@ietf.org; Tue, 27 Apr 2004 17:27:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BIa6V-00058x-00 for ipv6@ietf.org; Tue, 27 Apr 2004 17:26:59 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 27 Apr 2004 14:27:43 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3RLQS0Q006300; Tue, 27 Apr 2004 14:26:29 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-66.cisco.com [10.86.240.66]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHX48906; Tue, 27 Apr 2004 17:26:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20040427172358.02b05d28@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 X-Priority: 5 (Lowest) Date: Tue, 27 Apr 2004 17:26:25 -0400 To: From: Ralph Droms Subject: RE: interop requirements for DS [Re: whether we need the M flag ??] Cc: 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 John - I should have been more careful in my use of "we", which I had intended to mean the IETF as a whole. I agree that the issue of "implemented and interoperable" is not within the IPv6 WG's scope. It wouldn't hurt for the WG to be aware of the potential issues and come to an explciit decision about how to proceed within the context of past practice and documented requirements. - Ralph At 03:41 PM 4/27/2004 +0300, john.loughney@nokia.com wrote: >Hi Ralph, > > > I also agree that we should be more precise in our acceptance of > > "implemented and interoperable". I fear that the current practice can be > > (and has been) applied selectively to allow advancement of some standards > > while holding back others. > >I'm not sure that your point above is something that is within the IPv6 >WGs scope. Perhaps this needs to be taken up with the IESG or elsewhere. > >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 Apr 27 21:45:33 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 VAA16396 for ; Tue, 27 Apr 2004 21:45: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 1BIe73-00087T-CS for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 21:43:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S1hnCg031207 for ipv6-archive@odin.ietf.org; Tue, 27 Apr 2004 21:43:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIe1q-0007f4-QS for ipv6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 21:38: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 VAA16177 for ; Tue, 27 Apr 2004 21:38: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 1BIe1m-0003hV-3K for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 21:38:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIe0o-0003aW-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 21:37:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIe0X-0003TY-00 for ipv6-web-archive@ietf.org; Tue, 27 Apr 2004 21:37:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdsl-0006DJ-1r; Tue, 27 Apr 2004 21:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdq9-0005oW-RQ for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 21:26: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 VAA15865 for ; Tue, 27 Apr 2004 21:26: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 1BIdq5-0002EB-5N for ipv6@ietf.org; Tue, 27 Apr 2004 21:26:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIdpG-00027m-00 for ipv6@ietf.org; Tue, 27 Apr 2004 21:25:27 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BIdoo-0001zk-00 for ipv6@ietf.org; Tue, 27 Apr 2004 21:24:58 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 21:22:48 -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-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: whether we need the M flag ?? Date: Tue, 27 Apr 2004 21:22:47 -0400 Message-ID: Thread-Topic: whether we need the M flag ?? Thread-Index: AcQsc9caHBWZUXMFTzeyH2W4YmBqSQAShFPw From: "Soliman Hesham" To: CC: "IETF IPv6 Mailing List" X-OriginalArrivalTime: 28 Apr 2004 01:22:48.0012 (UTC) FILETIME=[50DAF8C0:01C42CBF] 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 thought that statement referred to one implementation only, which is confirmed by Jinmei's response to my email Hesham > -----Original Message----- > From: Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM] > Sent: Tuesday, April 27, 2004 12:14 PM > To: Soliman Hesham > Cc: IETF IPv6 Mailing List > Subject: Re: whether we need the M flag ?? >=20 >=20 >=20 > On Apr 27, 2004, at 1:50 AM, Soliman Hesham wrote: >=20 > > > >> The facts are: > >> > >> 1. there is code that sets the M&O bits. (router=20 > implementations) > >> 2. there are at least two implementations that read and > >> act on the O > >> bit. These two implementations both invoke=20 > stateless DHCPv6 as > >> the action. > > > > =3D> So based on 1) and 2) I suggest that people who want to = continue > > this discussion, despite the chairs' recommendation should=20 > limit the > > discussion to the M flag. If there are implementations that support > > the O flag then removing it should be out of the question. >=20 > I disagree. There are only 2 known implementations of the O flag, > and the author of one of them publicly said he was willing > to deprecate it. He said: > "Regarding KAME's implementation, at least the implementor=20 > (myself) is > okay to deprecate the flags. Also, it's just an experimental > implementation to identify issues, so this feature (invoking an > RFC3736 client) is disabled by default in the implementation and is > not officially released in the BSD community. In fact, I'm=20 > tempted to > deprecate the flags based on my experiments with the implementation, > identifying the issues described above." >=20 > So I do not believe that the argument that say they are existing=20 > implementations > of 'O' thus we cannot deprecate it is very strong >=20 > - Alain. >=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 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 Wed Apr 28 08:19: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 IAA11202 for ; Wed, 28 Apr 2004 08:19: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 1BInwP-00085M-7U for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCDTEV031069 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInbX-0002VQ-BQ for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 07:51: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 HAA08459 for ; Wed, 28 Apr 2004 07:51: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 1BInbW-0007lH-Lv for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 07:51:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInaY-0007Rv-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 07:50:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInZX-00078P-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 07:49:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInMR-0007fi-Ot; Wed, 28 Apr 2004 07:36:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfmE-0003Oj-Dv for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 23: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 XAA20953 for ; Tue, 27 Apr 2004 23:30: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 1BIfmA-0004Xs-Dm for ipv6@ietf.org; Tue, 27 Apr 2004 23:30:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIflD-0004LU-00 for ipv6@ietf.org; Tue, 27 Apr 2004 23:29:24 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BIfjC-0003yS-00 for ipv6@ietf.org; Tue, 27 Apr 2004 23:27:18 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:55f5:b9b3:5cfe:65b3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A1FD015210; Wed, 28 Apr 2004 12:27:11 +0900 (JST) Date: Wed, 28 Apr 2004 12:27:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Alain Durand Cc: IETF IPv6 Mailing List Subject: Re: whether we need the M flag ?? 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=none autolearn=no version=2.60 >>>>> On Tue, 27 Apr 2004 09:13:55 -0700, >>>>> Alain Durand said: >>> The facts are: >>> >>> 1. there is code that sets the M&O bits. (router implementations) >>> 2. there are at least two implementations that read and >>> act on the O >>> bit. These two implementations both invoke stateless DHCPv6 as >>> the action. >> >> => So based on 1) and 2) I suggest that people who want to continue >> this discussion, despite the chairs' recommendation should limit the >> discussion to the M flag. If there are implementations that support >> the O flag then removing it should be out of the question. > I disagree. There are only 2 known implementations of the O flag, > and the author of one of them publicly said he was willing > to deprecate it. He said: > "Regarding KAME's implementation, at least the implementor (myself) is > okay to deprecate the flags. Also, it's just an experimental > implementation to identify issues, so this feature (invoking an > RFC3736 client) is disabled by default in the implementation and is > not officially released in the BSD community. In fact, I'm tempted to > deprecate the flags based on my experiments with the implementation, > identifying the issues described above." > So I do not believe that the argument that say they are existing > implementations > of 'O' thus we cannot deprecate it is very strong Although my personal opinion on this does not change, this discussion has become meaningless...the chairs said we could recycle rfc2462bis at DS even without interoperable implementations regarding the M/O flags, and that's apparently what we have in the standardization process. Since this (sub)thread focuses on the process side of the issue, I think we should close the thread at this stage. 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 Apr 28 08:20:12 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11432 for ; Wed, 28 Apr 2004 08:20: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 1BInwR-00086k-21 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCDUid031147 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInbr-0002Za-GM for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 07:52: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 HAA08509 for ; Wed, 28 Apr 2004 07:52: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 1BInbq-0007nl-NL for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 07:52:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInb8-0007VM-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 07:51:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInaD-0007CS-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 07:50:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInMV-0007gQ-JZ; Wed, 28 Apr 2004 07:36:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIiuw-000472-7w for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 02:51: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 CAA27776 for ; Wed, 28 Apr 2004 02:51: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 1BIiuq-00061J-Ff for ipv6@ietf.org; Wed, 28 Apr 2004 02:51:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIitq-0005oU-00 for ipv6@ietf.org; Wed, 28 Apr 2004 02:50:31 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BIisp-0005TI-00 for ipv6@ietf.org; Wed, 28 Apr 2004 02:49:27 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:1036:dc74:13f8:73e0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BCF9115218; Wed, 28 Apr 2004 15:49:26 +0900 (JST) Date: Wed, 28 Apr 2004 15:49:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Alain Durand Cc: IETF IPv6 Mailing List Subject: Re: [rfc2462bis] whether we need the M/O flags In-Reply-To: References: <408D840B.4030903@innovationslab.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: multipart/mixed; boundary="Multipart_Wed_Apr_28_15:49:33_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=none autolearn=no version=2.60 --Multipart_Wed_Apr_28_15:49:33_2004-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Tue, 27 Apr 2004 09:06:06 -0700, >>>>> Alain Durand said: >> I would first like to be sure if it is okay to recycle the document as >> DS even with the lack of implementation on a part of the protocol >> description (in this case, the receiving side of the M flag), >> *process-wise*. >> If it's not okay, all the discussion we are having is meaningless; >> Regardless of whether we prefer the idea of deprecating the flag, or >> whether what Christian said is valid or not, we have no other choice >> than deprecating/removing the feature (though there may be some >> compromise on the details of "deprecate"). >> If it's okay, then we can continue the discussion. > Ok, thanks for the clarification. IMHO, it is not OK to keep > the document as DS with O&M given the general lack of implementation. Hmm, this message of yours seems to have been sent just after my latest one...so, please let me confirm your intention. Can you or can't you live with my revised proposal (attached below)? Regarding the process issue, I personally share your view. But I understood the current practice of the IETF is much more generous than I'd want to see, and I'd accept that for now. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Wed_Apr_28_15:49:33_2004-1 Content-Type: message/rfc822 Return-Path: X-Mail-Format-Warning: Bad RFC2822 header formatting in >From jinmei Wed Apr 28 01:29:28 2004 Return-Path: X-Original-To: jinmei@shuttle.wide.toshiba.co.jp Delivered-To: jinmei@shuttle.wide.toshiba.co.jp Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-6.2.4) for jinmei@localhost (single-drop); Wed, 28 Apr 2004 11:16:36 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [3ffe:501:100f:0:220:edff:fe2b:92c]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C1CA81521D; Wed, 28 Apr 2004 01:29:28 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id BC61433089; Wed, 28 Apr 2004 01:29:28 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id BAA13020; Wed, 28 Apr 2004 01:29:28 +0900 (JST) Received: from mx4.toshiba.co.jp (mx4.toshiba.co.jp [133.199.160.112]) by isl.rdc.toshiba.co.jp (8.11.7/8.11.6/1.4) with ESMTP id i3RGTRn11770; Wed, 28 Apr 2004 01:29:27 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id BAA02520; Wed, 28 Apr 2004 01:29:27 +0900 (JST) Received: from inet-tsb5.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3RGTQa3012402; Wed, 28 Apr 2004 01:29:26 +0900 (JST) Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by inet-tsb5.toshiba.co.jp with ESMTP id i3RGTECx026732; Wed, 28 Apr 2004 01:29:24 +0900 (JST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVOI-0001SG-A5; Tue, 27 Apr 2004 12:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV3r-0004Dh-Rq for ipv6@optimus.ietf.org; Tue, 27 Apr 2004 12:03: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 MAA09259 for ; Tue, 27 Apr 2004 12:03: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 1BIV3o-0000cM-Ey for ipv6@ietf.org; Tue, 27 Apr 2004 12:03:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIV2p-0000Yb-00 for ipv6@ietf.org; Tue, 27 Apr 2004 12:02:52 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BIV1t-0000UX-00 for ipv6@ietf.org; Tue, 27 Apr 2004 12:01:53 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:55f5:b9b3:5cfe:65b3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id EAA7015210; Wed, 28 Apr 2004 01:01:52 +0900 (JST) Date: Wed, 28 Apr 2004 01:01:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman Cc: IETF IPv6 Mailing List Subject: Re: [rfc2462bis] whether we need the M/O flags In-Reply-To: <408E3424.8070301@innovationslab.net> References: <408D840B.4030903@innovationslab.net> <408E3424.8070301@innovationslab.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-UIDL: L^#"!WS*"!Tf_!!>>>>> On Tue, 27 Apr 2004 06:21:24 -0400, >>>>> Brian Haberman said: > As a I stated in an earlier message, I believe it is okay to recycle > at DS given the granularity of detail in the interoperability reports. > http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt > clearly shows that the interoperation is being measured at the message > level and not at the bit level. Okay, thanks. Then it is probably okay to keep these flags in terms of the standardization process, even if we don't have the corresponding implementations at all. I personally would like to have a closer review process, but as Pekka said, this is apparently what we have, and I'm not intending to fight against it (at least for rfc2462bis). (wearing an editor's hat) through the discussion so far, it seems to me that we should keep both the flags. The reasons are: - there seems to be no process issue (about interoperable implementations) - the other points I raised to deprecate the flags were (apparently) not convincing enough - we may need some additional consideration for security concerns Alain raised, but I think we can deal with them without deprecating the flags: + as (implicitly?) described in the node requirements draft, it's optional to implement DHCPv6 in the first place, and the node req document warns administrators about the implication about turning on the M flag. Perhaps the node req draft could also add the security concerns, and/or rfc2462bis can describe the issues in its security consideration section. + after all, the entire autoconfiguration mechanism using RA (without SEND) is vulnerable to attacks from a malicious party in the same link. It might be true that the concerns raised by Alain increases the vulnerability, but I guess we can accept it by noting the concerns in the security consideration section. I hope this is acceptable for everyone. 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 -------------------------------------------------------------------- --Multipart_Wed_Apr_28_15:49:33_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 Wed Apr 28 08:23:52 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 IAA11968 for ; Wed, 28 Apr 2004 08:23: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 1BInz4-0000yQ-Dd for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 08:16:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCGECl003739 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 08:16:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInuJ-0007HE-UO for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 08:11: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 IAA10259 for ; Wed, 28 Apr 2004 08:11: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 1BInuI-0006Mw-UW for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 08:11:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIntQ-00062p-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 08:10:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInsM-0005gU-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 08:09:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInNq-0008H8-1U; Wed, 28 Apr 2004 07:37:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BImL2-0001bm-9j for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 06:30: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 GAA04726 for ; Wed, 28 Apr 2004 06: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 1BImKw-0001Vt-8R for ipv6@ietf.org; Wed, 28 Apr 2004 06:30:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BImJw-0001Fm-00 for ipv6@ietf.org; Wed, 28 Apr 2004 06:29:42 -0400 Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx with esmtp (Exim 4.12) id 1BImIv-0000pi-00 for ipv6@ietf.org; Wed, 28 Apr 2004 06:28:38 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:1036:dc74:13f8:73e0]) by tachyon.jinmei.org (Postfix) with ESMTP id 529D5355E4; Wed, 28 Apr 2004 19:28:28 +0900 (JST) Date: Wed, 28 Apr 2004 19:28:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Iljitsch van Beijnum Cc: ipv6@ietf.org Subject: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) In-Reply-To: <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.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=none autolearn=no version=2.60 Note: I'm responding to an old message not to restart the "deprecation" discussion, but to make progress on how we can clarify the things about these flags, assuming we have agreed on keeping them. My point in this message is that IMO we should specify the protocols corresponding to these flags clearly and concretely, without leaving any ambiguity (I've changed the subject accordingly.) That is, I strongly believe we should clearly say in rfc2462bis, *for example*, - the protocol that should be invoked by the M flag is DHCPv6 (RFC3315), and nothing else - the protocol that should be invoked by the O flag is stateless DHCPv6 (RFC3736), and nothing else >>>>> On Sat, 24 Apr 2004 11:23:39 +0200, >>>>> Iljitsch van Beijnum said: >> So are you proposing to keep the flags but leave the semantics (e.g., >> what the "stateful" protocol is) unclear as currently is? If so, I >> disagree for two reasons. >> First, it will easily cause confusion and interoperability problems to >> leave it unclear. In fact, we have seen the confusion due to the >> unclear specification since RFC2462 (or even since RFC1970), and this >> is exactly the reason why we are now trying to clarify this point. > Can you elaborate? I agree that some confusion is possible, but since > there are many interoperable implementations, I don't see how this can > lead to real-world problems. What we have seen is some confusion among implementors. What I expect if we continue to keep the specification unclear is real-world problems. One important difference is that now we have (at least) RFC3315 and RFC3736 standardized as RFCs, and it will be more likely for implementors to implement these protocols based on their interpretation of the O/M flags, increasing the risk of making the confusion real-world problems. (Not sure if this is the elaboration you wanted, but I don't see anything unclear in what I said in the quoted part above.) >> Secondly, if the situation is that immature, why can't we simply >> deprecate the flags for now and leave the flexibility for future >> extension? > Good question. > I believe that some information in RAs that guides the discovery and > configuration process is probably necessary in the future. We have > these two bits now. Suppose we remove them from the spec, and then in a > few years we really know what we need and introduce a new, better > mechanism. This gives us nine combinations of implementations to worry > about: hosts according to RFC 2462, 2462bis and 2462ter on the one > hand, and routes according to RFC 2462, 2462bis and 2462ter on the > other hand. Worse, we probably have to support at least coexistance of > hosts with different implementations on the same link at the same time > for a significant number of years. > Now consider the situation where we don't change the bits right now but > they are changed at some point in the future. This only gives us four > combinations to worry about: old host + old router, old host + new > router, new host + old router and new host + new router. That's less > than half the combinations. Also, if we are to change the bits, new > implementations would still have to recognize them to be backward > compatible so the change doesn't make any difference to code that is > cut any time soon. This is exactly why I want to be very clear on the protocols invoked by these flags. For example, if we leave it ambiguous what is the protocol that should be invoked by the O flag, we'll see many kinds of host implementations regarding the protocol; one may invoke the full DHCPv6 (RFC3315) client. Another one may invoke stateless DHCPv6 (RFC3736) client. We may see yet another one that invokes SLP client. Then we'll have hosts according to 2462bis-RFC3315, 2462bis-RFC3736, 2462bis-SLP, 2462bis-xxx, ... One thing I'm worried about in the past discussion is that there seems to be an opinion that the implementation/deployment status for RFC3315/RFC3736 is too immature to be clearly specified for the M/O flags (but in a different context, disagreeing the idea of deprecating the flags). If this type of opinion also indicates that we should rather keep the corresponding protocols ambiguous, I strongly disagree. In fact, I'd rather "deprecate" these flags, whatever it means, than to keep them ambiguous (I hope we won't have to fight this discussion again). (Meanwhile, I would have answered in the previous thread that this should be almost non issue in a practical sense while this is surely an issue theoretically. Since there are almost no host implementations for the M/O flags, we'd still have actually old+new implementations regardless of whether we deprecate the flags or not. Similarly, setting these flags on RFC2462 routers has no effect in a practical sense, so we'd still have old+new implementations regardless of whether we deprecate the flags or not. But I'm not intending to fight for this discussion, so you don't have to be bothered to make a counter argument on this part.) > Now lets focus our attention on what we want to accomplish > operationally. (snip) > In other words: > M = 0, O = 0: Do stateless address configuration and start to > communicate. > If DHCP is done, it's in the background. DHCP complements > static and RA other configuration. > M = 0, O = 1: Do stateless address configuration and complete DHCP > before initiating communication that requires other > configuration. > DHCP overwrites static and RA other configuration. > M = 1, O = 0: Do DHCP. If DHCP succeeds, don't do stateless address > configuration. Start to communicate after DHCP succeeds or > after DHCP fails and stateless address configuration > succeeds. Static and RA other configuration complement > DHCP. > M = 1, O = 1: Do DHCP. If DHCP succeeds, don't do stateless address > configuration. Start to communicate after DHCP succeeds or > after DHCP fails and stateless address configuration > succeeds. DHCP overwrites static and RA other > configuration. I don't have a strong opinion on whether we should specify in rfc2462bis this level of details for all the combinations of the flags; at the moment my take is not to describe this. But if others also want to include the specification and if we can quickly agree on a particular behavior, I don't mind to contain the result. In any event, I have a concern with the phrase of "RA other configuration". First, it's not clear what the phrase means. I guess you intended something like so called "DNS (recursive) server option in RA", but such a thing is quite controversial; there is even a discussion on whether we need this type of information in RA in the first place. So, considering the "conservative" aspect of rfc2462bis work, I don't think rfc2462bis can contain this type of immature notion. (I don't necessarily oppose to discussion about such a notion in a separate document as an extension or further clarifiation to 2462/2462bis.) And finally... (the following is not a comment from a technical point view, but I'm going to make it because I think it will be helpful to make further discussion productive. But in any event I'll refrain from making further posts on this particular topic since it's surely off-topic.) >>> I implore this wg to venture out into the real world and ask operators >>> what they need to be able to use IPv6 rather than regurgitate the same >>> RFCs over and over. This goes double for v6ops. >> A general comment, again...so what exactly are you proposing for this >> particular issue? Even though main subscribers in this list are >> implementors, I'm quite sure that we also have many operators here. >> In fact, I'm running IPv6 networks of my own. I also know operators >> working for major ISPs subscribe to this list. > If you compare the various IPv6-related lists (this one, v6ops and even > dnsops) with interdomain routing related ones such as grow and even > idr, it is apparent that most of the focus with IPv6 is on building > specifications based on theoretical considerations. I see very little > operational feedback. This is especially apparent with regard to the > DNS configuration issue. You have complained about this kind of general topics in the "deprecation" thread. I'm not sure about your real intention because it was too generic. If you've been just complaining about (recent?) decision process in the IETF, I sort of have sympathy with you. But it's irrelevant to this particular discussion (at least it does not have a direct relationship), so please do that somewhere else (you may want to go to open mike sessions in IETF meetings :-) On the other hand, if you have tried to claim that the proposal in the previous thread just came from theoretical considerations without venturing the real world and/or asking operators (and thus that the proposal was bad), I'd refute the argument by the following two points: - first, I believe I made the proposal based on my experiences of "venturing the real world and asking operators", rather than "theoretical considerations" (see below). If something that I proposed was not so convincing for you, it would probably because I failed to convey my experience very well, not because I made it based on "theoretical considerations". BTW: How can you be sure that a person that you are not very familiar with is making an argument just from theoretical considerations? Different people have different backgrounds of "venturing the real world", and it's hard for a third party person to prove that an argument based on a different background really comes from "theoretical considerations". With all due respect, you seem to have been insisting that opinions based on a different operational background than yours are just based on "theoretical considerations." - secondly, and more importantly, even if you can prove that someone is making an argument just from "theoretical considerations", does it help anything to complain about the fact? I must admit I might be not very convincing in some (or most?) cases, but then you can just point out the flaw of the argument, rather than complaining about what the argument comes from. At least I'm always willing to be corrected when I'm wrong, whether the counter argument is based on "real world experience" or on "theoretical considerations", as long as it is reasonable. You've actually made very good technical points, which I think are necesary and sufficient to have productive discussions. It would really be helpful to concentrate on the technical points, without complaining about what arguments come from. It is in general difficult to prove the background of an argument, and even if you can do that, I don't think it helps anything. As an appendix, I'm going to argue that I've made my proposals based on my own experience of "venturing the real world and asking operators" by describing who I believe I am. If you still think I've been acting just based on "theoretical considerations", please feel free to defeat me by proving that, either in a unicast response or a response on the list (though I won't make further responses in public). I operate my own IPv6 networks. I operate IPv6 routers from various vendors, I've configured and do manage an IPv6 firewall, and I've set up and do operate IPv6 web/ftp/DNS/mail servers. I'm struggling with the migration from ip6.int to ip6.arpa, and I admit it's weird. (For that matter, I was not there when the decision was made.) I've also developed, and I'm still developing, IPv6 related products. I've implemented neighbor discovery and stateless address autoconfiguration (with my co-workers), I've implemented stateless and stateful DHCPv6 servers/clients/relay agents. I'm using IPv6 every day. I read or send email over IPv6, log in to remote hosts by ssh over IPv6, browse web pages over IPv6 when reachable via IPv6, and so on. I've configured several routers in my networks so that they set the O flag in router advertisements, and have seen how it could interact with my stateless DHCPv6 client. When and where available, I configure the recursive resolver's address on my laptop through the stateless DHCPv6 client. I've seen several problems during my experience, on which I've presented my opinion/proposal here. I have several friends and co-works who work for ISPs operating their IPv6 networks. I often have a chance to discuss operational issues of IPv6 they face with them, and I at least have tried to reflect the results of such discussions in technical discussion in the IETF. 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 Apr 28 10:39: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 KAA18801 for ; Wed, 28 Apr 2004 10:39: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 1BIq5U-0006jr-AI for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 10:31:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SEV0AA025897 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 10:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoz2-0003uC-82 for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 09:20: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 JAA14270 for ; Wed, 28 Apr 2004 09:20: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 1BIoz0-0003fn-Lw for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 09:20:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIoxw-0003WA-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 09:19:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIowr-0003Pr-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 09:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIocJ-00076t-VE; Wed, 28 Apr 2004 08:56:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoCS-0003KE-0c for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 08:30: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 IAA12163 for ; Wed, 28 Apr 2004 08:30: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 1BIoCQ-0004QW-OE for ipv6@ietf.org; Wed, 28 Apr 2004 08:30:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIoBT-000494-00 for ipv6@ietf.org; Wed, 28 Apr 2004 08:29:03 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BIoAg-0003re-00 for ipv6@ietf.org; Wed, 28 Apr 2004 08:28:14 -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 i3SCSD7s015025 for ; Wed, 28 Apr 2004 13:28:13 +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 NAA06865 for ; Wed, 28 Apr 2004 13:28:11 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i3SCSBv07646 for ipv6@ietf.org; Wed, 28 Apr 2004 13:28:11 +0100 Date: Wed, 28 Apr 2004 13:28:11 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Message-ID: <20040428122811.GB7397@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> 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 Wed, Apr 28, 2004 at 07:28:39PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > My point in this message is that IMO we should specify the protocols > corresponding to these flags clearly and concretely, without leaving > any ambiguity (I've changed the subject accordingly.) That is, I > strongly believe we should clearly say in rfc2462bis, *for example*, > > - the protocol that should be invoked by the M flag is DHCPv6 > (RFC3315), and nothing else > - the protocol that should be invoked by the O flag is stateless > DHCPv6 (RFC3736), and nothing else But in reality nodes will have full DHCPv6 client support in them (3315) whether or not they then see the M or O flag that is what they will use? All the DHCPv6 servers implemented to date, to my knowledge, are 3315 and not the 3736 subset. So it is better to just say O flag is other (non address) configuration data, regardless of full/subset of DHCPv6 used? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 28 10:39:40 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18824 for ; Wed, 28 Apr 2004 10:39: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 1BIq63-0007Sk-50 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 10:31:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SEVZDD028682 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 10:31:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIozN-0003vu-Mo for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 09:20: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 JAA14323 for ; Wed, 28 Apr 2004 09:20: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 1BIozM-0003ig-4L for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 09:20:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIoy8-0003YT-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 09:19:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIoxD-0003Qp-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 09:18:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIocO-0007Ao-VG; Wed, 28 Apr 2004 08:56:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoTh-0005bY-SS for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 08:47: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 IAA12637 for ; Wed, 28 Apr 2004 08:47: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 1BIoTg-0001VS-HA for ipv6@ietf.org; Wed, 28 Apr 2004 08:47:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIoSl-0001FZ-00 for ipv6@ietf.org; Wed, 28 Apr 2004 08:46:56 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BIoS1-0000zc-00 for ipv6@ietf.org; Wed, 28 Apr 2004 08:46:10 -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 i3SCk2nY029165 for ; Wed, 28 Apr 2004 15:46:02 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) id i3SCk2Fs029162; Wed, 28 Apr 2004 15:46:02 +0300 Date: Wed, 28 Apr 2004 15:46:02 +0300 Message-Id: <200404281246.i3SCk2Fs029162@burp.tkv.asdf.org> From: Markku Savela To: ipv6@ietf.org In-reply-to: (message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= on Wed, 28 Apr 2004 19:28:39 +0900) Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.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 I believe DHCP for IPv6 is totally incorrect direction. It's a leftover dinosaur from IPv4 way of thinking. The whole DHCP6 concept should not have been designed. Instead, the effort should have gone to extend the standard IPv6 configuration framework: neighbor discovery. If configuration is needed, add new messages to the ND ICMP's, or options to the router advertisement. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 28 12:19:41 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 MAA25440 for ; Wed, 28 Apr 2004 12:19: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 1BIrb1-00049v-Cy for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 12:07:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SG7dvi015987 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 12:07:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrQ1-0001KY-O3 for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 11:56: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 LAA23599 for ; Wed, 28 Apr 2004 11:56: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 1BIrPz-00027q-9F for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 11:56:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrNK-0001Z2-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 11:53:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIrLs-0001JL-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 11:52:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIrIr-0002mr-Bb for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 11:48:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIr1b-00022j-Gv; Wed, 28 Apr 2004 11:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqqJ-0008A3-1v for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 11:19: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 LAA21094 for ; Wed, 28 Apr 2004 11:19: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 1BIqqG-0006Gl-QT for ipv6@ietf.org; Wed, 28 Apr 2004 11:19:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqpK-0006D3-00 for ipv6@ietf.org; Wed, 28 Apr 2004 11:18:22 -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 1BIqp5-000693-00 for ipv6@ietf.org; Wed, 28 Apr 2004 11:18:07 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2004 07:29:31 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SFHYW9005190 for ; Wed, 28 Apr 2004 08:17:34 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHX95285; Wed, 28 Apr 2004 11:17:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20040428111501.01f5db08@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Apr 2004 11:17:05 -0400 To: ipv6@ietf.org From: Ralph Droms Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) In-Reply-To: <200404281246.i3SCk2Fs029162@burp.tkv.asdf.org> References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.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 Well, picking up the thrown gauntlet - can't resist just this once - if the IETF hadn't spent so much time deciding how many spokes to put on all the wheels being reinvented, we'd have a complete and fully operational set of specs for a deployable IPv6 service by now. - Ralph At 03:46 PM 4/28/2004 +0300, Markku Savela wrote: >I believe DHCP for IPv6 is totally incorrect direction. It's a >leftover dinosaur from IPv4 way of thinking. > >The whole DHCP6 concept should not have been designed. Instead, the >effort should have gone to extend the standard IPv6 configuration >framework: neighbor discovery. > >If configuration is needed, add new messages to the ND ICMP's, or >options to the router advertisement. > > >-------------------------------------------------------------------- >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 Apr 28 12:28:37 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 MAA26418 for ; Wed, 28 Apr 2004 12:28:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrlg-0007uF-IT for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 12:18:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SGIee5030391 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 12:18:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrVD-000370-BL for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 12:01: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 MAA24519 for ; Wed, 28 Apr 2004 12:01: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 1BIrVA-0002rm-Ua for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 12:01:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrUM-0002mq-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 12:00:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIrTN-0002hs-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 11:59:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrLt-0000EE-ML; Wed, 28 Apr 2004 11:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIr3R-0002FH-Dc for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 11:32: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 LAA21774 for ; Wed, 28 Apr 2004 11:32: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 1BIr3P-0007Sn-3c for ipv6@ietf.org; Wed, 28 Apr 2004 11:32:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIr2b-0007LX-00 for ipv6@ietf.org; Wed, 28 Apr 2004 11:32:06 -0400 Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx with esmtp (Exim 4.12) id 1BIr0H-0007GB-00 for ipv6@ietf.org; Wed, 28 Apr 2004 11:29:41 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:1036:dc74:13f8:73e0]) by tachyon.jinmei.org (Postfix) with ESMTP id 97811355E4; Thu, 29 Apr 2004 00:29:30 +0900 (JST) Date: Thu, 29 Apr 2004 00:29:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Chown 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: <20040428122811.GB7397@login.ecs.soton.ac.uk> References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> <20040428122811.GB7397@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=none autolearn=no version=2.60 >>>>> On Wed, 28 Apr 2004 13:28:11 +0100, >>>>> Tim Chown said: >> My point in this message is that IMO we should specify the protocols >> corresponding to these flags clearly and concretely, without leaving >> any ambiguity (I've changed the subject accordingly.) That is, I >> strongly believe we should clearly say in rfc2462bis, *for example*, >> >> - the protocol that should be invoked by the M flag is DHCPv6 >> (RFC3315), and nothing else >> - the protocol that should be invoked by the O flag is stateless >> DHCPv6 (RFC3736), and nothing else > But in reality nodes will have full DHCPv6 client support in them (3315) > whether or not they then see the M or O flag that is what they will use? > All the DHCPv6 servers implemented to date, to my knowledge, are 3315 and > not the 3736 subset. > So it is better to just say O flag is other (non address) configuration > data, regardless of full/subset of DHCPv6 used? Aghhh....you have jumped to the next stage. I didn't intend to propose any particular protocols for the M/O flags in the above message. I first wanted to make it clear that we should clearly specify particular protocols for the M/O flags, whatever they are. That's why I emphasized the phrase "for example" by the set of asterisks. (In fact, I planned to add another note e.g., "even if we can agree on this approach, which protocol should be used for each flag is a separate question". I thought this was clear by the emphasized "for example", but apparently I was naive...) Since discussions in this thread has tend to diverge, please make it step-by-step. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. since you've already made a further step anyway, I'd clarify one thing at the moment: > All the DHCPv6 servers implemented to date, to my knowledge, are 3315 and > not the 3736 subset. This is not correct. The DHCPv6 server provided by the KAME project conforms to RFC3736, but does not fully conform to RFC3315. More importantly, there should be few implementations that conform to RFC3315 including the ability of configuring IPv6 addresses by DHCPv6. 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 Apr 28 12:51: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 MAA28144 for ; Wed, 28 Apr 2004 12:51: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 1BIsB5-000548-4n for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 12:44:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SGitP0019466 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 12:44:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrxw-0002Gx-RR for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 12:31: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 MAA26792 for ; Wed, 28 Apr 2004 12:31: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 1BIrxu-0005Dn-2i for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 12:31:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrwx-00058Q-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 12:30:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIrw7-00052c-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 12:29:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrm3-0007zU-8h; Wed, 28 Apr 2004 12: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 1BIrZ3-0003i6-55 for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 12:05: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 MAA24614 for ; Wed, 28 Apr 2004 12:05: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 1BIrZ0-0003AG-Hj for ipv6@ietf.org; Wed, 28 Apr 2004 12:05:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrY3-000369-00 for ipv6@ietf.org; Wed, 28 Apr 2004 12:04:36 -0400 Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx with esmtp (Exim 4.12) id 1BIrXe-00032W-00 for ipv6@ietf.org; Wed, 28 Apr 2004 12:04:10 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:1036:dc74:13f8:73e0]) by tachyon.jinmei.org (Postfix) with ESMTP id 31BAB355E4; Thu, 29 Apr 2004 01:04:02 +0900 (JST) Date: Thu, 29 Apr 2004 01:04:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela 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: <200404281246.i3SCk2Fs029162@burp.tkv.asdf.org> References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> <200404281246.i3SCk2Fs029162@burp.tkv.asdf.org> 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=none autolearn=no version=2.60 >>>>> On Wed, 28 Apr 2004 15:46:02 +0300, >>>>> Markku Savela said: > I believe DHCP for IPv6 is totally incorrect direction. It's a > leftover dinosaur from IPv4 way of thinking. > The whole DHCP6 concept should not have been designed. Instead, the > effort should have gone to extend the standard IPv6 configuration > framework: neighbor discovery. > If configuration is needed, add new messages to the ND ICMP's, or > options to the router advertisement. Well, I don't understand in which context you're making the above points because you even did not refer to any part in this thread... If you are trying to propose a particular action for the M/O flags in rfc2462bis, please clearly make your proposal. Otherwise, (and especially if it is not related to any part of rfc2462bis) please make a separate thread to discuss your opinion. 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 Wed Apr 28 13:04: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 NAA29015 for ; Wed, 28 Apr 2004 13: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 1BIsGV-0006DF-Rd for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 12:50:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SGoV0N023874 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 12:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIs9G-0004id-5d for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 12:43: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 MAA27498 for ; Wed, 28 Apr 2004 12:42: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 1BIs9D-0005pM-Co for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 12:42:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIs8J-0005kI-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 12:42:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIs7Q-0005gJ-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 12:41:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrvq-0001eB-Ev; Wed, 28 Apr 2004 12:29:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrlo-0007vx-29 for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 12: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 MAA25336 for ; Wed, 28 Apr 2004 12:18: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 1BIrll-0004HB-8P for ipv6@ietf.org; Wed, 28 Apr 2004 12:18:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrkn-0004E2-00 for ipv6@ietf.org; Wed, 28 Apr 2004 12:17:46 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BIrjz-000473-00 for ipv6@ietf.org; Wed, 28 Apr 2004 12:16:55 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2004 09:15: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 i3SGGJYu015042 for ; Wed, 28 Apr 2004 12:16:19 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHY02175; Wed, 28 Apr 2004 12:16:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20040428120350.02ae0f10@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Apr 2004 12:16:15 -0400 To: ipv6@ietf.org From: Ralph Droms Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) In-Reply-To: <20040428122811.GB7397@login.ecs.soton.ac.uk> References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.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 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. - Ralph At 01:28 PM 4/28/2004 +0100, Tim Chown wrote: >On Wed, Apr 28, 2004 at 07:28:39PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > > > My point in this message is that IMO we should specify the protocols > > corresponding to these flags clearly and concretely, without leaving > > any ambiguity (I've changed the subject accordingly.) That is, I > > strongly believe we should clearly say in rfc2462bis, *for example*, > > > > - the protocol that should be invoked by the M flag is DHCPv6 > > (RFC3315), and nothing else > > - the protocol that should be invoked by the O flag is stateless > > DHCPv6 (RFC3736), and nothing else > >But in reality nodes will have full DHCPv6 client support in them (3315) >whether or not they then see the M or O flag that is what they will use? > >All the DHCPv6 servers implemented to date, to my knowledge, are 3315 and >not the 3736 subset. > >So it is better to just say O flag is other (non address) configuration >data, regardless of full/subset of DHCPv6 used? > >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 Wed Apr 28 13:14: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 NAA29690 for ; Wed, 28 Apr 2004 13:14: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 1BIsUJ-0000qQ-TF for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 13:04:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SH4lJE003247 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 13:04:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsLK-0007Kp-VL for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 12:55: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 MAA28406 for ; Wed, 28 Apr 2004 12:55: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 1BIsLI-0006aj-2t for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 12:55:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsKL-0006Xs-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 12:54:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsJn-0006VB-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 12:53:55 -0400 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" Content-Transfer-Encoding: 7bit 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] 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 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 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 28 13:22:53 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 NAA00510 for ; Wed, 28 Apr 2004 13:22: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 1BIsWE-0001XL-EU for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 13:06:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SH6kUR005893 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 13:06:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsQz-00008D-TQ for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:01: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 NAA28756 for ; Wed, 28 Apr 2004 13:01: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 1BIsQw-0006ud-Rv for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 13:01:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsPz-0006r4-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 13:00:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsP6-0006oF-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 12:59:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsCC-0005Iq-DU; Wed, 28 Apr 2004 12:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIs3G-0002v2-Kd for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 12:36: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 MAA27118 for ; Wed, 28 Apr 2004 12:36: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 1BIs3D-0005Ss-6E for ipv6@ietf.org; Wed, 28 Apr 2004 12:36:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIs2H-0005RT-00 for ipv6@ietf.org; Wed, 28 Apr 2004 12:35:51 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BIs1k-0005Pj-00 for ipv6@ietf.org; Wed, 28 Apr 2004 12:35:16 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3SGZ21C018748; Wed, 28 Apr 2004 18:35:02 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <018DF770-9932-11D8-BCF0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Date: Wed, 28 Apr 2004 18:35:06 +0200 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= 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 On 28-apr-04, at 12:28, JINMEI Tatuya / $B?@L@C#:H(B wrote: > For example, if we leave it ambiguous what is the > protocol that should be invoked by the O flag, we'll see many kinds of > host implementations regarding the protocol; one may invoke the full > DHCPv6 (RFC3315) client. Another one may invoke stateless DHCPv6 > (RFC3736) client. (My apologies for having to ask, but life is short and wgs are aplenty...) What is the difference between stateful and stateless DHCPv6 anyway, as seen from the client? It seems a bit strange to me that the client should care about the internals of the server. > We may see yet another one that invokes SLP client. > Then we'll have hosts according to 2462bis-RFC3315, 2462bis-RFC3736, > 2462bis-SLP, 2462bis-xxx, ... Yes. I appreciate that life would be much simpler without having all these different options to support. But don't you think that people running networks may have very good reasons to prefer one protocol over another? So unless one protocol is so great that it suits everyone's needs, this will happen whether we put it in an RFC or not. I think it makes sense to face this reality now but I don't see how what we do in this reggard makes life for people running networks much harder so I don't feel too strongly about it. >> M = 0, O = 0: Do stateless address configuration and start to >> communicate. >> If DHCP is done, it's in the background. DHCP >> complements >> static and RA other configuration. >> M = 0, O = 1: Do stateless address configuration and complete DHCP >> before initiating communication that requires other >> configuration. >> DHCP overwrites static and RA other configuration. >> M = 1, O = 0: Do DHCP. If DHCP succeeds, don't do stateless address >> configuration. Start to communicate after DHCP >> succeeds or >> after DHCP fails and stateless address configuration >> succeeds. Static and RA other configuration complement >> DHCP. >> M = 1, O = 1: Do DHCP. If DHCP succeeds, don't do stateless address >> configuration. Start to communicate after DHCP >> succeeds or >> after DHCP fails and stateless address configuration >> succeeds. DHCP overwrites static and RA other >> configuration. > I don't have a strong opinion on whether we should specify in > rfc2462bis this level of details for all the combinations of the > flags; at the moment my take is not to describe this. But if others > also want to include the specification and if we can quickly agree on > a particular behavior, I don't mind to contain the result. The question is: what kind of bad stuff happens when people implement different ways to do this? If the answer is: lots of stuff, then we probably need something like this in the document. If the answer is: nothing much, then there is little need to bother. > In any event, I have a concern with the phrase of "RA other > configuration". First, it's not clear what the phrase means. That's a feature, not a bug. :-) There is always a tradeoff between being specific and being general. In theory, RAs can contain all kinds of interesting information, although in practice this info is fairly limited to stuff like the link MTU. > I guess > you intended something like so called "DNS (recursive) server option > in RA", but such a thing is quite controversial; That's why it's better to look at the general mechanism rather than any specific type of use of the mechanism. RA is mentioned along with static configuration, which is of course completely non-controversial as a source for recursive DNS server addresses. > there is even a > discussion on whether we need this type of information in RA in the > first place. So, considering the "conservative" aspect of rfc2462bis > work, I don't think rfc2462bis can contain this type of immature > notion. If you are 100% sure that there will not be any information that can be both in DHCPv6 and in RAs I agree. > (the following is not a comment from a technical point view, but I'm > going to make it because I think it will be helpful to make further > discussion productive. But in any event I'll refrain from making > further posts on this particular topic since it's surely off-topic.) Hm... >> If you compare the various IPv6-related lists (this one, v6ops and >> even >> dnsops) with interdomain routing related ones such as grow and even >> idr, it is apparent that most of the focus with IPv6 is on building >> specifications based on theoretical considerations. I see very little >> operational feedback. This is especially apparent with regard to the >> DNS configuration issue. > You have complained about this kind of general topics in the > "deprecation" thread. I'm not sure about your real intention because > it was too generic. Since you bring it up... I'm highly frustrated by the fact that if I bring my laptop to a place with IPv6 connectivity, I can't just connect to the network and enjoy the benefits of said IPv6 connectivity because there is no way to automatically configure DNS resolvers. And even worse than the fact that after nearly a decade such a simple yet important thing hasn't been solved is the fact that there is a significant number of people actually blocking this for various reasons that obviously make sense to them but not to me. Although this is the most egregious example, it's not the only one. I already mentioned ip6.int/ip6.arpa, then there is the fact that it took 8 years to figure out that site locals are a non-starter, the RIR/IANA publish an IPv6 address policy and then don't stick to that policy. That kind of thing. Now I appreciate the fact that going out in the world with a certain view of how things work and then expecting everyone and everything to conform to this view is the quick road towards disappointment, but I think all of this goes beyond that. IPv6 is a huge project and obviously mistakes will be made in such projects. But if the question how all of this plays out in the real world isn't given much attention, if any, there are deeper issues. > If you've been just complaining about (recent?) decision process in > the IETF, I sort of have sympathy with you. But it's irrelevant to > this particular discussion (at least it does not have a direct > relationship), so please do that somewhere else (you may want to go to > open mike sessions in IETF meetings :-) I promise I'll be at the next one that's in a country where you don't have to submit to finger printing like a common criminal to get in. > On the other hand, if you have tried to claim that the proposal in the > previous thread just came from theoretical considerations without > venturing the real world and/or asking operators (and thus that the > proposal was bad), I'd refute the argument by the following two > points: > - first, I believe I made the proposal based on my experiences of > "venturing the real world and asking operators", rather than > "theoretical considerations" (see below). Ok. Note by the way that theoretical considerations are not bad, they are hugely important. But while in theory there is no difference between theory and practice, in practice there is. We need both. > BTW: How can you be sure that a person that you are not very > familiar with is making an argument just from theoretical > considerations? Different people have different backgrounds of > "venturing the real world", and it's hard for a third party person > to prove that an argument based on a different background really > comes from "theoretical considerations". With all due respect, > you seem to have been insisting that opinions based on a different > operational background than yours are just based on "theoretical > considerations." You are right, I spoke too harshly. All of this is in the eye of the beholder: what happens here _seems_ mostly theoretical with little operational considerations to me, but I'm not qualified to determine whether this is actually so. > You've actually made very good technical points, which I think are > necesary and sufficient to have productive discussions. It would > really be helpful to concentrate on the technical points, without > complaining about what arguments come from. I agree and that's why you see much more technical points than general complaints from me. > I operate my own IPv6 networks. I operate IPv6 routers from various > vendors, I've configured and do manage an IPv6 firewall, and I've set > up and do operate IPv6 web/ftp/DNS/mail servers. Ok, going to be very careful now, as I certainly don't want to repeat my earlier mistake. But... (there is always a but.) I am somewhat familiar with the (IPv4) interdomain routing world. When I compare the issues that are relevant in IPv4 idr with what happens in IPv6 idr, it's hard to avoid the impression that lots of stuff that happens in IPv6 is fairly amateurish. Obviously there are many people who are very skilled and know exactly what they're doing in IPv6, but there is also a considerable group that's mostly playing around without much clue of real-world issues. For instance, there is a significant issue in IPv6 that "everyone gives everyone transit": many networks are so impressed by the fact that they're running IPv6 that they provide transit service to every other network they're connected to, often over tunnels and sometimes without even telling the other party that they're doing this. With the result that a while ago IPv6 connectivity was much hampered by the fact that the real network topology was hidden from BGP so lots of traffic want over tunnels where it didn't need to. Fortunately this is getting much better relatively fast now. Another issue is that since there are few real-world concerns ("do XXX or you'll lose my business") in IPv6 so a significant number of networks has policies that represent how the administrator of that network views the world rather than what makes sense in running a commercial network. So I guess what I'm saying is "where is Randy Bush when you need him". (-: -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 28 13:51:12 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03180 for ; Wed, 28 Apr 2004 13:51: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 1BIt6X-0002jB-EJ for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 13:44:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHiH33010478 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 13:44:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIswS-0000Kf-Bt for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:33: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 NAA01690 for ; Wed, 28 Apr 2004 13:33: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 1BIswO-0001i8-Rb for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 13:33:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsvN-0001cm-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 13:32:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsun-0001Xi-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 13:32:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsnu-0006fY-Qi; Wed, 28 Apr 2004 13:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsWv-0001oe-9g for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 13:07: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 NAA29357 for ; Wed, 28 Apr 2004 13:07: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 1BIsWr-0007NF-Ts for ipv6@ietf.org; Wed, 28 Apr 2004 13:07:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsW3-0007Jw-00 for ipv6@ietf.org; Wed, 28 Apr 2004 13:06:36 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BIsVK-0007Dc-00 for ipv6@ietf.org; Wed, 28 Apr 2004 13:05:50 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 28 Apr 2004 10:19:08 -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 i3SH5J6L016651; Wed, 28 Apr 2004 13:05:19 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHY07689; Wed, 28 Apr 2004 13:05:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20040428130309.02e78a90@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Apr 2004 13:05:16 -0400 To: "Christian Huitema" From: Ralph Droms Subject: RE: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Cc: =?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , "Tim Chown" , 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 Christian - where have you seen phrases like "do DHCP, and only if it fails do auto-config." They are clearly wrong. SLAAC and DHCPv6 are clearly independent - a host can use neither, one or the other or both - and are controlled independently. If that independence is not clear in the specs, than we should fix the text in the specs. - Ralph At 09:29 AM 4/28/2004 -0700, Christian Huitema wrote: >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 28 13:57:37 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03690 for ; Wed, 28 Apr 2004 13:57:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt9C-0003Ri-A8 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 13:47:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHl28g013242 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 13:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt4i-0002Kf-Gw for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:42: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 NAA02430 for ; Wed, 28 Apr 2004 13:42:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIt4f-0002NS-3t for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 13:42:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIt3i-0002Hc-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 13:41:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIt2i-0002B2-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 13:40:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIssm-0007lE-GO; Wed, 28 Apr 2004 13:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsfi-0004Iv-LS for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 13:16: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 NAA29970 for ; Wed, 28 Apr 2004 13:16: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 1BIsff-0000Dw-C9 for ipv6@ietf.org; Wed, 28 Apr 2004 13:16:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsf8-000095-00 for ipv6@ietf.org; Wed, 28 Apr 2004 13:15:58 -0400 Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx with esmtp (Exim 4.12) id 1BIseC-0007kp-00 for ipv6@ietf.org; Wed, 28 Apr 2004 13:15: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 i3SHF7t08759; Wed, 28 Apr 2004 10:15:07 -0700 (PDT) Received: from lapin (lapin [192.88.122.33]) by leo.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id i3SHF6H28492; Wed, 28 Apr 2004 10:15:07 -0700 (PDT) Subject: RE: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) From: Tim Hartrick Reply-To: tim@mentat.com To: Christian Huitema Cc: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= , Tim Chown , ipv6@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Mentat Inc. Message-Id: <1083172435.1875.9.camel@lapin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 28 Apr 2004 10:13:59 -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 Christian, On Wed, 2004-04-28 at 09:29, Christian Huitema wrote: > 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: > Hmmm... My understanding of RFC 2462 section 5.5.3 is that it already treats the M flag as you said it should. That is, the M flag does not prohibit the processing of prefix options. The same is true of the O flag. Is there text elsewhere which implies otherwise? > 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. I think that this is the approach that was originally intended. If there is text in the RFC which says that the M flag and auto-config are mutually exclusive, that text is wrong and should be corrected. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 28 14:22: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 OAA05492 for ; Wed, 28 Apr 2004 14:22: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 1BItcr-0001gH-8A for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 14:17:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SIHfsW006455 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 14:17:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItVr-000051-Dy for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:10: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 OAA04743 for ; Wed, 28 Apr 2004 14:10: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 1BItVn-0004OE-JG for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:10:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItUp-0004HV-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:09:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BItTx-0004CN-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:08:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItIu-0005W4-C6; Wed, 28 Apr 2004 13:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt8q-0003Ho-9e for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 13:46: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 NAA02851 for ; Wed, 28 Apr 2004 13:46: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 1BIt8m-0002ih-Ox for ipv6@ietf.org; Wed, 28 Apr 2004 13:46:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIt7v-0002e5-00 for ipv6@ietf.org; Wed, 28 Apr 2004 13:45:44 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BIt77-0002Wn-00 for ipv6@ietf.org; Wed, 28 Apr 2004 13:44:53 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3SHgG212071; Wed, 28 Apr 2004 10:42:16 -0700 X-mProtect: <200404281742> 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 smtpdDbdmRK; Wed, 28 Apr 2004 10:42:13 PDT Message-ID: <408FECFD.6070202@iprg.nokia.com> Date: Wed, 28 Apr 2004 10:42:21 -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: Ralph Droms CC: Christian Huitema , =?windows-1252?Q?JINMEI_Tatuya_/_=3F=3F=3F=3F?= , Tim Chown , ipv6@ietf.org Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) References: <4.3.2.7.2.20040428130309.02e78a90@flask.cisco.com> Content-Type: text/plain; charset=windows-1252; 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 Ralph, While the functions may be independent, wouldn't it be better if we had a unified set of messages for accessing the functions? (I'm thinking some sort of hybrid fusion of the RFC2461 ND and RFC3315 DHCPv6 messages.) Perhaps it is too late in the game to even consider this... Fred ftemplin@iprg.nokia.com Ralph Droms wrote: > Christian - where have you seen phrases like "do DHCP, and only if it > fails > do auto-config." They are clearly wrong. SLAAC and DHCPv6 are clearly > independent - a host can use neither, one or the other or both - and are > controlled independently. If that independence is not clear in the > specs, > than we should fix the text in the specs. > > - Ralph > > At 09:29 AM 4/28/2004 -0700, Christian Huitema wrote: > >> 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 >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > 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 Apr 28 14:22: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 OAA05543 for ; Wed, 28 Apr 2004 14:22: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 1BItd4-0001la-NP for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 14:17:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SIHsqR006786 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 14:17:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItak-0001FG-Av for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:15: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 OAA05185 for ; Wed, 28 Apr 2004 14:15: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 1BItag-0004pW-Ji for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:15:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItZk-0004mr-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:14:28 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BItYx-0004kD-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:13:39 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BItYz-0005Mu-QP for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:13:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItSY-0006sN-G6; Wed, 28 Apr 2004 14: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 1BItIL-0005JT-Oa for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 13:56: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 NAA03533 for ; Wed, 28 Apr 2004 13:56: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 1BItII-0003O2-5v for ipv6@ietf.org; Wed, 28 Apr 2004 13:56:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItHF-0003J1-00 for ipv6@ietf.org; Wed, 28 Apr 2004 13:55:22 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx with esmtp (Exim 4.12) id 1BItFH-0003EI-00 for ipv6@ietf.org; Wed, 28 Apr 2004 13:53:19 -0400 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3SHrF1C020218; Wed, 28 Apr 2004 19:53:15 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List From: Iljitsch van Beijnum Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Date: Wed, 28 Apr 2004 19:53:18 +0200 To: "Christian Huitema" 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 On 28-apr-04, at 18:29, Christian Huitema wrote: > 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, you are overlooking the possible situation where address configuration through DHCP is desired, but there are also hosts that don't support DHCP. In this case stateless address configuration can't be turned off. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 28 14:40: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 OAA06523 for ; Wed, 28 Apr 2004 14:40: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 1BItsA-0005AL-Jk for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 14:33:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SIXUnX019849 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 14:33:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItoL-000487-Qn for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:29: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 OAA05822 for ; Wed, 28 Apr 2004 14:29: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 1BItoI-0005Qm-04 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:29:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItnQ-0005O0-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:28:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BItmy-0005K2-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:28:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItdF-0001oW-PW; Wed, 28 Apr 2004 14:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItY5-0000oY-BA for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 14:12: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 OAA05068 for ; Wed, 28 Apr 2004 14:12: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 1BItY1-0004g5-Da for ipv6@ietf.org; Wed, 28 Apr 2004 14:12:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItXM-0004bV-00 for ipv6@ietf.org; Wed, 28 Apr 2004 14:12:00 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BItWc-0004UZ-00 for ipv6@ietf.org; Wed, 28 Apr 2004 14:11:14 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3SIBFdc021430 for ; Wed, 28 Apr 2004 12:11:15 -0600 (MDT) Received: from xpa-fe1 (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 <0HWW006967UQGG@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 28 Apr 2004 12:11:15 -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 <0HWW002ZI7UPVP@mail.sun.net> for ipv6@ietf.org; Wed, 28 Apr 2004 12:11:14 -0600 (MDT) Date: Wed, 28 Apr 2004 11:11:11 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Cc: IETF IPv6 Mailing List Message-id: <6DC5B720-993F-11D8-8F29-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: multipart/alternative; boundary="Boundary_(ID_dRkzA44vVM4loSCyUhmhKw)" References: <408D840B.4030903@innovationslab.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.0 required=5.0 tests=AWL autolearn=no version=2.60 --Boundary_(ID_dRkzA44vVM4loSCyUhmhKw) Content-type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7BIT On Apr 27, 2004, at 11:49 PM, JINMEI Tatuya / $B?@L@C#:H(B wrote: >> Ok, thanks for the clarification. IMHO, it is not OK to keep >> the document as DS with O&M given the general lack of implementation. > > Hmm, this message of yours seems to have been sent just after my > latest one...so, please let me confirm your intention. Can you or > can't you live with my revised proposal (attached below)? see proposal inline. > Regarding the process issue, I personally share your view. But I > understood the current practice of the IETF is much more generous than > I'd want to see, and I'd accept that for now. I'm not sure how the chairs can substantiate this position, as it is in violation of RFC2026. 4.1.2 Draft Standard [...[ The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. > - we may need some additional consideration for security concerns > Alain raised, but I think we can deal with them without deprecating > the flags: > + as (implicitly?) described in the node requirements draft, it's > optional to implement DHCPv6 in the first place, and the node req > document warns administrators about the implication about turning > on the M flag. Perhaps the node req draft could also add the > security concerns, and/or rfc2462bis can describe the issues in > its security consideration section. > + after all, the entire autoconfiguration mechanism using RA > (without SEND) is vulnerable to attacks from a malicious party in > the same link. It might be true that the concerns raised by Alain > increases the vulnerability, but I guess we can accept it by noting > the concerns in the security consideration section. I think the document should at minimum: - have text that analyze the security aspects of O&M - make it very clear that those bits only provide hints that there may be a DHCPv6 server and hosts MAY want to use it. - Alain. --Boundary_(ID_dRkzA44vVM4loSCyUhmhKw) Content-type: text/enriched; charset=ISO-2022-JP Content-Transfer-Encoding: 7BIT On Apr 27, 2004, at 11:49 PM, JINMEI Tatuya / Hiragino Kaku Gothic Pro$B?@L@C#:H(B wrote: Ok, thanks for the clarification. IMHO, it is not OK to keep the document as DS with O&M given the general lack of implementation. Hmm, this message of yours seems to have been sent just after my latest one...so, please let me confirm your intention. Can you or can't you live with my revised proposal (attached below)? see proposal inline. Regarding the process issue, I personally share your view. But I understood the current practice of the IETF is much more generous than I'd want to see, and I'd accept that for now. I'm not sure how the chairs can substantiate this position, as it is in violation of RFC2026. 4.1.2 Draft Standard [...[ The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. - we may need some additional consideration for security concerns Alain raised, but I think we can deal with them without deprecating the flags: + as (implicitly?) described in the node requirements draft, it's optional to implement DHCPv6 in the first place, and the node req document warns administrators about the implication about turning on the M flag. Perhaps the node req draft could also add the security concerns, and/or rfc2462bis can describe the issues in its security consideration section. + after all, the entire autoconfiguration mechanism using RA (without SEND) is vulnerable to attacks from a malicious party in the same link. It might be true that the concerns raised by Alain increases the vulnerability, but I guess we can accept it by noting the concerns in the security consideration section. I think the document should at minimum: - have text that analyze the security aspects of O&M - make it very clear that those bits only provide hints that there may be a DHCPv6 server and hosts MAY want to use it. - Alain. --Boundary_(ID_dRkzA44vVM4loSCyUhmhKw)-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 28 15:11: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 PAA09065 for ; Wed, 28 Apr 2004 15:11: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 1BIuNW-000179-92 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 15:05:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SJ5s09004278 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 15:05:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuFd-00029b-5a for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:57: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 OAA07587 for ; Wed, 28 Apr 2004 14:57: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 1BIuFZ-0007SO-1N for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:57:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuEk-0007Nm-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:56:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIuEE-0007I5-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 14:56:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIu0V-0007mG-KM; Wed, 28 Apr 2004 14:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItx2-0006ay-B0 for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 14:38: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 OAA06420 for ; Wed, 28 Apr 2004 14:38: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 1BItwy-00063L-9A for ipv6@ietf.org; Wed, 28 Apr 2004 14:38:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItvy-00060g-00 for ipv6@ietf.org; Wed, 28 Apr 2004 14:37:27 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1BItvo-0005y6-00 for ipv6@ietf.org; Wed, 28 Apr 2004 14:37:16 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3SIbHMu005343 for ; Wed, 28 Apr 2004 12:37:17 -0600 (MDT) Received: from xpa-fe1 (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 <0HWW006ZD924FV@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 28 Apr 2004 12:37:17 -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 <0HWW00BXI923GI@mail.sun.net> for ipv6@ietf.org; Wed, 28 Apr 2004 12:37:16 -0600 (MDT) Date: Wed, 28 Apr 2004 11:37:12 -0700 From: Alain Durand Subject: Re: [rfc2462bis] whether we need the M/O flags In-reply-to: <20040427092102.GD10666@login.ecs.soton.ac.uk> To: Tim Chown Cc: IETF IPv6 Mailing List Message-id: <10989DBB-9943-11D8-8F29-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: <1082968095.27019.34.camel@kummerog.uni-muenster.de> <1D60A11E-97A5-11D8-A69D-00039376A6AA@sun.com> <20040427092102.GD10666@login.ecs.soton.ac.uk> 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 Apr 27, 2004, at 2:21 AM, Tim Chown wrote: > On Mon, Apr 26, 2004 at 10:14:02AM -0700, Alain Durand wrote: >> Let me try to explain why I, as an implementor, do not like the M/O >> bits very much. >> ... > > Alain, > > Could you explain how the functionality of the O/M bits will be > replaced > within the ND/etc protocols? Or should they not be replaced? I'm not convinced they are needed in the first place. > Until now, most people have not worried about DNS resolver discovery > because > they run dual-stack networks (and thus use IPv4 transport DNS), but > hosts > autoconfiguring in an IPv6-only environment need a method to get DNS > and > other configuration info. I agree they can just try DHCPv6, rather > than > being told to do so. So is your argument that the client should > decide which > protocols to try, as per IPv4, rather than be "forced" to use DHCPv6 > when > DHCPv6 may not be secure? It has nothing to do with DHCPv6 being secure or not. I think it is up to the client to decide what to do. I have nothing against hints provided by the network that DHCPv6 may be here, but I'm not comfortable in having host being told to use it despite other configuration they may have. > But whether the client decides to use DHCP, or an RA tells it to do > so, there > is no way to know whether the DHCP response is from a real or > malicious server > (who uses authenticated DHCP? :). And if you're not using DHCP you > trust > the RA for the network settings anyway. not necessarily. You can use manual config. Or still use stateless autoconf and have an external verification. > So isn't SEND the answer to this, > rather than deprecating flags? You either run in an > authenticated/trusted > environment, or you don't... I agree with you for the M bit. Not for the O bit, as you can trivially mount attacks that were more difficult to do before. Overriding the configuration of the DNS server would be much more difficult to detect than overriding the default router. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 28 15:18:16 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 PAA09736 for ; Wed, 28 Apr 2004 15:18: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 1BIuSB-0003pG-1F for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 15:10:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SJAgt6014700 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 15:10:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuN9-0000p1-Si for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 15:05: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 PAA08234 for ; Wed, 28 Apr 2004 15:05: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 1BIuN5-0000Gl-FR for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 15:05:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuMG-0000Ea-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 15:04:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIuLc-0000BU-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 15:03:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuEx-00020w-Q2; Wed, 28 Apr 2004 14: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 1BIu5e-0008QQ-Tr for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 14:47: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 OAA06856 for ; Wed, 28 Apr 2004 14:47: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 1BIu5a-0006Y8-QM for ipv6@ietf.org; Wed, 28 Apr 2004 14:47:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIu4h-0006Vu-00 for ipv6@ietf.org; Wed, 28 Apr 2004 14:46:28 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1BIu4Q-0006TX-00 for ipv6@ietf.org; Wed, 28 Apr 2004 14:46:10 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3SIkCMu010379 for ; Wed, 28 Apr 2004 12:46:12 -0600 (MDT) Received: from xpa-fe1 (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 <0HWW0060P9GZGG@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 28 Apr 2004 12:46:12 -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 <0HWW002DU9GYVP@mail.sun.net> for ipv6@ietf.org; Wed, 28 Apr 2004 12:46:11 -0600 (MDT) Date: Wed, 28 Apr 2004 11:46:08 -0700 From: Alain Durand Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) In-reply-to: To: Christian Huitema Cc: ipv6@ietf.org, =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , Tim Chown Message-id: <4FAA3D92-9944-11D8-8F29-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: 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 Apr 28, 2004, at 9:29 AM, Christian Huitema wrote: > 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. I totally agree. More, there are cases where the hosts are using another external configuration mechanisms and forcing them to use DHCPv6 would be inappropriate. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Apr 28 17:38:49 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 RAA25042 for ; Wed, 28 Apr 2004 17:38: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 1BIwQU-0007b0-3E for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 17:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SLH6um029187 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 17:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIvxq-0003zq-CG for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 16:47: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 QAA18839 for ; Wed, 28 Apr 2004 16:47: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 1BIvxn-0002vK-66 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 16:47:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIvwq-0002l6-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 16:46:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIvvk-0002YQ-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 16:45:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIusw-0003o4-Am; Wed, 28 Apr 2004 15:38:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIum0-0001rq-10 for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 15:31:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11222; Wed, 28 Apr 2004 15:31:10 -0400 (EDT) Message-Id: <200404281931.PAA11222@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-rfc2013-update-03.txt Date: Wed, 28 Apr 2004 15:31:10 -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 : Management Information Base for the User Datagram Protocol (UDP) Author(s) : B. Fenner, J. Flick Filename : draft-ietf-ipv6-rfc2013-update-03.txt Pages : 22 Date : 2004-4-28 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2013-update-03.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-rfc2013-update-03.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-rfc2013-update-03.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-4-28153214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2013-update-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2013-update-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28153214.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 Wed Apr 28 23:57:17 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 XAA15648 for ; Wed, 28 Apr 2004 23:57: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 1BJ2aK-0007UG-7H for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 23:51:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T3peDR028775 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 23:51:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2Rp-0005lq-EB for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 23:42: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 XAA14686 for ; Wed, 28 Apr 2004 23:42: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 1BJ2Rk-0004wl-Bk for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 23:42:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2Qw-0004py-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 23:41:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ2QI-0004ik-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 23:41:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2IG-0003IE-Mz; Wed, 28 Apr 2004 23:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2CI-0001nm-Bo for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 23:26: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 XAA13780 for ; Wed, 28 Apr 2004 23:26: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 1BJ2CD-00036v-82 for ipv6@ietf.org; Wed, 28 Apr 2004 23:26:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2BJ-00031B-00 for ipv6@ietf.org; Wed, 28 Apr 2004 23:25:50 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1BJ2Ax-0002vO-00 for ipv6@ietf.org; Wed, 28 Apr 2004 23:25:27 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 0F8A55478; Wed, 28 Apr 2004 23:25: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); Wed, 28 Apr 2004 23:25: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Date: Wed, 28 Apr 2004 23:25:02 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612C923@tayexc13.americas.cpqcorp.net> Thread-Topic: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Thread-Index: AcQtOABERQ0/G9Q8RLi3edX4YsFdtwAYTOAA From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 29 Apr 2004 03:25:28.0924 (UTC) FILETIME=[9EB6C1C0:01C42D99] 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 I agree with Ralph. Also HP-UX will provide a production implementation of full DHCPv6 as product to Moonv6 for complete interoperability testing in a real world IPv6 network in August 2004. Beta will be available to Moonv6 soon for initial testing and in the UNH IOL IPv6 Lab. Linux also supports a full DHCPv6. Both of these support both m and o bits. Removing them is not an option now. Regarding DHCPv6 most users will use it instead of stateless in Enterprises for control reasons. /jim=20 > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On=20 > Behalf Of Ralph Droms > Sent: Wednesday, April 28, 2004 11:17 AM > To: ipv6@ietf.org > Subject: Re: the protocols for the M/O flags (Re:=20 > [rfc2462bis] whether we need the M/O flags) >=20 > Well, picking up the thrown gauntlet - can't resist just this=20 > once - if the IETF hadn't spent so much time deciding how=20 > many spokes to put on all the wheels being reinvented, we'd=20 > have a complete and fully operational set of specs for a=20 > deployable IPv6 service by now. >=20 > - Ralph >=20 >=20 >=20 >=20 > At 03:46 PM 4/28/2004 +0300, Markku Savela wrote: > >I believe DHCP for IPv6 is totally incorrect direction. It's=20 > a leftover=20 > >dinosaur from IPv4 way of thinking. > > > >The whole DHCP6 concept should not have been designed. Instead, the=20 > >effort should have gone to extend the standard IPv6 configuration > >framework: neighbor discovery. > > > >If configuration is needed, add new messages to the ND ICMP's, or=20 > >options to the router advertisement. > > > > > >-------------------------------------------------------------------- > >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 > -------------------------------------------------------------------- >=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 Thu Apr 29 00:00: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 AAA15856 for ; Thu, 29 Apr 2004 00:00: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 1BJ2ed-0008ER-Hd for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 23:56:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T3u7Hl031641 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 23:56:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2Uj-0006bc-NF for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 23:45: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 XAA14897 for ; Wed, 28 Apr 2004 23:45: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 1BJ2Ue-0005Iu-Gv for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 23:45:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2Ti-0005BG-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 23:44:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ2T4-00055G-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 23:44:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2II-0003IU-Iw; Wed, 28 Apr 2004 23:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2DD-0001wX-Cu for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 23:27: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 XAA13818 for ; Wed, 28 Apr 2004 23:27: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 1BJ2D8-0003Cp-6T for ipv6@ietf.org; Wed, 28 Apr 2004 23:27:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2CE-00037B-00 for ipv6@ietf.org; Wed, 28 Apr 2004 23:26:46 -0400 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1BJ2Bz-00031U-00 for ipv6@ietf.org; Wed, 28 Apr 2004 23:26:31 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 7FA359F02; Wed, 28 Apr 2004 23:26:33 -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, 28 Apr 2004 23:26: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: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Date: Wed, 28 Apr 2004 23:26:06 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612C924@tayexc13.americas.cpqcorp.net> Thread-Topic: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Thread-Index: AcQtP6BpOSGlLqMmRwqGJM2qy+FTIQAWgSLQ From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 29 Apr 2004 03:26:33.0210 (UTC) FILETIME=[C50805A0:01C42D99] 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 And if people would read the spec they would deduce for themselves what Ralph states below. /jim=20 > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On=20 > Behalf Of Ralph Droms > Sent: Wednesday, April 28, 2004 12:16 PM > To: ipv6@ietf.org > Subject: Re: the protocols for the M/O flags (Re:=20 > [rfc2462bis] whether we need the M/O flags) >=20 > I think the O flag (if we keep it!) should simply specify=20 > DHCPv6, with no implication about the way in which DHCPv6 is used. >=20 > "Stateless DHCPv6" is simply a way to use some of the=20 > messages from the full specification in RFC 3315. RFC 3376=20 > is a guideline to the implementation of > DHCPv6 that uses just Information-request/Reply messages. A=20 > client can choose to use the Request/Reply or the=20 > Information-request/Reply message exchange to obtain other=20 > configuration information without address assignment. >=20 > - Ralph >=20 >=20 > At 01:28 PM 4/28/2004 +0100, Tim Chown wrote: > >On Wed, Apr 28, 2004 at 07:28:39PM +0900, JINMEI Tatuya /=20 > ?$B?@L@C#:H wrote: > > > > > > My point in this message is that IMO we should specify=20 > the protocols=20 > > > corresponding to these flags clearly and concretely,=20 > without leaving=20 > > > any ambiguity (I've changed the subject accordingly.) That is, I=20 > > > strongly believe we should clearly say in rfc2462bis,=20 > *for example*, > > > > > > - the protocol that should be invoked by the M flag is DHCPv6 > > > (RFC3315), and nothing else > > > - the protocol that should be invoked by the O flag is stateless > > > DHCPv6 (RFC3736), and nothing else > > > >But in reality nodes will have full DHCPv6 client support in them=20 > >(3315) whether or not they then see the M or O flag that is=20 > what they will use? > > > >All the DHCPv6 servers implemented to date, to my knowledge,=20 > are 3315=20 > >and not the 3736 subset. > > > >So it is better to just say O flag is other (non address)=20 > configuration=20 > >data, regardless of full/subset of DHCPv6 used? > > > >Tim > > > >-------------------------------------------------------------------- > >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 > -------------------------------------------------------------------- >=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 Thu Apr 29 00:00: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 AAA15876 for ; Thu, 29 Apr 2004 00:00: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 1BJ2el-0008I9-Ru for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 23:56:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T3uFeC031865 for ipv6-archive@odin.ietf.org; Wed, 28 Apr 2004 23:56:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2XY-00070O-JW for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 23:48: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 XAA15111 for ; Wed, 28 Apr 2004 23:48: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 1BJ2XT-0005hw-Ab for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 23:48:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2WU-0005aW-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 23:47:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ2Vb-0005S8-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 23:46:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2IK-0003Iy-Fy; Wed, 28 Apr 2004 23: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 1BJ2FB-0002Jg-GS for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 23:29: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 XAA13927 for ; Wed, 28 Apr 2004 23:29: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 1BJ2F6-0003QT-8n for ipv6@ietf.org; Wed, 28 Apr 2004 23:29:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2EI-0003Kz-00 for ipv6@ietf.org; Wed, 28 Apr 2004 23:28:54 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1BJ2Dg-0003EP-00 for ipv6@ietf.org; Wed, 28 Apr 2004 23:28:16 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A8B723652; Wed, 28 Apr 2004 23:28:18 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Apr 2004 23:28:18 -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: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Date: Wed, 28 Apr 2004 23:27:51 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612C925@tayexc13.americas.cpqcorp.net> Thread-Topic: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Thread-Index: AcQtOhw8CIb55GwuTZm1PA7KcX1SBAAAZKdAABeHONA= From: "Bound, Jim" To: "Christian Huitema" , =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= , "Tim Chown" Cc: X-OriginalArrivalTime: 29 Apr 2004 03:28:18.0568 (UTC) FILETIME=[03D46080:01C42D9A] 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhpcyBtYWtlcyBzZW5zZSBleGNlcHQgSSBhZ3JlZSB3aXRoIFJhbHBoIG8gYml0IHNob3VsZCBq dXN0IGJlIERIQ1B2NiBhbmQgbSBiaXQgdG9vLiAgQWxzbyBESENQdjYgaW1wbGVtZW50YXRpb25z IG11c3QgY29leGlzdCB3aXRoIHN0YXRlbGVzcy4NCi9qaW0gDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogaXB2Ni1hZG1pbkBpZXRmLm9yZyBbbWFpbHRvOmlwdjYtYWRt aW5AaWV0Zi5vcmddIE9uIA0KPiBCZWhhbGYgT2YgQ2hyaXN0aWFuIEh1aXRlbWENCj4gU2VudDog V2VkbmVzZGF5LCBBcHJpbCAyOCwgMjAwNCAxMjoyOSBQTQ0KPiBUbzogSklOTUVJIFRhdHV5YSAv IOelnuaYjumBlOWTiTsgVGltIENob3duDQo+IENjOiBpcHY2QGlldGYub3JnDQo+IFN1YmplY3Q6 IFJFOiB0aGUgcHJvdG9jb2xzIGZvciB0aGUgTS9PIGZsYWdzIChSZTogDQo+IFtyZmMyNDYyYmlz XSB3aGV0aGVyIHdlIG5lZWQgdGhlIE0vTyBmbGFncykNCj4gDQo+IEkgdGhpbmsgYSB3aG9sZSBs b3Qgb2YgdGhlIGlzc3VlIGhhcyB0byBkbyB3aXRoIHRoZSANCj4gc3VwcG9zZWRseSBtYW5kYXRv cnkgbmF0dXJlIG9mIHRoZSBNIGZsYWcsIHdoaWNoIGxlYWRzIHRvIA0KPiBwaHJhc2VzIGxpa2Ug ImRvIERIQ1AsIGFuZCBvbmx5IGlmIGl0IGZhaWxzIGRvIGF1dG8tY29uZmlnLiIgDQo+IEl0IHdv dWxkIGJlIG11Y2ggc2ltcGxlciB0byBzaW1wbHkgZGVmaW5lIHRoZSBmbGFncyBhcyANCj4gImFu bm91bmNpbmcgYW4gYXZhaWxhYmxlIHNlcnZpY2UiLCBhcyBpbjoNCj4gDQo+IDEpIFRoZSAiTSIg ZmxhZyBpcyBzZXQgdG8gaW5kaWNhdGUgdGhhdCBhIERIQ1B2NiBhZGRyZXNzIA0KPiBjb25maWd1 cmF0aW9uIHNlcnZpY2UgaXMgYXZhaWxhYmxlIG9uIHRoaXMgbGluaywgYXMgc3BlY2lmaWVkIA0K PiBpbiBSRkMzMzE1Lg0KPiANCj4gMikgVGhlICJPIiBmbGFnIGlzIHNldCB0byBpbmRpY2F0ZSB0 aGF0IGEgREhDUHY2IGluZm9ybWF0aW9uIA0KPiBzZXJ2aWNlIGlzIGF2YWlsYWJsZSBvbiB0aGlz IGxpbmssIGFzIHNwZWNpZmllZCBpbiBSRkMzNzM2Lg0KPiANCj4gV2Ugc2hvdWxkIHRoZW4gbGVh dmUgaXQgYXQgdGhhdCwgYW5kIGxlYXZlIGl0IHRvIG5vZGVzIHRvIA0KPiBkZWNpZGUgd2hldGhl ciB0aGV5IHdhbnQgdG8gdXNlIHRoZXNlIHNlcnZpY2VzIG9yIG5vdC4gRm9yIA0KPiBleGFtcGxl LCBhIHNlcnZlciB3aXRoIGEgY29uZmlndXJlZCBhZGRyZXNzIHdpbGwgbmV2ZXIgdXNlIA0KPiBE SENQdjYgYWRkcmVzcyBjb25maWd1cmF0aW9uOyBhbiBhcHBsaWFuY2UgdGhhdCBuZXZlciBoYXMg dG8gDQo+IHJlc29sdmUgRE5TIG5hbWVzIHdpbGwgbmV2ZXIgdXNlIHRoZSBpbmZvcm1hdGlvbiBz ZXJ2aWNlLiBCeSANCj4gc2V0dGluZyB0aGUgZmxhZ3MgdG8gaW5kaWNhdGUgc2VydmljZSBhdmFp bGFiaWxpdHksIHdlIHdpbGwgDQo+IHJlZHVjZSB0aGUgYW1vdW50IG9mIHVzZWxlc3MgY2hhdHRl ciBvbiB0aGUgbGluayB3aGVuIHRoZSANCj4gc2VydmljZXMgYXJlIG5vdCBpbiBmYWN0IGF2YWls YWJsZS4NCj4gDQo+IFdlIHNob3VsZCBub3RlIHRoYXQsIGZyb20gYSBwcm90b2NvbCBwb2ludCBv ZiB2aWV3LCB0aGVyZSBpcyANCj4gbm8gbmVlZCB0byB1c2UgdGhlIE0gYml0IHRvIGNvbnRyb2wg c3RhdGVsZXNzIGFkZHJlc3MgDQo+IGNvbmZpZ3VyYXRpb24uIFRoaXMgZnVuY3Rpb24gaXMgYWxy ZWFkeSBhY2hpZXZlZCBieSB0aGUgDQo+ICJBdXRvbm9tb3VzIGZsYWciIGluIHRoZSBwcmVmaXgg aW5mb3JtYXRpb24gb3B0aW9uLiBJZiB0aGUgDQo+IGZsYWcgaXMgbm90IHNldCwgdGhlIGhvc3Rz IHdpbGwgbm90IGNvbmZpZ3VyZSBpbmZvcm1hdGlvbiANCj4gZnJvbSB0aGUgcHJlZml4LiANCj4g DQo+IC0tIENocmlzdGlhbiBIdWl0ZW1hDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYg d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJh dGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2 Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 29 00:04: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 AAA16066 for ; Thu, 29 Apr 2004 00:04: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 1BJ2ib-00018k-A3 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 00:00:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T40DKp004376 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 00:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2bq-0007eL-6Q for ipv6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 23: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 XAA15464 for ; Wed, 28 Apr 2004 23:53: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 1BJ2bk-0006Hr-Tz for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 23:53:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2as-00069n-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 23:52:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ2Zm-000603-00 for ipv6-web-archive@ietf.org; Wed, 28 Apr 2004 23:51:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2KE-0003mZ-Ak; Wed, 28 Apr 2004 23: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 1BJ2HA-0002ue-MH for ipv6@optimus.ietf.org; Wed, 28 Apr 2004 23:31: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 XAA13997 for ; Wed, 28 Apr 2004 23:31: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 1BJ2H5-0003dc-HL for ipv6@ietf.org; Wed, 28 Apr 2004 23:31:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2G7-0003XN-00 for ipv6@ietf.org; Wed, 28 Apr 2004 23:30:47 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1BJ2Fr-0003RF-00 for ipv6@ietf.org; Wed, 28 Apr 2004 23:30:31 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 503312647; Wed, 28 Apr 2004 23:30: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); Wed, 28 Apr 2004 23:30:34 -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: Wed, 28 Apr 2004 23:30:07 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612C926@tayexc13.americas.cpqcorp.net> Thread-Topic: [rfc2462bis] whether we need the M/O flags Thread-Index: AcQtUnfCPaSKSrwRTOCPePla5FCbpQAR8Xvw From: "Bound, Jim" To: "Alain Durand" , "Tim Chown" Cc: "IETF IPv6 Mailing List" X-OriginalArrivalTime: 29 Apr 2004 03:30:34.0180 (UTC) FILETIME=[54A92040:01C42D9A] 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 DHCPv6 is secure read the spec. /jim=20 > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On=20 > Behalf Of Alain Durand > Sent: Wednesday, April 28, 2004 2:37 PM > To: Tim Chown > Cc: IETF IPv6 Mailing List > Subject: Re: [rfc2462bis] whether we need the M/O flags >=20 >=20 > On Apr 27, 2004, at 2:21 AM, Tim Chown wrote: >=20 > > On Mon, Apr 26, 2004 at 10:14:02AM -0700, Alain Durand wrote: > >> Let me try to explain why I, as an implementor, do not=20 > like the M/O=20 > >> bits very much. > >> ... > > > > Alain, > > > > Could you explain how the functionality of the O/M bits will be=20 > > replaced within the ND/etc protocols? Or should they not=20 > be replaced? >=20 > I'm not convinced they are needed in the first place. >=20 > > Until now, most people have not worried about DNS resolver=20 > discovery=20 > > because they run dual-stack networks (and thus use IPv4 transport=20 > > DNS), but hosts autoconfiguring in an IPv6-only environment need a=20 > > method to get DNS and other configuration info. I agree=20 > they can just=20 > > try DHCPv6, rather than being told to do so. So is your=20 > argument that=20 > > the client should decide which protocols to try, as per=20 > IPv4, rather=20 > > than be "forced" to use DHCPv6 when > > DHCPv6 may not be secure? >=20 > It has nothing to do with DHCPv6 being secure or not. > I think it is up to the client to decide what to do. I have=20 > nothing against hints provided by the network that DHCPv6 may=20 > be here, but I'm not comfortable in having host being told to=20 > use it despite other configuration they may have. >=20 > > But whether the client decides to use DHCP, or an RA tells it to do=20 > > so, there is no way to know whether the DHCP response is=20 > from a real=20 > > or malicious server > > (who uses authenticated DHCP? :). And if you're not using=20 > DHCP you=20 > > trust > > the RA for the network settings anyway. >=20 > not necessarily. You can use manual config. Or still use=20 > stateless autoconf and have an external verification. >=20 > > So isn't SEND the answer to this, > > rather than deprecating flags? You either run in an=20 > > authenticated/trusted > > environment, or you don't... >=20 > I agree with you for the M bit. Not for the O bit, as you can=20 > trivially mount attacks that were more difficult to do=20 > before. Overriding the configuration of the DNS server would=20 > be much more difficult to detect than overriding the default router. >=20 > - Alain. >=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 Thu Apr 29 02:29:14 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 CAA07672 for ; Thu, 29 Apr 2004 02:29: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 1BJ4r9-0002il-62 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 02:17:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T6HBDw010459 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 02:17:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4o9-0000sK-I2 for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 02:14: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 CAA06292 for ; Thu, 29 Apr 2004 02:14: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 1BJ4o2-0001yo-Uw for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 02:13:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ4n4-0001pe-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 02:12:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ4mU-0001hG-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 02:12:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4Zw-0001Bu-JN; Thu, 29 Apr 2004 01:59:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4To-0008CB-48 for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 01: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 BAA22156 for ; Thu, 29 Apr 2004 01:53: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 1BJ4Th-0006Ru-N7 for ipv6@ietf.org; Thu, 29 Apr 2004 01:52:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ4T7-0006HN-00 for ipv6@ietf.org; Thu, 29 Apr 2004 01:52:22 -0400 Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx with esmtp (Exim 4.12) id 1BJ4RE-0005nT-00 for ipv6@ietf.org; Thu, 29 Apr 2004 01:50:24 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:1036:dc74:13f8:73e0]) by tachyon.jinmei.org (Postfix) with ESMTP id 0CFBD37827; Thu, 29 Apr 2004 14:50:12 +0900 (JST) Date: Thu, 29 Apr 2004 14:50:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Chown 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: References: <94FBBB7E-956C-11D8-BB01-000A95CD987A@muada.com> <12529F16-95D1-11D8-BB01-000A95CD987A@muada.com> <20040428122811.GB7397@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=none autolearn=no version=2.60 >>>>> On Thu, 29 Apr 2004 00:29:41 +0900, >>>>> JINMEI Tatuya said: >>> My point in this message is that IMO we should specify the protocols >>> corresponding to these flags clearly and concretely, without leaving >>> any ambiguity (I've changed the subject accordingly.) That is, I >>> strongly believe we should clearly say in rfc2462bis, *for example*, >>> >>> - the protocol that should be invoked by the M flag is DHCPv6 >>> (RFC3315), and nothing else >>> - the protocol that should be invoked by the O flag is stateless >>> DHCPv6 (RFC3736), and nothing else (snip) > Aghhh....you have jumped to the next stage. I didn't intend to > propose any particular protocols for the M/O flags in the above > message. I first wanted to make it clear that we should clearly > specify particular protocols for the M/O flags, whatever they are. > That's why I emphasized the phrase "for example" by the set of > asterisks. Hmm, despite the notice, people have started and explored the specific discussion on which protocols should be specified for the M/O flags and how we describe it... Please recall such a discussion will become meaningless (in the scope of rfc2462bis) unless we can agree on specifying particular protocols for these flags. So let's first make a consensus on this. I guess it's okay for most of those who joined the specific discussion to specify particular protocols. In fact, they seem to have assumed the agreement. Can we think this shows a consensus here? If someone strongly disagrees with this idea, please speak up right now. 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 Apr 29 02:37: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 CAA08201 for ; Thu, 29 Apr 2004 02:37: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 1BJ53J-0008OK-2l for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 02:29:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T6Tj0c032257 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 02:29:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ50X-0007GV-Re for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 02:26: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 CAA07632 for ; Thu, 29 Apr 2004 02:26: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 1BJ50R-0003pV-5b for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 02:26:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ4zb-0003ii-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 02:25:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ4yj-0003be-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 02:25:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4q8-0002AS-Ba; Thu, 29 Apr 2004 02: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 1BJ4jR-0006BY-RJ for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 02:09: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 CAA01894 for ; Thu, 29 Apr 2004 02:09: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 1BJ4jL-00017v-1V for ipv6@ietf.org; Thu, 29 Apr 2004 02:09:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ4iU-0000yo-00 for ipv6@ietf.org; Thu, 29 Apr 2004 02:08:15 -0400 Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx with esmtp (Exim 4.12) id 1BJ4he-0000n5-00 for ipv6@ietf.org; Thu, 29 Apr 2004 02:07:22 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:1036:dc74:13f8:73e0]) by tachyon.jinmei.org (Postfix) with ESMTP id 248B337827; Thu, 29 Apr 2004 15:07:16 +0900 (JST) Date: Thu, 29 Apr 2004 15:07:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Alain Durand Cc: IETF IPv6 Mailing List Subject: Re: [rfc2462bis] whether we need the M/O flags In-Reply-To: <6DC5B720-993F-11D8-8F29-00039376A6AA@sun.com> References: <408D840B.4030903@innovationslab.net> <6DC5B720-993F-11D8-8F29-00039376A6AA@sun.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=none autolearn=no version=2.60 >>>>> On Wed, 28 Apr 2004 11:11:11 -0700, >>>>> Alain Durand said: >> Hmm, this message of yours seems to have been sent just after my >> latest one...so, please let me confirm your intention. Can you or >> can't you live with my revised proposal (attached below)? > see proposal inline. > Regarding the process issue, I personally share your view. But I > understood the current practice of the IETF is much more generous than > I'd want to see, and I'd accept that for now. > I'm not sure how the chairs can substantiate this position, as it is > in violation > of RFC2026. Again, I'm personally not sure either. But I think the "process" discussion was over anyway, so I won't mention this point in the scope of this discussion. > I think the document should at minimum: > - have text that analyze the security aspects of O&M > - make it very clear that those bits only provide hints that > there may be a DHCPv6 server and hosts MAY want to use it. I read this to mean you can accept the decision of keeping the flags if the text is reasonable for you. At the moment, I'm not sure if the result will be acceptable for you (since opinions still seem to vary on details), but I think we can at least move forward for now. Thanks for your patience. 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 Apr 29 04: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 EAA12510 for ; Thu, 29 Apr 2004 04: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 1BJ6Vl-0003gB-Rz for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 04:03:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T83DaR014142 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 04:03:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6Qv-0002iw-GP for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 03:58: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 DAA11885 for ; Thu, 29 Apr 2004 03:58: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 1BJ6Qo-0001cH-0u for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 03:58:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ6Pw-0001Oo-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 03:57:12 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ6P7-0001Dq-03 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 03:56:21 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJ6La-0000dR-9v for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 03:52:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ69O-0007fn-9z; Thu, 29 Apr 2004 03:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ65V-00065U-Mo for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 03:36: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 DAA10770 for ; Thu, 29 Apr 2004 03: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 1BJ65O-0005yf-9S for ipv6@ietf.org; Thu, 29 Apr 2004 03:35:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ64P-0005pU-00 for ipv6@ietf.org; Thu, 29 Apr 2004 03:34:58 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJ63x-0005h5-00 for ipv6@ietf.org; Thu, 29 Apr 2004 03:34:29 -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 i3T7YU7s006270 for ; Thu, 29 Apr 2004 08:34:31 +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 IAA29612 for ; Thu, 29 Apr 2004 08:34:29 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i3T7YTw23162 for ipv6@ietf.org; Thu, 29 Apr 2004 08:34:29 +0100 Date: Thu, 29 Apr 2004 08:34:28 +0100 From: Tim Chown To: IETF IPv6 Mailing List Subject: Re: [rfc2462bis] whether we need the M/O flags Message-ID: <20040429073428.GI22185@login.ecs.soton.ac.uk> Mail-Followup-To: IETF IPv6 Mailing List References: <9C422444DE99BC46B3AD3C6EAFC9711B0612C926@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0612C926@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 Sorry Jim, said "when DHCPv6 may not be secure", i.e. there will be many deployments like now with IPv4 where authentication is not deployed by the local administrator. Bear in mind there is very little use of RFC3118 DHCP authentication today for IPv4. So key message is DHCPv6 can be deployed securely, and it's great to hear you'll be building and testing this on Moonv6 in a full implementation. Tim On Wed, Apr 28, 2004 at 11:30:07PM -0400, Bound, Jim wrote: > DHCPv6 is secure read the spec. > /jim > > > -----Original Message----- > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > > Behalf Of Alain Durand > > Sent: Wednesday, April 28, 2004 2:37 PM > > To: Tim Chown > > Cc: IETF IPv6 Mailing List > > Subject: Re: [rfc2462bis] whether we need the M/O flags > > > > > > On Apr 27, 2004, at 2:21 AM, Tim Chown wrote: > > > > > On Mon, Apr 26, 2004 at 10:14:02AM -0700, Alain Durand wrote: > > >> Let me try to explain why I, as an implementor, do not > > like the M/O > > >> bits very much. > > >> ... > > > > > > Alain, > > > > > > Could you explain how the functionality of the O/M bits will be > > > replaced within the ND/etc protocols? Or should they not > > be replaced? > > > > I'm not convinced they are needed in the first place. > > > > > Until now, most people have not worried about DNS resolver > > discovery > > > because they run dual-stack networks (and thus use IPv4 transport > > > DNS), but hosts autoconfiguring in an IPv6-only environment need a > > > method to get DNS and other configuration info. I agree > > they can just > > > try DHCPv6, rather than being told to do so. So is your > > argument that > > > the client should decide which protocols to try, as per > > IPv4, rather > > > than be "forced" to use DHCPv6 when > > > DHCPv6 may not be secure? > > > > It has nothing to do with DHCPv6 being secure or not. > > I think it is up to the client to decide what to do. I have > > nothing against hints provided by the network that DHCPv6 may > > be here, but I'm not comfortable in having host being told to > > use it despite other configuration they may have. > > > > > But whether the client decides to use DHCP, or an RA tells it to do > > > so, there is no way to know whether the DHCP response is > > from a real > > > or malicious server > > > (who uses authenticated DHCP? :). And if you're not using > > DHCP you > > > trust > > > the RA for the network settings anyway. > > > > not necessarily. You can use manual config. Or still use > > stateless autoconf and have an external verification. > > > > > So isn't SEND the answer to this, > > > rather than deprecating flags? You either run in an > > > authenticated/trusted > > > environment, or you don't... > > > > I agree with you for the M bit. Not for the O bit, as you can > > trivially mount attacks that were more difficult to do > > before. Overriding the configuration of the DNS server would > > be much more difficult to detect than overriding the default router. > > > > - Alain. > > > > > > -------------------------------------------------------------------- > > 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 Thu Apr 29 10:43: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 KAA06387 for ; Thu, 29 Apr 2004 10:43: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 1BJCQw-0006Zu-4e for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 10:22:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TEMcN6025259 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 10:22:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCN6-0004eZ-6e for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 10:18: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 KAA04585 for ; Thu, 29 Apr 2004 10:18: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 1BJCMv-0003db-89 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 10:18:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCM0-0003OC-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 10:17:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJCLV-00037z-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 10:17:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC3A-0002BT-7C; Thu, 29 Apr 2004 09:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBtr-0007nG-EJ for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 09:48: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 JAA01854 for ; Thu, 29 Apr 2004 09:48: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 1BJBtg-0003pA-K2 for ipv6@ietf.org; Thu, 29 Apr 2004 09:48:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBsk-0003Yv-00 for ipv6@ietf.org; Thu, 29 Apr 2004 09:47:19 -0400 Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx with esmtp (Exim 4.12) id 1BJBrm-0003IH-00 for ipv6@ietf.org; Thu, 29 Apr 2004 09:46:20 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:8c5c:583b:5abc:d4a1]) by tachyon.jinmei.org (Postfix) with ESMTP id 8F3D0355E4; Thu, 29 Apr 2004 22:46:02 +0900 (JST) Date: Thu, 29 Apr 2004 22:46:19 +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=none 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. A quick question for clarification: do you mean a client can choose to use the request/reply message exchange to obtain other configuration information without address assignment (in addition to information-request/reply exchange)? If so, I have several related questions. In this scenario, the client first sends a Solicit message. RFC3315 says in 17.1.1 that The client includes IA options for any IAs to which it wants the server to assign addresses. If the client does not want address assignment, is it okay for the client to send a Solicit without including an IA option? It's not clear to me, but this is probably okay (at least the RFC does not seem to prohibit it). Then, the server seems to take the following action according to Section 17.2.2 of RFC3315: If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. And the client will ignore the Advertise message because in Section 17.1.3 the RFC says: The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. and so the exchange should fail at this stage. 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 Apr 29 11:01:17 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 LAA07668 for ; Thu, 29 Apr 2004 11:01: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 1BJCnv-0004qE-Dx for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 10:46:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TEkNSD018596 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 10:46:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCeO-0001id-JZ for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 10:36: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 KAA05942 for ; Thu, 29 Apr 2004 10:36: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 1BJCeD-0000Wb-Hf for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 10:36:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCdI-0000Gq-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 10:35:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJCcT-0007no-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 10:34:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCPQ-00067q-LO; Thu, 29 Apr 2004 10: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 1BJC6Q-0003e1-Td for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 10:01: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 KAA02666 for ; Thu, 29 Apr 2004 10:01: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 1BJC6F-00075x-UB for ipv6@ietf.org; Thu, 29 Apr 2004 10:01:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJC5M-0006rp-00 for ipv6@ietf.org; Thu, 29 Apr 2004 10:00:21 -0400 Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx with esmtp (Exim 4.12) id 1BJC4s-0006dD-00 for ipv6@ietf.org; Thu, 29 Apr 2004 09:59:50 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:8c5c:583b:5abc:d4a1]) by tachyon.jinmei.org (Postfix) with ESMTP id 04128355E4 for ; Thu, 29 Apr 2004 22:59:44 +0900 (JST) Date: Thu, 29 Apr 2004 23:00:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) 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> 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=none autolearn=no version=2.60 >>>>> On Thu, 29 Apr 2004 14:50:26 +0900, >>>>> JINMEI Tatuya said: > Hmm, despite the notice, people have started and explored the > specific discussion on which protocols should be specified for the M/O > flags and how we describe it... > Please recall such a discussion will become meaningless (in the scope > of rfc2462bis) unless we can agree on specifying particular protocols > for these flags. So let's first make a consensus on this. > I guess it's okay for most of those who joined the specific discussion > to specify particular protocols. In fact, they seem to have assumed > the agreement. > Can we think this shows a consensus here? If someone strongly > disagrees with this idea, please speak up right now. It might be too early to conclude, but I interpret the silence as an agreement at the moment. So, what we've agreed on so far are: - we'll keep the M and O flags - we should clearly specify the protocols corresponding to the flags (without leaving ambiguity) - the protocol for the M flag is DHCPv6 (we've already reached a consensus on this, but I mention it explicitly because we've had some fundamental discussions) And what we should discuss from now on are: - which protocol should be used for the O flag - details of the relationship between each flag and protocol, e.g. whether we should mandate to invoke the protocol or we can just regard the flag as a hint and let the host decide if it invokes the protocol (as Christian suggested), etc. I'll be off from the list for a vacation until May 7th. Hopefully the discussion will continue in a productive manner during the period but will not diverge very much:-) 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 Apr 29 11:33:49 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09397 for ; Thu, 29 Apr 2004 11:33: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 1BJDLS-0005gM-Fa for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 11:21:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TFL2S5021829 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 11: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 1BJDBE-0003Fy-7p for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 11:10: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 LAA08173 for ; Thu, 29 Apr 2004 11: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 1BJDB2-00029W-Qq for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 11:10:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDA5-0001su-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 11:09:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJD9E-0001ci-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 11:08:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCoh-00050P-E2; Thu, 29 Apr 2004 10:47:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCgA-0002Kc-HH for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 10:38: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 KAA06033 for ; Thu, 29 Apr 2004 10:38: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 1BJCfz-00010s-9R for ipv6@ietf.org; Thu, 29 Apr 2004 10:38:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCf1-0000lQ-00 for ipv6@ietf.org; Thu, 29 Apr 2004 10:37:11 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BJCe5-0000IH-00 for ipv6@ietf.org; Thu, 29 Apr 2004 10:36:13 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Apr 2004 20:08:04 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D6D14805@kavithai.ctd.hcltech.com> From: "Subramonia Pillai - CTD, Chennai" To: ipv6@ietf.org Subject: IPV6CP - RFC Compliance 2472 Date: Thu, 29 Apr 2004 20:05:42 +0530 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.0 required=5.0 tests=none autolearn=no version=2.60 Hi, One of Major Core Router vender is not advertising Interface Identifier as part of IPV6CP Configuration Request. The control packet from that box is as given below. 80 57 01 28 00 04 (no Interface Identifier options). Even I send Nak for this message with Interface Identifier option, I didn't get Interface Identifier. In that case, how will come to bring up the link and know the link-local address? Is it not violating standard? Please tell me if any one of you already come across this issue. Thanks Subu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 29 11:33: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 LAA09431 for ; Thu, 29 Apr 2004 11:33: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 1BJDLa-0005qa-FE for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 11:21:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TFLAS6022468 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 11:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDDB-0003sk-Lp for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 11: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 LAA08307 for ; Thu, 29 Apr 2004 11:12: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 1BJDD7-0002jv-JY for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 11:12:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDCH-0002TK-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 11:11:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJDBc-0002CN-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 11:10:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCzB-0007ft-9w; Thu, 29 Apr 2004 10: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 1BJB7v-00065q-Bq for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 08:58: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 IAA27435 for ; Thu, 29 Apr 2004 08:58: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 1BJB7l-0005vE-2b for ipv6@ietf.org; Thu, 29 Apr 2004 08:58:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJB6j-0005am-00 for ipv6@ietf.org; Thu, 29 Apr 2004 08:57:41 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BJB5Z-0004zg-00 for ipv6@ietf.org; Thu, 29 Apr 2004 08:56:29 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Apr 2004 18:28:18 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D6D146A2@kavithai.ctd.hcltech.com> From: "Subramonia Pillai - CTD, Chennai" To: ipv6@ietf.org Subject: IPV6CP - RFC Compliance 2472 Date: Thu, 29 Apr 2004 18:25:55 +0530 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.0 required=5.0 tests=none autolearn=no version=2.60 Hi, One of Major Core Router vender is not advertising Interface Identifier as part of IPV6CP Configuration Request. The control packet from that box is as given below. 80 57 01 28 00 04 (no Interface Identifier options). Even I send Nak for this message with Interface Identifier option, I didn't get Interface Identifier. In that case, how will come to bring up the link and know the link-local address? Is it not violating standard? Please tell me if any one of you already come across this issue. Thanks Subu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 29 11:51: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 LAA10358 for ; Thu, 29 Apr 2004 11:51:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDkQ-0004U8-7c for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 11:46:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TFkoAU017236 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 11:46:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDaR-00015Q-7g for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 11:36: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 LAA09624 for ; Thu, 29 Apr 2004 11:36: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 1BJDaM-0001KL-UR for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 11:36:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDZQ-00013i-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 11:35:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJDYt-0000nM-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 11:34:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDMR-0005yC-Hm; Thu, 29 Apr 2004 11:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDCH-0003dB-LN for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 11:11: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 LAA08228 for ; Thu, 29 Apr 2004 11:11: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 1BJDC6-0002Rc-7n for ipv6@ietf.org; Thu, 29 Apr 2004 11:11:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDBC-0002B5-00 for ipv6@ietf.org; Thu, 29 Apr 2004 11:10:27 -0400 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1BJDAV-0001uj-00 for ipv6@ietf.org; Thu, 29 Apr 2004 11:09:43 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 61F369D80; Thu, 29 Apr 2004 11:09:46 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Apr 2004 11:09: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: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Date: Thu, 29 Apr 2004 11:09:18 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612C9A0@tayexc13.americas.cpqcorp.net> Thread-Topic: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) Thread-Index: AcQt9tn+FCuxWp8UQRWcZTinuqFpWAABQjRA From: "Bound, Jim" To: =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= , X-OriginalArrivalTime: 29 Apr 2004 15:09:46.0082 (UTC) FILETIME=[01F15C20:01C42DFC] 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 MzMxNSBzdXBwb3J0cyBib3RoIG0gYW5kIG8uICBqdXN0IGEgZmFjdC4gIHRoYXQgSSBrbm93Lg0K L2ppbSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2LWFkbWlu QGlldGYub3JnIFttYWlsdG86aXB2Ni1hZG1pbkBpZXRmLm9yZ10gT24gDQo+IEJlaGFsZiBPZiBK SU5NRUkgVGF0dXlhIC8gPz8/Pw0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjksIDIwMDQgMTA6 MDAgQU0NCj4gVG86IGlwdjZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IHRoZSBwcm90b2NvbHMg Zm9yIHRoZSBNL08gZmxhZ3MgKFJlOiANCj4gW3JmYzI0NjJiaXNdIHdoZXRoZXIgd2UgbmVlZCB0 aGUgTS9PIGZsYWdzKQ0KPiANCj4gPj4+Pj4gT24gVGh1LCAyOSBBcHIgMjAwNCAxNDo1MDoyNiAr MDkwMCwgSklOTUVJIFRhdHV5YSANCj4gPj4+Pj4gPGppbm1laUBrYW1lLm5ldD4gc2FpZDoNCj4g DQo+ID4gSG1tLCBkZXNwaXRlIHRoZSBub3RpY2UsIHBlb3BsZSBoYXZlIHN0YXJ0ZWQgYW5kIGV4 cGxvcmVkIA0KPiB0aGUgc3BlY2lmaWMgDQo+ID4gZGlzY3Vzc2lvbiBvbiB3aGljaCBwcm90b2Nv bHMgc2hvdWxkIGJlIHNwZWNpZmllZCBmb3IgdGhlIE0vTyBmbGFncyANCj4gPiBhbmQgaG93IHdl IGRlc2NyaWJlIGl0Li4uDQo+IA0KPiA+IFBsZWFzZSByZWNhbGwgc3VjaCBhIGRpc2N1c3Npb24g d2lsbCBiZWNvbWUgbWVhbmluZ2xlc3MgKGluIA0KPiB0aGUgc2NvcGUgDQo+ID4gb2YgcmZjMjQ2 MmJpcykgdW5sZXNzIHdlIGNhbiBhZ3JlZSBvbiBzcGVjaWZ5aW5nIHBhcnRpY3VsYXIgDQo+IHBy b3RvY29scyANCj4gPiBmb3IgdGhlc2UgZmxhZ3MuICBTbyBsZXQncyBmaXJzdCBtYWtlIGEgY29u c2Vuc3VzIG9uIHRoaXMuDQo+IA0KPiA+IEkgZ3Vlc3MgaXQncyBva2F5IGZvciBtb3N0IG9mIHRo b3NlIHdobyBqb2luZWQgdGhlIHNwZWNpZmljIA0KPiBkaXNjdXNzaW9uIA0KPiA+IHRvIHNwZWNp ZnkgcGFydGljdWxhciBwcm90b2NvbHMuICBJbiBmYWN0LCB0aGV5IHNlZW0gdG8gDQo+IGhhdmUg YXNzdW1lZCANCj4gPiB0aGUgYWdyZWVtZW50Lg0KPiANCj4gPiBDYW4gd2UgdGhpbmsgdGhpcyBz aG93cyBhIGNvbnNlbnN1cyBoZXJlPyAgSWYgc29tZW9uZSBzdHJvbmdseSANCj4gPiBkaXNhZ3Jl ZXMgd2l0aCB0aGlzIGlkZWEsIHBsZWFzZSBzcGVhayB1cCByaWdodCBub3cuDQo+IA0KPiBJdCBt aWdodCBiZSB0b28gZWFybHkgdG8gY29uY2x1ZGUsIGJ1dCBJIGludGVycHJldCB0aGUgDQo+IHNp bGVuY2UgYXMgYW4gYWdyZWVtZW50IGF0IHRoZSBtb21lbnQuDQo+IA0KPiBTbywgd2hhdCB3ZSd2 ZSBhZ3JlZWQgb24gc28gZmFyIGFyZToNCj4gDQo+IC0gd2UnbGwga2VlcCB0aGUgTSBhbmQgTyBm bGFncw0KPiAtIHdlIHNob3VsZCBjbGVhcmx5IHNwZWNpZnkgdGhlIHByb3RvY29scyBjb3JyZXNw b25kaW5nIHRvIHRoZSBmbGFncw0KPiAgICh3aXRob3V0IGxlYXZpbmcgYW1iaWd1aXR5KQ0KPiAt IHRoZSBwcm90b2NvbCBmb3IgdGhlIE0gZmxhZyBpcyBESENQdjYgKHdlJ3ZlIGFscmVhZHkgcmVh Y2hlZCBhDQo+ICAgY29uc2Vuc3VzIG9uIHRoaXMsIGJ1dCBJIG1lbnRpb24gaXQgZXhwbGljaXRs eSBiZWNhdXNlIHdlJ3ZlIGhhZA0KPiAgIHNvbWUgZnVuZGFtZW50YWwgZGlzY3Vzc2lvbnMpDQo+ IA0KPiBBbmQgd2hhdCB3ZSBzaG91bGQgZGlzY3VzcyBmcm9tIG5vdyBvbiBhcmU6DQo+IA0KPiAt IHdoaWNoIHByb3RvY29sIHNob3VsZCBiZSB1c2VkIGZvciB0aGUgTyBmbGFnDQo+IC0gZGV0YWls cyBvZiB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gZWFjaCBmbGFnIGFuZCBwcm90b2NvbCwgZS5n Lg0KPiAgIHdoZXRoZXIgd2Ugc2hvdWxkIG1hbmRhdGUgdG8gaW52b2tlIHRoZSBwcm90b2NvbCBv ciB3ZSBjYW4ganVzdA0KPiAgIHJlZ2FyZCB0aGUgZmxhZyBhcyBhIGhpbnQgYW5kIGxldCB0aGUg aG9zdCBkZWNpZGUgaWYgaXQgaW52b2tlcyB0aGUNCj4gICBwcm90b2NvbCAoYXMgQ2hyaXN0aWFu IHN1Z2dlc3RlZCksIGV0Yy4NCj4gDQo+IEknbGwgYmUgb2ZmIGZyb20gdGhlIGxpc3QgZm9yIGEg dmFjYXRpb24gdW50aWwgTWF5IDd0aC4gIA0KPiBIb3BlZnVsbHkgdGhlIGRpc2N1c3Npb24gd2ls bCBjb250aW51ZSBpbiBhIHByb2R1Y3RpdmUgbWFubmVyIA0KPiBkdXJpbmcgdGhlIHBlcmlvZCBi dXQgd2lsbCBub3QgZGl2ZXJnZSB2ZXJ5IG11Y2g6LSkNCj4gDQo+IFRoYW5rcywNCj4gDQo+IAkJ CQkJSklOTUVJLCBUYXR1eWENCj4gCQkJCQlDb21tdW5pY2F0aW9uIFBsYXRmb3JtIExhYi4NCj4g CQkJCQlDb3Jwb3JhdGUgUiZEIENlbnRlciwgDQo+IFRvc2hpYmEgQ29ycC4NCj4gCQkJCQlqaW5t ZWlAaXNsLnJkYy50b3NoaWJhLmNvLmpwDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYg d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJh dGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2 Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 29 11:51:54 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10382 for ; Thu, 29 Apr 2004 11:51: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 1BJDkt-0004pD-6X for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 11:47:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TFlJr8018541 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 11:47:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDg5-0002sI-58 for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 11:42: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 LAA09895 for ; Thu, 29 Apr 2004 11:42: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 1BJDg0-0002wR-Lh for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 11:42:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDf5-0002h1-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 11:41:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJDeH-0002Ru-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 11:40:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDRF-0007QR-LI; Thu, 29 Apr 2004 11:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDFB-0004Lp-SH for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 11:14: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 LAA08503 for ; Thu, 29 Apr 2004 11:14: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 1BJDF7-0003L3-N9 for ipv6@ietf.org; Thu, 29 Apr 2004 11:14:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDEF-00033J-00 for ipv6@ietf.org; Thu, 29 Apr 2004 11:13:36 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJDDH-0002UY-00 for ipv6@ietf.org; Thu, 29 Apr 2004 11:12:35 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TFC2e31483; Thu, 29 Apr 2004 18:12:02 +0300 Date: Thu, 29 Apr 2004 18:12:02 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipv6@ietf.org Subject: M/O flags: hints vs more [Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags)] In-Reply-To: Message-ID: MIME-Version: 1.0 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.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 29 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > - details of the relationship between each flag and protocol, e.g. > whether we should mandate to invoke the protocol or we can just > regard the flag as a hint and let the host decide if it invokes the > protocol (as Christian suggested), etc. I support Christian's suggestion; they should be just hints. No flag is going to force the node to run a protocol. More often than not, for implementation simplicity, I'd guess most nodes (especially where DHCPv6 is available), the nodes are going to run DHCPv6(-lite) in any case, whether they saw a flag or not. On the other hand, absence of a flag is not going to prevent a node from running a protocol. -- 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 Thu Apr 29 12:43: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 MAA13326 for ; Thu, 29 Apr 2004 12:43: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 1BJETW-00036r-SB for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 12:33:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TGXQ78011951 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 12:33:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJECy-00058q-MG for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 12:16: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 MAA11643 for ; Thu, 29 Apr 2004 12:16: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 1BJECu-0004Hg-4U for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 12:16:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEBx-00040i-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 12:15:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJEAu-0003fF-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 12:14:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDql-000628-N4; Thu, 29 Apr 2004 11:53:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDnu-0005N8-CV for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 11:50: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 LAA10284 for ; Thu, 29 Apr 2004 11:50: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 1BJDnp-000587-KG for ipv6@ietf.org; Thu, 29 Apr 2004 11:50:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDmt-0004qo-00 for ipv6@ietf.org; Thu, 29 Apr 2004 11:49:23 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1BJDm1-0004Yx-00 for ipv6@ietf.org; Thu, 29 Apr 2004 11:48:29 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 971C43757; Thu, 29 Apr 2004 11:48:32 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Apr 2004 11:48:21 -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: M/O flags: hints vs more [Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags)] Date: Thu, 29 Apr 2004 11:47:53 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612C9AC@tayexc13.americas.cpqcorp.net> Thread-Topic: M/O flags: hints vs more [Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags)] Thread-Index: AcQuADeFWEQeuuS9TMWRxxsSUJL40QAAPH3A From: "Bound, Jim" To: "Pekka Savola" , =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= Cc: X-OriginalArrivalTime: 29 Apr 2004 15:48:21.0371 (UTC) FILETIME=[65F66CB0:01C42E01] 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 aW4gdGhlIGVudGVycHJpc2UgImluaXRpYWxseSIgdGhleSB3aWxsIHJ1biBkaGNwdjYgYmVjYXVz ZSBzdGF0ZWxlc3MgZm9yIHdpcmVsaW5lIHdpbGwgbm90IGJlIHVzZWQgaXMgbXkgb3Bpbmlvbi4g IHJlYXNvbiBpcyBjb250cm9sLg0KL2ppbSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBpcHY2LWFkbWluQGlldGYub3JnIFttYWlsdG86aXB2Ni1hZG1pbkBpZXRmLm9y Z10gT24gDQo+IEJlaGFsZiBPZiBQZWtrYSBTYXZvbGENCj4gU2VudDogVGh1cnNkYXksIEFwcmls IDI5LCAyMDA0IDExOjEyIEFNDQo+IFRvOiBKSU5NRUkgVGF0dXlhIC8g56We5piO6YGU5ZOJDQo+ IENjOiBpcHY2QGlldGYub3JnDQo+IFN1YmplY3Q6IE0vTyBmbGFnczogaGludHMgdnMgbW9yZSBb UmU6IHRoZSBwcm90b2NvbHMgZm9yIHRoZSANCj4gTS9PIGZsYWdzIChSZTogW3JmYzI0NjJiaXNd IHdoZXRoZXIgd2UgbmVlZCB0aGUgTS9PIGZsYWdzKV0NCj4gDQo+IE9uIFRodSwgMjkgQXByIDIw MDQsIEpJTk1FSSBUYXR1eWEgLyBbSVNPLTIwMjItSlBdIA0KPiAbJEI/QExAQyM6SBsoQiB3cm90 ZToNCj4gPiAtIGRldGFpbHMgb2YgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGVhY2ggZmxhZyBh bmQgcHJvdG9jb2wsIGUuZy4NCj4gPiAgIHdoZXRoZXIgd2Ugc2hvdWxkIG1hbmRhdGUgdG8gaW52 b2tlIHRoZSBwcm90b2NvbCBvciB3ZSBjYW4ganVzdA0KPiA+ICAgcmVnYXJkIHRoZSBmbGFnIGFz IGEgaGludCBhbmQgbGV0IHRoZSBob3N0IGRlY2lkZSBpZiBpdCANCj4gaW52b2tlcyB0aGUNCj4g PiAgIHByb3RvY29sIChhcyBDaHJpc3RpYW4gc3VnZ2VzdGVkKSwgZXRjLg0KPiANCj4gSSBzdXBw b3J0IENocmlzdGlhbidzIHN1Z2dlc3Rpb247IHRoZXkgc2hvdWxkIGJlIGp1c3QgaGludHMuICAN Cj4gDQo+IE5vIGZsYWcgaXMgZ29pbmcgdG8gZm9yY2UgdGhlIG5vZGUgdG8gcnVuIGEgcHJvdG9j b2wuICBNb3JlIA0KPiBvZnRlbiB0aGFuIG5vdCwgZm9yIGltcGxlbWVudGF0aW9uIHNpbXBsaWNp dHksIEknZCBndWVzcyBtb3N0IA0KPiBub2RlcyAoZXNwZWNpYWxseSB3aGVyZSBESENQdjYgaXMg YXZhaWxhYmxlKSwgdGhlIG5vZGVzIGFyZSANCj4gZ29pbmcgdG8gcnVuIERIQ1B2NigtbGl0ZSkg aW4gYW55IGNhc2UsIHdoZXRoZXIgdGhleSBzYXcgYSANCj4gZmxhZyBvciBub3QuDQo+IA0KPiBP biB0aGUgb3RoZXIgaGFuZCwgYWJzZW5jZSBvZiBhIGZsYWcgaXMgbm90IGdvaW5nIHRvIHByZXZl bnQgDQo+IGEgbm9kZSBmcm9tIHJ1bm5pbmcgYSBwcm90b2NvbC4NCj4gDQo+IC0tIA0KPiBQZWtr YSBTYXZvbGEgICAgICAgICAgICAgICAgICJZb3UgZWFjaCBuYW1lIHlvdXJzZWx2ZXMga2luZywg eWV0IHRoZQ0KPiBOZXRjb3JlIE95ICAgICAgICAgICAgICAgICAgICBraW5nZG9tIGJsZWVkcy4i DQo+IFN5c3RlbXMuIE5ldHdvcmtzLiBTZWN1cml0eS4gLS0gR2VvcmdlIFIuUi4gTWFydGluOiBB IENsYXNoIG9mIEtpbmdzDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3 b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0 aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2 DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCg== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 29 12:48:17 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 MAA13420 for ; Thu, 29 Apr 2004 12:48: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 1BJEXx-0004pL-Ke for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 12:38:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TGc1sH018551 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 12:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJEF5-0006Yx-Lu for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 12:18: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 MAA11779 for ; Thu, 29 Apr 2004 12:18: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 1BJEF0-0004qB-W4 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 12:18:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEE7-0004Zs-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 12:17:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJEDe-0004JU-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 12:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDqn-00062R-0I; Thu, 29 Apr 2004 11:53:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDnx-0005Nv-Vv for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 11:50: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 LAA10308 for ; Thu, 29 Apr 2004 11:50: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 1BJDnt-00058V-E9 for ipv6@ietf.org; Thu, 29 Apr 2004 11:50:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDn3-0004sJ-00 for ipv6@ietf.org; Thu, 29 Apr 2004 11:49:34 -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 1BJDmK-0004XH-00 for ipv6@ietf.org; Thu, 29 Apr 2004 11:48:48 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Apr 2004 08:01:32 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3TFmAW9001775; Thu, 29 Apr 2004 08:48:11 -0700 (PDT) Received: (from otroan@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA22159; Thu, 29 Apr 2004 16:48:09 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: "Subramonia Pillai - CTD, Chennai" Cc: ipv6@ietf.org Subject: Re: IPV6CP - RFC Compliance 2472 References: <68C9DA8F50019B4E8622C53811BEE1D6D146A2@kavithai.ctd.hcltech.com> From: Ole Troan Date: Thu, 29 Apr 2004 16:48:09 +0100 In-Reply-To: <68C9DA8F50019B4E8622C53811BEE1D6D146A2@kavithai.ctd.hcltech.com> (Subramonia Pillai's message of "Thu, 29 Apr 2004 18:25:55 +0530") Message-ID: <7t57jvy7pl2.fsf@mrwint.cisco.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2.95 (usg-unix-v) 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=none autolearn=no version=2.60 > One of Major Core Router vender is not advertising Interface Identifier as > part of IPV6CP Configuration Request. The control packet from that box is as > given below. > > 80 57 01 28 00 04 (no Interface Identifier options). > > Even I send Nak for this message with Interface Identifier option, I didn't > get Interface Identifier. In that case, how will come to bring up the link > and know the link-local address? Is it not violating standard? Please tell > me if any one of you already come across this issue. not speaking for the vendor in question. this is perfectly valid according to RFC2472. an implementation of IPV6CP doesn't need to support the Interface-Identifier option. you shouldn't need to know the peers link-local address anyway. /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 29 13:51:06 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16699 for ; Thu, 29 Apr 2004 13:51: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 1BJFe5-0006CZ-Lp for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 13:48:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3THmPbP023839 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 13:48:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFTX-0001M7-NP for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 13:37: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 NAA15477 for ; Thu, 29 Apr 2004 13:37: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 1BJFTS-00037R-7j for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 13:37:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFSU-0002qC-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 13:36:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJFRZ-0002Yn-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 13:35:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFEh-0006cl-Ly; Thu, 29 Apr 2004 13:22:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJED9-0005B4-Tm for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 12:16: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 MAA11676 for ; Thu, 29 Apr 2004 12: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 1BJED5-0004IW-2N for ipv6@ietf.org; Thu, 29 Apr 2004 12:16:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJECX-00042f-00 for ipv6@ietf.org; Thu, 29 Apr 2004 12:15:54 -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 1BJEBX-0003m1-00 for ipv6@ietf.org; Thu, 29 Apr 2004 12:14:51 -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 i3TGEhed028611 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 29 Apr 2004 18:14:48 +0200 (CEST) Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need 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: <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> Content-Type: text/plain Organization: JOIN-Team, WWU-Muenster Message-Id: <1083255257.32217.145.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 29 Apr 2004 18:14:38 +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 > If the client does not want address assignment, is it okay for the > client to send a Solicit without including an IA option? It's not That should be possible, yes. The purpose of a solicit message is to find a DHCPv6 server or a relay agent, there's no implication that it has some immediate connection to address assignment (which makes IA options mandatory). > The client MUST ignore any Advertise message that includes a Status > Code option containing the value NoAddrsAvail, with the exception > that the client MAY display the associated status message to the > user. > > and so the exchange should fail at this stage. That is only true if the client included an IA option in a request in the first place (e.g. to ask for an address for this particular interface that is in this IA). If it did not include any IA options, the server consequently does not have to set the status code of the advertise message to NoaddrsAvail because address assignment can only be done in the context of an Identity Association. 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 Thu Apr 29 14:00:12 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17205 for ; Thu, 29 Apr 2004 14:00: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 1BJFfO-0006ev-C6 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 13:49:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3THnkJl025592 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 13:49:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFbX-0004tX-8s for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 13:45: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 NAA16051 for ; Thu, 29 Apr 2004 13:45: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 1BJFbR-0005Xr-Mw for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 13:45:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFaQ-0005Bj-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 13:44:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJFZP-0004rv-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 13:43:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFFg-00071Z-5g; Thu, 29 Apr 2004 13: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 1BJEtn-0002Oh-Se for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 13:00: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 NAA13879 for ; Thu, 29 Apr 2004 13:00: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 1BJEti-0000z5-O6 for ipv6@ietf.org; Thu, 29 Apr 2004 13:00:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEsm-0000ih-00 for ipv6@ietf.org; Thu, 29 Apr 2004 12:59:33 -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 1BJEsF-0000S3-00 for ipv6@ietf.org; Thu, 29 Apr 2004 12:58:59 -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 i3TGwv3Y029218 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 29 Apr 2004 18:58:57 +0200 (CEST) Subject: Re: M/O flags: hints vs more [Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags)] From: "Christian Strauf (JOIN)" To: Pekka Savola Cc: ipv6@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: JOIN-Team, WWU-Muenster Message-Id: <1083257937.32210.186.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 29 Apr 2004 18:58:57 +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 > I support Christian's suggestion; they should be just hints. I also support this suggestion. > No flag is going to force the node to run a protocol. More often than > not, for implementation simplicity, I'd guess most nodes (especially > where DHCPv6 is available), the nodes are going to run DHCPv6(-lite) > in any case, whether they saw a flag or not. Your first statement is correct, but I think that it is important to stress that the M/O bits should not be seen as trivial or unimportant because they have no mandatory implications. Even if they're "only" hints, they're quite useful in some scenarios. Next to the protocol authority, there's the administrative authority. It's not the node that choses whether or not it's going to run a protocol in this particular case. It's the administrator who puts a DHCPv6 client onto the machine that respects the M/O bits or not and who decides if he wants to set certain M/O bit combinations in his site for one reason or the other (think WiFi spots with SAA and stateless DHCPv6, think cluster nodes without any SAA and with stateful DHCPv6 for full control and think about machines that need to detect whether or not they need to use SAA or stateful methods depending on their location (portable nodes)). So, you get a consistent behaviour since it's the administrator who decides about the usefulness of utilising the M/O bits (client side and "RA emitter" side). Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 29 14:04: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 OAA17487 for ; Thu, 29 Apr 2004 14:04: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 1BJFsg-0001ZK-74 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 14:03:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TI3ULA006023 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 14:03:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFnq-0000Kr-85 for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 13:58: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 NAA17133 for ; Thu, 29 Apr 2004 13:58: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 1BJFnk-0001kU-KH for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 13:58:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFmq-0001Tr-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 13:57:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJFm4-0001D9-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 13:56:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFej-0006X9-J1; Thu, 29 Apr 2004 13:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFJs-0007oq-BS for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 13:27: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 NAA14852 for ; Thu, 29 Apr 2004 13:27: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 1BJFJm-0000Ny-Ta for ipv6@ietf.org; Thu, 29 Apr 2004 13:27:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFIj-00006s-00 for ipv6@ietf.org; Thu, 29 Apr 2004 13:26:21 -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 1BJFHr-0007dk-00 for ipv6@ietf.org; Thu, 29 Apr 2004 13:25:28 -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 i3THOuln029529 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 29 Apr 2004 19:25:01 +0200 (CEST) Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need 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: Ralph Droms , 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> Content-Type: text/plain Organization: JOIN-Team, WWU-Muenster Message-Id: <1083259495.32218.209.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 29 Apr 2004 19:24:56 +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 > and so the exchange should fail at this stage. I just realised some implications of your post. As I wrote in my other mail, the client indeed does not need to send IA options and hence the NoAddrsAvail will not be sent to the client in an Advertise message, if no IA options are used in the first place. But the real question is: does the client actually know when it doesn't need to send IA options? Consider this scenario: - O bit is set in RAs - DHCPv6 server is configured _not_ to assign addresses to DHCPv6 clients (SAA is used) - there is a DHCPv6 client that DOES NOT respect the O bit and consequently will request an address from the DHCPv6 server next to information options (DNS, etc.) In this case, the client doesn't know that it doesn't actually need to request an address and it will use IA options consequently. Hence the retrieval of information options will fail for the reasons you identified. That is, needless to say, bad. The only way around it is to either beforehand configure the client not to be a stateful DHCPv6 client or to only use a DHCPv6 client that respects the O bit. On the other hand, if you by default configured stateless DHCPv6 you would be lost in a subnet without RAs. So, the only way out of this dilemma is to have a DHCPv6 client that respects the M/O bits. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 29 15:27: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 PAA22556 for ; Thu, 29 Apr 2004 15:27: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 1BJH85-0005Fk-Vt for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 15:23:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJNTMi020191 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 15:23:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGof-0001XN-RH for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:03: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 PAA19948 for ; Thu, 29 Apr 2004 15:03:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGoZ-0002zM-In for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 15:03:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGne-0002xO-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 15:02:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJGnL-0002vR-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 15:02:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGgA-0003Pf-63; Thu, 29 Apr 2004 14:54:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFNf-0008Gw-IH for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 13:31: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 NAA15057 for ; Thu, 29 Apr 2004 13: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 1BJFNZ-0001Rp-W5 for ipv6@ietf.org; Thu, 29 Apr 2004 13:31:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFMh-0001Bz-00 for ipv6@ietf.org; Thu, 29 Apr 2004 13:30:28 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJFMC-0000vv-00 for ipv6@ietf.org; Thu, 29 Apr 2004 13:29:56 -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 i3THTx7s019131 for ; Thu, 29 Apr 2004 18:29:59 +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 SAA02525 for ; Thu, 29 Apr 2004 18:29:58 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i3THTwl06122 for ipv6@ietf.org; Thu, 29 Apr 2004 18:29:58 +0100 Date: Thu, 29 Apr 2004 18:29:57 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: M/O flags: hints vs more [Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags)] Message-ID: <20040429172957.GE5433@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 Content-Transfer-Encoding: quoted-printable 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 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 On Thu, Apr 29, 2004 at 06:12:02PM +0300, Pekka Savola wrote: > On Thu, 29 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] =1B$B?@L@C#:H=1B(B wro= te: > > - details of the relationship between each flag and protocol, e.g. > > whether we should mandate to invoke the protocol or we can just > > regard the flag as a hint and let the host decide if it invokes the > > protocol (as Christian suggested), etc. >=20 > I support Christian's suggestion; they should be just hints. =20 It says "should" in 2462, not MUST? You want "may"? So it's not mandated at the moment, unless there's reference in another RFC? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 29 19:35: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 TAA10931 for ; Thu, 29 Apr 2004 19:35: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 1BJKwJ-0000oF-VP for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 19:27:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TNRZOL003104 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 19:27:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKqh-0007yB-Kr for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 19:21: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 TAA10343 for ; Thu, 29 Apr 2004 19:21: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 1BJKqc-0007k3-Ra for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 19:21:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKpg-0007eY-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 19:20:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJKp2-0007Zc-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 19:20:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKeP-0005zD-1s; Thu, 29 Apr 2004 19:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKVE-0004N8-2l for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 18:59: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 SAA09059 for ; Thu, 29 Apr 2004 18:59: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 1BJKV5-0005wE-IZ for ipv6@ietf.org; Thu, 29 Apr 2004 18:59:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKUC-0005qw-00 for ipv6@ietf.org; Thu, 29 Apr 2004 18:58:33 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1BJKTc-0005nb-00 for ipv6@ietf.org; Thu, 29 Apr 2004 18:57:56 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3TMvtdc012440 for ; Thu, 29 Apr 2004 16:57:55 -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 <0HWY007U0FSIYE@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Thu, 29 Apr 2004 16:57:55 -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 <0HWY00K3CFSH3Q@mail.sun.net> for ipv6@ietf.org; Thu, 29 Apr 2004 16:57:54 -0600 (MDT) Date: Thu, 29 Apr 2004 15:57:50 -0700 From: Alain Durand Subject: Re: M/O flags: hints vs more [Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags)] In-reply-to: <20040429172957.GE5433@login.ecs.soton.ac.uk> To: Tim Chown Cc: ipv6@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: multipart/alternative; boundary="Boundary_(ID_+ppFCUCFdFT27Wox7zGsIg)" References: <20040429172957.GE5433@login.ecs.soton.ac.uk> 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 --Boundary_(ID_+ppFCUCFdFT27Wox7zGsIg) Content-type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7BIT On Apr 29, 2004, at 10:29 AM, Tim Chown wrote: > On Thu, Apr 29, 2004 at 06:12:02PM +0300, Pekka Savola wrote: >> On Thu, 29 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: >>> - details of the relationship between each flag and protocol, e.g. >>> whether we should mandate to invoke the protocol or we can just >>> regard the flag as a hint and let the host decide if it invokes the >>> protocol (as Christian suggested), etc. >> >> I support Christian's suggestion; they should be just hints. > > It says "should" in 2462, not MUST? You want "may"? Essentially, yes, I'd like to see a "MAY" instead of a "should". - Alain. --Boundary_(ID_+ppFCUCFdFT27Wox7zGsIg) Content-type: text/enriched; charset=ISO-2022-JP Content-Transfer-Encoding: 7BIT On Apr 29, 2004, at 10:29 AM, Tim Chown wrote: On Thu, Apr 29, 2004 at 06:12:02PM +0300, Pekka Savola wrote: On Thu, 29 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] Hiragino Kaku Gothic Pro$B?@L@C#:H(B wrote: - details of the relationship between each flag and protocol, e.g. whether we should mandate to invoke the protocol or we can just regard the flag as a hint and let the host decide if it invokes the protocol (as Christian suggested), etc. I support Christian's suggestion; they should be just hints. It says "should" in 2462, not MUST? You want "may"? Essentially, yes, I'd like to see a "MAY" instead of a "should". - Alain. --Boundary_(ID_+ppFCUCFdFT27Wox7zGsIg)-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Apr 29 20:00:12 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12069 for ; Thu, 29 Apr 2004 20:00: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 1BJLQZ-0005Eh-Nj for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 19:58:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TNwpPs020123 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 19:58:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJLNO-0004ky-8J for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 19:55: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 TAA11907 for ; Thu, 29 Apr 2004 19:55: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 1BJLNI-0002ED-VA for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 19:55:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJLMO-00029e-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 19:54:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJLLb-00024U-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 19:53:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJLG6-0003op-PZ; Thu, 29 Apr 2004 19: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 1BJLCf-0003K1-UH for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 19:44: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 TAA11442 for ; Thu, 29 Apr 2004 19:44: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 1BJLCa-0001MS-RL for ipv6@ietf.org; Thu, 29 Apr 2004 19:44:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJLBj-0001JJ-00 for ipv6@ietf.org; Thu, 29 Apr 2004 19:43:31 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BJLAs-0001Cw-00 for ipv6@ietf.org; Thu, 29 Apr 2004 19:42:38 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3TNgBV13149 for ; Thu, 29 Apr 2004 16:42:11 -0700 X-mProtect: <200404292342> 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 smtpdcL5sY4; Thu, 29 Apr 2004 16:42:04 PDT Message-Id: <4.3.2.7.2.20040429163229.030f6af0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Apr 2004 16:40:12 -0700 To: ipv6@ietf.org From: Bob Hinden Subject: IPv6 Work Group Last Call: IPv6 Scoped Address Architecture 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 : 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. Please direct substantive comments to the IPv6 mailing list. Editorial comments can be directed 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 Thu Apr 29 22:13:26 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 WAA18467 for ; Thu, 29 Apr 2004 22:13: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 1BJNST-000817-HT for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 22:08:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U28vcL030803 for ipv6-archive@odin.ietf.org; Thu, 29 Apr 2004 22:08:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJNNe-0006yD-OC for ipv6-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 22:03: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 WAA18138 for ; Thu, 29 Apr 2004 22:03: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 1BJNNY-0004o7-EU for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 22:03:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJNMd-0004ht-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 22:02:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJNLx-0004ak-00 for ipv6-web-archive@ietf.org; Thu, 29 Apr 2004 22:02:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJNAA-0004lG-H6; Thu, 29 Apr 2004 21: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 1BJN7m-0004ID-GL for ipv6@optimus.ietf.org; Thu, 29 Apr 2004 21:47: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 VAA17306 for ; Thu, 29 Apr 2004 21: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 1BJN7g-0003Iw-9Q for ipv6@ietf.org; Thu, 29 Apr 2004 21:47:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJN6h-0003Ex-00 for ipv6@ietf.org; Thu, 29 Apr 2004 21:46:28 -0400 Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx with esmtp (Exim 4.12) id 1BJN5k-00037F-00 for ipv6@ietf.org; Thu, 29 Apr 2004 21:45:28 -0400 Received: from ocean.jinmei.org (unknown [2001:218:10ff:0:640f:b1e2:1c71:dfdb]) by tachyon.jinmei.org (Postfix) with ESMTP id B26D1355E4; Fri, 30 Apr 2004 10:45:18 +0900 (JST) Date: Fri, 30 Apr 2004 10:45:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bound, Jim" Cc: Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags) In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0612C9A0@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B0612C9A0@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=none autolearn=no version=2.60 >>>>> On Thu, 29 Apr 2004 11:09:18 -0400, >>>>> "Bound, Jim" said: > 3315 supports both m and o. just a fact. that I know. I'm not really sure about the intention of the above statement, but I guess you made your opinion (fact?) for the following point. >> - which protocol should be used for the O flag (If not, please clarify the real intention.) 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 Apr 30 01:09:40 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26159 for ; Fri, 30 Apr 2004 01:09: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 1BJQEX-0000bT-Ah for ipv6-archive@odin.ietf.org; Fri, 30 Apr 2004 01:06:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U56jrJ002319 for ipv6-archive@odin.ietf.org; Fri, 30 Apr 2004 01:06:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJQAe-0008Kd-Iq for ipv6-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 01:02: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 BAA25978 for ; Fri, 30 Apr 2004 01:02: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 1BJQAY-0006Bg-DQ for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 01:02:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJQ9d-00066V-00 for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 01:01:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJQ8o-00061N-00 for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 01:00:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJQ1F-00073K-Ix; Fri, 30 Apr 2004 00:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJPw5-0006Pt-Vu for ipv6@optimus.ietf.org; Fri, 30 Apr 2004 00:47: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 AAA25370 for ; Fri, 30 Apr 2004 00:47: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 1BJPvz-0004nZ-TL for ipv6@ietf.org; Fri, 30 Apr 2004 00:47:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJPv2-0004iw-00 for ipv6@ietf.org; Fri, 30 Apr 2004 00:46:37 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BJPuH-0004aO-00 for ipv6@ietf.org; Fri, 30 Apr 2004 00:45:49 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 10:17:37 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D6D14A88@kavithai.ctd.hcltech.com> From: "Subramonia Pillai - CTD, Chennai" To: Ole Troan Cc: ipv6@ietf.org Subject: RE: IPV6CP - RFC Compliance 2472 Date: Fri, 30 Apr 2004 10:15:17 +0530 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.0 required=5.0 tests=none autolearn=no version=2.60 Hi, According to RFC, Interface Identifier being used to not only for the Link-local address, EUI-64 global unicast address is derived from that. Based on your input, 1. How one end will come to know the other end address (both link-local and global unicast address)? 2. Will unicast routing protocol will advertise that address? or some other protocol? 3. Can you please tell me, what is being followed by the industry in this scenario ? Thanks Subu -----Original Message----- From: Ole Troan [mailto:ot@cisco.com] Sent: Thursday, April 29, 2004 9:18 PM To: Subramonia Pillai - CTD, Chennai Cc: ipv6@ietf.org Subject: Re: IPV6CP - RFC Compliance 2472 > One of Major Core Router vender is not advertising Interface Identifier as > part of IPV6CP Configuration Request. The control packet from that box is as > given below. > > 80 57 01 28 00 04 (no Interface Identifier options). > > Even I send Nak for this message with Interface Identifier option, I didn't > get Interface Identifier. In that case, how will come to bring up the link > and know the link-local address? Is it not violating standard? Please tell > me if any one of you already come across this issue. not speaking for the vendor in question. this is perfectly valid according to RFC2472. an implementation of IPV6CP doesn't need to support the Interface-Identifier option. you shouldn't need to know the peers link-local address anyway. /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 30 01:35: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 BAA27029 for ; Fri, 30 Apr 2004 01:35: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 1BJQc0-0007c1-GF for ipv6-archive@odin.ietf.org; Fri, 30 Apr 2004 01:31:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U5V0p3029262 for ipv6-archive@odin.ietf.org; Fri, 30 Apr 2004 01:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJQas-00073K-Vp for ipv6-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 01: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 BAA26823 for ; Fri, 30 Apr 2004 01: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 1BJQam-0000wf-KO for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 01:29:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJQZv-0000q8-00 for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 01:28:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJQZK-0000jj-00 for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 01:28:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJQRQ-0005dd-4B; Fri, 30 Apr 2004 01: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 1BJQPC-0005Pi-VX for ipv6@optimus.ietf.org; Fri, 30 Apr 2004 01:17: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 BAA26548 for ; Fri, 30 Apr 2004 01:17: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 1BJQP6-0007gY-Lc for ipv6@ietf.org; Fri, 30 Apr 2004 01:17:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJQOJ-0007bX-00 for ipv6@ietf.org; Fri, 30 Apr 2004 01:16:51 -0400 Received: from mx.uom.ac.mu ([202.60.7.12]) by ietf-mx with esmtp (Exim 4.12) id 1BJQNU-0007PP-00 for ipv6@ietf.org; Fri, 30 Apr 2004 01:16:00 -0400 Received: from texcomlabpc001 ([]) by mx.uom.ac.mu (Merak 7.2.0) with SMTP id DWA74278 for ; Fri, 30 Apr 2004 09:15:28 +0400 Message-ID: <003101c42e72$7ea0bfb0$241c16ac@ntcentral.uom.ac.mu> From: "spireen" To: Subject: routing in IPv6 Date: Fri, 30 Apr 2004 09:17:55 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C42E94.058D99A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 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.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C42E94.058D99A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I am a new researcher in mobile IPv6. I will like to know = the routing problems in IPv6.Bye. Mr Avinash=20 Reseacher in IPv6 University of Mauritius. ------=_NextPart_000_002E_01C42E94.058D99A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
       =20     I am a new researcher in mobile IPv6. I will like to = know the=20 routing problems in IPv6.Bye.
Mr Avinash
Reseacher in IPv6
University of = Mauritius.
------=_NextPart_000_002E_01C42E94.058D99A0-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Apr 30 04:05: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 EAA01964 for ; Fri, 30 Apr 2004 04:05: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 1BJSzm-0007mY-GE for ipv6-archive@odin.ietf.org; Fri, 30 Apr 2004 04:03:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U83g9l029887 for ipv6-archive@odin.ietf.org; Fri, 30 Apr 2004 04:03:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJSyv-0006a6-Ia for ipv6-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 04: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 EAA01847 for ; Fri, 30 Apr 2004 04: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 1BJSyp-00027S-JE for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 04:02:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJSxq-0001yu-00 for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 04:01:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJSwy-0001qF-00 for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 04:00:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJSsN-0005JC-47; Fri, 30 Apr 2004 03:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJSoR-0004bt-7j for ipv6@optimus.ietf.org; Fri, 30 Apr 2004 03:51: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 DAA01418 for ; Fri, 30 Apr 2004 03:51: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 1BJSoL-0000mE-08 for ipv6@ietf.org; Fri, 30 Apr 2004 03:51:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJSnP-0000eU-00 for ipv6@ietf.org; Fri, 30 Apr 2004 03:50:55 -0400 Received: from coconut.itojun.org ([221.249.121.227]) by ietf-mx with esmtp (Exim 4.12) id 1BJSmK-0000WQ-00 for ipv6@ietf.org; Fri, 30 Apr 2004 03:49:49 -0400 Received: by coconut.itojun.org (Postfix, from userid 1001) id 9E4636C; Fri, 30 Apr 2004 16:49:45 +0900 (JST) To: subramoniap@ctd.hcltech.com Cc: ot@cisco.com, ipv6@ietf.org Subject: RE: IPV6CP - RFC Compliance 2472 In-Reply-To: Your message of "Fri, 30 Apr 2004 10:15:17 +0530" <68C9DA8F50019B4E8622C53811BEE1D6D14A88@kavithai.ctd.hcltech.com> References: <68C9DA8F50019B4E8622C53811BEE1D6D14A88@kavithai.ctd.hcltech.com> X-Mailer: Cue version 0.6 (040307-1118/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040430074945.9E4636C@coconut.itojun.org> Date: Fri, 30 Apr 2004 16:49:45 +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 > Hi, > > According to RFC, Interface Identifier being used to not only for the > Link-local address, EUI-64 global unicast address is derived from that. > > Based on your input, > 1. How one end will come to know the other end address (both link-local and > global unicast address)? normally routers learn their peer's link-local address via routing protocol. there's no need to know global address. > 2. Will unicast routing protocol will advertise that address? or some other > protocol? they will advertise link-local address (in the case of RIPng). > 3. Can you please tell me, what is being followed by the industry in this > scenario ? what is "this scenario"? 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 Apr 30 09:37:36 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 JAA01215 for ; Fri, 30 Apr 2004 09:37: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 1BJY6E-0001Tt-Uf for ipv6-archive@odin.ietf.org; Fri, 30 Apr 2004 09:30:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UDUgO7005693 for ipv6-archive@odin.ietf.org; Fri, 30 Apr 2004 09: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 1BJXwt-0008TJ-N7 for ipv6-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 09:21: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 JAA00278 for ; Fri, 30 Apr 2004 09:20: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 1BJXws-0007DZ-3o for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 09:21:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXvt-00071L-00 for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 09:20:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJXut-0006le-00 for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 09:18:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXp7-0006I5-JN; Fri, 30 Apr 2004 09:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXfi-0004U3-P9 for ipv6@optimus.ietf.org; Fri, 30 Apr 2004 09:03: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 JAA29411 for ; Fri, 30 Apr 2004 09:03: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 1BJXfh-0003zf-90 for ipv6@ietf.org; Fri, 30 Apr 2004 09:03:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXem-0003nK-00 for ipv6@ietf.org; Fri, 30 Apr 2004 09:02:21 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BJXdr-0003O8-00 for ipv6@ietf.org; Fri, 30 Apr 2004 09:01:23 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 18:33:04 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D6D33510@kavithai.ctd.hcltech.com> From: "Subramonia Pillai - CTD, Chennai" To: itojun@itojun.org, "Subramonia Pillai - CTD, Chennai" Cc: ot@cisco.com, ipv6@ietf.org Subject: RE: IPV6CP - RFC Compliance 2472 Date: Fri, 30 Apr 2004 18:30:46 +0530 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.0 required=5.0 tests=none autolearn=no version=2.60 Hi, One of reason behind exchanging Interface Identifier as part of IPV6CP, is to make sure its uniqueness in both ends. Link-local address is generated from the Interface Identifier. If there is a clash, there is a chance both ends with use same address as link-local address? How we can avoid this? Thanks Subu -----Original Message----- From: itojun@itojun.org [mailto:itojun@itojun.org] Sent: Friday, April 30, 2004 1:20 PM To: subramoniap@ctd.hcltech.com Cc: ot@cisco.com; ipv6@ietf.org Subject: RE: IPV6CP - RFC Compliance 2472 > Hi, > > According to RFC, Interface Identifier being used to not only for the > Link-local address, EUI-64 global unicast address is derived from that. > > Based on your input, > 1. How one end will come to know the other end address (both link-local and > global unicast address)? normally routers learn their peer's link-local address via routing protocol. there's no need to know global address. > 2. Will unicast routing protocol will advertise that address? or some other > protocol? they will advertise link-local address (in the case of RIPng). > 3. Can you please tell me, what is being followed by the industry in this > scenario ? what is "this scenario"? 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 Apr 30 12:46:25 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 MAA13718 for ; Fri, 30 Apr 2004 12:46: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 1BJb4Z-0000nU-Pl for ipv6-archive@odin.ietf.org; Fri, 30 Apr 2004 12:41:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UGfBY5003059 for ipv6-archive@odin.ietf.org; Fri, 30 Apr 2004 12:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaxm-0006zy-Se for ipv6-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 12:34: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 MAA13059 for ; Fri, 30 Apr 2004 12:34: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 1BJaxl-0006Pj-8u for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 12:34:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJawn-0006Lt-00 for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 12:33:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJavx-0006I7-00 for ipv6-web-archive@ietf.org; Fri, 30 Apr 2004 12:32:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJan0-0004uY-28; Fri, 30 Apr 2004 12: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 1BJaTo-0008PJ-8X for ipv6@optimus.ietf.org; Fri, 30 Apr 2004 12:03: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 MAA11418 for ; Fri, 30 Apr 2004 12:03: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 1BJaTm-0004On-V1 for ipv6@ietf.org; Fri, 30 Apr 2004 12:03:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJaSx-0004L1-00 for ipv6@ietf.org; Fri, 30 Apr 2004 12:02:20 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BJaRy-0004Ew-00 for ipv6@ietf.org; Fri, 30 Apr 2004 12:01:18 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3UG0hW9016224; Fri, 30 Apr 2004 09:00:44 -0700 (PDT) Received: (from otroan@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA14351; Fri, 30 Apr 2004 17:00:41 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: "Subramonia Pillai - CTD, Chennai" Cc: itojun@itojun.org, ipv6@ietf.org Subject: Re: IPV6CP - RFC Compliance 2472 References: <68C9DA8F50019B4E8622C53811BEE1D6D33510@kavithai.ctd.hcltech.com> From: Ole Troan Date: Fri, 30 Apr 2004 17:00:41 +0100 In-Reply-To: <68C9DA8F50019B4E8622C53811BEE1D6D33510@kavithai.ctd.hcltech.com> (Subramonia Pillai's message of "Fri, 30 Apr 2004 18:30:46 +0530") Message-ID: <7t5llkdpiae.fsf@mrwint.cisco.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2.95 (usg-unix-v) 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=none autolearn=no version=2.60 > One of reason behind exchanging Interface Identifier as part of IPV6CP, is > to make sure its uniqueness in both ends. Link-local address is generated > from the Interface Identifier. > > If there is a clash, there is a chance both ends with use same address as > link-local address? How we can avoid this? for the record, I do think it is useful to negotiate the interface identifier. in the case where you cannot, just use DAD to ensure uniqueness. /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------