From exim@www1.ietf.org Sun Feb 1 00:05:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25380 for ; Sun, 1 Feb 2004 00:05:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An9nU-0006al-Rk for ipv6-archive@odin.ietf.org; Sun, 01 Feb 2004 00:05:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1155Svv025339 for ipv6-archive@odin.ietf.org; Sun, 1 Feb 2004 00:05:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An9nU-0006ac-N6 for ipv6-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 00:05: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 AAA25330 for ; Sun, 1 Feb 2004 00:05:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An9nS-0005sX-00 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 00:05:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An9mT-0005lD-00 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 00:04:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1An9lU-0005eS-00 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 00:03:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An9l8-0006Gb-IJ; Sun, 01 Feb 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 1An9kb-0006GA-VF for ipv6@optimus.ietf.org; Sun, 01 Feb 2004 00:02: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 AAA25219 for ; Sun, 1 Feb 2004 00:02:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An9kZ-0005Yt-00 for ipv6@ietf.org; Sun, 01 Feb 2004 00:02:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An9jy-0005TW-00 for ipv6@ietf.org; Sun, 01 Feb 2004 00:01:50 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1An9iu-0005FF-00 for ipv6@ietf.org; Sun, 01 Feb 2004 00:00:44 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 7C44A653 for ; Sun, 1 Feb 2004 00:00:14 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 01 Feb 2004 00:00:14 -0500 Message-Id: <20040201050014.7C44A653@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% | 5 | 20.46% | 31257 | mbagnulo@ing.uc3m.es 16.67% | 5 | 17.06% | 26067 | huitema@windows.microsoft.com 13.33% | 4 | 10.92% | 16681 | pekkas@netcore.fi 10.00% | 3 | 12.10% | 18488 | mukesh.gupta@nokia.com 10.00% | 3 | 9.32% | 14244 | brian@innovationslab.net 6.67% | 2 | 5.53% | 8452 | alain.durand@sun.com 3.33% | 1 | 4.88% | 7453 | ftemplin@iprg.nokia.com 3.33% | 1 | 3.45% | 5276 | internet-drafts@ietf.org 3.33% | 1 | 3.39% | 5179 | brc@zurich.ibm.com 3.33% | 1 | 2.74% | 4180 | sommerfeld@east.sun.com 3.33% | 1 | 2.70% | 4127 | bob.hinden@nokia.com 3.33% | 1 | 2.56% | 3918 | itojun@itojun.org 3.33% | 1 | 2.55% | 3892 | gih@telstra.net 3.33% | 1 | 2.35% | 3587 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 30 |100.00% | 152801 | 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 Feb 1 19:42:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20369 for ; Sun, 1 Feb 2004 19:42:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnSAF-0002lc-Es for ipv6-archive@odin.ietf.org; Sun, 01 Feb 2004 19:42:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i120gB1X010633 for ipv6-archive@odin.ietf.org; Sun, 1 Feb 2004 19:42:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnSAF-0002lQ-2k for ipv6-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 19:42:11 -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 TAA20208 for ; Sun, 1 Feb 2004 19:42:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnSAD-0000Uh-00 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 19:42:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnS8b-00005y-00 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 19:40:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnS7K-0007ke-07 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 19:39:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnRxW-0007IH-0a; Sun, 01 Feb 2004 19:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnRwx-00079h-A6 for ipv6@optimus.ietf.org; Sun, 01 Feb 2004 19:28: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 TAA19649 for ; Sun, 1 Feb 2004 19:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnRwv-0006pf-00 for ipv6@ietf.org; Sun, 01 Feb 2004 19:28:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnRwH-0006gg-00 for ipv6@ietf.org; Sun, 01 Feb 2004 19:27:45 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx with esmtp (Exim 4.12) id 1AnRuz-0006OP-00 for ipv6@ietf.org; Sun, 01 Feb 2004 19:26:25 -0500 Received: from localhost ([130.194.13.81]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L64HWAZEZO91Y39P@vaxc.its.monash.edu.au> for ipv6@ietf.org; Mon, 02 Feb 2004 11:25:15 +1100 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 0AE481B000C; Mon, 02 Feb 2004 11:25:15 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id E36B2124005; Mon, 02 Feb 2004 11:25:14 +1100 (EST) Date: Mon, 02 Feb 2004 11:25:14 +1100 From: Greg Daley Subject: Learning a valid prefix (Re: ICMPv6: New destination unreachable codes) To: Christian Huitema Cc: Mukesh.Gupta@nokia.com, pekkas@netcore.fi, mbagnulo@ing.uc3m.es, ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <401D98EA.7070907@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 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 Hi Christian, I agree, Desination Unreachable is not the right place to put this information. I'll explain further below. Christian Huitema wrote: >>If I am not wrong, if we wanted the router to send the correct >>prefix to the host in the ICMP message, we will have to change >>the format of the ICMPv6 Destination Unreachable message. >> >>Currently, we just have 4 bytes unused in the message format and >>this prefix can't fit in there. >> >>So the question is: is it worth changing the format of the message >>for this optimization ?? > > > Probably not. Having the proper code is a really nice first step. While the ICMP Dest Unreachable message isn't the right place to put this sort of information, it should be available in the advertised routing information (for a first hop router). When configuring addresses, the first point of contact is the router from which the address was configured. Unless there's a configuration issue within the access network, one of the most likely reasons for receiving this message is that the host is misconfigured (may have changed access networks). SEND defines not only standard prefix discovery, but also provides certificates of which prefixes a router is allowed to route (that particular source addresses are valid). So, either prefix discovery (by requiring source addresses to be from on-link prefixes) or an authoritative routing delegation can be used to identify valid prefixes for the router. If the device providing the invalid source message is not on the first hop, I'm pretty sure you wouldn't trust it to dictate which address to use anyway (without further checks). Greg Daley -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 1 19:42:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20439 for ; Sun, 1 Feb 2004 19:42:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnSAR-0002nq-F1 for ipv6-archive@odin.ietf.org; Sun, 01 Feb 2004 19:42:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i120gN0f010767 for ipv6-archive@odin.ietf.org; Sun, 1 Feb 2004 19:42:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnSAR-0002na-Aj for ipv6-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 19:42: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 TAA20269 for ; Sun, 1 Feb 2004 19:42:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnSAP-0000XE-00 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 19:42:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnS8x-00009j-00 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 19:40:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnS7O-0007ke-01 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 19:39:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnRtx-0005uM-65; Sun, 01 Feb 2004 19:25:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnMbV-00039D-0W for ipv6@optimus.ietf.org; Sun, 01 Feb 2004 13:45: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 NAA07146 for ; Sun, 1 Feb 2004 13:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnMbS-0007iW-00 for ipv6@ietf.org; Sun, 01 Feb 2004 13:45:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnMaZ-0007e0-00 for ipv6@ietf.org; Sun, 01 Feb 2004 13:45:00 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnMZn-0007Z1-00 for ipv6@ietf.org; Sun, 01 Feb 2004 13:44:12 -0500 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i11Ihwk14067; Sun, 1 Feb 2004 10:43:59 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sun, 1 Feb 2004 10:43:57 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Brian Haberman cc: ipv6@ietf.org, "Wijnen, Bert (Bert)" Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt In-Reply-To: <200401301650.LAA26852@ietf.org> 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=none autolearn=no version=2.60 On Fri, 30 Jan 2004 Internet-Drafts@ietf.org wrote: > 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 : IP Forwarding Table MIB > Author(s) : M. Wasserman, B. Haberman > Filename : draft-ietf-ipv6-rfc2096-update-06.txt > Pages : 36 > Date : 2004-1-29 Brian, The following change from the previous version caught my attention: 28 Jan 2004 Added range of (0..128) to inetCidrRoutePfxLen The corresponding object definition now reads: inetCidrRoutePfxLen OBJECT-TYPE SYNTAX InetAddressPrefixLength (0..128) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the number of leading one bits which form the mask to be logical-ANDed with the destination address before being compared to the value in the inetCidrRouteDest field. The values for the index objects inetCidrRouteDest and inetCidrRoutePfxLen must be consistent. When the value of inetCidrRouteDest is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object inetCidrRoutePfxLen MUST be equal to x. If not, then the index pair is not consistent and an inconsistentName error must be returned on SET or CREATE requests." ::= { inetCidrRouteEntry 3 } There are two things (IMHO) that are wrong with this definition: 1.) RFC 3291 and its successor draft-ietf-ops-rfc3291bis-03.txt both go to great lengths to tell MIB authors not to sub-type InetAddressType and InetAddress objects: The InetAddressType and InetAddress objects SHOULD NOT be sub-typed in object definitions. Sub-typing binds the MIB module to specific address formats, which may cause serious problems if new address formats need to be introduced. Note that it is possible to write compliance statements in order to express that only a subset of the defined address types must be implemented to be compliant. Since the same kinds of problems can be introduces by sub-typing InetAddressPrefixLength, it seems to me that if we are consistent in our usage we should not sub-type InetAddressPrefixLength objects, either. I've raised this issue on the mreview (Mib Doctors) mailing list; archives are at http://ops.ietf.org/lists/mreview/ for those who wish to review the discussion. If the reason why inetCidrRoutePfxLen got a range restriction was to silence warning from SNICng or some other MIB compiler then a better solution would be to use the range (0..2040), which will accomodate an address length up to 255 octets. Since InetAddress objects already have a size restriction of 255 octets, this does not impose any additional arbitrary limitations other than those already imposed by the InetAddress TC itself. Another possibility, of course, is to remove the range restriction, since it is not required by the SMI (in this case compiler warning != illegal practice). 2.) The following problem is one that neither I (nor, apparently, any other reviewers) noticed up to now: inetCidrRoutePfxLen allows the value zero, but the object definition does not specify what the value zero means. Note that RFC 3291 requires that if the value zero is allowed, then its meaning must be specified in the object definition: The value zero is object-specific and must be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations where the Internet network address prefix is unknown or does not apply. To me, the meaning when inetCidrRoutePfxLen is set to zero is clear: the corresponding row represents a default route. But that might not be true for everyone, and it would be good to spell this out in the DESCRIPTION clause, as RFC 3291 requires. Thanks and regards, Mike Heard -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 1 19:42:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20438 for ; Sun, 1 Feb 2004 19:42:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnSAR-0002nZ-0q for ipv6-archive@odin.ietf.org; Sun, 01 Feb 2004 19:42:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i120gMsr010751 for ipv6-archive@odin.ietf.org; Sun, 1 Feb 2004 19:42:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnSAQ-0002nK-Rg for ipv6-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 19:42:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20266 for ; Sun, 1 Feb 2004 19:42:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnSAP-0000X8-00 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 19:42:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnS8w-00009b-00 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 19:40:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnS7O-0007ke-00 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 19:39:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnRu0-0005vg-T8; Sun, 01 Feb 2004 19:25:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnMuq-0003PC-Ki for ipv6@optimus.ietf.org; Sun, 01 Feb 2004 14:05:56 -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 OAA07705 for ; Sun, 1 Feb 2004 14:05:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnMuo-0001fl-00 for ipv6@ietf.org; Sun, 01 Feb 2004 14:05:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnMtu-0001bR-00 for ipv6@ietf.org; Sun, 01 Feb 2004 14:04:59 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AnMtS-0001WX-00 for ipv6@ietf.org; Sun, 01 Feb 2004 14:04:31 -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 i11J3WV21469; Sun, 1 Feb 2004 11:03:32 -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 i11JDPlN004349 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 1 Feb 2004 11:13:33 -0800 Message-ID: <401D4D77.1010907@innovationslab.net> Date: Sun, 01 Feb 2004 14:03:19 -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: "C. M. Heard" CC: ipv6@ietf.org, "Wijnen, Bert (Bert)" Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.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 Mike, C. M. Heard wrote: > On Fri, 30 Jan 2004 Internet-Drafts@ietf.org wrote: > >>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 : IP Forwarding Table MIB >> Author(s) : M. Wasserman, B. Haberman >> Filename : draft-ietf-ipv6-rfc2096-update-06.txt >> Pages : 36 >> Date : 2004-1-29 > > > Brian, > > The following change from the previous version caught my attention: > > 28 Jan 2004 Added range of (0..128) to inetCidrRoutePfxLen > > The corresponding object definition now reads: > > inetCidrRoutePfxLen OBJECT-TYPE > SYNTAX InetAddressPrefixLength (0..128) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Indicates the number of leading one bits which form the > mask to be logical-ANDed with the destination address > before being compared to the value in the > inetCidrRouteDest field. > > The values for the index objects inetCidrRouteDest and > inetCidrRoutePfxLen must be consistent. When the value > of inetCidrRouteDest is x, then the bitwise logical-AND > of x with the value of the mask formed from the > corresponding index object inetCidrRoutePfxLen MUST be > equal to x. If not, then the index pair is not > consistent and an inconsistentName error must be > returned on SET or CREATE requests." > ::= { inetCidrRouteEntry 3 } > > There are two things (IMHO) that are wrong with this definition: > > 1.) RFC 3291 and its successor draft-ietf-ops-rfc3291bis-03.txt > both go to great lengths to tell MIB authors not to sub-type > InetAddressType and InetAddress objects: > > The InetAddressType and InetAddress objects SHOULD NOT be sub-typed > in object definitions. Sub-typing binds the MIB module to specific > address formats, which may cause serious problems if new address > formats need to be introduced. Note that it is possible to write > compliance statements in order to express that only a subset of the > defined address types must be implemented to be compliant. > > Since the same kinds of problems can be introduces by sub-typing > InetAddressPrefixLength, it seems to me that if we are consistent in > our usage we should not sub-type InetAddressPrefixLength objects, > either. I've raised this issue on the mreview (Mib Doctors) mailing > list; archives are at http://ops.ietf.org/lists/mreview/ for those > who wish to review the discussion. > > If the reason why inetCidrRoutePfxLen got a range restriction was to > silence warning from SNICng or some other MIB compiler then a better > solution would be to use the range (0..2040), which will accomodate > an address length up to 255 octets. Since InetAddress objects > already have a size restriction of 255 octets, this does not impose > any additional arbitrary limitations other than those already > imposed by the InetAddress TC itself. Another possibility, of > course, is to remove the range restriction, since it is not required > by the SMI (in this case compiler warning != illegal practice). > The range was added based on a comment from Bert. I similar change was made in the IP MIB update (2011bis). I believe the comment I saw was that adding a range to the prefix length was not a big deal since the addition of another address type would require other changes in the mib. My preference is to leave it unrestricted (i.e. no range), but I could argue it either way. I would like to hear others' comments on this issue since both 2011bis and 2096bis are very close to being done. > 2.) The following problem is one that neither I (nor, apparently, > any other reviewers) noticed up to now: inetCidrRoutePfxLen allows > the value zero, but the object definition does not specify what the > value zero means. Note that RFC 3291 requires that if the value > zero is allowed, then its meaning must be specified in the object > definition: > > The value zero is object-specific and must be defined as > part of the description of any object which uses this > syntax. Examples of the usage of zero might include > situations where the Internet network address prefix > is unknown or does not apply. > > To me, the meaning when inetCidrRoutePfxLen is set to zero is clear: > the corresponding row represents a default route. But that might > not be true for everyone, and it would be good to spell this out in > the DESCRIPTION clause, as RFC 3291 requires. I can add text to the DESCRIPTION that states that the value 0 indicates a default route. Thanks, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 1 20:11:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21957 for ; Sun, 1 Feb 2004 20:11:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnSc7-0005lW-6y for ipv6-archive@odin.ietf.org; Sun, 01 Feb 2004 20:10:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i121AxEw022156 for ipv6-archive@odin.ietf.org; Sun, 1 Feb 2004 20:10:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnSc7-0005lH-0U for ipv6-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 20:10:59 -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 UAA21767 for ; Sun, 1 Feb 2004 20:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnSc4-0005VW-00 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 20:10:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnSSv-0002tE-00 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 20:01:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnSQt-0002Vy-04 for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 19:59:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AnSDI-0004tK-0R for ipv6-web-archive@ietf.org; Sun, 01 Feb 2004 19:45:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnSD1-0003qk-VB; Sun, 01 Feb 2004 19:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnSCE-0003XH-EZ for ipv6@optimus.ietf.org; Sun, 01 Feb 2004 19:44:14 -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 TAA20656 for ; Sun, 1 Feb 2004 19:44:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnSCC-0000t5-00 for ipv6@ietf.org; Sun, 01 Feb 2004 19:44:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnSBE-0000iz-00 for ipv6@ietf.org; Sun, 01 Feb 2004 19:43:13 -0500 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 1AnS9r-0000NY-00 for ipv6@ietf.org; Sun, 01 Feb 2004 19:41:47 -0500 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 5E2D87F81 for ; Mon, 2 Feb 2004 01:41:44 +0100 (CET) From: "Jeroen Massar" To: Subject: RE: Microsoft Security Resolution KB303663 Date: Mon, 2 Feb 2004 01:41:14 +0100 Organization: Unfix Message-ID: <00b801c3e925$43574380$210d640a@unfix.org> 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.4510 In-Reply-To: <0536299114.20040201050332@microsoft.com> Importance: Normal 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.1 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > Behalf Of TERESSA PROVOST > Sent: Sunday, February 01, 2004 11:04 AM > To: Ipv > Subject: Microsoft Security Resolution KB303663 This is ofcourse yet another virus(tm), with the new ultracool pick a pair of source/dest code in virusses this thing came through. Unfortunatly the ietf mailers don't do viruschecking yet :( The message headers are now blocked and need manual approval, thus it shouldn't happen again. If one notices any other oddities don't forget to mention them to me ofcourse... Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQB2coCmqKFIzPnwjEQKb/wCeJYytfY/TPURMy+WFWqTD+bSgGxQAnj8g bN109iCxOVG8TK2+CAEzy+VW =XmBW -----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 Mon Feb 2 01:40:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08343 for ; Mon, 2 Feb 2004 01:40: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 1AnXkr-00027e-D6 for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 01:40:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i126eLCP008155 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 01:40:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnXkr-00027S-4i for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 01:40:21 -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 BAA08319 for ; Mon, 2 Feb 2004 01:40:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnXko-0000px-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 01:40:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnXjs-0000ku-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 01:39:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnXjD-0000gJ-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 01:38:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnXic-0001nI-Hs; Mon, 02 Feb 2004 01: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 1AnXi1-0001b1-TE for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 01:37: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 BAA08244 for ; Mon, 2 Feb 2004 01:37:23 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnXhy-0000Zy-00 for ipv6@ietf.org; Mon, 02 Feb 2004 01:37:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnXhA-0000Un-00 for ipv6@ietf.org; Mon, 02 Feb 2004 01:36:32 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AnXgE-0000Oc-00 for ipv6@ietf.org; Mon, 02 Feb 2004 01:35:34 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i126ZYM29378 for ; Mon, 2 Feb 2004 08:35:34 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Feb 2004 08:35:33 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 2 Feb 2004 00:35:31 -0600 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: ICMPv6: New destination unreachable codes Date: Mon, 2 Feb 2004 00:35:31 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA4015471BB@daebe009.americas.nokia.com> Thread-Topic: ICMPv6: New destination unreachable codes Thread-Index: AcPoC5hYsuV2yWhKRWeCTg37cTOmTAAMHxgQAEaLMEA= To: , , Cc: X-OriginalArrivalTime: 02 Feb 2004 06:35:31.0469 (UTC) FILETIME=[C138CBD0:01C3E956] 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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with Christian and Pekka here. So I think, we mostly agree upon the text that I had sent out and I don't have to make any changes to that. > -----Original Message----- > From: ext Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Saturday, January 31, 2004 1:04 PM > To: Pekka Savola; marcelo bagnulo > Cc: Gupta Mukesh (Nokia-NET/MtView); ipv6@ietf.org > Subject: RE: ICMPv6: New destination unreachable codes >=20 >=20 > > But this is just an operational procedure, which needs to=20 > be stated in > > the multihoming solution documents, but something that IMHO must not > > be added to the ICMPv6 spec, as it's really out of scope from ICMP > > perspective. >=20 > I agree with Pekka. The purpose of the ICMPv6 document is to=20 > reserve the > code and define the format. As Marcelo said, the MH code can work with > this code and format. Let's just go with it. >=20 > I understand Marcelo's concern. He (and I) would like to make life as > good as possible for hosts in multi-homed sites. This will require > operational rules for hosts and for routers. As I mentioned in a > previous message, the code definition is a nice first step.=20 > It tells the > host that it should try another source address. It is only a=20 > first step, > because it does not tell which one. The host will have to use some > heuristic. In some cases, e.g. when there are just two addresses, the > heuristic is trivial. In more complex cases, having more information > might help. But it may be a bit early to determine how this=20 > information > should be passed. We could pass it in ICMP messages, but we could just > as well use a yet-to-be-defined information protocol associating exit > routers with allowed prefixes, or even let hosts use some cached > knowledge from previous connections. Given the wide choices, I would > rather not try to mess around with the ICMPv6 specification. >=20 > -- Christian Huitema >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 02:11:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21171 for ; Mon, 2 Feb 2004 02:11: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 1AnYEs-0007Qi-CI for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 02:11:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i127BL27028544 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 02:11:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYEr-0007Pv-0h for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 02:11:21 -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 CAA21098 for ; Mon, 2 Feb 2004 02:11:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnYEn-0003XN-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 02:11:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnYDs-0003Qa-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 02:10:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnYCv-0003Kd-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 02:09:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYCe-0006Us-SL; Mon, 02 Feb 2004 02:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYC3-0006FE-Dy for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 02:08: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 CAA18439 for ; Mon, 2 Feb 2004 02:08:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnYBz-0003Ek-00 for ipv6@ietf.org; Mon, 02 Feb 2004 02:08:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnYB5-00039j-00 for ipv6@ietf.org; Mon, 02 Feb 2004 02:07:28 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnYAg-000344-00 for ipv6@ietf.org; Mon, 02 Feb 2004 02:07:02 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1276VT29464; Mon, 2 Feb 2004 09:06:31 +0200 Date: Mon, 2 Feb 2004 09:06:31 +0200 (EET) From: Pekka Savola To: Mukesh.Gupta@nokia.com cc: ipv6@ietf.org Subject: Re: ICMPv6: New destination unreachable codes In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABE7D@daebe009.americas.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 29 Jan 2004 Mukesh.Gupta@nokia.com wrote: > 5 - source address failed ingress policy [...] > > If the reason for the failure to deliver is that packets with this > source address is not allowed due to ingress filtering policies, the > Code field is set to 5. One minor comment here: this code could also be applicable to egress policies, if the site is practising those. (That is, before sending the traffic off to your upstream interface, check at the outbound interface that the source address belongs to your site prefixes.) Pedantically that's egress filtering. Should we just replace "ingress" with "ingress/egress"? -- 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 Feb 2 02:38:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23447 for ; Mon, 2 Feb 2004 02:38:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYf2-0006N2-N8 for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 02:38:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i127cO7t024460 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 02:38:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYf0-0006MJ-KV for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 02:38:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23405 for ; Mon, 2 Feb 2004 02:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnYew-0006O6-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 02:38:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnYdy-0006Gx-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 02:37:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnYd3-0006Ac-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 02:36:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYcn-0005ro-AS; Mon, 02 Feb 2004 02:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYcB-0005jZ-G3 for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 02:35: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 CAA23249 for ; Mon, 2 Feb 2004 02:35:24 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnYc7-00064Y-00 for ipv6@ietf.org; Mon, 02 Feb 2004 02:35:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnYbG-0005z0-00 for ipv6@ietf.org; Mon, 02 Feb 2004 02:34:31 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AnYao-0005t4-00 for ipv6@ietf.org; Mon, 02 Feb 2004 02:34:02 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i127Y2M24330 for ; Mon, 2 Feb 2004 09:34:02 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Feb 2004 09:34:02 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 2 Feb 2004 01:34:01 -0600 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: ICMPv6: New destination unreachable codes Date: Mon, 2 Feb 2004 01:34:00 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA4015471BE@daebe009.americas.nokia.com> Thread-Topic: ICMPv6: New destination unreachable codes Thread-Index: AcPpWx90GGY7cHSURCG537JQF1wdegAA5nQA To: Cc: X-OriginalArrivalTime: 02 Feb 2004 07:34:01.0172 (UTC) FILETIME=[ED2AF940:01C3E95E] 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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > 5 - source address failed ingress policy > [...] > >=20 > > If the reason for the failure to deliver is that packets=20 > with this > > source address is not allowed due to ingress filtering=20 > policies, the > > Code field is set to 5. >=20 > One minor comment here: this code could also be applicable to egress=20 > policies, if the site is practising those. (That is, before sending=20 > the traffic off to your upstream interface, check at the outbound=20 > interface that the source address belongs to your site prefixes.) =20 > Pedantically that's egress filtering. >=20 > Should we just replace "ingress" with "ingress/egress"? Makes sense. will change that. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 04:41:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29318 for ; Mon, 2 Feb 2004 04:41:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnaZ7-0001wC-EZ for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 04:40:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i129ePAE007445 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 04:40:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnaZ6-0001vu-Rj for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 04:40:24 -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 EAA29279 for ; Mon, 2 Feb 2004 04:40:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnaZ3-0004dI-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 04:40:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnaY8-0004Xt-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 04:39:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnaXL-0004TH-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 04:38:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnaWo-0001Q5-Ou; Mon, 02 Feb 2004 04: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 1AnaWC-0001I8-Qx for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 04:37:24 -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 EAA29175 for ; Mon, 2 Feb 2004 04:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnaW9-0004NS-00 for ipv6@ietf.org; Mon, 02 Feb 2004 04:37:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnaVD-0004IM-00 for ipv6@ietf.org; Mon, 02 Feb 2004 04:36:23 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1AnaUN-00047z-00 for ipv6@ietf.org; Mon, 02 Feb 2004 04:35:31 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id EB7E1842FA; Mon, 2 Feb 2004 10:35:01 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.18]) by merkur.iu-bremen.de (Postfix) with ESMTP id 25E618257C; Mon, 2 Feb 2004 10:35:01 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 1B7F88A6E; Mon, 2 Feb 2004 10:35:01 +0100 (CET) Date: Mon, 2 Feb 2004 10:35:01 +0100 From: Juergen Schoenwaelder To: Brian Haberman Cc: "C. M. Heard" , ipv6@ietf.org, "Wijnen, Bert (Bert)" Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt Message-ID: <20040202093501.GB881@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Brian Haberman , "C. M. Heard" , ipv6@ietf.org, "Wijnen, Bert (Bert)" References: <401D4D77.1010907@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <401D4D77.1010907@innovationslab.net> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 Sun, Feb 01, 2004 at 02:03:19PM -0500, Brian Haberman wrote: > The range was added based on a comment from Bert. I similar change > was made in the IP MIB update (2011bis). I believe there is no problem with not having a range restriction since the type is an Unsigned32 which should nicely fit into an OID subidentifier. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 05:34:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01801 for ; Mon, 2 Feb 2004 05:34:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnbOu-0007NL-Vu for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 05:33:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12AXup4028350 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 05:33:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnbOu-0007NB-Mr for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 05:33:56 -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 FAA01777 for ; Mon, 2 Feb 2004 05:33:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnbOr-0002OG-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 05:33:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnbNw-0002Fq-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 05:32:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnbNH-00026n-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 05:32:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnbN6-0006zA-Dm; Mon, 02 Feb 2004 05:32:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnbMZ-0006yX-Py for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 05:31:31 -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 FAA01530 for ; Mon, 2 Feb 2004 05:31:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnbMW-00023U-00 for ipv6@ietf.org; Mon, 02 Feb 2004 05:31:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnbLV-0001xO-00 for ipv6@ietf.org; Mon, 02 Feb 2004 05:30:25 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1AnbKa-0001nu-00 for ipv6@ietf.org; Mon, 02 Feb 2004 05:29:29 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 9D0F984383; Mon, 2 Feb 2004 11:28:58 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.18]) by merkur.iu-bremen.de (Postfix) with ESMTP id AA3FD8436E; Mon, 2 Feb 2004 11:28:55 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 742198A6E; Mon, 2 Feb 2004 11:28:55 +0100 (CET) Date: Mon, 2 Feb 2004 11:28:55 +0100 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Cc: "David Perkins (E-mail)" , "C. M. Heard" , ipv6@ietf.org, Brian Haberman Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt Message-ID: <20040202102855.GC1126@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Wijnen, Bert (Bert)" , "David Perkins (E-mail)" , "C. M. Heard" , ipv6@ietf.org, Brian Haberman References: <7D5D48D2CAA3D84C813F5B154F43B155028EC4B6@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC4B6@nl0006exch001u.nl.lucent.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 Mon, Feb 02, 2004 at 11:18:14AM +0100, Wijnen, Bert (Bert) wrote: > I think (but I hope David Perkins can give definite answer) that the > warning is given because it is used as an index object. OK, this might be the reason for the message. > An unsigned32 includes value zero, which we prefer not to be valid > value for an index. If people do want to allow for zero, then they > better be explicit about that. I think 0 makes sense for the default route as explained by Mike. Otherwise, if the idea is indeed to exclude 0, then the range should be (1..4294967295) - this makes it quite clear that just 0 was removed from the set of possible values. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 06:14:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04221 for ; Mon, 2 Feb 2004 06:14:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anc28-0003vi-9c for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 06:14:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12BEST1015103 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 06:14:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anc28-0003vW-1B for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 06:14: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 GAA04196 for ; Mon, 2 Feb 2004 06:14:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anc24-0007c6-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 06:14:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anc1A-0007Wh-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 06:13:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Anc0F-0007Qy-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 06:12:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anbzl-0003cX-NT; Mon, 02 Feb 2004 06:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnbzM-0003bv-9W for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 06:11:36 -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 GAA04120 for ; Mon, 2 Feb 2004 06:11:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnbzI-0007LX-00 for ipv6@ietf.org; Mon, 02 Feb 2004 06:11:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnbyO-0007GE-00 for ipv6@ietf.org; Mon, 02 Feb 2004 06:10:37 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1Anbxr-0007Al-00 for ipv6@ietf.org; Mon, 02 Feb 2004 06:10:03 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A8CA88FF0; Mon, 2 Feb 2004 12:09:34 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 91A238FEA; Mon, 2 Feb 2004 12:09:34 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , , Cc: Subject: RE: ICMPv6: New destination unreachable codes Date: Mon, 2 Feb 2004 12:08:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <8D260779A766FB4A9C1739A476F84FA4015471BB@daebe009.americas.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ok, we include the additional stuff in the mh solution when we need it. Regards, marcelo > -----Mensaje original----- > De: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] > Enviado el: lunes, 02 de febrero de 2004 7:36 > Para: huitema@windows.microsoft.com; pekkas@netcore.fi; > mbagnulo@ing.uc3m.es > CC: ipv6@ietf.org > Asunto: RE: ICMPv6: New destination unreachable codes > > > I agree with Christian and Pekka here. > > So I think, we mostly agree upon the text that I had sent out > and I don't have to make any changes to that. > > > -----Original Message----- > > From: ext Christian Huitema [mailto:huitema@windows.microsoft.com] > > Sent: Saturday, January 31, 2004 1:04 PM > > To: Pekka Savola; marcelo bagnulo > > Cc: Gupta Mukesh (Nokia-NET/MtView); ipv6@ietf.org > > Subject: RE: ICMPv6: New destination unreachable codes > > > > > > > But this is just an operational procedure, which needs to > > be stated in > > > the multihoming solution documents, but something that IMHO must not > > > be added to the ICMPv6 spec, as it's really out of scope from ICMP > > > perspective. > > > > I agree with Pekka. The purpose of the ICMPv6 document is to > > reserve the > > code and define the format. As Marcelo said, the MH code can work with > > this code and format. Let's just go with it. > > > > I understand Marcelo's concern. He (and I) would like to make life as > > good as possible for hosts in multi-homed sites. This will require > > operational rules for hosts and for routers. As I mentioned in a > > previous message, the code definition is a nice first step. > > It tells the > > host that it should try another source address. It is only a > > first step, > > because it does not tell which one. The host will have to use some > > heuristic. In some cases, e.g. when there are just two addresses, the > > heuristic is trivial. In more complex cases, having more information > > might help. But it may be a bit early to determine how this > > information > > should be passed. We could pass it in ICMP messages, but we could just > > as well use a yet-to-be-defined information protocol associating exit > > routers with allowed prefixes, or even let hosts use some cached > > knowledge from previous connections. Given the wide choices, I would > > rather not try to mess around with the ICMPv6 specification. > > > > -- 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 Feb 2 07:10:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05969 for ; Mon, 2 Feb 2004 07:10:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ancte-0001Es-6M for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 07:09:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12C9kvN004756 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 07:09:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anctd-0001Ed-TO for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 07:09: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 HAA05963 for ; Mon, 2 Feb 2004 07:09:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnctZ-0004kl-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 07:09:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ancsk-0004e3-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 07:08:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ancs9-0004Vw-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 07:08:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ancrx-00007b-OL; Mon, 02 Feb 2004 07:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AncrU-0008Jx-FL for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 07:07: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 HAA05768 for ; Mon, 2 Feb 2004 07:07:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AncrP-0004S3-00 for ipv6@ietf.org; Mon, 02 Feb 2004 07:07:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AncqW-0004Mw-00 for ipv6@ietf.org; Mon, 02 Feb 2004 07:06:32 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ancpp-0004D4-00 for ipv6@ietf.org; Mon, 02 Feb 2004 07:05:50 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 62869843A8; Mon, 2 Feb 2004 13:05:19 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.18]) by merkur.iu-bremen.de (Postfix) with ESMTP id 812C084388; Mon, 2 Feb 2004 13:05:18 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 54BCA5EE6E; Mon, 2 Feb 2004 13:05:17 +0100 (CET) Date: Mon, 2 Feb 2004 13:05:17 +0100 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Cc: "David Perkins (E-mail)" , "C. M. Heard" , ipv6@ietf.org, Brian Haberman Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt Message-ID: <20040202120517.GB1725@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Wijnen, Bert (Bert)" , "David Perkins (E-mail)" , "C. M. Heard" , ipv6@ietf.org, Brian Haberman References: <7D5D48D2CAA3D84C813F5B154F43B155028EC4BA@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC4BA@nl0006exch001u.nl.lucent.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 Mon, Feb 02, 2004 at 11:39:30AM +0100, Wijnen, Bert (Bert) wrote: > > > > I think 0 makes sense for the default route as explained by Mike. > > Otherwise, if the idea is indeed to exclude 0, then the range should > > be (1..4294967295) - this makes it quite clear that just 0 was removed > > from the set of possible values. > > > I understand that zero makes sense. I did not say we should remove it. > I said that by specifying the range (and including zero) that that way > we are explicit to state that we do want it included. I am not sure I like the direction to specify ranges which just repeat what is there anyway. See below... > By the way I like Mike's proposal to make it (0..2040), which would > line up with the max size of an InetAddress (255 octets). This makes indeed sense. One can ask whether this range should not be added to the InetPrefixLength TC itself so that the range is already bound to the TC. Of course, applying to your logic above, you would repeat the range (0..2040) anyway just to be explicit that zero is included... So what do we do? a) Add the range (0..2040) to the InetPrefixLength TC? (Now is the right time to do this.) b) Add the range (0..2040) just to the objects in question that use the InetPrefixLength TC? c) Do both? I think I prefer a) at the moment. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 08:45:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11657 for ; Mon, 2 Feb 2004 08:45: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 1AneNS-0000bW-BJ for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 08:44:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12DicO1002316 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 08:44:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneNS-0000bH-3s for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 08:44: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 IAA11574 for ; Mon, 2 Feb 2004 08:44:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AneNQ-0001Aj-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 08:44:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AneMW-00010M-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 08:43:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AneLg-0000uU-06 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 08:42:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ane3d-0005f8-Jg; Mon, 02 Feb 2004 08:24:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anbkq-0001BP-93 for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 05:56:36 -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 FAA03531 for ; Mon, 2 Feb 2004 05:56:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anbkm-0005sL-00 for ipv6@ietf.org; Mon, 02 Feb 2004 05:56:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anbjp-0005mO-00 for ipv6@ietf.org; Mon, 02 Feb 2004 05:55:33 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AnbjV-0005gk-00 for ipv6@ietf.org; Mon, 02 Feb 2004 05:55:13 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i12AsdH21026 for ; Mon, 2 Feb 2004 04:54:40 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Feb 2004 11:39:30 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC4BA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'j.schoenwaelder@iu-bremen.de'" , "Wijnen, Bert (Bert)" Cc: "David Perkins (E-mail)" , "C. M. Heard" , ipv6@ietf.org, Brian Haberman Subject: RE: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt Date: Mon, 2 Feb 2004 11:39:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > > I think (but I hope David Perkins can give definite answer) > > that the > > warning is given because it is used as an index object. > > OK, this might be the reason for the message. > > > An unsigned32 includes value zero, which we prefer not to be valid > > value for an index. If people do want to allow for zero, then they > > better be explicit about that. > > I think 0 makes sense for the default route as explained by Mike. > Otherwise, if the idea is indeed to exclude 0, then the range should > be (1..4294967295) - this makes it quite clear that just 0 was removed > from the set of possible values. > I understand that zero makes sense. I did not say we should remove it. I said that by specifying the range (and including zero) that that way we are explicit to state that we do want it included. By the way I like Mike's proposal to make it (0..2040), which would line up with the max size of an InetAddress (255 octets). Bert > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 08:45:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11680 for ; Mon, 2 Feb 2004 08:45:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneNa-0000dU-26 for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 08:44:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12DikS0002438 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 08:44:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneNZ-0000dF-TM for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 08:44: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 IAA11612 for ; Mon, 2 Feb 2004 08:44:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AneNY-0001Bj-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 08:44:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AneMe-000120-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 08:43:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AneLh-0000uU-01 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 08:42:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ane3b-0005ew-T6; Mon, 02 Feb 2004 08:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnbBu-0006Lg-5g for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 05:20:30 -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 FAA01003 for ; Mon, 2 Feb 2004 05:20:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnbBq-0000qY-00 for ipv6@ietf.org; Mon, 02 Feb 2004 05:20:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnbAt-0000lC-00 for ipv6@ietf.org; Mon, 02 Feb 2004 05:19:28 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AnbAH-0000c5-00 for ipv6@ietf.org; Mon, 02 Feb 2004 05:18:49 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i12AIHH15046 for ; Mon, 2 Feb 2004 04:18:17 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Feb 2004 11:18:15 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC4B6@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "David Perkins (E-mail)" , "'j.schoenwaelder@iu-bremen.de'" Cc: "C. M. Heard" , ipv6@ietf.org, Brian Haberman Subject: RE: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt Date: Mon, 2 Feb 2004 11:18:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 > > The range was added based on a comment from Bert. I similar change > > was made in the IP MIB update (2011bis). > > I believe there is no problem with not having a range restriction > since the type is an Unsigned32 which should nicely fit into an OID > subidentifier. > I think (but I hope David Perkins can give definite answer) that the warning is given because it is used as an index object. An unsigned32 includes value zero, which we prefer not to be valid value for an index. If people do want to allow for zero, then they better be explicit about that. Dave? Bert > /js -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 08:51:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12486 for ; Mon, 2 Feb 2004 08:51:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneTP-0001aF-LR for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 08:50:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12DolW0006081 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 08:50:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneTP-0001a0-Em for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 08:50:47 -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 IAA12461 for ; Mon, 2 Feb 2004 08:50:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AneTO-0002Pv-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 08:50:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AneSn-0002Ke-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 08:50:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AneRy-0002Bh-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 08:49:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneRl-0001Ea-2v; Mon, 02 Feb 2004 08:49:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneR9-00015m-6m for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 08:48: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 IAA12188 for ; Mon, 2 Feb 2004 08:48:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AneR7-0001zM-00 for ipv6@ietf.org; Mon, 02 Feb 2004 08:48:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnePc-0001dA-00 for ipv6@ietf.org; Mon, 02 Feb 2004 08:46:54 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AneNF-00016L-00 for ipv6@ietf.org; Mon, 02 Feb 2004 08:44:25 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 43B1715263; Mon, 2 Feb 2004 22:44:23 +0900 (JST) Date: Mon, 02 Feb 2004 22:44:23 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: pekkas@netcore.fi Cc: ipv6@ietf.org Subject: a new revision of ipv6-scoping-arch-00 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,HTML_MESSAGE autolearn=no version=2.60 Hello, I'm now (finally) revising draft-ietf-ipv6-scoping-arch-00.txt, addressing comments received during the WG last call. I've almost done on the revise work, but want to be sure about some of your comments (hopefully you remember the comments and follow-up discussions). First, I'm still not sure how I can deal with the following point: > When an implementation interprets the format, it should construct the > "full" zone ID, which contains the scope type, from the > part and the scope type specified by the
part. > >==> unless I have completely misunderstood the spec, the first "scope type" >should actually be "scope zone" :-) In response to this comment, I said the first "scope type" was correct and it corresponds to the following part of Section 6: Each zone index of a particular scope should contain an information to represent the scope type, so that all indices of all scopes are unique within the node and zone indices themselves can be used for a dedicated purpose. You then said: >Reading the first snippet (the first above), I got the feeling "but hey, >why is full zone ID including the scope type, and the scope type being >overridden from the
". So there probably has to be some revision >to clarify that? Why the "full" zone ID is including the scope type is explained in Section 6 (to make it clear, I myself did not support the idea. But this was the wg consensus). So are you okay if we refer to section 6 from Section 11? Except for this particular point, I've addressed all the comments, or at least have proposals to the comments. The following three may be controversial, so I'll explicitly propose the resolution here. >3) I think this statement in section 5 needs to be spelled out a bit more: > > Each interface belongs to exactly one zone of each possible scope. > >.. that is, this could be read either as it's probably intended ("no >interface must belong to more than one zone"), or as "each interface must >be in a zone of each scope, even if it would have no addresses etc. from >that scope". If the intent is the latter, this needs to be spelled out a >bit more, if the former, a different wording should be used. Proposed resolution: revise the text to (i.e, add the second sentence): Each interface belongs to exactly one zone of each possible scope. Note that this means an interface belongs to a scope zone regardless of what kind of unicast address the interface has or of which multicast groups the node joins on the interface. >6) In the section 9, "Forwarding", I think the text about picking the >destination address zone could be enhanced a bit: > > o The zone of the destination address is determined by the scope of > the address and arrival interface of the packet. The next-hop > interface is chosen by looking up the destination address in a > (conceptual) routing table specific to that zone. That routing > table is restricted to refer only to interfaces belonging to that > zone. >==> that is, this does not seem to spell out whether the routing table >could include more than just the interfaces of destination address zone -- >i.e., in the case of a global destination address, the "interfaces belonging >to that zone" is a bit confusing :-) Proposed resolution: do not change anything on this. Reason: even after reading a follow-up from you, I still don't think this is a problem. We could add something like "Note that if the destination address has the global scope, the routing table refers to all the interfaces of the node". But, IMO, the original wording includes this, and the additional note seems even redundant to me. I admit the wording "only" sounds a little bit odd when it actually means "all", but it doesn't look so strange for me that a formal specification has this type of wording. >11) Note that there is a normative reference to the ICMPv6-bis document, >which has been pretty much stalled for the last 2 years or so. This >document cannot be published before ICMPv6-bis is also published. The >ICMPv6-bis seems integral to this specification, so I think the options are >either to revise the text about sending ICMP DU "beyond the scope of source address" messages (removing it), or kicking off the effort for getting >ICMPv6-bis out of the door: > > [4] Conta, A. and S. Deering, "Internet Control Message (ICMPv6) for > the Internet Protocol Version 6 (IPv6)", Internet Draft draft- > ietf-ipngwg-icmp-v3-02.txt, November 2001. Proposed resolution: change the reference to the old RFC (2463), and describe this part as a new feature. More concretely, I'll revise this part as follows: ... Moreover, if the packets destination address is a unicast address, an ICMP Destination Unreachable message [4] with Code 2 ("beyond scope of source address") is sent to the source of the original packet. Note: Code 2, as defined in [4], had a different semantics, but the semantics has already been obsolete and the IANA is going to re-assign the value for the new purpose. (where [4] now refers to RFC2463.) This approach may look like a tricky compromise, but I agree on this with wg chairs by a local talk, and the chairs said they would soon ask the IANA for the new assignment. I hope this approach makes sense to others. 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 Feb 2 08:58:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12841 for ; Mon, 2 Feb 2004 08:58:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anea1-0002ED-4t for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 08:57:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12DvbAm008559 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 08:57:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anea0-0002Dy-UD for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 08:57:36 -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 IAA12836 for ; Mon, 2 Feb 2004 08:57:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AneZz-000337-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 08:57:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AneZ9-0002yT-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 08:56:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AneYv-0002tC-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 08:56:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneYU-0001rf-Mj; Mon, 02 Feb 2004 08:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneY2-0001qk-FX for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 08:55:34 -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 IAA12706 for ; Mon, 2 Feb 2004 08:55:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AneY1-0002qf-00 for ipv6@ietf.org; Mon, 02 Feb 2004 08:55:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AneX5-0002lZ-00 for ipv6@ietf.org; Mon, 02 Feb 2004 08:54:37 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AneWI-0002c0-00 for ipv6@ietf.org; Mon, 02 Feb 2004 08:53:46 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i12DrCC04865 for ; Mon, 2 Feb 2004 15:53:13 +0200 Date: Mon, 2 Feb 2004 15:53:12 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt In-Reply-To: <40158529.2090805@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 26 Jan 2004, Brian Haberman wrote: > This is the start of an IPv6 working group last call on: > > > Title : Unique Local IPv6 Unicast Addresses > > Author(s) : R. Hinden, B. Haberman > > Filename : draft-ietf-ipv6-unique-local-addr-02.txt > > Pages : 16 > > Date : 2004-1-21 Below are my comments. I don't think we really need this kind of stuff, but as local addressing seems to have been taken as granted already, I don't argue on those grounds. (However, at some point I believe someone will make you insert a better applicability statement on where to (not) use the local addressing.. you could very well try to do it now.) As for the rest, I have a major concern on picking just one registrar for the central allocations. I also have major deployment and implementation concerns with "default deny" policies; they seem to be unacceptable or unfeasible. The security of local addressing must be based on the fact that the site administrator has toggled on a switch or configured the access-lists -- NOT on protocols having to filter out the addresses, or having some kind of default access-lists magically deny all the traffic at vague site borders. Below.. substantial ----------- 1) specifying just one allocator to the end-sites; this is always bad and prone to create monsters such as ICANN. It seems like that the model should be provided to support enough registries (e.g. 2 bit = 4 or 3 bits = 8). Just to make sure that the customers can pick someone else's service unless they aren't satisfied with an organization, so that there is some incentive not to have too high charges, to avoid the claims of building monopolies who get free money for numbers, etc.etc. Unless you have instructions in mind for IANA who should have this registry monopoly, there should probably be multiple registries in the only one of them screws up in a major way (e.g., compare to the mess with .com zone by verisign). 2) The specification requires that routing protocols special-case these prefixes by MUST filtering them. This is unacceptable, and should be removed. Any filtering should be done by the sites themselves. Note that running any other protocol than BGP is not feasible anyway to be run over administrative domains (exclusing provider-provisioned VPNs, maybe, but those are special case anyway), so we can pretty much limit the discussion to BGP. Which is pretty trivial, because 1) why would the ISP advertise such prefixes, and 2) why would the site not filter out stuff it doesn't want. Any routing protocol that is used between sites MUST filter out any incoming or outgoing Local IPv6 unicast routes. The exception to this is if specific /48 IPv6 local unicast routes have been configured to allow for inter-site communication. If BGP is being used at the site border with an ISP, filters MUST be installed by default in the BGP configuration to keep any Local IPv6 address prefixes from being advertised outside of the site or for these prefixes to be learned from another site. The exception to this is if there are specific /48 routes created for one or more Local IPv6 prefixes. 3) Similar to the above, there are some particularly inpractical issues with site-border security: Site border routers SHOULD install a black hole route for the Local IPv6 prefix FC00::/7. This will insure that packets with Local IPv6 destination addresses will not be forwarded outside of the site via a default route. Site border routers SHOULD respond with the appropriate ICMPv6 Destination Unreachable message to inform the source that the packet was not forwarded [ICMPV6]. This feedback is important to avoid transport protocol timeouts. 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. The default behavior of these devices SHOULD be to filter them. Site border routers SHOULD respond with the appropriate ICMPv6 Destination Unreachable message to inform the source that the packet was not forwarded. .. this is inpractical, and should be reworded. The site border routers cannot know that they are site-border routers, so these checks cannot be implemented. What you can do is state that a toggle SHOULD be implemented and when enabled on an interface, it would apply these kind of restrictions to it. But the point is that you WILL need administrator action. "Deny by default" just is not practical approach here, because you don't know that you should be denying these by default. Additionally, domain border routers connecting autonomous systems throughout the Internet SHOULD obey these recommendations for site border routers. ==> as for this, I have no idea what this even tries to say, so it requires rewording. semi-editorial -------------- 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). ==> hopefully the centrally assigned global IDs don't use their (single) computer's EUI-64 in the generation :-) 4) Compute an MD5 digest on the key as specified in [MD5DIG]. ==> security folks have been pushed for the use of SHA-1 because it's more collision-proof. It doesn't matter much in this specific context, but at least nobody would object if you changed this to using an SHA-1 digest. Site border routers SHOULD install a black hole route for the Local IPv6 prefix FC00::/7. ==> I think you mean "a reject route" ? (or a "discard" route might also work OK) For future study names with Local IPv6 addresses may be resolved inside of the site using dynamic naming systems such as Multicast DNS. ==> this seems irrelevant and should be removed; above, it already states someting general about local naming systems. Local IPv6 addresses, like global scope unicast addresses, are only assigned to nodes if their use has been enabled (via IPv6 address autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually) and configured in the DNS. ==> "and configured in the DNS" is not requirement and is irrelevant; should be removed? assign them. In order for a node to learn the Local IPv6 address of another node, the Local IPv6 address must have been installed in the DNS. ==> s/DNS/DNS or another naming system/ ? 11.2 Disadvantages ==> Add to disadvantages: - Instead of using global unicast addresses inside the sites, the sites may be tempted to start using Local IPv6 addresses excessively, instead of using global unicast addresses and reachability restrictions such as firewalls or access control lists. editorial --------- ==> please include the IPR and copyright sections if possible.. INTERNET-DRAFT R. Hinden, Nokia January 20, 2004 Brian Haberman, Caspian ==> s/Brian/B./ (same style :) This document defines an unicast address format that is globally ==> s/an/an IPv6/ interface ID 64-bit IID as defined in [ADDARCH]. ==> s/IID/interface ID/ prefix and Global ID field length. There is a direct tradeoff ==> s/Global ID/global ID/ -- or at least be consistent whether it starts with the upper case in the middle of sentence or not (the same with a few other places) needlessly. A reasonable way of evaluating a specific field length is to compare it to a projected 2050 world population of 9.3 billion [POPUL] to compare the number of resulting /48 prefixes per person. ==> s/to compare/and/ (the latter "to compare") Prefix Global ID Number /48 Prefixes % of IPv6 Length Prefixes per Person Address Space ==> s/Number/Number of/ ==> IPv6 Address Space goes beyond 72 words/line, which is bad. A very high utilization ratio of these allocations can be assumed because no internal structure is required in the field nor is there any reason to be able to aggregate the prefixes. ==> sounds soooo awkward, maybe reword: A very high utilization ratio of these allocations can be assumed because the global ID field does not require internal structure, and there is no reason to be able to aggregate the prefixes. ... The authors believes that a /7 prefix resulting in a 41 bit Global ID ==> s/believes/believe/ exhausted. If more than this was needed, then additional IPv6 address space could be allocated for this purpose. ==> s/was/were to be/ ? should not be assigned sequentially or with well known numbers. This to ensure that there is not any relationship between allocations and ==> s/This/This is/ duplicate assignments. The local assignments are free and do not need any central coordination or assignment, but have a lower (but ==> remove "are free and" due to removing the 10 euro charge text? (without coordination or assignment, there certainly can't be any fee to them :) This is easiest to accomplish if there is a single source of the assignments. ==> sounds funny, maybe s/of/for/ ? addition to web based registration they should support some methods like telephone, postal mail, fax, telex, etc. They should also ==> perhaps it has been long enough to be able to remove "telex" from the list :-) It is escrowed to insure there are no duplicate allocations and in ==> s/insure/ensure/ (the same elsewhere) makes it easy to get a prefix with out the need to contact an ==> s/with out/without/ is adequate for sites planning a small to moderate amount inter-site communication using locally generated global IDs. Sites planning ==> s/amount/amount of/ [ICMPV6] Conta, A., S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC1885, December 1998. ==> old reference. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP00009, October 1996. ==> remove this, unused reference. [RTP] Schulzrinne, H., S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications" RFC1889, January 1996. ==> use RFC3550 instead. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 09:04:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13441 for ; Mon, 2 Feb 2004 09:04:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aneg4-0002zb-7f for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 09:03:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12E3qdR011500 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 09:03:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aneg4-0002zP-3Q for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 09:03: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 JAA13429 for ; Mon, 2 Feb 2004 09:03:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aneg2-0003vK-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 09:03:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anef9-0003ni-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 09:02:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AneeT-0003gj-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 09:02:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneeI-0002ay-KL; Mon, 02 Feb 2004 09:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneeA-0002Zq-0j for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 09:01:54 -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 JAA13261 for ; Mon, 2 Feb 2004 09:01:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anee8-0003e8-00 for ipv6@ietf.org; Mon, 02 Feb 2004 09:01:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnedI-0003We-00 for ipv6@ietf.org; Mon, 02 Feb 2004 09:01:01 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Anecl-0003Nz-00 for ipv6@ietf.org; Mon, 02 Feb 2004 09:00:27 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3182615263; Mon, 2 Feb 2004 23:00:26 +0900 (JST) Date: Mon, 02 Feb 2004 23:00:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: j.schoenwaelder@iu-bremen.de Cc: ipv6@ietf.org Subject: scope zone ID zero as the default (for revision of ipv6-scoping-arch) 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 Hello, (I hope you still remember this) during the wg last call for draft-ietf-ipv6-scoping-arch-00.txt, you proposed to use the zone ID value zero as the default with a higher requirement level: > b) I have a more serious issue with the default zone. The text says in > several places that the zone index zero might be used to indicate > the default zone but it explicitely allows to use other values. In > section six, it says: > Similarly, an implementation may choose an index value other > than zero to represent the default zone. > I am not sure why this is helpful. Is there a particular reason why > we can not just say that the default zone is indicated by a zone > index which MUST (or SHOULD if we have to compromise) be zero? And, if I remember the discussion correctly, the consensus was we should mandate zero as the default. So, I'd like to propose the following changes: ============ In Section 6 (the 3rd paragraph of page 7), change An implementation should also support the concept of a "default" zone for each scope. It is convenient to reserve the index value zero, at each scope, to mean "use the default zone". to An implementation should also support the concept of a "default" zone for each scope. And, when supported, the index value zero at each scope SHOULD be reserved to mean "use the default zone". And change the last paragraph of Section 6: An implementation may use any value it chooses to label a zone as long as it meets the requirement that the index value of each zone of all scopes be unique within the node. Similarly, an implementation may choose an index value other than zero to represent the default zone. to An implementation may use any value it chooses to label a zone as long as it meets the requirement that the index value of each zone of all scopes be unique within the node and that zero SHOULD be reserved to represent the default zone. ============ Would you live with this? I also slightly remember that someone in the Minneapolis meeting pointed out that it might be a good idea to ask other implementors if they use a non-zero value as the default. So, I now would like to ask the question here. If anyone knows an implementation that uses a different value as the default and especially if you object to mandating the default value, please speak up. 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 Mon Feb 2 09:13:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13878 for ; Mon, 2 Feb 2004 09:13: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 1Aneoa-00043K-0H for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 09:12:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12ECd0j015572 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 09:12:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneoZ-000435-RJ for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 09:12: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 JAA13872 for ; Mon, 2 Feb 2004 09:12:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AneoY-0004k6-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 09:12:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anenc-0004ek-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 09:11:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnenI-0004Zq-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 09:11:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anen0-0003dK-Ej; Mon, 02 Feb 2004 09:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anegy-000329-7m for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 09:04:48 -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 JAA13542 for ; Mon, 2 Feb 2004 09:04:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anegw-00042h-00 for ipv6@ietf.org; Mon, 02 Feb 2004 09:04:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aneg5-0003vs-00 for ipv6@ietf.org; Mon, 02 Feb 2004 09:03:54 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AnefG-0003kU-00 for ipv6@ietf.org; Mon, 02 Feb 2004 09:03:02 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i12E2SJ08200 for ; Mon, 2 Feb 2004 08:02:29 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Feb 2004 15:02:27 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC4BF@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'j.schoenwaelder@iu-bremen.de'" , "Wijnen, Bert (Bert)" Cc: "David Perkins (E-mail)" , "C. M. Heard" , ipv6@ietf.org, Brian Haberman Subject: RE: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt Date: Mon, 2 Feb 2004 15:02:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 > > By the way I like Mike's proposal to make it (0..2040), which would > > line up with the max size of an InetAddress (255 octets). > > This makes indeed sense. One can ask whether this range should not be > added to the InetPrefixLength TC itself so that the range is already > bound to the TC. Of course, applying to your logic above, you would > repeat the range (0..2040) anyway just to be explicit that zero is > included... > > So what do we do? > > a) Add the range (0..2040) to the InetPrefixLength TC? (Now > is the right > time to do this.) > > b) Add the range (0..2040) just to the objects in question > that use the > InetPrefixLength TC? > > c) Do both? > > I think I prefer a) at the moment. > I agree that a) is the best solution. And it does make the warning go away too! Bert > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 09:23:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14452 for ; Mon, 2 Feb 2004 09:23:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneyI-0005Kq-Ne for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 09:22:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12EMgNm020502 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 09:22:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneyI-0005Kb-If for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 09:22:42 -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 JAA14425 for ; Mon, 2 Feb 2004 09:22:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AneyG-0005nx-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 09:22:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnexR-0005hV-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 09:21:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Anewv-0005b6-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 09:21:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anewj-0004hj-H5; Mon, 02 Feb 2004 09:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnewP-0004cE-SN for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 09:20: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 JAA14263 for ; Mon, 2 Feb 2004 09:20:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnewO-0005Ym-00 for ipv6@ietf.org; Mon, 02 Feb 2004 09:20:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnevY-0005Sy-00 for ipv6@ietf.org; Mon, 02 Feb 2004 09:19:53 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aneut-0005N6-00 for ipv6@ietf.org; Mon, 02 Feb 2004 09:19:11 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C44CC1525D for ; Mon, 2 Feb 2004 23:19:10 +0900 (JST) Date: Mon, 02 Feb 2004 23:19:11 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: reference from ipv6-scoping-arch to ipaddr-text-rep 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 said in a separate message, I'm now revising draft-ietf-ipv6-scoping-arch-00 in response to the wg last call comments. I remember one related comment, which is not an explicit comment in the last call period though, that we may need to add a reference to draft-main-ipaddr-text-rep-01. I personally don't mind to include this one (and, in fact, I support this document). However, I'm not going to do it at the moment, since the base address architecture document won't have a reference to the ipaddr-text-rep draft (we discussed this in the ML before, but I've not seen a clear consensus - at least the authors did not explicitly agree to add the reference). Since the scoping-arch doc primarily refers to the base address architecture document, it would not make sense to refer to ipaddr-text-rep just from scoping-arch. If we can quickly agree upon the reference issue for the base document, I'll reflect the change for the next revision of ipv6-scoping-arch accordingly. In any event, I don't think this reference issue can be a show-stopper to advance the scoping-arch document. 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 Feb 2 09:56:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15842 for ; Mon, 2 Feb 2004 09:56:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnfUB-00084V-8y for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 09:55:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12EtdgG031021 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 09:55:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnfUB-00084G-1j for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 09:55: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 JAA15802 for ; Mon, 2 Feb 2004 09:55:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnfU9-0001Ci-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 09:55:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnfT9-00013s-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 09:54:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnfSC-0000wQ-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 09:53:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnfRd-0007eH-Gf; Mon, 02 Feb 2004 09:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnfRI-0007dM-BO for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 09:52:40 -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 JAA15640 for ; Mon, 2 Feb 2004 09:52:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnfRG-0000pP-00 for ipv6@ietf.org; Mon, 02 Feb 2004 09:52:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnfQG-0000jA-00 for ipv6@ietf.org; Mon, 02 Feb 2004 09:51:38 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1AnfPa-0000a3-00 for ipv6@ietf.org; Mon, 02 Feb 2004 09:50:54 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i12EoJRT126526 for ; Mon, 2 Feb 2004 14:50:19 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i12EoKUM283730 for ; Mon, 2 Feb 2004 15:50:20 +0100 Received: from zurich.ibm.com (sig-9-145-171-24.de.ibm.com [9.145.171.24]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA56254 for ; Mon, 2 Feb 2004 15:50:17 +0100 Message-ID: <401E63D2.DC645181@zurich.ibm.com> Date: Mon, 02 Feb 2004 15:50:58 +0100 From: Brian E Carpenter Reply-To: IPv6 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 Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, As I am packing for a 3.5 week trip, I don't have time to go into full detail. I mostly disagree with you on the big points (your smaller points are fine), but these are not new arguments anyway. > 1) specifying just one allocator to the end-sites; this is always bad > and prone to create monsters such as ICANN. That's unfair language. ICANN is not a monopolist. > It seems like that the model should be provided to support > enough registries (e.g. 2 bit = 4 or 3 bits = 8). It might indeed be wise for IANA to only hand out 1/8 of the space to the first registry - that would leave flexibility to create more if competition proved necessary. > Any routing protocol that is used between sites MUST filter out any > incoming or outgoing Local IPv6 unicast routes. The exception to > this is if specific /48 IPv6 local unicast routes have been > configured to allow for inter-site communication. I do agree this is badly phrased - it isn't the *protocol* that does the filtering, it's the default router config. Just as NATs are shipped with an effective "deny all" configured, IPv6 routers should be shipped with "deny FC00::/7" configured. And it's because so many corporate security solutions now depend on that effective "deny all", much as you and I may hate it, that we need this. You can certainly deny by default. A site that wants to use FC00::/7 internally or on VPNs can enable it where needed. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM *** I will be on vacation February 3-25, 2004 *** Pekka Savola wrote: > > On Mon, 26 Jan 2004, Brian Haberman wrote: > > This is the start of an IPv6 working group last call on: > > > > > Title : Unique Local IPv6 Unicast Addresses > > > Author(s) : R. Hinden, B. Haberman > > > Filename : draft-ietf-ipv6-unique-local-addr-02.txt > > > Pages : 16 > > > Date : 2004-1-21 > > Below are my comments. I don't think we really need this kind of > stuff, but as local addressing seems to have been taken as granted > already, I don't argue on those grounds. (However, at some point I > believe someone will make you insert a better applicability statement > on where to (not) use the local addressing.. you could very well try > to do it now.) > > As for the rest, I have a major concern on picking just one registrar > for the central allocations. I also have major deployment and > implementation concerns with "default deny" policies; they seem to be > unacceptable or unfeasible. The security of local addressing must be > based on the fact that the site administrator has toggled on a switch > or configured the access-lists -- NOT on protocols having to filter > out the addresses, or having some kind of default access-lists > magically deny all the traffic at vague site borders. > > Below.. > > substantial > ----------- > > 1) specifying just one allocator to the end-sites; this is always bad > and prone to create monsters such as ICANN. > > It seems like that the model should be provided to support > enough registries (e.g. 2 bit = 4 or 3 bits = 8). Just to make sure that > the customers can pick someone else's service unless they aren't satisfied > with an organization, so that there is some incentive not to have too high > charges, to avoid the claims of building monopolies who get free money for > numbers, etc.etc. > > Unless you have instructions in mind for IANA who should have this registry > monopoly, there should probably be multiple registries in the only one of > them screws up in a major way (e.g., compare to the mess with .com zone by > verisign). > > 2) The specification requires that routing protocols special-case these > prefixes by MUST filtering them. This is unacceptable, and should be > removed. Any filtering should be done by the sites themselves. Note that > running any other protocol than BGP is not feasible anyway to be run over > administrative domains (exclusing provider-provisioned VPNs, maybe, but > those are special case anyway), so we can pretty much limit the discussion > to BGP. Which is pretty trivial, because 1) why would the ISP advertise > such prefixes, and 2) why would the site not filter out stuff it doesn't > want. > > Any routing protocol that is used between sites MUST filter out any > incoming or outgoing Local IPv6 unicast routes. The exception to > this is if specific /48 IPv6 local unicast routes have been > configured to allow for inter-site communication. > > If BGP is being used at the site border with an ISP, filters MUST be > installed by default in the BGP configuration to keep any Local IPv6 > address prefixes from being advertised outside of the site or for > these prefixes to be learned from another site. The exception to > this is if there are specific /48 routes created for one or more > Local IPv6 prefixes. > > 3) Similar to the above, there are some particularly inpractical issues with > site-border security: > > Site border routers SHOULD install a black hole route for the Local > IPv6 prefix FC00::/7. This will insure that packets with Local IPv6 > destination addresses will not be forwarded outside of the site via a > default route. Site border routers SHOULD respond with the > appropriate ICMPv6 Destination Unreachable message to inform the > source that the packet was not forwarded [ICMPV6]. This feedback is > important to avoid transport protocol timeouts. > > 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. The default behavior of these devices > SHOULD be to filter them. Site border routers SHOULD respond with > the appropriate ICMPv6 Destination Unreachable message to inform the > source that the packet was not forwarded. > > .. this is inpractical, and should be reworded. The site border routers > cannot know that they are site-border routers, so these checks cannot be > implemented. What you can do is state that a toggle SHOULD be implemented > and when enabled on an interface, it would apply these kind of restrictions > to it. But the point is that you WILL need administrator action. "Deny by > default" just is not practical approach here, because you don't know that > you should be denying these by default. > > Additionally, domain border routers connecting autonomous systems > throughout the Internet SHOULD obey these recommendations for site > border routers. > > ==> as for this, I have no idea what this even tries to say, so it requires > rewording. > > semi-editorial > -------------- > > 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). > > ==> hopefully the centrally assigned global IDs don't use their > (single) computer's EUI-64 in the generation :-) > > 4) Compute an MD5 digest on the key as specified in [MD5DIG]. > > ==> security folks have been pushed for the use of SHA-1 because it's more > collision-proof. It doesn't matter much in this specific context, but at > least nobody would object if you changed this to using an SHA-1 digest. > > Site border routers SHOULD install a black hole route for the Local > IPv6 prefix FC00::/7. > > ==> I think you mean "a reject route" ? (or a "discard" route might > also work OK) > > For future study names with Local IPv6 addresses may be resolved > inside of the site using dynamic naming systems such as Multicast > DNS. > > ==> this seems irrelevant and should be removed; above, it already > states someting general about local naming systems. > > Local IPv6 addresses, like global scope unicast addresses, are only > assigned to nodes if their use has been enabled (via IPv6 address > autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually) and > configured in the DNS. > > ==> "and configured in the DNS" is not requirement and is irrelevant; should > be removed? > > assign them. In order for a node to learn the Local IPv6 address of > another node, the Local IPv6 address must have been installed in the > DNS. > > ==> s/DNS/DNS or another naming system/ ? > > 11.2 Disadvantages > > ==> Add to disadvantages: > > - Instead of using global unicast addresses inside the sites, the > sites may be tempted to start using Local IPv6 addresses excessively, > instead of using global unicast addresses and reachability restrictions > such as firewalls or access control lists. > > editorial > --------- > > ==> please include the IPR and copyright sections if possible.. > > INTERNET-DRAFT R. Hinden, Nokia > January 20, 2004 Brian Haberman, Caspian > > ==> s/Brian/B./ (same style :) > > This document defines an unicast address format that is globally > > ==> s/an/an IPv6/ > > interface ID 64-bit IID as defined in [ADDARCH]. > > ==> s/IID/interface ID/ > > prefix and Global ID field length. There is a direct tradeoff > > ==> s/Global ID/global ID/ -- or at least be consistent whether it starts > with the upper case in the middle of sentence or not (the same with a few > other places) > > needlessly. A reasonable way of evaluating a specific field length > is to compare it to a projected 2050 world population of 9.3 billion > [POPUL] to compare the number of resulting /48 prefixes per person. > > ==> s/to compare/and/ (the latter "to compare") > > Prefix Global ID Number /48 Prefixes % of IPv6 > Length Prefixes per Person Address Space > > ==> s/Number/Number of/ > > ==> IPv6 Address Space goes beyond 72 words/line, which is bad. > > A very high utilization ratio of these allocations can be assumed > because no internal structure is required in the field nor is there > any reason to be able to aggregate the prefixes. > > ==> sounds soooo awkward, maybe reword: > > A very high utilization ratio of these allocations can be assumed > because the global ID field does not require internal structure, > and there is no reason to be able to aggregate the prefixes. > > ... > The authors believes that a /7 prefix resulting in a 41 bit Global ID > > ==> s/believes/believe/ > > exhausted. If more than this was needed, then additional IPv6 > address space could be allocated for this purpose. > > ==> s/was/were to be/ ? > > should not be assigned sequentially or with well known numbers. This > to ensure that there is not any relationship between allocations and > > ==> s/This/This is/ > > duplicate assignments. The local assignments are free and do not > need any central coordination or assignment, but have a lower (but > > ==> remove "are free and" due to removing the 10 euro charge text? > (without coordination or assignment, there certainly can't be any > fee to them :) > > This is easiest to accomplish if there is a single source of the > assignments. > > ==> sounds funny, maybe s/of/for/ ? > > addition to web based registration they should support some methods > like telephone, postal mail, fax, telex, etc. They should also > > ==> perhaps it has been long enough to be able to remove "telex" from the > list :-) > > It is escrowed to insure there are no duplicate allocations and in > > ==> s/insure/ensure/ (the same elsewhere) > > makes it easy to get a prefix with out the need to contact an > > > ==> s/with out/without/ > > is adequate for sites planning a small to moderate amount inter-site > communication using locally generated global IDs. Sites planning > > ==> s/amount/amount of/ > > [ICMPV6] Conta, A., S. Deering, "Internet Control Message Protocol > (ICMPv6) for the Internet Protocol Version 6 (IPv6) > Specification", RFC1885, December 1998. > ==> old reference. > > [RFC2026] Bradner, S., "The Internet Standards Process -- Revision > 3", RFC 2026, BCP00009, October 1996. > > ==> remove this, unused reference. > > [RTP] Schulzrinne, H., S. Casner, R. Frederick, V. Jacobson, > "RTP: A Transport Protocol for Real-Time Applications" > RFC1889, January 1996. > > ==> use RFC3550 instead. > > -------------------------------------------------------------------- > 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 Feb 2 10:16:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17897 for ; Mon, 2 Feb 2004 10:16: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 1AnfnY-0006HK-4t for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 10:15:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12FFet3024128 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 10:15:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnfnX-0006H5-TC for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 10:15: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 KAA17857 for ; Mon, 2 Feb 2004 10:15:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnfnV-0003vI-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 10:15:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anfmd-0003qm-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 10:14:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnfmC-0003lb-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 10:14:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anfly-0005fR-6V; Mon, 02 Feb 2004 10:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anfld-0005c1-Nj for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 10:13:41 -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 KAA17661 for ; Mon, 2 Feb 2004 10:13:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anflb-0003kt-00 for ipv6@ietf.org; Mon, 02 Feb 2004 10:13:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anfkh-0003fw-00 for ipv6@ietf.org; Mon, 02 Feb 2004 10:12:43 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AnfkK-0003ai-00 for ipv6@ietf.org; Mon, 02 Feb 2004 10:12:20 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i12FCF8C022554; Mon, 2 Feb 2004 17:12:15 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i12FCFVw022551; Mon, 2 Feb 2004 17:12:15 +0200 Date: Mon, 2 Feb 2004 17:12:15 +0200 Message-Id: <200402021512.i12FCFVw022551@burp.tkv.asdf.org> From: Markku Savela To: jinmei@isl.rdc.toshiba.co.jp CC: pekkas@netcore.fi, ipv6@ietf.org In-reply-to: (message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= on Mon, 02 Feb 2004 22:44:23 +0900) Subject: Re: a new revision of ipv6-scoping-arch-00 References: Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 Wait a minute... > Moreover, if the packets destination address is a unicast address, > an ICMP Destination Unreachable message [4] with Code 2 ("beyond > scope of source address") is sent to the source of the original > packet. Note: Code 2, as defined in [4], had a different > semantics, but the semantics has already been obsolete and the > IANA is going to re-assign the value for the new purpose. .. isn't this code still needed/useful if one has , and packet falls into forwarding to another link? At least I don't have any special handling for link locals here, they get automaticly handled by scoping rules, e.g. beyond scope of source... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 10:36:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18861 for ; Mon, 2 Feb 2004 10:36:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ang7B-0000gn-KY for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 10:35:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12FZvX4002648 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 10:35:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ang7B-0000gd-6v for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 10:35: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 KAA18845 for ; Mon, 2 Feb 2004 10:35:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ang78-0005ky-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 10:35:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ang68-0005eO-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 10:34:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ang5b-0005Xr-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 10:34:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ang5K-0000M8-6c; Mon, 02 Feb 2004 10:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ang4x-0000Ko-L1 for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 10:33: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 KAA18700 for ; Mon, 2 Feb 2004 10:33:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ang4v-0005VG-00 for ipv6@ietf.org; Mon, 02 Feb 2004 10:33:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ang40-0005Pa-00 for ipv6@ietf.org; Mon, 02 Feb 2004 10:32:41 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ang32-0005KT-00 for ipv6@ietf.org; Mon, 02 Feb 2004 10:31:40 -0500 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i12FVNG31656; Mon, 2 Feb 2004 07:31:23 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 2 Feb 2004 07:31:22 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "Wijnen, Bert (Bert)" cc: "'j.schoenwaelder@iu-bremen.de'" , "David Perkins (E-mail)" , ipv6@ietf.org, Brian Haberman Subject: RE: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC4BF@nl0006exch001u.nl.lucent.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=none autolearn=no version=2.60 On Mon, 2 Feb 2004, Wijnen, Bert (Bert) wrote: > > So what do we do? > > > > a) Add the range (0..2040) to the InetPrefixLength TC? (Now > > is the right > > time to do this.) > > > > b) Add the range (0..2040) just to the objects in question > > that use the > > InetPrefixLength TC? > > > > c) Do both? > > > > I think I prefer a) at the moment. > > > I agree that a) is the best solution. That is my opinion, too. Mike -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 13:08:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27284 for ; Mon, 2 Feb 2004 13:08:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniU9-000795-R5 for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 13:07:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12I7n2F027463 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 13:07:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniU9-00078e-9z for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:07:49 -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 NAA27140 for ; Mon, 2 Feb 2004 13:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniU7-0002aP-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 13:07:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniPx-0001Wl-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 13:03:32 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AniN9-0000tL-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 13:00:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AniAZ-0006mx-DG for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 12:47:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ani95-00046F-DY; Mon, 02 Feb 2004 12:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ani8H-0003yF-92 for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 12:45:13 -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 MAA25254 for ; Mon, 2 Feb 2004 12:45:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ani8F-0006Nu-00 for ipv6@ietf.org; Mon, 02 Feb 2004 12:45:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ani27-0004qT-00 for ipv6@ietf.org; Mon, 02 Feb 2004 12:38:56 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnhuC-00037F-00 for ipv6@ietf.org; Mon, 02 Feb 2004 12:30:41 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i12HU2q09163; Mon, 2 Feb 2004 19:30:02 +0200 Date: Mon, 2 Feb 2004 19:30:02 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipv6@ietf.org Subject: Re: a new revision of ipv6-scoping-arch-00 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,HTML_MESSAGE autolearn=no version=2.60 On Mon, 2 Feb 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >Reading the first snippet (the first above), I got the feeling "but hey, > >why is full zone ID including the scope type, and the scope type being > >overridden from the
". So there probably has to be some revision > >to clarify that? > > Why the "full" zone ID is including the scope type is explained in > Section 6 (to make it clear, I myself did not support the idea. But > this was the wg consensus). So are you okay if we refer to section 6 > from Section 11? Fine with me. > > Each interface belongs to exactly one zone of each possible scope. > > > >.. that is, this could be read either as it's probably intended ("no > >interface must belong to more than one zone"), or as "each interface must > >be in a zone of each scope, even if it would have no addresses etc. from > >that scope". If the intent is the latter, this needs to be spelled out a > >bit more, if the former, a different wording should be used. > > Proposed resolution: revise the text to (i.e, add the second > sentence): > > Each interface belongs to exactly one zone of each possible scope. > Note that this means an interface belongs to a scope zone > regardless of what kind of unicast address the interface has or > of which multicast groups the node joins on the interface. Seems good. > >6) In the section 9, "Forwarding", I think the text about picking the > >destination address zone could be enhanced a bit: > > > > o The zone of the destination address is determined by the scope of > > the address and arrival interface of the packet. The next-hop > > interface is chosen by looking up the destination address in a > > (conceptual) routing table specific to that zone. That routing > > table is restricted to refer only to interfaces belonging to that > > zone. > > >==> that is, this does not seem to spell out whether the routing table > >could include more than just the interfaces of destination address zone -- > >i.e., in the case of a global destination address, the "interfaces belonging > >to that zone" is a bit confusing :-) > > Proposed resolution: do not change anything on this. > > Reason: even after reading a follow-up from you, I still don't think > this is a problem. We could add something like "Note that if the > destination address has the global scope, the routing table refers to > all the interfaces of the node". But, IMO, the original wording > includes this, and the additional note seems even redundant to me. I > admit the wording "only" sounds a little bit odd when it actually > means "all", but it doesn't look so strange for me that a formal > specification has this type of wording. I'd add a note like the one you describe, but I'm OK with leaving it out. > >11) Note that there is a normative reference to the ICMPv6-bis document, > >which has been pretty much stalled for the last 2 years or so. This > >document cannot be published before ICMPv6-bis is also published. The > >ICMPv6-bis seems integral to this specification, so I think the options are > >either to revise the text about sending ICMP DU "beyond the scope of source > address" messages (removing it), or kicking off the effort for getting > >ICMPv6-bis out of the door: > > > > [4] Conta, A. and S. Deering, "Internet Control Message (ICMPv6) for > > the Internet Protocol Version 6 (IPv6)", Internet Draft draft- > > ietf-ipngwg-icmp-v3-02.txt, November 2001. > > Proposed resolution: change the reference to the old RFC (2463), and > describe this part as a new feature. More concretely, I'll revise > this part as follows: > > ... > Moreover, if the packets destination address is a unicast address, > an ICMP Destination Unreachable message [4] with Code 2 ("beyond > scope of source address") is sent to the source of the original > packet. Note: Code 2, as defined in [4], had a different > semantics, but the semantics has already been obsolete and the > IANA is going to re-assign the value for the new purpose. > (where [4] now refers to RFC2463.) Fine with me. A few grammar checks; I'm assuming 'semantics' is not a special word (plural but acting as a singular form): s/packets/packet's/ ? s/a different/different/ ? s/semantics has already been obsolete/semantics are already obsolete/ (or "have already been obsoleted"? -- 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 Feb 2 13:09:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27579 for ; Mon, 2 Feb 2004 13:09:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniUv-0007HV-Fq for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 13:08:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12I8b3N027981 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 13:08:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniUv-0007HE-BO for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:08:37 -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 NAA27404 for ; Mon, 2 Feb 2004 13:08:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniUt-0002o8-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 13:08:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniRA-0001oQ-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 13:04:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AniNX-00010e-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 13:00:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniD3-0004o2-Ug; Mon, 02 Feb 2004 12:50:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniCj-0004ha-VM for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 12:49:49 -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 MAA25788 for ; Mon, 2 Feb 2004 12:49:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniCi-0007TU-00 for ipv6@ietf.org; Mon, 02 Feb 2004 12:49:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ani9V-0006fU-00 for ipv6@ietf.org; Mon, 02 Feb 2004 12:46:31 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ani4b-0005IG-00 for ipv6@ietf.org; Mon, 02 Feb 2004 12:41:26 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i12HerZ09349 for ; Mon, 2 Feb 2004 19:40:53 +0200 Date: Mon, 2 Feb 2004 19:40:53 +0200 (EET) From: Pekka Savola To: IPv6 Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt In-Reply-To: <401E63D2.DC645181@zurich.ibm.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 Mon, 2 Feb 2004, Brian E Carpenter wrote: > > 1) specifying just one allocator to the end-sites; this is always bad > > and prone to create monsters such as ICANN. > 7> That's unfair language. ICANN is not a monopolist. > > > It seems like that the model should be provided to support > > enough registries (e.g. 2 bit = 4 or 3 bits = 8). > > It might indeed be wise for IANA to only hand out 1/8 of the space > to the first registry - that would leave flexibility to create > more if competition proved necessary. Well, I just feel quite uncertain of the current model -- we're basically telling IANA to find someone to build a monopoly by selling IP addresses. Not so different from what RIRs do, of course, but at least they pretend the addresses don't cost anything. Here we WANT them to cost money. Monopolies and money for (pretty much) nothing seems like a bad idea. The only thing that seems to cost a significant amount of money in the proposal is to have a possibility to get the addresses over phone, fax, or whatever -- so that they cannot be processed automatically. On further thought, requiring non-Internet -based mechanisms doesn't seem to be worth the trouble, because those can't be (semi)automated. Anyone requiring such addresses can find a place to surf to a website, or send an email. If not, they have other things to worry about (or can use the locally generated ones if they really want). > > Any routing protocol that is used between sites MUST filter out any > > incoming or outgoing Local IPv6 unicast routes. The exception to > > this is if specific /48 IPv6 local unicast routes have been > > configured to allow for inter-site communication. > > I do agree this is badly phrased - it isn't the *protocol* that > does the filtering, it's the default router config. Just as NATs > are shipped with an effective "deny all" configured, IPv6 routers > should be shipped with "deny FC00::/7" configured. It would be trivial to say that the devices SHOULD (or MUST) be shipped with a built-in reject route for FC00::/7 -- this is simple and very easily implemented but then note that: - this only affects packets which are forwarded (destination address) - in source address, it would not be checked - the routers would have to know participate in the IGP, i.e., stub decide couldn't just point a default route towards the site's internal infrastructure (I'm not so sure how realistic this is). On the other hand, making this a firewall / access-list policy is pretty much unworkable because whether it would be activated or not would depend on the existance of the more specific routes. This would be a very unwelcome connection between the filters and routing tables. -- 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 Feb 2 14:01:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02588 for ; Mon, 2 Feb 2004 14:01:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjJu-000552-Rv for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 14:01:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12J1ILV019521 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 14:01:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjJu-00054l-IX for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 14:01:18 -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 OAA02485 for ; Mon, 2 Feb 2004 14:01:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjJs-0004u7-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 14:01:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjIW-0004bI-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 13:59:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnjGb-000448-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 13:57:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjFl-0004Iz-NS; Mon, 02 Feb 2004 13:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjEr-00041S-3B for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 13:56:05 -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 NAA01477 for ; Mon, 2 Feb 2004 13:56:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjEo-0003bA-00 for ipv6@ietf.org; Mon, 02 Feb 2004 13:56:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjBw-0002nm-00 for ipv6@ietf.org; Mon, 02 Feb 2004 13:53:06 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1Anj8M-0001tu-00 for ipv6@ietf.org; Mon, 02 Feb 2004 13:49:22 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Feb 2004 10:49:10 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Mon, 2 Feb 2004 10:48:45 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Feb 2004 10:48:49 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Feb 2004 10:50:59 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Feb 2004 10:48:39 -0800 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, 2 Feb 2004 10:47:16 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Date: Mon, 2 Feb 2004 10:48:45 -0800 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Thread-Index: AcPptRxUp8bCxF93Rt+Sp2ck7DpPNAABzjoQ From: "Christian Huitema" To: "Pekka Savola" , "IPv6" X-OriginalArrivalTime: 02 Feb 2004 18:47:16.0849 (UTC) FILETIME=[FADE1E10:01C3E9BC] 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 > Well, I just feel quite uncertain of the current model -- we're > basically telling IANA to find someone to build a monopoly by selling > IP addresses. Not so different from what RIRs do, of course, but at > least they pretend the addresses don't cost anything. Here we WANT > them to cost money. Monopolies and money for (pretty much) nothing > seems like a bad idea. I am also not sure that the specification should mention monetary exchanges. It should be sufficient to mention the operational goal, i.e. make sure that addresses are not hoarded and/or wasted. > The only thing that seems to cost a significant amount of money in the > proposal is to have a possibility to get the addresses over phone, > fax, or whatever -- so that they cannot be processed automatically. If the goal is just to prevent hoarding, then there are several alternatives to monetary exchanges. The registry could implement a "human test" to check that the numbers are actually requested by a human being rather than a machine. The registry could also require solving a computer puzzle of some kind, to attach a computing cost to the request. -- 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 Feb 2 14:05:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03038 for ; Mon, 2 Feb 2004 14:05:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjNi-0005lM-Bj for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 14:05:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12J5E5w022146 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 14:05:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjNh-0005kr-W0 for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 14:05:14 -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 OAA02972 for ; Mon, 2 Feb 2004 14:05:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjNf-0005ac-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 14:05:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjMo-0005SG-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 14:04:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnjLw-0005II-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 14:03:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjLb-0005JJ-HY; Mon, 02 Feb 2004 14:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjL4-0005DZ-AI for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 14:02:30 -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 OAA02689 for ; Mon, 2 Feb 2004 14:02:27 -0500 (EST) From: shawn.routhier@windriver.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjL1-00056V-00 for ipv6@ietf.org; Mon, 02 Feb 2004 14:02:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjJi-0004sj-00 for ipv6@ietf.org; Mon, 02 Feb 2004 14:01:08 -0500 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx with esmtp (Exim 4.12) id 1AnjIF-0004O2-00 for ipv6@ietf.org; Mon, 02 Feb 2004 13:59:35 -0500 Received: from ala-mta03.windriver.com (ala-mta03 [147.11.57.132]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA02688; Mon, 2 Feb 2004 10:57:40 -0800 (PST) Received: by ala-mta03.wrs.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Feb 2004 10:57:47 -0800 Message-ID: <47DD7107796EF94CBE7873B8F31DF2C3CB061D@ala-mail01.wrs.com> To: brian@innovationslab.net, heard@pobox.com Cc: ipv6@ietf.org, bwijnen@lucent.com Subject: RE: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt Date: Mon, 2 Feb 2004 10:57:46 -0800 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.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 I'm ambivalent about the addition of a constraint. I agree with Mike that if we keep a constraint switching it to 2040 would fit in better with the rest of the inet address constructs. regards, Shawn >-----Original Message----- >From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On >Behalf Of Brian >Haberman >Sent: Sunday, February 01, 2004 11:03 AM >To: C. M. Heard >Cc: ipv6@ietf.org; Wijnen, Bert (Bert) >Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt > > >Mike, > >C. M. Heard wrote: >> On Fri, 30 Jan 2004 Internet-Drafts@ietf.org wrote: >> >>>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 : IP Forwarding Table MIB >>> Author(s) : M. Wasserman, B. Haberman >>> Filename : draft-ietf-ipv6-rfc2096-update-06.txt >>> Pages : 36 >>> Date : 2004-1-29 >> >> >> Brian, >> >> The following change from the previous version caught my attention: >> >> 28 Jan 2004 Added range of (0..128) to inetCidrRoutePfxLen >> >> The corresponding object definition now reads: >> >> inetCidrRoutePfxLen OBJECT-TYPE >> SYNTAX InetAddressPrefixLength (0..128) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "Indicates the number of leading one bits which form the >> mask to be logical-ANDed with the destination address >> before being compared to the value in the >> inetCidrRouteDest field. >> >> The values for the index objects inetCidrRouteDest and >> inetCidrRoutePfxLen must be consistent. When the value >> of inetCidrRouteDest is x, then the bitwise logical-AND >> of x with the value of the mask formed from the >> corresponding index object inetCidrRoutePfxLen MUST be >> equal to x. If not, then the index pair is not >> consistent and an inconsistentName error must be >> returned on SET or CREATE requests." >> ::= { inetCidrRouteEntry 3 } >> >> There are two things (IMHO) that are wrong with this definition: >> >> 1.) RFC 3291 and its successor draft-ietf-ops-rfc3291bis-03.txt >> both go to great lengths to tell MIB authors not to sub-type >> InetAddressType and InetAddress objects: >> >> The InetAddressType and InetAddress objects SHOULD NOT be >sub-typed >> in object definitions. Sub-typing binds the MIB module to specific >> address formats, which may cause serious problems if new address >> formats need to be introduced. Note that it is possible to write >> compliance statements in order to express that only a >subset of the >> defined address types must be implemented to be compliant. >> >> Since the same kinds of problems can be introduces by sub-typing >> InetAddressPrefixLength, it seems to me that if we are consistent in >> our usage we should not sub-type InetAddressPrefixLength objects, >> either. I've raised this issue on the mreview (Mib Doctors) mailing >> list; archives are at http://ops.ietf.org/lists/mreview/ for those >> who wish to review the discussion. >> >> If the reason why inetCidrRoutePfxLen got a range restriction was to >> silence warning from SNICng or some other MIB compiler then a better >> solution would be to use the range (0..2040), which will accomodate >> an address length up to 255 octets. Since InetAddress objects >> already have a size restriction of 255 octets, this does not impose >> any additional arbitrary limitations other than those already >> imposed by the InetAddress TC itself. Another possibility, of >> course, is to remove the range restriction, since it is not required >> by the SMI (in this case compiler warning != illegal practice). >> > >The range was added based on a comment from Bert. I similar change >was made in the IP MIB update (2011bis). I believe the comment I >saw was that adding a range to the prefix length was not a big deal >since the addition of another address type would require other >changes in the mib. > >My preference is to leave it unrestricted (i.e. no range), but I could >argue it either way. > >I would like to hear others' comments on this issue since both 2011bis >and 2096bis are very close to being done. > >> 2.) The following problem is one that neither I (nor, apparently, >> any other reviewers) noticed up to now: inetCidrRoutePfxLen allows >> the value zero, but the object definition does not specify what the >> value zero means. Note that RFC 3291 requires that if the value >> zero is allowed, then its meaning must be specified in the object >> definition: >> >> The value zero is object-specific and must be defined as >> part of the description of any object which uses this >> syntax. Examples of the usage of zero might include >> situations where the Internet network address prefix >> is unknown or does not apply. >> >> To me, the meaning when inetCidrRoutePfxLen is set to zero >is clear: >> the corresponding row represents a default route. But that might >> not be true for everyone, and it would be good to spell this out in >> the DESCRIPTION clause, as RFC 3291 requires. > >I can add text to the DESCRIPTION that states that the value 0 >indicates >a default route. > >Thanks, >Brian > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 16:10:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10602 for ; Mon, 2 Feb 2004 16: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 1AnlKI-00087y-MW for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 16:09:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12L9o6Q031236 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 16:09:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlKI-00087j-Ik for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 16:09:50 -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 QAA10354 for ; Mon, 2 Feb 2004 16:09:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnlKG-0001RW-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 16:09:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnlJJ-0001JK-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 16:08:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnlIO-0001D6-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 16:07:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlHc-0007Ln-AC; Mon, 02 Feb 2004 16:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlGo-0007Iy-EG for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 16:06:14 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09624; Mon, 2 Feb 2004 16:06:11 -0500 (EST) Message-Id: <200402022106.QAA09624@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2011-update-06.txt Date: Mon, 02 Feb 2004 16:06:11 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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,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-06.txt Pages : 133 Date : 2004-2-2 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-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-06.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-06.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-2-2150942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2011-update-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2011-update-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2150942.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 17:00:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16519 for ; Mon, 2 Feb 2004 17:00:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anm6k-0004EC-2C for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 16:59:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12LxsPR016252 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 16:59:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anm6j-0004E3-RZ for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 16:59:53 -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 QAA16444 for ; Mon, 2 Feb 2004 16:59:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anm6h-0002O6-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 16:59:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anm5k-0002Fl-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 16:58:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Anm4l-00027S-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 16:57:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anm3x-0003zs-1Q; Mon, 02 Feb 2004 16:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anm3n-0003zY-T6 for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 16:56:56 -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 QAA16281 for ; Mon, 2 Feb 2004 16:56:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anm3l-00020P-00 for ipv6@ietf.org; Mon, 02 Feb 2004 16:56:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anm2q-0001su-00 for ipv6@ietf.org; Mon, 02 Feb 2004 16:55:53 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1Anm1w-0001Zi-00 for ipv6@ietf.org; Mon, 02 Feb 2004 16:54:57 -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 i12LsHV32500; Mon, 2 Feb 2004 13:54:17 -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 i12M4FlN010706 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 2 Feb 2004 14:04:22 -0800 Message-ID: <401EC6F1.8060206@innovationslab.net> Date: Mon, 02 Feb 2004 16:53:53 -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: "C. M. Heard" CC: "Wijnen, Bert (Bert)" , "'j.schoenwaelder@iu-bremen.de'" , "David Perkins (E-mail)" , ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.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 C. M. Heard wrote: > On Mon, 2 Feb 2004, Wijnen, Bert (Bert) wrote: > >>>So what do we do? >>> >>>a) Add the range (0..2040) to the InetPrefixLength TC? (Now >>>is the right >>> time to do this.) >>> >>>b) Add the range (0..2040) just to the objects in question >>>that use the >>> InetPrefixLength TC? >>> >>>c) Do both? >>> >>>I think I prefer a) at the moment. >>> >> >>I agree that a) is the best solution. > > > That is my opinion, too. I prefer a) as well. It makes it cleaner for all the docs involved. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 2 21:00:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00500 for ; Mon, 2 Feb 2004 21:00:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anpr5-0008LM-K4 for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 21:00:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i131xxh4032066 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 20:59:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anpr5-0008L7-CL for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 20:59:59 -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 UAA00472 for ; Mon, 2 Feb 2004 20:59:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anpr3-0007MU-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 20:59:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anpq7-0007Hc-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 20:59:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Anppe-0007DF-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 20:58:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnppB-0007ya-T7; Mon, 02 Feb 2004 20:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnpoD-0007x1-Fr for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 20:57: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 UAA00399 for ; Mon, 2 Feb 2004 20:56:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnpoB-00077z-00 for ipv6@ietf.org; Mon, 02 Feb 2004 20:56:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnpnK-00073f-00 for ipv6@ietf.org; Mon, 02 Feb 2004 20:56:07 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Anpmj-0006yC-00 for ipv6@ietf.org; Mon, 02 Feb 2004 20:55:29 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 900891525D; Tue, 3 Feb 2004 10:55:27 +0900 (JST) Date: Tue, 03 Feb 2004 10:55:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela Cc: ipv6@ietf.org Subject: Re: a new revision of ipv6-scoping-arch-00 In-Reply-To: <200402021512.i12FCFVw022551@burp.tkv.asdf.org> References: <200402021512.i12FCFVw022551@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=AWL autolearn=no version=2.60 >>>>> On Mon, 2 Feb 2004 17:12:15 +0200, >>>>> Markku Savela said: > Wait a minute... >> Moreover, if the packets destination address is a unicast address, >> an ICMP Destination Unreachable message [4] with Code 2 ("beyond >> scope of source address") is sent to the source of the original >> packet. Note: Code 2, as defined in [4], had a different >> semantics, but the semantics has already been obsolete and the >> IANA is going to re-assign the value for the new purpose. > .. isn't this code still needed/useful if one has dst=global>, and packet falls into forwarding to another link? Yes, of course. Perhaps the revised wording above was confusing, but we are NOT going to deprecate the new "beyond scope of source address" ICMPv6 error. We'll need this one, and this draft specifies to use the new semantics of the code. The reason for referring to the old RFC (2463) is simply because we'd have to stop the publication of this document until ICMPv6-v3 is published. I'll try to make this point clearer below. Does this make sense to you? Moreover, if the packets destination address is a unicast address, an ICMP Destination Unreachable message [4] with Code 2 ("beyond scope of source address") is sent to the source of the original packet. Note: Code 2 is currently left as unassigned in [4]. But the IANA is going to re-assign the value for the new purpose, and [4] will be revised with this change. 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 Feb 2 22:19:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03077 for ; Mon, 2 Feb 2004 22:19:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anr5d-0008T7-T0 for ipv6-archive@odin.ietf.org; Mon, 02 Feb 2004 22:19:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i133J5u3032546 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 22:19:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anr5d-0008Sr-NU for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 22:19:05 -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 WAA03048 for ; Mon, 2 Feb 2004 22:19:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anr5a-0007ar-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 22:19:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anr4j-0007VL-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 22:18:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Anr3u-0007Pk-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 22:17:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anr3e-00087S-Cs; Mon, 02 Feb 2004 22:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anr2n-00085G-Sv for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 22:16:09 -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 WAA02968 for ; Mon, 2 Feb 2004 22:16:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anr2k-0007K2-00 for ipv6@ietf.org; Mon, 02 Feb 2004 22:16:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anr1y-0007Em-00 for ipv6@ietf.org; Mon, 02 Feb 2004 22:15:19 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Anr1C-00077q-00 for ipv6@ietf.org; Mon, 02 Feb 2004 22:14:30 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9DD4615263; Tue, 3 Feb 2004 12:14:30 +0900 (JST) Date: Tue, 03 Feb 2004 12:14:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: ipv6@ietf.org Subject: Re: a new revision of ipv6-scoping-arch-00 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, 2 Feb 2004 19:30:02 +0200 (EET), >>>>> Pekka Savola said: >> Proposed resolution: change the reference to the old RFC (2463), and >> describe this part as a new feature. More concretely, I'll revise >> this part as follows: >> >> ... >> Moreover, if the packets destination address is a unicast address, >> an ICMP Destination Unreachable message [4] with Code 2 ("beyond >> scope of source address") is sent to the source of the original >> packet. Note: Code 2, as defined in [4], had a different >> semantics, but the semantics has already been obsolete and the >> IANA is going to re-assign the value for the new purpose. >> (where [4] now refers to RFC2463.) > Fine with me. > A few grammar checks; I'm assuming 'semantics' is not a special word > (plural but acting as a singular form): > s/packets/packet's/ ? Yes, this was a typo. Thanks for the correction. > s/a different/different/ ? > s/semantics has already been obsolete/semantics are already obsolete/ > (or "have already been obsoleted"? Hmm, my Cobuild dictionary says "semantics" is an uncountable noun, so the original wording should be okay according to the dictionary. BTW, this part may be rewritten based on a different branch of this thread, and "semantics" may disappear there. If the final text still uses the word, I'll use it as an uncountable noun. (But I don't have a particular opinion on this. If others stronglly encourage to use it as a plural, I'll follow it.) 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 Feb 3 11:10: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 LAA15911 for ; Tue, 3 Feb 2004 11:10:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao37N-0003IJ-Ds for ipv6-archive@odin.ietf.org; Tue, 03 Feb 2004 11:09:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13G9fsL012659 for ipv6-archive@odin.ietf.org; Tue, 3 Feb 2004 11:09:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao37M-0003I5-Kn for ipv6-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 11:09:40 -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 LAA15897 for ; Tue, 3 Feb 2004 11:09:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao37K-0002df-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 11:09:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao36L-0002YB-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 11:08:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao363-0002S7-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 11:08:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao35n-0002za-0d; Tue, 03 Feb 2004 11:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao35P-0002sm-56 for ipv6@optimus.ietf.org; Tue, 03 Feb 2004 11:07: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 LAA15785 for ; Tue, 3 Feb 2004 11:07:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao35M-0002RX-00 for ipv6@ietf.org; Tue, 03 Feb 2004 11:07:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao34V-0002Lt-00 for ipv6@ietf.org; Tue, 03 Feb 2004 11:06:43 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao344-0002FF-00 for ipv6@ietf.org; Tue, 03 Feb 2004 11:06:16 -0500 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i13G6DF09952; Tue, 3 Feb 2004 08:06:13 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 3 Feb 2004 08:06:12 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Brian Haberman cc: ipv6@ietf.org, "Wijnen, Bert (Bert)" Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.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=none autolearn=no version=2.60 Brian, Here is another small thing I just noticed: inetCidrRouteIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The ifIndex value which identifies the local interface through which the next hop of this route should be reached. A value of 0 is valid and represents the scenario where no interface is specified." ::= { inetCidrRouteEntry 7 } The SYNTAX value above should be InterfaceIndexOrZero, since InterfaceIndex does not allow values of zero. Sorry for not catching this earlier. The fix is easy, though: just make a global substitution s/InterfaceIndex/InterfaceIndexOrZero/ Mike -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 3 14:37: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 OAA26316 for ; Tue, 3 Feb 2004 14:37: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 1Ao6La-0006eL-Qn for ipv6-archive@odin.ietf.org; Tue, 03 Feb 2004 14:36:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13JaYjZ025561 for ipv6-archive@odin.ietf.org; Tue, 3 Feb 2004 14:36:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6La-0006eC-Jv for ipv6-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 14:36:34 -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 OAA26264 for ; Tue, 3 Feb 2004 14:36:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6LX-0002eg-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 14:36:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6Ka-0002XW-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 14:35:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6Jf-0002S2-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 14:34:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6J7-0006O8-Gj; Tue, 03 Feb 2004 14:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6Il-0006Nf-IW for ipv6@optimus.ietf.org; Tue, 03 Feb 2004 14:33: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 OAA26130 for ; Tue, 3 Feb 2004 14:33:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6Ii-0002MN-00 for ipv6@ietf.org; Tue, 03 Feb 2004 14:33:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6Hi-0002H7-00 for ipv6@ietf.org; Tue, 03 Feb 2004 14:32:36 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6H3-00026X-00 for ipv6@ietf.org; Tue, 03 Feb 2004 14:31:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i13JV5531325; Tue, 3 Feb 2004 11:31:05 -0800 X-mProtect: <200402031931> Nokia Silicon Valley Messaging Protection Received: from h164.hinden.meer.net (209.157.142.164, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdMfsNgl; Tue, 03 Feb 2004 11:31:03 PST Message-Id: <4.3.2.7.2.20040203111552.02f16710@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Feb 2004 11:27:54 -0800 To: Pekka Savola From: Bob Hinden Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Cc: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Pekka, Thanks for the comments. I will respond to the substantial issues and semi-editorial in your email. The editorial ones look fine and should be to include them in the next version of the draft. >substantial >----------- > >1) specifying just one allocator to the end-sites; this is always bad >and prone to create monsters such as ICANN. I don't see how the current text would "create monsters such as ICANN". All we are talking about is assignment of local prefixes. Somewhat more limited scope than what ICANN has. >It seems like that the model should be provided to support >enough registries (e.g. 2 bit = 4 or 3 bits = 8). Just to make sure that >the customers can pick someone else's service unless they aren't satisfied >with an organization, so that there is some incentive not to have too high >charges, to avoid the claims of building monopolies who get free money for >numbers, etc.etc. >Unless you have instructions in mind for IANA who should have this registry >monopoly, there should probably be multiple registries in the only one of >them screws up in a major way (e.g., compare to the mess with .com zone by >verisign). The text in the IANA considerations section calls for the IANA to set up a "allocation authority" for the centrally assigned ULA prefixes. The exact details of how to do this (i.e., one or many organizations doing the assignments, who it is, etc., etc.) are left to the IANA as long as they meet the requirements stated in the document. I am comfortable with the IANA doing this in a manner that will be beneficial from the community. It is also, of course, out of scope for the IETF to specify more than the allocation requirements, which this document does do. We have learned from past experience it's not wise to over specify when asking the IANA to do address allocation. I think the current text is about right in this regard. Also, if the resulting allocation authority becomes too onerous for some people, they can use the locally assigned prefixes. No one is forced to use the central allocations. >2) The specification requires that routing protocols special-case these >prefixes by MUST filtering them. This is unacceptable, and should be >removed. Any filtering should be done by the sites themselves. Note that >running any other protocol than BGP is not feasible anyway to be run over >administrative domains (exclusing provider-provisioned VPNs, maybe, but >those are special case anyway), so we can pretty much limit the discussion >to BGP. Which is pretty trivial, because 1) why would the ISP advertise >such prefixes, and 2) why would the site not filter out stuff it doesn't >want. > > Any routing protocol that is used between sites MUST filter out any > incoming or outgoing Local IPv6 unicast routes. The exception to > this is if specific /48 IPv6 local unicast routes have been > configured to allow for inter-site communication. I agree this could be stated better. I think it would be good to change it to "Any router that is used between sites....", as it is not the routing protocols doing the filtering, but the router based on it's configuration. The requirement is that the FC00::/7 is filtered by default by routers at the site boundary. As Brian Carpenter pointed out if there is a filter for this prefix configured by default in all routers, it does no harm as sites that wish to use these addresses would add more specific routes that would override the default filters for these more specific prefixes. > If BGP is being used at the site border with an ISP, filters MUST be > installed by default in the BGP configuration to keep any Local IPv6 > address prefixes from being advertised outside of the site or for > these prefixes to be learned from another site. The exception to > this is if there are specific /48 routes created for one or more > Local IPv6 prefixes. > >3) Similar to the above, there are some particularly inpractical issues with >site-border security: > > Site border routers SHOULD install a black hole route for the Local > IPv6 prefix FC00::/7. This will insure that packets with Local IPv6 > destination addresses will not be forwarded outside of the site via a > default route. Site border routers SHOULD respond with the > appropriate ICMPv6 Destination Unreachable message to inform the > source that the packet was not forwarded [ICMPV6]. This feedback is > important to avoid transport protocol timeouts. > > 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. The default behavior of these devices > SHOULD be to filter them. Site border routers SHOULD respond with > the appropriate ICMPv6 Destination Unreachable message to inform the > source that the packet was not forwarded. > >.. this is inpractical, and should be reworded. The site border routers >cannot know that they are site-border routers, so these checks cannot be >implemented. What you can do is state that a toggle SHOULD be implemented >and when enabled on an interface, it would apply these kind of restrictions >to it. But the point is that you WILL need administrator action. "Deny by >default" just is not practical approach here, because you don't know that >you should be denying these by default. I don't agree. As stated above if the /7 prefix is filtered by default, it does no harm. But I think changing the text to make it clearer that these routers should be configured to do this filtering would make the text clearer. > Additionally, domain border routers connecting autonomous systems > throughout the Internet SHOULD obey these recommendations for site > border routers. > >==> as for this, I have no idea what this even tries to say, so it requires >rewording. It is trying to say that routers that connect autonomous systems also be configured to do this filtering. Even if they are not at site boundaries. How about: Routers that maintain peering arrangements between Autonomous Systems throughout the Internet SHOULD obey the recommendations for site border routers unless configured otherwise. >semi-editorial >-------------- > > 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). > >==> hopefully the centrally assigned global IDs don't use their >(single) computer's EUI-64 in the generation :-) I don't think this is a problem. Every time the algorithm is run the time would change resulting in a new distinct allocation. The MD5 hash guarantees it. > 4) Compute an MD5 digest on the key as specified in [MD5DIG]. >==> security folks have been pushed for the use of SHA-1 because it's more >collision-proof. It doesn't matter much in this specific context, but at >least nobody would object if you changed this to using an SHA-1 digest. As you said, "it doesn't matter...". > Site border routers SHOULD install a black hole route for the Local > IPv6 prefix FC00::/7. > >==> I think you mean "a reject route" ? (or a "discard" route might >also work OK) I agree this should be changed to a "reject route". Mukesh Gupta also pointed this out during the discussion of the new ICMPv6 destination unreachable codes. > For future study names with Local IPv6 addresses may be resolved > inside of the site using dynamic naming systems such as Multicast > DNS. > >==> this seems irrelevant and should be removed; above, it already >states someting general about local naming systems. I don't see it doing any harm either. > Local IPv6 addresses, like global scope unicast addresses, are only > assigned to nodes if their use has been enabled (via IPv6 address > autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually) and > configured in the DNS. > >==> "and configured in the DNS" is not requirement and is irrelevant; should >be removed? > > assign them. In order for a node to learn the Local IPv6 address of > another node, the Local IPv6 address must have been installed in the > DNS. > >==> s/DNS/DNS or another naming system/ ? Thanks. Both changes are fine. >11.2 Disadvantages > >==> Add to disadvantages: > > - Instead of using global unicast addresses inside the sites, the > sites may be tempted to start using Local IPv6 addresses excessively, > instead of using global unicast addresses and reachability restrictions > such as firewalls or access control lists I think this is out of scope for this document. Thanks again for your comments. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 3 15:18: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 PAA28836 for ; Tue, 3 Feb 2004 15:18:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6zO-00059A-6O for ipv6-archive@odin.ietf.org; Tue, 03 Feb 2004 15:17:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13KHgYI019778 for ipv6-archive@odin.ietf.org; Tue, 3 Feb 2004 15:17:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6zN-00058v-Vg for ipv6-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:17:42 -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 PAA28798 for ; Tue, 3 Feb 2004 15:17:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6zM-0006fT-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 15:17:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6yN-0006aR-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 15:16:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6y3-0006VQ-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 15:16:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6xm-0004ON-HL; Tue, 03 Feb 2004 15:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6xN-0004Hf-5B for ipv6@optimus.ietf.org; Tue, 03 Feb 2004 15:15:37 -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 PAA28583 for ; Tue, 3 Feb 2004 15:15:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6xL-0006UI-00 for ipv6@ietf.org; Tue, 03 Feb 2004 15:15:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6wP-0006PR-00 for ipv6@ietf.org; Tue, 03 Feb 2004 15:14:38 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6w8-0006Kc-00 for ipv6@ietf.org; Tue, 03 Feb 2004 15:14:20 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i13KDmS07295; Tue, 3 Feb 2004 22:13:48 +0200 Date: Tue, 3 Feb 2004 22:13:48 +0200 (EET) From: Pekka Savola To: Bob Hinden cc: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt In-Reply-To: <4.3.2.7.2.20040203111552.02f16710@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Inline.. On Tue, 3 Feb 2004, Bob Hinden wrote: > The text in the IANA considerations section calls for the IANA to set up a > "allocation authority" for the centrally assigned ULA prefixes. The exact > details of how to do this (i.e., one or many organizations doing the > assignments, who it is, etc., etc.) are left to the IANA as long as they > meet the requirements stated in the document. I read "an allocation authority" as singular, just one organization. As the space is specified to be non-hierarchical and the randomizer algorithm is specified to use LSB 40 bits for centrally allocated prefixes, this does strongly imply a single organization (or organizations with a pretty well-synched up database :). > I am comfortable with the IANA doing this in a manner that will be > beneficial from the community. It is also, of course, out of scope > for the IETF to specify more than the allocation requirements, which > this document does do. We have learned from past experience it's not > wise to over specify when asking the IANA to do address allocation. > I think the current text is about right in this regard. If folks think this is OK, it's fine by me. Clarification in IANA considerations like "If deemed appropriate, the authority may also consist of multiple organizations performing the authority duties" might be in order though. > >2) The specification requires that routing protocols special-case these > >prefixes by MUST filtering them. This is unacceptable, and should be > >removed. Any filtering should be done by the sites themselves. Note that > >running any other protocol than BGP is not feasible anyway to be run over > >administrative domains (exclusing provider-provisioned VPNs, maybe, but > >those are special case anyway), so we can pretty much limit the discussion > >to BGP. Which is pretty trivial, because 1) why would the ISP advertise > >such prefixes, and 2) why would the site not filter out stuff it doesn't > >want. > > > > Any routing protocol that is used between sites MUST filter out any > > incoming or outgoing Local IPv6 unicast routes. The exception to > > this is if specific /48 IPv6 local unicast routes have been > > configured to allow for inter-site communication. > > I agree this could be stated better. I think it would be good to > change it to "Any router that is used between sites....", as it is > not the routing protocols doing the filtering, but the router based > on it's configuration. But then it's an operational guidance, right? Maybe not uppercase material? > The requirement is that the FC00::/7 is > filtered by default by routers at the site boundary. As Brian > Carpenter pointed out if there is a filter for this prefix > configured by default in all routers, it does no harm as sites that > wish to use these addresses would add more specific routes that > would override the default filters for these more specific prefixes. Please check my response to Brian. There is a very specific difference of "FC00::/7 reject route" and "FC00::/7" filter. If you mean the former -- fine, it works in most cases (except the stub router and no IGP case I mentioned) -- if the latter, you're in for a lot of trouble. Something like this would be very difficult to implement properly. > >3) Similar to the above, there are some particularly inpractical issues with > >site-border security: > > > > Site border routers SHOULD install a black hole route for the Local > > IPv6 prefix FC00::/7. This will insure that packets with Local IPv6 > > destination addresses will not be forwarded outside of the site via a > > default route. Site border routers SHOULD respond with the > > appropriate ICMPv6 Destination Unreachable message to inform the > > source that the packet was not forwarded [ICMPV6]. This feedback is > > important to avoid transport protocol timeouts. > > > > 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. The default behavior of these devices > > SHOULD be to filter them. Site border routers SHOULD respond with > > the appropriate ICMPv6 Destination Unreachable message to inform the > > source that the packet was not forwarded. > > > >.. this is inpractical, and should be reworded. The site border routers > >cannot know that they are site-border routers, so these checks cannot be > >implemented. What you can do is state that a toggle SHOULD be implemented > >and when enabled on an interface, it would apply these kind of restrictions > >to it. But the point is that you WILL need administrator action. "Deny by > >default" just is not practical approach here, because you don't know that > >you should be denying these by default. > > I don't agree. As stated above if the /7 prefix is filtered by default, it > does no harm. But I think changing the text to make it clearer that these > routers should be configured to do this filtering would make the text clearer. "Filtered" has entirely different implications whether it's "done" (inpartially) with a reject route, or done with access lists. See my note to Brian. "access-lists by default" pretty much by definition WILL block the more specifics, and are difficult to deploy or specify here. > > Additionally, domain border routers connecting autonomous systems > > throughout the Internet SHOULD obey these recommendations for site > > border routers. > > > >==> as for this, I have no idea what this even tries to say, so it requires > >rewording. > > It is trying to say that routers that connect autonomous systems also be > configured to do this filtering. Even if they are not at site > boundaries. How about: > > Routers that maintain peering arrangements between Autonomous > Systems throughout the Internet SHOULD obey the recommendations for > site border routers unless configured otherwise. Ok, that's understandable. But again, why use an uppercase SHOULD keyword? This is a requirement for operators, not a protocol interoperability issue? > >semi-editorial > >-------------- > > > > 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). > > > >==> hopefully the centrally assigned global IDs don't use their > >(single) computer's EUI-64 in the generation :-) > > I don't think this is a problem. Every time the algorithm is run the time > would change resulting in a new distinct allocation. The MD5 hash > guarantees it. Sure, but the amount of entropy given as input to the has function is significantly lower. For central allocations this is probably not a problem. > > 4) Compute an MD5 digest on the key as specified in [MD5DIG]. > > >==> security folks have been pushed for the use of SHA-1 because it's more > >collision-proof. It doesn't matter much in this specific context, but at > >least nobody would object if you changed this to using an SHA-1 digest. > > As you said, "it doesn't matter...". If you feel so. This might come up at IESG review from security ADs though :). > > For future study names with Local IPv6 addresses may be resolved > > inside of the site using dynamic naming systems such as Multicast > > DNS. > > > >==> this seems irrelevant and should be removed; above, it already > >states someting general about local naming systems. > > I don't see it doing any harm either. This is an unnecessary plug for Multicast DNS. (btw, if it stays, it should be reworded for better english..) > >11.2 Disadvantages > > > >==> Add to disadvantages: > > > > - Instead of using global unicast addresses inside the sites, the > > sites may be tempted to start using Local IPv6 addresses excessively, > > instead of using global unicast addresses and reachability restrictions > > such as firewalls or access control lists > > I think this is out of scope for this document. Applicability statements or reality checks are in scope for all kinds of documents. :) I don't think this document has any chance of passing through the other reviews unless it spells out its usability (and especially nonusability!) better. I'm not sure that adding a rather architectural disadvantage is enough but it could be a start. -- 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 Feb 3 15:52: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 PAA00668 for ; Tue, 3 Feb 2004 15:52:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7WF-0000ef-Uq for ipv6-archive@odin.ietf.org; Tue, 03 Feb 2004 15:51:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13KpdtZ002511 for ipv6-archive@odin.ietf.org; Tue, 3 Feb 2004 15:51:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7WF-0000eQ-QL for ipv6-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:51: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 PAA00632 for ; Tue, 3 Feb 2004 15:51:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7WE-0001zD-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 15:51:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7VJ-0001tx-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 15:50:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7V3-0001oq-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 15:50:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Ui-00008C-Sz; Tue, 03 Feb 2004 15:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7UN-000062-OX for ipv6@optimus.ietf.org; Tue, 03 Feb 2004 15:49:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00405; Tue, 3 Feb 2004 15:49:41 -0500 (EST) Message-Id: <200402032049.PAA00405@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-host-load-sharing-01.txt Date: Tue, 03 Feb 2004 15:49:41 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Host to Router Load Sharing Author(s) : R. Hinden Filename : draft-ietf-ipv6-host-load-sharing-01.txt Pages : 5 Date : 2004-2-3 The original IPv6 conceptual sending algorithm does not require load-sharing among equivalent IPv6 routers, and suggests schemes which can be problematic in practice. This document updates the conceptual sending algorithm so that traffic to different destinations is distributed among routers in an efficient fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-host-load-sharing-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-host-load-sharing-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-host-load-sharing-01.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-2-3150116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-host-load-sharing-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-host-load-sharing-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-3150116.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 Feb 4 03: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 DAA25055 for ; Wed, 4 Feb 2004 03:16:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoICe-0000cN-N9 for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 03:16:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i148G8W6002374 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 03:16:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoICe-0000cC-79 for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 03:16:08 -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 DAA25045 for ; Wed, 4 Feb 2004 03:16:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoICc-0003uT-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 03:16:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoIBh-0003mo-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 03:15:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoIAn-0003fQ-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 03:14:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIAc-0000Cj-OQ; Wed, 04 Feb 2004 03:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIAa-0000Bu-8l for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 03:14:00 -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 DAA24981 for ; Wed, 4 Feb 2004 03:13:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoIAY-0003cK-00 for ipv6@ietf.org; Wed, 04 Feb 2004 03:13:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoI9b-0003Wh-00 for ipv6@ietf.org; Wed, 04 Feb 2004 03:13:00 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AoI8v-0003Rt-00 for ipv6@ietf.org; Wed, 04 Feb 2004 03:12:17 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id A62946A902; Wed, 4 Feb 2004 10:12:12 +0200 (EET) Message-ID: <4020A8FD.5070200@kolumbus.fi> Date: Wed, 04 Feb 2004 10:10:37 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JINMEI Tatuya Cc: ipv6@ietf.org Subject: Re: [2462bis] preferred lifetime and the 'two-hour' rule References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit JINMEI Tatuya wrote: > While working on the rfc2462bis (stateless address autoconf) work, > I've found a new issue, and would like to hear opinions. > > The current RFC2462 describes in Section 5.5.3 e) how the valid > lifetime of an autoconfigured address is updated, considering the > avoidance of DoS attack with too short lifetimes. However, it doesn't > mention preferred lifetimes. 5.5.3 e) says: > > e) If the advertised prefix matches the prefix of an autoconfigured > address (i.e., one obtained via stateless or stateful address > autoconfiguration) in the list of addresses associated with the > interface, the specific action to perform depends on the Valid > Lifetime in the received advertisement and the Lifetime > associated with the previously autoconfigured address (which we > call StoredLifetime in the discussion that follows): > ... > > This document doesn't say anything about preferred lifetimes from this > part to the end of this section. Oops. This could cause all addresses to go deprecated. That in itself may not be too dangerous, however, since according to 5.5.4 you must be able to still use deprecated addresses even on new connections if there are no other available addresses. But I agree that it would be good to avoid this. > On the other hand, RFC1971, which was obsoleted by RFC2462, clearly > said in Section 5.5.3 how the preferred lifetime should be updated: > > d) If the advertised prefix matches the prefix of an autoconfigured > address (i.e., obtained via stateless or stateful address > autoconfiguration) in the list of addresses associated with the > interface, set the preferred timer to that of the option's preferred <--- > lifetime, and set the valid lifetime to that of the option's valid > lifetime. > > I guess this part was unintentionally dropped in RFC2462 while we > concentrated on the DoS avoidance. > > If so, it should make sense to recover this part in rfc2462bis. > Possible options include: > > 1) update the preferred lifetime regardless of whether the valid > lifetime is accepted or not wrt the "two-hour" rule > 2) update the preferred lifetime only when the valid lifetime is > accepted > 3) leave this as implementation dependent > > I don't think option 3 is the way to go, since RFC1971 clearly > mentioned the preferred lifetime. > > The KAME/BSD implementation behaves as option 1. However, it seems to > me that option 2 makes much more sense because a rejected valid > lifetime indicates a possibility of attack and the other parts of > the information may then be bogus as well. I agree. Option 2 sounds right. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 4 04:23: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 EAA27356 for ; Wed, 4 Feb 2004 04:23:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJFR-00060G-Iy for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 04:23:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i149N51Q023075 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 04:23:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJFR-000606-4n for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 04:23:05 -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 EAA27331 for ; Wed, 4 Feb 2004 04:23:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJFO-0002f2-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 04:23:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJEU-0002Zf-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 04:22:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoJDy-0002UF-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 04:21:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJDT-0005cZ-MY; Wed, 04 Feb 2004 04:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJCU-0005Ve-Us for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 04:20: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 EAA27171 for ; Wed, 4 Feb 2004 04:20:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJCS-0002Mn-00 for ipv6@ietf.org; Wed, 04 Feb 2004 04:20:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJBX-0002Hq-00 for ipv6@ietf.org; Wed, 04 Feb 2004 04:19:04 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AoJAn-000275-00 for ipv6@ietf.org; Wed, 04 Feb 2004 04:18:18 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i149Hi123457; Wed, 4 Feb 2004 10:17:45 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i149HiSj043851; Wed, 4 Feb 2004 10:17:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402040917.i149HiSj043851@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipv6@ietf.org Subject: Re: [2462bis] preferred lifetime and the 'two-hour' rule In-reply-to: Your message of Wed, 04 Feb 2004 16:38:20 +0900. Date: Wed, 04 Feb 2004 10:17:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 In your previous mail you wrote: The current RFC2462 describes in Section 5.5.3 e) how the valid lifetime of an autoconfigured address is updated, considering the avoidance of DoS attack with too short lifetimes. => the DoS attack is about valid lifetime only because when a valid lifetime is dropped to zero an implementation can (IMHO it is in fact a SHOULD) kill all connections using a now unvalid address. The behavior for zero preferred lifetime is far less drastic ("deprecated" addresses are not used for new "connections" when there are other available addresses) and (IMPORTANT) we need for multi-homing to be able to play with preferred lifetimes. However, it doesn't mention preferred lifetimes. 5.5.3 e) says: ... This document doesn't say anything about preferred lifetimes from this part to the end of this section. => this is on purpose. If so, it should make sense to recover this part in rfc2462bis. Possible options include: 1) update the preferred lifetime regardless of whether the valid lifetime is accepted or not wrt the "two-hour" rule 2) update the preferred lifetime only when the valid lifetime is accepted 3) leave this as implementation dependent I don't think option 3 is the way to go, since RFC1971 clearly mentioned the preferred lifetime. => I agree. I am in favor of 1 or 2 with a little preference for 1 which seems more logical (I suggest to introduce a notion of valid prefix information and to make prefix informations which don't follow the two hour rule invalid). The KAME/BSD implementation behaves as option 1. However, it seems to me that option 2 makes much more sense because a rejected valid lifetime indicates a possibility of attack and the other parts of the information may then be bogus as well. => we agree. And, in fact, item 2 of 5.5.3 e) says: 2) If the StoredLifetime is less than or equal to 2 hours and the received Lifetime is less than or equal to StoredLifetime, ignore the prefix,... => s/prefix/prefix information/ ? that is, it specifies ignoring "the prefix", not just "the valid lifetime". => same comment. What do others think? As I already indicated, I'd propose to revise the text clearly with option 2 above. => please proceed. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 4 07:33: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 HAA03467 for ; Wed, 4 Feb 2004 07:33:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMDQ-0000JY-Ph for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 07:33:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14CXCc7001208 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 07:33:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMDQ-0000JP-KQ for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 07:33:12 -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 HAA03452 for ; Wed, 4 Feb 2004 07:33:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMDQ-00066P-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 07:33:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMCT-00060b-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 07:32:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoMBp-0005vK-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 07:31:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMBK-0008OA-LK; Wed, 04 Feb 2004 07:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMAS-0008NO-DS for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 07:30:08 -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 HAA03401 for ; Wed, 4 Feb 2004 07:30:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMAR-0005pw-00 for ipv6@ietf.org; Wed, 04 Feb 2004 07:30:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoM9U-0005lc-00 for ipv6@ietf.org; Wed, 04 Feb 2004 07:29:09 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1AoM97-0005gq-00 for ipv6@ietf.org; Wed, 04 Feb 2004 07:28:45 -0500 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 i14CSE5B494226 for ; Wed, 4 Feb 2004 07:28:14 -0500 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 i14CSEGd125596 for ; Wed, 4 Feb 2004 05:28:14 -0700 To: ipv6@ietf.org MIME-Version: 1.0 Subject: SIOCGIFaaa ioctls and IPv6 interfaces X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 Message-ID: From: Kristine Adamson Date: Wed, 4 Feb 2004 07:28:13 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 02/04/2004 05:28:14, Serialize complete at 02/04/2004 05:28:14 Content-Type: multipart/alternative; boundary="=_alternative 00448D2D85256E30_=" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 00448D2D85256E30_= Content-Type: text/plain; charset="US-ASCII" Hello, Are there any interface ioctl() function calls, similar to the SIOCGIFaaa calls, that we could use to retrieve data about IPv6 interfaces? Thanks! Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.com --=_alternative 00448D2D85256E30_= Content-Type: text/html; charset="US-ASCII"
Hello,
   Are there any interface ioctl() function calls, similar to the SIOCGIFaaa calls, that we could use to retrieve data about IPv6 interfaces?  Thanks!

Kristine Adamson
IBM Communications Server for MVS: TCP/IP Development
Internet e-mail:adamson@us.ibm.com
 --=_alternative 00448D2D85256E30_=-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 4 08:06: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 IAA04505 for ; Wed, 4 Feb 2004 08:06:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMjJ-00030L-KF for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 08:06:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14D69QB011548 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 08:06:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMjJ-00030B-Dn for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 08:06:09 -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 IAA04467 for ; Wed, 4 Feb 2004 08:06:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMjI-0001Kg-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 08:06:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMiJ-0001EP-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 08:05:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoMhP-00018m-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 08:04:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMhF-0002eZ-Gu; Wed, 04 Feb 2004 08:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMgQ-0002Yw-BN for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 08:03:10 -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 IAA04358 for ; Wed, 4 Feb 2004 08:03:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMgP-00012P-00 for ipv6@ietf.org; Wed, 04 Feb 2004 08:03:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMfT-0000xN-00 for ipv6@ietf.org; Wed, 04 Feb 2004 08:02:11 -0500 Received: from c211-30-120-24.carlnfd2.nsw.optusnet.com.au ([211.30.120.24] helo=drugs.dv.isc.org) by ietf-mx with esmtp (Exim 4.12) id 1AoMez-0000sf-00 for ipv6@ietf.org; Wed, 04 Feb 2004 08:01:42 -0500 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i14D1acc042157; Thu, 5 Feb 2004 00:01:39 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200402041301.i14D1acc042157@drugs.dv.isc.org> To: Kristine Adamson Cc: ipv6@ietf.org From: Mark.Andrews@isc.org Subject: Re: SIOCGIFaaa ioctls and IPv6 interfaces In-reply-to: Your message of "Wed, 04 Feb 2004 07:28:13 CDT." Date: Thu, 05 Feb 2004 00:01:36 +1100 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 > Hello, > Are there any interface ioctl() function calls, similar to the > SIOCGIFaaa calls, that we could use to retrieve data about IPv6 > interfaces? Thanks! > > Kristine Adamson > IBM Communications Server for MVS: TCP/IP Development > Internet e-mail:adamson@us.ibm.com There are heaps. Every vendor has their own set which make life fun for anyone that need to actually do it. Note there are duplicate MACRO names that take different arguements. There are duplicate structure names with different contents. None of it is well documented. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 4 10:06: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 KAA08916 for ; Wed, 4 Feb 2004 10:06:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoObY-0005Kb-GN for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 10:06:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14F6GIs020462 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 10:06:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoObX-0005JQ-PN for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 10:06:15 -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 KAA08836 for ; Wed, 4 Feb 2004 10:06:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoObV-0005qb-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 10:06:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoOac-0005kP-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 10:05:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoOZi-0005fL-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 10:04:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoOYQ-0003tb-39; Wed, 04 Feb 2004 10: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 1AoOXd-0003C6-UR for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 10:02:13 -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 KAA08451 for ; Wed, 4 Feb 2004 10:02:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoOXb-0005Qn-00 for ipv6@ietf.org; Wed, 04 Feb 2004 10:02:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoOWe-0005Kd-00 for ipv6@ietf.org; Wed, 04 Feb 2004 10:01:13 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1AoOVi-00059k-00 for ipv6@ietf.org; Wed, 04 Feb 2004 10:00:14 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i14Exelv609912 for ; Wed, 4 Feb 2004 09:59:40 -0500 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 i14Exdcj128962 for ; Wed, 4 Feb 2004 07:59:39 -0700 In-Reply-To: <200402041301.i14D1acc042157@drugs.dv.isc.org> To: ipv6@ietf.org MIME-Version: 1.0 Subject: Re: SIOCGIFaaa ioctls and IPv6 interfaces X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 Message-ID: From: Kristine Adamson Date: Wed, 4 Feb 2004 09:59:37 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 02/04/2004 07:59:39, Serialize complete at 02/04/2004 07:59:39 Content-Type: multipart/alternative; boundary="=_alternative 005269DC85256E30_=" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 005269DC85256E30_= Content-Type: text/plain; charset="US-ASCII" Thanks for the feedback. Was there ever any discussion in the IPv6 working group in regards to creating a standard set of ioctl() function calls, similar to the SIOCGIFaaa ioctls, the could either be used wit IPv6 interfaces, or which could be used with both IPv4 and IPv6 interfaces (i.e., version-neutral)? Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.com marka@isc.org wrote on 02/04/2004 08:01:36 AM: > > Hello, > > Are there any interface ioctl() function calls, similar to the > > SIOCGIFaaa calls, that we could use to retrieve data about IPv6 > > interfaces? Thanks! > > > > Kristine Adamson > > IBM Communications Server for MVS: TCP/IP Development > > Internet e-mail:adamson@us.ibm.com > There are heaps. Every vendor has their own set which > make life fun for anyone that need to actually do it. > > Note there are duplicate MACRO names that take different > arguements. There are duplicate structure names with > different contents. > > None of it is well documented. > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org --=_alternative 005269DC85256E30_= Content-Type: text/html; charset="US-ASCII"
Thanks for the feedback.  Was there ever any discussion in the IPv6 working group in regards to creating a standard set of ioctl() function calls, similar to the SIOCGIFaaa ioctls, the could either be used wit IPv6 interfaces, or which could be used with both IPv4 and IPv6 interfaces (i.e., version-neutral)?

Kristine Adamson
IBM Communications Server for MVS: TCP/IP Development
Internet e-mail:adamson@us.ibm.com

marka@isc.org wrote on 02/04/2004 08:01:36 AM:

> > Hello,
> >    Are there any interface ioctl() function calls, similar to the
> > SIOCGIFaaa calls, that we could use to retrieve data about IPv6
> > interfaces?  Thanks!
> >
> > Kristine Adamson
> > IBM Communications Server for MVS: TCP/IP Development
> > Internet e-mail:adamson@us.ibm.com
> There are heaps.  Every vendor has their own set which
> make life fun for anyone that need to actually do it.
>
> Note there are duplicate MACRO names that take different
> arguements.  There are duplicate structure names with
> different contents.
>
> None of it is well documented.
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org --=_alternative 005269DC85256E30_=-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 4 10:39: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 KAA11158 for ; Wed, 4 Feb 2004 10:39:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoP7X-0002z5-7a for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 10:39:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14FdJc8011470 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 10:39:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoP7V-0002yv-MD for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 10:39:18 -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 KAA11091 for ; Wed, 4 Feb 2004 10:39:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoP7T-0001LE-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 10:39:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoP6X-0001FW-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 10:38:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoP5i-0001A5-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 10:37:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoP5J-0002MP-E3; Wed, 04 Feb 2004 10:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoP4j-0002LD-1t for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 10:36:25 -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 KAA10897 for ; Wed, 4 Feb 2004 10:36:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoP4g-00012o-00 for ipv6@ietf.org; Wed, 04 Feb 2004 10:36:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoP3m-0000xQ-00 for ipv6@ietf.org; Wed, 04 Feb 2004 10:35:27 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoP3R-0000r0-00 for ipv6@ietf.org; Wed, 04 Feb 2004 10:35:05 -0500 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i14FYwV28581; Wed, 4 Feb 2004 07:34:59 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 4 Feb 2004 07:34:58 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Brian Haberman cc: ipv6@ietf.org, "Wijnen, Bert (Bert)" Subject: problem with inetCidrRouteDest/inetCidrRoutePfxLen consistency check language in draft-ietf-ipv6-rfc2096-update-06.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=none autolearn=no version=2.60 Brian, If interpreted literally, the following language in the DESCRIPTION clauses for inetCidrRouteDest and inetCidrRoutePfxLen seems to prohibit having a non-zero zone index in inetCidrRouteDest: The values for the index objects inetCidrRouteDest and inetCidrRoutePfxLen must be consistent. When the value of inetCidrRouteDest is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object inetCidrRoutePfxLen MUST be equal to x. If not, then the index pair is not consistent and an inconsistentName error must be returned on SET or CREATE requests. This is so because the mask formed from inetCidrRoutePfxLen is contiguous and does not include the zone index part. Thus, the bitwise logical-AND of the value of inetCidrRouteDest and the value of the mask formed from the corresponding index object inetCidrRoutePfxLen will necessarily have zeroes in the zone index position. It seems to me that an easy fix for this problem would be to alter the text to exclude the zone index from the comparison. Here is my suggestion: The values for the index objects inetCidrRouteDest and inetCidrRoutePfxLen must be consistent. When the value of inetCidrRouteDest (excluding the zone index, if one is present) is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object inetCidrRoutePfxLen MUST be equal to x. If not, then the index pair is not consistent and an inconsistentName error must be returned on SET or CREATE requests. Thanks, Mike -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 4 10:52: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 KAA11915 for ; Wed, 4 Feb 2004 10:52:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPKK-00048l-C4 for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 10:52:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14FqWM5015915 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 10:52:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPKK-00048c-3A for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 10:52: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 KAA11894 for ; Wed, 4 Feb 2004 10:52:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPKH-000338-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 10:52:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPJG-0002vG-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 10:51:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoPIK-0002oj-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 10:50:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPHw-0003WY-45; Wed, 04 Feb 2004 10:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPH8-0003VB-Dh for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 10:49:14 -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 KAA11797 for ; Wed, 4 Feb 2004 10:49:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPH5-0002fE-00 for ipv6@ietf.org; Wed, 04 Feb 2004 10:49:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPG9-0002Yg-00 for ipv6@ietf.org; Wed, 04 Feb 2004 10:48:14 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AoPFJ-0002Mh-00 for ipv6@ietf.org; Wed, 04 Feb 2004 10:47:21 -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 i14FkbV17327; Wed, 4 Feb 2004 07:46:37 -0800 Received: from innovationslab.net (sjca.caspiannetworks.com [63.108.173.130]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i14FuklN019794 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 4 Feb 2004 07:56:52 -0800 Message-ID: <402113CD.90103@innovationslab.net> Date: Wed, 04 Feb 2004 10:46:21 -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: "C. M. Heard" CC: ipv6@ietf.org, "Wijnen, Bert (Bert)" Subject: Re: problem with inetCidrRouteDest/inetCidrRoutePfxLen consistency check language in draft-ietf-ipv6-rfc2096-update-06.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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit C. M. Heard wrote: > Brian, > > If interpreted literally, the following language in the DESCRIPTION > clauses for inetCidrRouteDest and inetCidrRoutePfxLen seems to > prohibit having a non-zero zone index in inetCidrRouteDest: > > The values for the index objects inetCidrRouteDest and > inetCidrRoutePfxLen must be consistent. When the value > of inetCidrRouteDest is x, then the bitwise logical-AND > of x with the value of the mask formed from the > corresponding index object inetCidrRoutePfxLen MUST be > equal to x. If not, then the index pair is not > consistent and an inconsistentName error must be > returned on SET or CREATE requests. > > This is so because the mask formed from inetCidrRoutePfxLen is > contiguous and does not include the zone index part. Thus, the > bitwise logical-AND of the value of inetCidrRouteDest and the value > of the mask formed from the corresponding index object > inetCidrRoutePfxLen will necessarily have zeroes in the zone index > position. > > It seems to me that an easy fix for this problem would be to alter > the text to exclude the zone index from the comparison. Here is > my suggestion: > > The values for the index objects inetCidrRouteDest and > inetCidrRoutePfxLen must be consistent. When the value > of inetCidrRouteDest (excluding the zone index, if one > is present) is x, then the bitwise logical-AND > of x with the value of the mask formed from the > corresponding index object inetCidrRoutePfxLen MUST be > equal to x. If not, then the index pair is not > consistent and an inconsistentName error must be > returned on SET or CREATE requests. After reading through the thread again and looking at the text, I agree that it is wrong wrt scoped addresses. I like your suggested text with one caveat. I believe we need to include some words in the DESCRIPTION that talk about what to do when a zone index is present in the address. I need to think some more about what that text should be and where it should go. 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 Wed Feb 4 12:08: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 MAA15014 for ; Wed, 4 Feb 2004 12:08:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQVe-0003LD-QA for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 12:08:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14H8I3l012829 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 12:08:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQVe-0003Kq-BW for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 12:08:18 -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 MAA14995 for ; Wed, 4 Feb 2004 12:08:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQVd-0003FB-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 12:08:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQUh-00039u-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 12:07:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoQTt-00034W-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 12:06:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQTR-0002iT-Ro; Wed, 04 Feb 2004 12:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQSk-0002ej-Pz for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 12:05:18 -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 MAA14789 for ; Wed, 4 Feb 2004 12:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQSf-0002vp-00 for ipv6@ietf.org; Wed, 04 Feb 2004 12:05:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQRh-0002om-00 for ipv6@ietf.org; Wed, 04 Feb 2004 12:04:14 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1AoQQk-0002ds-00 for ipv6@ietf.org; Wed, 04 Feb 2004 12:03:14 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id E1F3F848C5; Wed, 4 Feb 2004 18:02:40 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.18]) by merkur.iu-bremen.de (Postfix) with ESMTP id 7902D847B8; Wed, 4 Feb 2004 18:02:39 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 6E27C82DF; Wed, 4 Feb 2004 18:02:38 +0100 (CET) Date: Wed, 4 Feb 2004 18:02:38 +0100 From: Juergen Schoenwaelder To: "C. M. Heard" Cc: Brian Haberman , ipv6@ietf.org, "Wijnen, Bert (Bert)" Subject: Re: problem with inetCidrRouteDest/inetCidrRoutePfxLen consistency check language in draft-ietf-ipv6-rfc2096-update-06.txt Message-ID: <20040204170238.GA1400@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "C. M. Heard" , Brian Haberman , ipv6@ietf.org, "Wijnen, Bert (Bert)" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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, Feb 04, 2004 at 07:34:58AM -0800, C. M. Heard wrote: [...] > It seems to me that an easy fix for this problem would be to alter > the text to exclude the zone index from the comparison. Here is > my suggestion: > > The values for the index objects inetCidrRouteDest and > inetCidrRoutePfxLen must be consistent. When the value > of inetCidrRouteDest (excluding the zone index, if one > is present) is x, then the bitwise logical-AND > of x with the value of the mask formed from the > corresponding index object inetCidrRoutePfxLen MUST be > equal to x. If not, then the index pair is not > consistent and an inconsistentName error must be > returned on SET or CREATE requests. This text is clearly an improvement over what has been there before. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 4 12:30: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 MAA16122 for ; Wed, 4 Feb 2004 12:30:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQr7-0005Iu-3t for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 12:30:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14HUTxv020382 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 12:30:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQr6-0005If-UR for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 12:30: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 MAA16052 for ; Wed, 4 Feb 2004 12:30:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQr5-0005dO-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 12:30:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQq9-0005TG-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 12:29:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoQp9-0005Iz-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 12:28:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQoj-0004iU-Pi; Wed, 04 Feb 2004 12:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQo0-0004eO-K8 for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 12:27:16 -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 MAA15689 for ; Wed, 4 Feb 2004 12:27:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQnz-00057P-00 for ipv6@ietf.org; Wed, 04 Feb 2004 12:27:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQmz-0004yO-00 for ipv6@ietf.org; Wed, 04 Feb 2004 12:26:14 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AoQm0-0004mt-00 for ipv6@ietf.org; Wed, 04 Feb 2004 12:25:13 -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 i14HOdV18055 for ; Wed, 4 Feb 2004 09:24:39 -0800 Received: from innovationslab.net (sjca.caspiannetworks.com [63.108.173.130]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i14HYplN020131 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 4 Feb 2004 09:34:55 -0800 Message-ID: <40212ACA.9070701@innovationslab.net> Date: Wed, 04 Feb 2004 12:24:26 -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: IETF Mailing List Subject: Issue Tracker for 2461 and 2462 updates Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, We are using the issue tracker at rt.psg.com to track the updates for 2461 and 2462. We are going to add the IPv6 mailing list to the CC: list for changes posted to the issue tracker. This will be to keep the WG up-to-date on changes in the issues lists. Please keep any follow-up to these posts directed to the mailing list and not to the issue tracker e-mail address. Thanks, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 4 15:32: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 PAA24873 for ; Wed, 4 Feb 2004 15:32:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoThA-0003pR-7T for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 15:32:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14KWOM9014711 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 15:32:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTh9-0003pC-Vh for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 15:32:24 -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 PAA24830 for ; Wed, 4 Feb 2004 15:32:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTh8-0000dD-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 15:32:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTgD-0000Xe-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 15:31:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoTfR-0000T8-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 15:30:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTet-0003Rt-73; Wed, 04 Feb 2004 15:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTeK-0003NN-Hj for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 15:29: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 PAA24739 for ; Wed, 4 Feb 2004 15:29:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTeI-0000NZ-00 for ipv6@ietf.org; Wed, 04 Feb 2004 15:29:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTdH-0000HH-00 for ipv6@ietf.org; Wed, 04 Feb 2004 15:28:24 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AoTcJ-00006e-00 for ipv6@ietf.org; Wed, 04 Feb 2004 15:27:23 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i14KQgQ28180; Wed, 4 Feb 2004 12:26:42 -0800 X-mProtect: <200402042026> Nokia Silicon Valley Messaging Protection Received: from hr2423.wlan.dnafinland.fi (62.237.24.23, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdvTbLDc; Wed, 04 Feb 2004 12:26:38 PST Message-Id: <4.3.2.7.2.20040204092106.03afdc28@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Feb 2004 12:23:25 -0800 To: Pekka Savola From: Bob Hinden Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Cc: Bob Hinden , ipv6@ietf.org In-Reply-To: References: <4.3.2.7.2.20040203111552.02f16710@mailhost.iprg.nokia.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 Pekka, At 12:13 PM 2/3/2004, Pekka Savola wrote: >Inline.. likewise... >On Tue, 3 Feb 2004, Bob Hinden wrote: > > The text in the IANA considerations section calls for the IANA to set up a > > "allocation authority" for the centrally assigned ULA prefixes. The exact > > details of how to do this (i.e., one or many organizations doing the > > assignments, who it is, etc., etc.) are left to the IANA as long as they > > meet the requirements stated in the document. > >I read "an allocation authority" as singular, just one organization. >As the space is specified to be non-hierarchical and the randomizer >algorithm is specified to use LSB 40 bits for centrally allocated >prefixes, this does strongly imply a single organization (or >organizations with a pretty well-synched up database :). That was certainly the original intent, but at the same time I don't think the current text limits it to a single organization as long as the allocations are made in a manner as if a single organization was doing it. For example, if the IANA ran the algorithm a million times and then assigned a hundred thousand of the prefixes to ten organizations (and then repeated as required) that would be consistent with text and satisfy your concern about a single organization. Note, I don't have the same issue you have with a single organization, so opinions vary on this. I think the current text is a reasonable middle ground. > > I am comfortable with the IANA doing this in a manner that will be > > beneficial from the community. It is also, of course, out of scope > > for the IETF to specify more than the allocation requirements, which > > this document does do. We have learned from past experience it's not > > wise to over specify when asking the IANA to do address allocation. > > I think the current text is about right in this regard. > >If folks think this is OK, it's fine by me. Clarification in IANA >considerations like "If deemed appropriate, the authority may also >consist of multiple organizations performing the authority duties" >might be in order though. I will take a look at the IANA considerations text and see what can be done. > > >2) The specification requires that routing protocols special-case these > > >prefixes by MUST filtering them. This is unacceptable, and should be > > >removed. Any filtering should be done by the sites themselves. Note that > > >running any other protocol than BGP is not feasible anyway to be run over > > >administrative domains (exclusing provider-provisioned VPNs, maybe, but > > >those are special case anyway), so we can pretty much limit the discussion > > >to BGP. Which is pretty trivial, because 1) why would the ISP advertise > > >such prefixes, and 2) why would the site not filter out stuff it doesn't > > >want. > > > > > > Any routing protocol that is used between sites MUST filter out any > > > incoming or outgoing Local IPv6 unicast routes. The exception to > > > this is if specific /48 IPv6 local unicast routes have been > > > configured to allow for inter-site communication. > > > > I agree this could be stated better. I think it would be good to > > change it to "Any router that is used between sites....", as it is > > not the routing protocols doing the filtering, but the router based > > on it's configuration. > >But then it's an operational guidance, right? Maybe not uppercase >material? I don't have any problem making this change, but I don't understand the difference between upper and lower case in these sections. > > The requirement is that the FC00::/7 is > > filtered by default by routers at the site boundary. As Brian > > Carpenter pointed out if there is a filter for this prefix > > configured by default in all routers, it does no harm as sites that > > wish to use these addresses would add more specific routes that > > would override the default filters for these more specific prefixes. > >Please check my response to Brian. There is a very specific >difference of "FC00::/7 reject route" and "FC00::/7" filter. If you >mean the former -- fine, it works in most cases (except the stub >router and no IGP case I mentioned) -- if the latter, you're in for a >lot of trouble. Something like this would be very difficult to >implement properly. The intent was "reject route". I will clarify the text. > > >3) Similar to the above, there are some particularly inpractical > issues with > > >site-border security: > > > > > > Site border routers SHOULD install a black hole route for the Local > > > IPv6 prefix FC00::/7. This will insure that packets with Local IPv6 > > > destination addresses will not be forwarded outside of the site via a > > > default route. Site border routers SHOULD respond with the > > > appropriate ICMPv6 Destination Unreachable message to inform the > > > source that the packet was not forwarded [ICMPV6]. This feedback is > > > important to avoid transport protocol timeouts. > > > > > > 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. The default behavior of these devices > > > SHOULD be to filter them. Site border routers SHOULD respond with > > > the appropriate ICMPv6 Destination Unreachable message to inform the > > > source that the packet was not forwarded. > > > > > >.. this is inpractical, and should be reworded. The site border routers > > >cannot know that they are site-border routers, so these checks cannot be > > >implemented. What you can do is state that a toggle SHOULD be implemented > > >and when enabled on an interface, it would apply these kind of > restrictions > > >to it. But the point is that you WILL need administrator > action. "Deny by > > >default" just is not practical approach here, because you don't know that > > >you should be denying these by default. > > > > I don't agree. As stated above if the /7 prefix is filtered by default, it > > does no harm. But I think changing the text to make it clearer that these > > routers should be configured to do this filtering would make the text > clearer. > >"Filtered" has entirely different implications whether it's "done" >(inpartially) with a reject route, or done with access lists. See my >note to Brian. "access-lists by default" pretty much by definition >WILL block the more specifics, and are difficult to deploy or specify >here. I will clarify that it should be a "reject route". That also consistent with providing the ICMP feedback. > > > Additionally, domain border routers connecting autonomous systems > > > throughout the Internet SHOULD obey these recommendations for site > > > border routers. > > > > > >==> as for this, I have no idea what this even tries to say, so it > requires > > >rewording. > > > > It is trying to say that routers that connect autonomous systems also be > > configured to do this filtering. Even if they are not at site > > boundaries. How about: > > > > Routers that maintain peering arrangements between Autonomous > > Systems throughout the Internet SHOULD obey the recommendations for > > site border routers unless configured otherwise. > >Ok, that's understandable. But again, why use an uppercase SHOULD >keyword? This is a requirement for operators, not a protocol >interoperability issue? As above, please explain the difference? > > >semi-editorial > > >-------------- > > > > > > 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). > > > > > >==> hopefully the centrally assigned global IDs don't use their > > >(single) computer's EUI-64 in the generation :-) > > > > I don't think this is a problem. Every time the algorithm is run the time > > would change resulting in a new distinct allocation. The MD5 hash > > guarantees it. > >Sure, but the amount of entropy given as input to the has function is >significantly lower. For central allocations this is probably not a >problem. Agreed. > > > 4) Compute an MD5 digest on the key as specified in [MD5DIG]. > > > > >==> security folks have been pushed for the use of SHA-1 because it's more > > >collision-proof. It doesn't matter much in this specific context, but at > > >least nobody would object if you changed this to using an SHA-1 digest. > > > > As you said, "it doesn't matter...". > >If you feel so. This might come up at IESG review from security ADs >though :). I am sure they will have something to say whatever is in the document :-) > > > For future study names with Local IPv6 addresses may be resolved > > > inside of the site using dynamic naming systems such as Multicast > > > DNS. > > > > > >==> this seems irrelevant and should be removed; above, it already > > >states someting general about local naming systems. > > > > I don't see it doing any harm either. > >This is an unnecessary plug for Multicast DNS. > >(btw, if it stays, it should be reworded for better english..) OK. > > >11.2 Disadvantages > > > > > >==> Add to disadvantages: > > > > > > - Instead of using global unicast addresses inside the sites, the > > > sites may be tempted to start using Local IPv6 addresses > excessively, > > > instead of using global unicast addresses and reachability > restrictions > > > such as firewalls or access control lists > > > > I think this is out of scope for this document. > >Applicability statements or reality checks are in scope for all kinds >of documents. :) But as can be seen from the volume of mail on the merits of appropriate use of local vs. global addresses, opinions do vary widely on this. I don't think it would be very productive to repeat that discussion. >I don't think this document has any chance of passing through the >other reviews unless it spells out its usability (and especially >nonusability!) better. > >I'm not sure that adding a rather architectural disadvantage is enough >but it could be a start. I agree that as this document progresses through the process other changes will likely be required. Has any document ever gone from a w.g. through the IESG without any changes :-) Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 4 17:38:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05193 for ; Wed, 4 Feb 2004 17:38:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVfB-00063P-1Y for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 17:38:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14McTx3023268 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 17:38:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVfA-00063D-PH for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 17:38: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 RAA05179 for ; Wed, 4 Feb 2004 17:38:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoVf8-0002Os-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 17:38:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoVeA-0002Jq-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 17:37:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoVdn-0002Fa-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 17:37:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVco-0005Ta-9I; Wed, 04 Feb 2004 17:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVcE-0005Sm-SJ for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 17:35: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 RAA05079 for ; Wed, 4 Feb 2004 17:35:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoVcC-0002A3-00 for ipv6@ietf.org; Wed, 04 Feb 2004 17:35:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoVbI-00025J-00 for ipv6@ietf.org; Wed, 04 Feb 2004 17:34:29 -0500 Received: from c211-30-120-24.carlnfd2.nsw.optusnet.com.au ([211.30.120.24] helo=drugs.dv.isc.org) by ietf-mx with esmtp (Exim 4.12) id 1AoVaY-00020q-00 for ipv6@ietf.org; Wed, 04 Feb 2004 17:33:43 -0500 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i14MXccc043624; Thu, 5 Feb 2004 09:33:41 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200402042233.i14MXccc043624@drugs.dv.isc.org> To: Kristine Adamson Cc: ipv6@ietf.org From: Mark.Andrews@isc.org Subject: Re: SIOCGIFaaa ioctls and IPv6 interfaces In-reply-to: Your message of "Wed, 04 Feb 2004 09:59:37 CDT." Date: Thu, 05 Feb 2004 09:33:38 +1100 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 > This is a multipart message in MIME format. > --=_alternative 005269DC85256E30_= > Content-Type: text/plain; charset="US-ASCII" > > Thanks for the feedback. Was there ever any discussion in the IPv6 > working group in regards to creating a standard set of ioctl() function > calls, similar to the SIOCGIFaaa ioctls, the could either be used wit IPv6 > interfaces, or which could be used with both IPv4 and IPv6 interfaces > (i.e., version-neutral)? Not that I can remember. Some have getifaddrs(3). Which is a little higher. > Kristine Adamson > IBM Communications Server for MVS: TCP/IP Development > Internet e-mail:adamson@us.ibm.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 4 19:37: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 TAA11058 for ; Wed, 4 Feb 2004 19:37:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoXVQ-0003G0-NX for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 19:36:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i150aWk6012515 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 19:36:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoXVQ-0003Fm-H9 for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 19:36: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 TAA11020 for ; Wed, 4 Feb 2004 19:36:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoXVO-0006sq-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 19:36:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoXUV-0006nA-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 19:35:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoXTZ-0006hz-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 19:34:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoXSz-0002tH-LX; Wed, 04 Feb 2004 19:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoXSU-0002sG-Pt for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 19:33:30 -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 TAA10958 for ; Wed, 4 Feb 2004 19:33:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoXST-0006bx-00 for ipv6@ietf.org; Wed, 04 Feb 2004 19:33:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoXRV-0006XF-00 for ipv6@ietf.org; Wed, 04 Feb 2004 19:32:29 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AoXQc-0006Nr-00 for ipv6@ietf.org; Wed, 04 Feb 2004 19:31:35 -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 i150UxV21225 for ; Wed, 4 Feb 2004 16:30:59 -0800 Received: from innovationslab.net (sjca.caspiannetworks.com [63.108.173.130]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i150fClN021451 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 4 Feb 2004 16:41:16 -0800 Message-ID: <40218EAF.10405@innovationslab.net> Date: Wed, 04 Feb 2004 19:30:39 -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: ipv6@ietf.org Subject: IPv6 WG Last Call:draft-ietf-ipv6-rfc2011-update-06.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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, This starts a 1 week, working group last call on: Title : Management Information Base for the Internet Protocol (IP) Author(s) : S. Routhier Filename : draft-ietf-ipv6-rfc2011-update-06.txt Pages : 133 Date : 2004-2-2 as a Proposed Standard. Substantive comments should be sent to the mailing list. Editorial comments can be sent to the editor. The Last Call will end on Tuesday (02/10/2004) at 17:00 EST. Regards, Brian & Bob IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 4 21:42: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 VAA14769 for ; Wed, 4 Feb 2004 21:42:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoZSZ-0003D3-LA for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 21:41:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i152fhBQ012331 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 21:41:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoZSZ-0003Cg-FK for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 21:41:43 -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 VAA14763 for ; Wed, 4 Feb 2004 21:41:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoZSW-0002nz-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 21:41:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoZRe-0002iG-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 21:40:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoZRL-0002cQ-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 21:40:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoZQx-0002jk-SW; Wed, 04 Feb 2004 21:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoZQf-0002eW-3z for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 21:39: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 VAA14581 for ; Wed, 4 Feb 2004 21:39:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoZQc-0002Y9-00 for ipv6@ietf.org; Wed, 04 Feb 2004 21:39:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoZPV-0002NA-00 for ipv6@ietf.org; Wed, 04 Feb 2004 21:38:34 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AoZOe-00025O-00 for ipv6@ietf.org; Wed, 04 Feb 2004 21:37:40 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HSL00K4GB9YMH@mailout1.samsung.com> for ipv6@ietf.org; Thu, 05 Feb 2004 11:37:10 +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 <0HSL00E4GB9G1H@mailout1.samsung.com> for ipv6@ietf.org; Thu, 05 Feb 2004 11:36:53 +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 <0HSL00KE9B9GY4@mmp1.samsung.com> for ipv6@ietf.org; Thu, 05 Feb 2004 11:36:52 +0900 (KST) Date: Thu, 05 Feb 2004 11:35:53 +0900 From: "S. Daniel Park" Subject: RE: [2462bis] preferred lifetime and the 'two-hour' rule In-reply-to: To: =?ks_c_5601-1987?B?J0pJTk1FSSBUYXR1eWEgLyA/lr6SQo3GJw==?= , ipv6@ietf.org Message-id: <013c01c3eb90$e65fec90$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=ks_c_5601-1987 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.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > If so, it should make sense to recover this part in rfc2462bis. > Possible options include: > > 1) update the preferred lifetime regardless of whether the valid > lifetime is accepted or not wrt the "two-hour" rule > 2) update the preferred lifetime only when the valid lifetime is > accepted > 3) leave this as implementation dependent > > I don't think option 3 is the way to go, since RFC1971 clearly > mentioned the preferred lifetime. > > The KAME/BSD implementation behaves as option 1. However, it seems to > me that option 2 makes much more sense because a rejected valid > lifetime indicates a possibility of attack and the other parts of > the information may then be bogus as well. And, in fact, item 2 of > 5.5.3 e) says: > > 2) If the StoredLifetime is less than or equal to 2 > hours and the > received Lifetime is less than or equal to StoredLifetime, > ignore the prefix,... > > that is, it specifies ignoring "the prefix", not just "the valid > lifetime". > > What do others think? As I already indicated, I'd propose to revise > the text clearly with option 2 above. To reduce logically redundancy, KAME just omitted "two-hour" rule IMHO. So I think you can propose both of them to clarify this rule with high preference for (2). Hope this helps... 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 Wed Feb 4 22:22: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 WAA16306 for ; Wed, 4 Feb 2004 22:22:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa5U-0006Ii-4K for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 22:21:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i153Luw2024212 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 22:21:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa5T-0006IQ-NT for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 22:21:56 -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 WAA16259 for ; Wed, 4 Feb 2004 22:21:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa5Q-0006ve-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 22:21:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoa4l-0006nC-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 22:21:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aoa3e-0006ey-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 22:20:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AoZoT-0004FZ-BP for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 22:04:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoZoA-00056X-AV; Wed, 04 Feb 2004 22: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 1AoZnY-00055U-4J for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 22:03:24 -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 WAA15676 for ; Wed, 4 Feb 2004 22:03:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoZnV-0005CA-00 for ipv6@ietf.org; Wed, 04 Feb 2004 22:03:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoZmP-0004w4-00 for ipv6@ietf.org; Wed, 04 Feb 2004 22:02:14 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AoZkh-0004X1-00 for ipv6@ietf.org; Wed, 04 Feb 2004 22:00:27 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E35791525D; Thu, 5 Feb 2004 12:00:25 +0900 (JST) Date: Thu, 05 Feb 2004 12:00:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "S. Daniel Park" Cc: ipv6@ietf.org Subject: Re: [2462bis] preferred lifetime and the 'two-hour' rule In-Reply-To: <013c01c3eb90$e65fec90$67cadba8@LocalHost> References: <013c01c3eb90$e65fec90$67cadba8@LocalHost> 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, 05 Feb 2004 11:35:53 +0900, >>>>> "S. Daniel Park" said: >> The KAME/BSD implementation behaves as option 1. However, it seems to >> me that option 2 makes much more sense because a rejected valid >> lifetime indicates a possibility of attack and the other parts of >> the information may then be bogus as well. And, in fact, item 2 of >> 5.5.3 e) says: >> >> 2) If the StoredLifetime is less than or equal to 2 >> hours and the >> received Lifetime is less than or equal to StoredLifetime, >> ignore the prefix,... >> >> that is, it specifies ignoring "the prefix", not just "the valid >> lifetime". >> >> What do others think? As I already indicated, I'd propose to revise >> the text clearly with option 2 above. > To reduce logically redundancy, KAME just omitted "two-hour" rule IMHO. What do you mean by "omitted 'two-hour' rule"? KAME implements the two-hour rule just as specified in RFC2462 with one exception: omitting the following part of 5.5.3 e) 2) If ...(snip) and the received Lifetime is less than or equal to StoredLifetime, since this condition is "logically redundant" as already discussed in the wg. (but the details of the KAME behavior about the two-hour rule itself is not directly related to the main point in this thread. So let's stop discussing this particular point in this thread) 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 Feb 4 22:24: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 WAA16419 for ; Wed, 4 Feb 2004 22:24:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa7G-0006kJ-6m for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 22:23:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i153NkFb025923 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 22:23:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa7G-0006k2-2l for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 22:23:46 -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 WAA16396 for ; Wed, 4 Feb 2004 22:23:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa7D-000796-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 22:23:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoa6I-00073N-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 22:22:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa5t-0006xF-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 22:22:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa5Z-0006JK-1w; Wed, 04 Feb 2004 22:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa5A-0006Fe-3J for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 22:21:36 -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 WAA16194 for ; Wed, 4 Feb 2004 22:21:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa56-0006t2-00 for ipv6@ietf.org; Wed, 04 Feb 2004 22:21:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoa4C-0006jR-00 for ipv6@ietf.org; Wed, 04 Feb 2004 22:20:36 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa3M-0006es-00 for ipv6@ietf.org; Wed, 04 Feb 2004 22:19:44 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 96F2C15263; Thu, 5 Feb 2004 12:19:44 +0900 (JST) Date: Thu, 05 Feb 2004 12:19:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipv6@ietf.org Subject: Re: [2462bis] preferred lifetime and the 'two-hour' rule In-Reply-To: <200402040917.i149HiSj043851@givry.rennes.enst-bretagne.fr> 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, 04 Feb 2004 10:17:44 +0100, >>>>> Francis Dupont said: > The current RFC2462 describes in Section 5.5.3 e) how the valid > lifetime of an autoconfigured address is updated, considering the > avoidance of DoS attack with too short lifetimes. > => the DoS attack is about valid lifetime only because when a valid > lifetime is dropped to zero an implementation can (IMHO it is in fact > a SHOULD) kill all connections using a now unvalid address. > The behavior for zero preferred lifetime is far less drastic ("deprecated" > addresses are not used for new "connections" when there are other > available addresses) and (IMPORTANT) we need for multi-homing to be > able to play with preferred lifetimes. > However, it doesn't mention preferred lifetimes. 5.5.3 e) says: > ... > This document doesn't say anything about preferred lifetimes from this > part to the end of this section. > => this is on purpose. I know the rationale why the two-hour rule only affects the valid lifetime. Perhaps I was not clear enough in the previous message, but my point is that RFC2462 doesn't say **anything** about preferred lifetime update. To make the story simple, let's forget the DoS issue and the two-hour rule for now. Assume we receive a valid RA containing a prefix information option, and the processing the RA reaches at 5.5.3 e). Also assume the valid and preferred lifetimes of the prefix information are long enough so that I don't have to worry about a DoS. Now please re-read 5.5.3 e) carefully. It is very clear that we should reset the valid lifetime to the advertised valid lifetime. But we cannot be sure how we should do about the preferred lifetime because 5.5.3 e) doesn't say anything about the preferred lifetime. Of course, a common sense would suggest that we also reset the preferred lifetime to the advertised value, and I believe all implementations work this way, at least in normal (i.e., non-DoS) cases. Still, it's just a guess; RFC2462 doesn't say anything about this point. So my first point is that we should clearly specify how the preferred lifetime is updated in 5.5.3 e) of rfc2462bis, mainly for normal cases. My second point is what we should do about the preferred lifetime when the valid lifetime is ignored due to the two-hour rule. My suggestion to the first point is that the preferred lifetime should basically be reset to the advertised value (of course!). My suggestion to the second point is that we should also ignore the preferred lifetime if the valid lifetime is ignored due to the two-hour rule. Hope I'm clear this time. 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 Feb 4 22:29: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 WAA16599 for ; Wed, 4 Feb 2004 22:29:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaC5-0007GI-Gi for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 22:28:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i153Sjc7027908 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 22:28:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaC5-0007G3-CK for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 22:28: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 WAA16582 for ; Wed, 4 Feb 2004 22:28:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoaC2-0007cv-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 22:28:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoaB3-0007X6-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 22:27:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoaAX-0007RP-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 22:27:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaAP-0006vF-Px; Wed, 04 Feb 2004 22:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaA0-0006u0-9P for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 22:26:36 -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 WAA16482 for ; Wed, 4 Feb 2004 22:26:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa9x-0007Pl-00 for ipv6@ietf.org; Wed, 04 Feb 2004 22:26:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoa92-0007Ke-00 for ipv6@ietf.org; Wed, 04 Feb 2004 22:25:36 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa8b-0007GE-00 for ipv6@ietf.org; Wed, 04 Feb 2004 22:25:09 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9776E1525D; Thu, 5 Feb 2004 12:25:09 +0900 (JST) Date: Thu, 05 Feb 2004 12:25:11 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jari Arkko Cc: ipv6@ietf.org Subject: Re: [2462bis] preferred lifetime and the 'two-hour' rule In-Reply-To: <4020A8FD.5070200@kolumbus.fi> References: <4020A8FD.5070200@kolumbus.fi> 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, 04 Feb 2004 10:10:37 +0200, >>>>> Jari Arkko said: >> This document doesn't say anything about preferred lifetimes from this >> part to the end of this section. > Oops. This could cause all addresses to go deprecated. That in itself > may not be too dangerous, however, since according to 5.5.4 you must be > able to still use deprecated addresses even on new connections if there > are no other available addresses. But I agree that it would be good to > avoid this. (I'm not objecting to this particular view, but) To make the point clearer, my main point was not how to avoid "DoS" for preferred lifetime. My point was RFC2462 didn't say anything about the update of the preferred lifetime, even for normal cases. (See my response to Francis for more details) 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 Feb 4 23:10: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 XAA17463 for ; Wed, 4 Feb 2004 23:10: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 1AoaqI-0003vB-PV for ipv6-archive@odin.ietf.org; Wed, 04 Feb 2004 23:10:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i154AIWM015073 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 23:10:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaqH-0003v2-BJ for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 23:10:17 -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 XAA17435 for ; Wed, 4 Feb 2004 23:10:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoaqD-0003Ga-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 23:10:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoaol-00039S-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 23:08:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoanY-0002zp-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 23:07:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoan7-0003HB-MA; Wed, 04 Feb 2004 23:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoamr-0003GQ-R0 for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 23:06:46 -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 XAA17339 for ; Wed, 4 Feb 2004 23:06:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoami-0002y0-00 for ipv6@ietf.org; Wed, 04 Feb 2004 23:06:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoalj-0002s4-00 for ipv6@ietf.org; Wed, 04 Feb 2004 23:05:36 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aoaki-0002in-00 for ipv6@ietf.org; Wed, 04 Feb 2004 23:04:32 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1039615263; Thu, 5 Feb 2004 13:04:32 +0900 (JST) Date: Thu, 05 Feb 2004 13:04:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mark.Andrews@isc.org Cc: Kristine Adamson , ipv6@ietf.org Subject: Re: SIOCGIFaaa ioctls and IPv6 interfaces In-Reply-To: <200402042233.i14MXccc043624@drugs.dv.isc.org> References: <200402042233.i14MXccc043624@drugs.dv.isc.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=AWL autolearn=no version=2.60 >>>>> On Thu, 05 Feb 2004 09:33:38 +1100, >>>>> Mark.Andrews@isc.org said: >> Thanks for the feedback. Was there ever any discussion in the IPv6 >> working group in regards to creating a standard set of ioctl() function >> calls, similar to the SIOCGIFaaa ioctls, the could either be used wit IPv6 >> interfaces, or which could be used with both IPv4 and IPv6 interfaces >> (i.e., version-neutral)? > Not that I can remember. Some have getifaddrs(3). Which is > a little higher. I've always been hoping that getifaddrs(3) is officially standardized and deployed. Aside from the portability issue, SIOCGIFxxx ioctl has many pitfalls for application programmers. To name a few: - buffer size estimation and try-and-error - OS/architecture dependent alignment - consideration for the existence (or non-existence) of the sa_len member (to advance the pointer in the buffer correctly) Many applications I've seen have fallen into some of the pits. Other OS-dependent low-layer interfaces like SIOCGIFxxx have similar pitfalls. getifaddrs(3) solves all the problems. If we can widely deploy a high-level interface like this one, it would help application programmers very much and make applications more accurate and robust. (Of course, OS vendors will still need to deal with low-level interfaces to implement the library) I know the IETF isn't the most appropriate place to discuss this type of thing, but does it help to write a short informational I-D describing the specification with some recommendation? 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 Feb 5 00:06: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 AAA18584 for ; Thu, 5 Feb 2004 00:06:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aobhx-0006Yd-Cg for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 00:05:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1555jOm025206 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 00:05:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aobhw-0006YT-V7 for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 00:05: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 AAA18577 for ; Thu, 5 Feb 2004 00:05:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aobhu-0000DA-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 00:05:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aobgs-00008Y-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 00:04:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aobgb-000047-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 00:04:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AobgG-0006FW-Uu; Thu, 05 Feb 2004 00:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aobfv-0006F5-Sz for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 00:03: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 AAA18540 for ; Thu, 5 Feb 2004 00:03:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aobft-00003P-00 for ipv6@ietf.org; Thu, 05 Feb 2004 00:03:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aobex-0007mw-00 for ipv6@ietf.org; Thu, 05 Feb 2004 00:02:39 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1Aobeh-0007ib-00 for ipv6@ietf.org; Thu, 05 Feb 2004 00:02:23 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HSL00901GFSTO@mailout3.samsung.com> for ipv6@ietf.org; Thu, 05 Feb 2004 13:28:40 +0900 (KST) Received: from ep_mmp1 (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 <0HSL00IQFGFRKO@mailout3.samsung.com> for ipv6@ietf.org; Thu, 05 Feb 2004 13:28:40 +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 <0HSL00KAOGFRY4@mmp1.samsung.com> for ipv6@ietf.org; Thu, 05 Feb 2004 13:28:39 +0900 (KST) Date: Thu, 05 Feb 2004 13:27:41 +0900 From: "S. Daniel Park" Subject: RE: [2462bis] preferred lifetime and the 'two-hour' rule In-reply-to: To: =?ks_c_5601-1987?B?J0pJTk1FSSBUYXR1eWEgLyA/lr6SQo3GJw==?= Cc: ipv6@ietf.org Message-id: <000301c3eba0$83e40780$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=ks_c_5601-1987 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 > What do you mean by "omitted 'two-hour' rule"? KAME implements the > two-hour rule just as specified in RFC2462 with one exception: > omitting the following part of 5.5.3 e) > > 2) If ...(snip) and the > received Lifetime is less than or equal to StoredLifetime, > > since this condition is "logically redundant" as already discussed in > the wg. It's my fault. I said what you say... and I may lost track of this point. Danel -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 5 09:45: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 JAA16828 for ; Thu, 5 Feb 2004 09:45:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokkV-0001Gs-GR for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 09:45:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15EixDp004880 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 09:44:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokkV-0001Gd-98 for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 09:44:59 -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 JAA16801 for ; Thu, 5 Feb 2004 09:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AokkT-00061i-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 09:44:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokjX-0005vH-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 09:44:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aokie-0005pQ-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 09:43:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aokgg-0000kd-BB; Thu, 05 Feb 2004 09:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aokg1-0000jO-JJ for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 09:40:21 -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 JAA16647 for ; Thu, 5 Feb 2004 09:40:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aokfz-0005Wz-00 for ipv6@ietf.org; Thu, 05 Feb 2004 09:40:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokfB-0005Q2-00 for ipv6@ietf.org; Thu, 05 Feb 2004 09:39:30 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aokea-0005HX-00 for ipv6@ietf.org; Thu, 05 Feb 2004 09:38:52 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 057C41525D for ; Thu, 5 Feb 2004 23:38:49 +0900 (JST) Date: Thu, 05 Feb 2004 23:38:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: a summary of proposals for rfc2462bis 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 Hello, I'm now working on the rfc2462bis document, and I've done the work for most of the issues I raised in the previous draft and presented in Minneapolis with my own proposed resolutions (which should be discussed and agreed by the wg, of course). I've revised the rfc2462bis text with the resolutions, which will be posted before the I-D cutoff date for initial submissions (Feb 9th). The attached below is a summary of the proposals. I believe most of them are trivial or based on the consensus of the wg (so I'm simply posting a summary), but I'll make separate threads for those that might be controversial. There are still some open issues, for which I'll make separate threads to hear opinions/comments. You can see detailed notes and specific changes at the rt.psg.com issue tracker: https://rt.psg.com/ user/password=ietf/ietf issue queue: ipv6-2462bis Please make comments if you find problems in the proposals by making a separate thread. If the comments can easily be addressed, I'll put the resolution to the new revision before submitting it. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp Issues that have proposals (basically from draft-jinmei-ipv6-rfc2462bis-00.txt, and IDs at the issue tracker for reference): ID Issue/Proposed Resolution ------------------------------------------------------------------ 264 There is dead code in the DoS prevention algorithm in Section 5.5.3 => Proposed Resolution: simply remove the redundant code. 265 Unclear text about a corner case in the inbound Neighbor Advertisement processing. => Proposed Resolution: clarify that a unicasted NS/NA should be discarded. 266 Unclear text about StoredLifetime. => Proposed Resolution: clarify the text (no change in the behavior, but replace StoredLifetime with RemainingLifetime for clarification) 267 since the wg are going to deprecate SL addresses, it would also make sense to remove references to site-local from this document. => Proposed Resolution: remove references to site-local and revise wording around the keyword. 268 Source address selection issues with regards to deprecated addresses. E.g., which one should be preferred as a source address, between a deprecated address and a smaller-scope address? => Proposed Resolution: add a simple note on this and a reference to RFC3484. detailed description on this is out of scope of this document. 269 The semantics of "new communication" is not very clear; is a passively opened TCP connection a new communication? What if an application specifies a deprecated address as a source address? => Proposed Resolution: revise the first paragraph of Section 5.5.4 so that - it clearly says incoming TCP-SYN to a deprecated address must be accepted. - it clearly says if the application specifies to use a deprecated address explicitly, the protocol stack must accept that. 270 There was a question about the semantics where the on-link (L) flag is 0 and the autonomous (A) flag is 1. => Proposed Resolution: no change for this. 271 An implementation may want to use stable storage for autoconfigured addresses. => Proposed Resolution: add a subsection in Section 5 to mention this (without mandating anything). DAD must be run after rebooting. (Note: this resolution may be controversial) 272 This document may need to be aligned with the SEND requirement draft in its security consideration. => Proposed Resolution: revise the second paragraph of Security Considerations so that: - add an informative reference to send-psreq - note that the use of IPsec is not always feasible 273 802.11 specification requires a link-layer filtering that conflicts with the condition to make DAD work correctly. => Proposed Resolution: add a note in Appendix A about this issue. Also refer to the wlan-dad draft (or perhaps the 802.11 274 There is conflict with the Multicast Listener Discovery specification about random delay for the first packet. The address autoconfiguration requires a random delay for a DAD packet if it is the first packet from the node, but an MLD report packet should usually be sent before the DAD packet. => Proposed Resolution: add a workaround to impose a random delay for DAD NS even after the first MLD. (Note: this resolution may be controversial since it may affect exiting implementations) 276 There is a possible denial of service attack not discussed: What if a malicious node intentionally sends prefixes for other LANs? => Proposed Resolution: no change for this (this is actually covered by send-psreq) (Note: we may still have to note this because this points out the two-hour rule for DoS avoidance may cause another DoS) 278 Whether a router (not a host) can autoconfigure itself using the stateless autoconfiguration protocol may need to be discussed. => Proposed Resolution: do nothing (this was actually pretty clear) (Note: but we may have to clarify if the definition of "router" is per-interface basis) 279 Should this document define a 'not-yet-ready' status of an autoconfigured address to help renumbering operation? => Proposed Resolution: nope. 280 The requirement about the interface failure upon DAD failure may be too strong. Does it make sense to loosen it, e.g., allowing automatic recovery? => Proposed Resolution: add "An implementation MAY try an automatic recovery technique from this failure and re-enable the interface." (Note: this may not be enough, based on a discussion in last November) 321 Preferred lifetime and the 'two-hour' rule => Proposed Resolution: clearly say that the preferred lifetime should be set the advertised value unless the prefix information option is ignored in the "two-hour" rules. Issues that are still open 275 Many DAD related issues have been discussed, including if it is okay to omit DAD in some environments or if DAD can be replaced with DIID (duplicate interface ID detection). 277 The semantics of the M/O flags is not very clear. 281 It is not very clear if this document always require a 64-bit Interface ID. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 5 09:48: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 JAA16968 for ; Thu, 5 Feb 2004 09:48: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 1AoknV-0001ua-Ck for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 09:48:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Em50f007342 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 09:48:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoknV-0001uL-7y for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 09:48:05 -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 JAA16945 for ; Thu, 5 Feb 2004 09:48:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoknT-0006Ll-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 09:48:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokmV-0006FR-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 09:47:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoklg-00069p-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 09:46:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoklX-0001Q3-2E; Thu, 05 Feb 2004 09:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aokkg-0001IF-M6 for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 09:45:10 -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 JAA16817 for ; Thu, 5 Feb 2004 09:45:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aokke-00063J-00 for ipv6@ietf.org; Thu, 05 Feb 2004 09:45:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aokjg-0005wy-00 for ipv6@ietf.org; Thu, 05 Feb 2004 09:44:10 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1AokjB-0005pK-00 for ipv6@ietf.org; Thu, 05 Feb 2004 09:43:38 -0500 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 i15Eh25B444952 for ; Thu, 5 Feb 2004 09:43:02 -0500 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 i15Eh2LU129522 for ; Thu, 5 Feb 2004 07:43:02 -0700 In-Reply-To: To: ipv6@ietf.org MIME-Version: 1.0 Subject: Re: SIOCGIFaaa ioctls and IPv6 interfaces X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 Message-ID: From: Kristine Adamson Date: Thu, 5 Feb 2004 09:43:00 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 02/05/2004 07:43:01, Serialize complete at 02/05/2004 07:43:01 Content-Type: multipart/alternative; boundary="=_alternative 0050E41F85256E31_=" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 0050E41F85256E31_= Content-Type: text/plain; charset="US-ASCII" jinmei@isl.rdc.toshiba.co.jp wrote on 02/04/2004 11:04:33 PM: > >>>>> On Thu, 05 Feb 2004 09:33:38 +1100, > >>>>> Mark.Andrews@isc.org said: > >> Thanks for the feedback. Was there ever any discussion in the IPv6 > >> working group in regards to creating a standard set of ioctl() function > >> calls, similar to the SIOCGIFaaa ioctls, the could either be used wit IPv6 > >> interfaces, or which could be used with both IPv4 and IPv6 interfaces > >> (i.e., version-neutral)? > > Not that I can remember. Some have getifaddrs(3). Which is > > a little higher. > I've always been hoping that getifaddrs(3) is officially standardized > and deployed. Aside from the portability issue, SIOCGIFxxx ioctl has > many pitfalls for application programmers. To name a few: > - buffer size estimation and try-and-error > - OS/architecture dependent alignment > - consideration for the existence (or non-existence) of the sa_len > member (to advance the pointer in the buffer correctly) > Many applications I've seen have fallen into some of the pits. Other > OS-dependent low-layer interfaces like SIOCGIFxxx have similar > pitfalls. > getifaddrs(3) solves all the problems. If we can widely deploy a > high-level interface like this one, it would help application > programmers very much and make applications more accurate and robust. > (Of course, OS vendors will still need to deal with low-level > interfaces to implement the library) > I know the IETF isn't the most appropriate place to discuss this type > of thing, but does it help to write a short informational I-D > describing the specification with some recommendation? We have received many questions from vendors about what APIs can provide the same information as the SIOCGIFaaa ioctls, for IPv6 addresses/interfaces. I thought that this subject may have been discussed as part of the IPv6 API discussions that produced the basic/advanced socket RFCs. So, if getifaddrs(3) seems to be the de facto standard for retrieving this information, then I think it would be great if the IPv6 working group published something to try to recommend it as the standard for this function, in order to ensure greater portability of applications. In regards to getifaddrs(3), for IPv6 I assume that the netmask field contain a 16-octet mask in the sockaddr_in6 structure, correct? There doesn't appear to be a returned field that contains the prefix length. > 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 > -------------------------------------------------------------------- Thanks, Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.com --=_alternative 0050E41F85256E31_= Content-Type: text/html; charset="US-ASCII"

jinmei@isl.rdc.toshiba.co.jp wrote on 02/04/2004 11:04:33 PM:

> >>>>> On Thu, 05 Feb 2004 09:33:38 +1100,
> >>>>> Mark.Andrews@isc.org said:
> >> Thanks for the feedback.  Was there ever any discussion in the IPv6
> >> working group in regards to creating a standard set of ioctl() function
> >> calls, similar to the SIOCGIFaaa ioctls, the could either be used wit IPv6
> >> interfaces, or which could be used with both IPv4 and IPv6 interfaces
> >> (i.e., version-neutral)?
> >  Not that I can remember.  Some have getifaddrs(3).  Which is
> >  a little higher.
> I've always been hoping that getifaddrs(3) is officially standardized
> and deployed.  Aside from the portability issue, SIOCGIFxxx ioctl has
> many pitfalls for application programmers.  To name a few:
> - buffer size estimation and try-and-error
> - OS/architecture dependent alignment
> - consideration for the existence (or non-existence) of the sa_len
> member (to advance the pointer in the buffer correctly)
> Many applications I've seen have fallen into some of the pits.  Other
> OS-dependent low-layer interfaces like SIOCGIFxxx have similar
> pitfalls.
> getifaddrs(3) solves all the problems.  If we can widely deploy a
> high-level interface like this one, it would help application
> programmers very much and make applications more accurate and robust.
> (Of course, OS vendors will still need to deal with low-level
> interfaces to implement the library)
> I know the IETF isn't the most appropriate place to discuss this type
> of thing, but does it help to write a short informational I-D
> describing the specification with some recommendation?

We have received many questions from vendors about what APIs can provide the same information as the SIOCGIFaaa ioctls, for IPv6 addresses/interfaces.  I thought that this subject may have been discussed as part of the IPv6 API discussions that produced the basic/advanced socket RFCs.  So, if getifaddrs(3) seems to be the de facto standard for retrieving this information, then I think it would be great if the IPv6 working group published something to try to recommend it as the standard for this function, in order to ensure greater portability of applications.

In regards to getifaddrs(3), for IPv6 I assume that the netmask field contain a 16-octet mask in the sockaddr_in6 structure, correct?  There doesn't appear to be a returned field that contains the prefix length.    

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

Thanks,

Kristine Adamson
IBM Communications Server for MVS: TCP/IP Development
Internet e-mail:adamson@us.ibm.com --=_alternative 0050E41F85256E31_=-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 5 10:05: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 KAA17734 for ; Thu, 5 Feb 2004 10:05:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aol3r-0005dX-H8 for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 10:04:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15F4xgM021667 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 10:04:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aol3r-0005d5-1A for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 10:04:59 -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 KAA17677 for ; Thu, 5 Feb 2004 10:04:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aol3o-0000AP-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:04:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aol2t-00005H-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:04:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aol2A-00000E-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:03:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aol1y-0004rj-J1; Thu, 05 Feb 2004 10: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 1Aol11-0003ve-Ci for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 10:02:03 -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 KAA17454 for ; Thu, 5 Feb 2004 10:02:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aol0z-0007hN-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:02:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aol02-0007cA-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:01:02 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aokzj-0007XH-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:00:43 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B70C01525D for ; Fri, 6 Feb 2004 00:00:42 +0900 (JST) Date: Fri, 06 Feb 2004 00:00:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis issue 271] retaining addresses in stable storage 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 To address rfc2462bis issue 271, "An implementation may want to use stable storage for autoconfigured addresses", I've added the following new (sub)section: ================================================================ 5.7 Retaining Configured Addresses for Stability It is reasoanble that implementations that have stable storage retain their addresses and the preferred and valid lifetimes if the addresses were acquired using the stateless address autoconfiguration. Assuming the lifetimes used are reasonable, this technique implies that a temporary outage (less than the preferred lifetime) will never result in the node loosing its global address even if the node were to reboot. This will particularly be useful in "zeroconf" environments where nodes are configuring their addresses by the stateless address autoconfiguration but all communication is closed in a single link. In such a case, the failure of a "router" (that provides the prefix for address configuration) is not significant, but loosing the global addresses might be a pain. When an implementation tries to reuse a retained address after rebooting, it MUST run Duplicate Address Detection for the address under the criteria described in Section 5.4, as though the address were just configured by stateless address autoconfiguration. The reason for this is because a different host may have started using the address while the rebooting host cannot respond to Duplicate Address Detection from the other host. ================================================================ I tried not to introduce any new requirements that affect existing implementations (compliant to RFC2462). But there is still a MUST in this new section, which may be overkilling for the purpose of this document. We could even drop the entire section and leave this stuff as a future extension. What do others think? 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 Feb 5 10: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 KAA18975 for ; Thu, 5 Feb 2004 10:16:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolEh-00010P-6Z for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 10:16:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15FGBns003862 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 10:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolEg-00010A-VW for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 10:16:11 -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 KAA18905 for ; Thu, 5 Feb 2004 10:16:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolEe-0001Ro-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:16:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolDj-0001JU-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:15:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AolCn-0001Ce-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:14:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolCd-00005q-56; Thu, 05 Feb 2004 10:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolCa-000054-Cr for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 10:14:00 -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 KAA18702 for ; Thu, 5 Feb 2004 10:13:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolCY-0001AM-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:13:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolBe-00014l-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:13:02 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AolAq-0000tv-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:12:12 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i15FBfo15512 for ; Thu, 5 Feb 2004 07:11:41 -0800 X-mProtect: <200402051511> Nokia Silicon Valley Messaging Protection Received: from merced.iprg.nokia.com (205.226.12.76, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdBlexv8; Thu, 05 Feb 2004 07:11:37 PST Message-Id: <4.3.2.7.2.20040205070625.022911c8@127.0.0.1> X-Sender: hinden@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Feb 2004 07:08:23 -0800 To: ipv6@ietf.org From: Bob Hinden Subject: FWD: [Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul..] 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 FYI. ---------- Forwarded message ---------- Date: Mon, 02 Feb 2004 10:48:25 -0500 From: internet-drafts@ietf.org To: IETF-Announce: ; Subject: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea There are two (2) Internet-Draft cutoff dates for the 59th IETF Meeting in Seoul, Korea: February 9th: Cutoff Date for Initial Internet-Draft Submissions (new documents) All initial Internet-Drafts (-00) and updates to initial Internet-Drafts must be submitted by Monday, February 9th, at 09:00 ET. As always, all initial submissions (-00) with a filename beginning with "draft-ietf" MUST be approved by the appropriate WG Chair before they can be processed or announced. WG Chair approval MUST be received by Wednesday, February 4th, at 09:00 ET. February 16th: Cutoff Date for Revised Internet-Draft Submissions (-01 and higher) All revised Internet-Drafts (-01 and higher) must be submitted by Monday, February 16th, at 09:00 ET. Initial and revised Internet-Drafts received after their respective cutoff dates will NOT be made available in the Internet-Drafts directory OR announced, and will have to be resubmitted. Please do NOT wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, March 8th. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. FYI: The Internet-Draft cutoff dates as well as other significant dates for the 59th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_59.html. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 5 10:22: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 KAA19531 for ; Thu, 5 Feb 2004 10:22:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolKM-0002jk-Tb for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 10:22:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15FM29K010520 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 10:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolKM-0002jV-3m for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 10:22: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 KAA19480 for ; Thu, 5 Feb 2004 10:21:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolKJ-00029P-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:21:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolJR-00023C-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:21:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AolIZ-0001x7-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:20:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolIP-00023s-Hg; Thu, 05 Feb 2004 10:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolHQ-0001iM-JY for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 10:19:00 -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 KAA19313 for ; Thu, 5 Feb 2004 10:18:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolHO-0001qL-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:18:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolGQ-0001k0-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:17:59 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AolFi-0001dH-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:17:14 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id DB8091525D for ; Fri, 6 Feb 2004 00:17:13 +0900 (JST) Date: Fri, 06 Feb 2004 00:17:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis issue 274] conflict between MLD and NS delay 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 To address the following issue for rfc2462bis: There is conflict with the Multicast Listener Discovery specification about random delay for the first packet. The address autoconfiguration requires a random delay for a DAD packet if it is the first packet from the node, but an MLD report packet should usually be sent before the DAD packet. I've added the following paragraph to Section 5.4.2: ================================================================= It should be noted that the Neighbor Solicitation is usually not the first message. As stated above, the sending node must join the solicited-node multicast address prior to sending the Neighbor Solicitation and an MLD report message [9] for the multicast address should have been sent at that time. Unfortunately, RFC 2710 [9] does not request a random delay to avoid race conditions. Thus, if the sending node interpreted the "first message" literally, it would not impose a delay for the MLD report or for the Neighbor Solicitation, making the race conditions worse. This document therefore suggests the following workaround: even if the Neighbor Solicitation is not the first message, the same random delay should be imposed when the sending node knows the Neighbor Solicitation can be synchronized with other nodes. This includes the first Neighbor Solicitation after the MLD report message in the above case. [9] is RFC2710 (the MLD spec) ================================================================= I myself think this is a reasonable compromise to avoid making the possible race condition worse. However, the new paragraph would make existing implementations that conform to RFC2462 in a "literal" sense become "non-compliant", and in that sense, this may be too aggressive for the purpose of this document. Alternatively, we could simply note the issue and not impose any change on the behavior. Some day when RFC2710 will be updated with a random delay for the first report, the race condition issue will also be resolved. Which one is better? Or is there any other solution? 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 Feb 5 10:33: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 KAA19875 for ; Thu, 5 Feb 2004 10:33: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 1AolV1-0003Vn-OE for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 10:33:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15FX3F9013495 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 10:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolV1-0003Va-Ia for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 10:33:03 -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 KAA19859 for ; Thu, 5 Feb 2004 10:33:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolUz-00035p-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:33:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolU0-00030W-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:32:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AolTT-0002vm-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:31:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolT4-00035g-VN; Thu, 05 Feb 2004 10:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolS6-000328-Iw for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 10:30: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 KAA19686 for ; Thu, 5 Feb 2004 10:29:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolS4-0002q2-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:30:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolR7-0002lG-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:29:01 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AolQE-0002gW-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:28:06 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B3A281525D for ; Fri, 6 Feb 2004 00:28:05 +0900 (JST) Date: Fri, 06 Feb 2004 00:28:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis issue 278] 2462bis for "routers" 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 There was an issue about how much we should allow a router (not a host) to use the RFC2462 spec to configure itself. Specifically, a) if a router can configure a global address by stateless autoconf b) if a router can configure a link-local address in a way described in RFC 2462 c) if a router can configure itself about "other" configuration information and I suggested in Minneapolis "a=NO, b=YES, c=NO". I then noticed this was actually pretty clear in the original RFC2462. It says in Introduction that: The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means. However, it is expected that routers will generate link-local addresses using the mechanism described in this document. In addition, routers are expected to successfully pass the Duplicate Address Detection procedure described in this document on all addresses prior to assigning them to an interface. So, my current resolution for this is "do nothing". However, we may have to clear whether the definition of a "router" is per-interface basis. The current definition in RFC2462 is: router - a node that forwards IP packets not explicitly addressed to itself. which I would NOT call per-interface basis. If we agree on adopting the per-interface definition, we'll probably need to revise the definition in the "TERMINOLOGY" section. Additionally, adopting this definition also opens up the possibility of a "half-host, half-router" node, like: ------(I1)Node(I2)------- (I3) | | where I1 and I2 are "normal" interfaces for which the node is acting as a router, and I3 is an interface to a "back-door" for which the node is acting as a host. This node can accept a router advertisement on interface I3 to configure an address or even configure a "default route" to I3 (though the latter part is out of scope of 2462bis). Should we, if adopting the per-interface definition, explicitly mention this type of configuration 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 Feb 5 10:55: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 KAA20536 for ; Thu, 5 Feb 2004 10:55:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolqP-0004xB-FR for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 10:55:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Ft91C019035 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 10:55:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolqP-0004ww-Am for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 10:55:09 -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 KAA20515 for ; Thu, 5 Feb 2004 10:55:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolqM-000590-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:55:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolpT-00052B-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:54:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aolof-0004w5-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:53:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoloL-0004ab-Qo; Thu, 05 Feb 2004 10:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolnN-0004Yb-JJ for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 10:52: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 KAA20372 for ; Thu, 5 Feb 2004 10:51:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolnL-0004oz-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:51:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolmO-0004jf-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:51:01 -0500 Received: from mclean-vscan3.bah.com ([156.80.3.63]) by ietf-mx with esmtp (Exim 4.12) id 1AollS-0004ZI-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:50:02 -0500 Received: from mclean-vscan3.bah.com (mclean-vscan3.bah.com [156.80.3.63]) by mclean-vscan3.bah.com (8.11.0/8.11.0) with SMTP id i15FnUP28572 for ; Thu, 5 Feb 2004 10:49:30 -0500 (EST) Received: from mclean6-mail.usae.bah.com ([156.80.5.102]) by mclean-vscan3.bah.com (NAVGW 2.5.2.12) with SMTP id M2004020510493015549 for ; Thu, 05 Feb 2004 10:49:30 -0500 Received: from BAHRUSSELL ([198.253.78.125]) by mclean6-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HSMBYI00.4AH; Thu, 5 Feb 2004 10:49:30 -0500 From: "Russell Brian" To: =?US-ASCII?B?SklOTUVJIFRhdHV5YSAvID9fLT8nQj9B?= , Subject: RE: [rfc2462bis issue 278] 2462bis for "routers" Date: Thu, 5 Feb 2004 07:49:12 -0800 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.1165 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 RFC 2460 provides this note in the terminology section: Note: it is possible, though unusual, for a device with multiple interfaces to be configured to forward non-self-destined packets arriving from some set (fewer than all) of its interfaces, and to discard non-self-destined packets arriving from its other interfaces. Such a device must obey the protocol requirements for routers when receiving packets from, and interacting with neighbors over, the former (forwarding) interfaces. It must obey the protocol requirements for hosts when receiving packets from, and interacting with neighbors over, the latter (non-forwarding) interfaces. I believe this covers this scenarios described below. Organizations have already started to define v6 requirements based on this note using host on 1 interface / router on another interface model. It would be nice to have specific terminology definitions for this configuration but changes would need to be made to 2460 as well. Brian Russell Systems Engineer Booz Allen Hamilton russell_brian@bah.com -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of JINMEI Tatuya / ?_-?'B?A Sent: Thursday, February 05, 2004 7:28 AM To: ipv6@ietf.org Subject: [rfc2462bis issue 278] 2462bis for "routers" There was an issue about how much we should allow a router (not a host) to use the RFC2462 spec to configure itself. Specifically, a) if a router can configure a global address by stateless autoconf b) if a router can configure a link-local address in a way described in RFC 2462 c) if a router can configure itself about "other" configuration information and I suggested in Minneapolis "a=NO, b=YES, c=NO". I then noticed this was actually pretty clear in the original RFC2462. It says in Introduction that: The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means. However, it is expected that routers will generate link-local addresses using the mechanism described in this document. In addition, routers are expected to successfully pass the Duplicate Address Detection procedure described in this document on all addresses prior to assigning them to an interface. So, my current resolution for this is "do nothing". However, we may have to clear whether the definition of a "router" is per-interface basis. The current definition in RFC2462 is: router - a node that forwards IP packets not explicitly addressed to itself. which I would NOT call per-interface basis. If we agree on adopting the per-interface definition, we'll probably need to revise the definition in the "TERMINOLOGY" section. Additionally, adopting this definition also opens up the possibility of a "half-host, half-router" node, like: ------(I1)Node(I2)------- (I3) | | where I1 and I2 are "normal" interfaces for which the node is acting as a router, and I3 is an interface to a "back-door" for which the node is acting as a host. This node can accept a router advertisement on interface I3 to configure an address or even configure a "default route" to I3 (though the latter part is out of scope of 2462bis). Should we, if adopting the per-interface definition, explicitly mention this type of configuration 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 5 10:58: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 KAA20764 for ; Thu, 5 Feb 2004 10:58:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoltF-0005Uh-RX for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 10:58:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Fw5Lv021107 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 10:58:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoltF-0005UM-IT for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 10:58:05 -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 KAA20724 for ; Thu, 5 Feb 2004 10:58:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoltD-0005Vm-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:58:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolsI-0005Oh-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:57:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AolrN-0005Gf-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:56:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolrH-00051c-Kk; Thu, 05 Feb 2004 10:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolqN-0004wk-S9 for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 10:55:07 -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 KAA20509 for ; Thu, 5 Feb 2004 10:55:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolqL-00058o-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:55:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolpR-00051v-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:54:10 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AoloZ-0004w1-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:53:15 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4A51E15263 for ; Fri, 6 Feb 2004 00:53:14 +0900 (JST) Date: Fri, 06 Feb 2004 00:53:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis issue 280] interface failure upon DAD failure 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 To address the issue "the requirement that the interface SHOULD be disabled upon DAD failure is too strong", I simply added the following line to Section 5.4.5: An implementation MAY try an automatic recovery technique from this failure and re-enable the interface. in the proposed resolution. But I then noticed that the issue was not that simple; I missed a discussion in last November (which I should have joined, actually...). By catching up the discussion, my impression is: - many people agreed that the "SHOULD" for the interface is too strong. The MUST NOT for the address is enough. - one motivation to remove the SHOULD for the interface is the possibility of DoS attacks. But it seems to me that it's not very convincing; as Thomas (Narten) said, the attacker can continue the attack even if we re-enable the interface. - Thomas made a good point about the rationale of the SHOULD (DAD failure for an EUI-64 based address likely indicates MAC address duplication). We should also note that John (Loughney) pointed out the assumption in 2462 is not necessarily met for the 3GPP case (I don't know what exactly he wanted to say, though) and my current feeling about the resolution is: + keep SHOULD for the interface if the interface identifier is derived from the layer 2 address, with the original intention Thomas explained. + allow MAY for the other cases (does this help the 3GPP case?) + remove the current resolution: "MAY try an automatic recovery" Does this make sense to others? 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 Feb 5 11: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 LAA20908 for ; Thu, 5 Feb 2004 11:00:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolvI-00062N-0x for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 11:00:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15G0Bn0023201 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 11:00:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolvG-000626-UF for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:00:10 -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 LAA20873 for ; Thu, 5 Feb 2004 11:00:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolvE-0005jz-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 11:00:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoluE-0005dk-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:59:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoltM-0005X9-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 10:58:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoltC-0005SN-Dh; Thu, 05 Feb 2004 10:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolsN-0005PV-Ap for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 10:57:11 -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 KAA20658 for ; Thu, 5 Feb 2004 10:57:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolsK-0005Ou-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:57:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolrO-0005Gy-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:56:11 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AolqT-00059a-00 for ipv6@ietf.org; Thu, 05 Feb 2004 10:55:13 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i15Ft87U031845; Thu, 5 Feb 2004 17:55:08 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i15Ft8Zo031842; Thu, 5 Feb 2004 17:55:08 +0200 Date: Thu, 5 Feb 2004 17:55:08 +0200 Message-Id: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> From: Markku Savela To: jinmei@isl.rdc.toshiba.co.jp CC: ipv6@ietf.org In-reply-to: (message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= on Fri, 06 Feb 2004 00:17:12 +0900) Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 > To address the following issue for rfc2462bis: > > There is conflict with the Multicast Listener Discovery > specification about random delay for the first packet. The address > autoconfiguration requires a random delay for a DAD packet if it > is the first packet from the node, but an MLD report packet should > usually be sent before the DAD packet. > > I've added the following paragraph to Section 5.4.2: > > ================================================================= > It should be noted that the Neighbor Solicitation is usually not the > first message. As stated above, the sending node must join the > solicited-node multicast address prior to sending the Neighbor > Solicitation and an MLD report message [9] for the multicast address > should have been sent at that time. Unfortunately, RFC 2710 [9] does > not request a random delay to avoid race conditions. Thus, if the > sending node interpreted the "first message" literally, it would not > impose a delay for the MLD report or for the Neighbor Solicitation, > making the race conditions worse. This document therefore suggests > the following workaround: even if the Neighbor Solicitation is not > the first message, the same random delay should be imposed when the > sending node knows the Neighbor Solicitation can be synchronized with > other nodes. This includes the first Neighbor Solicitation after the > MLD report message in the above case. This is silly! I thought the reason for the random delay was to prevent simultaneus packet sending of all hosts on the link, if they boot up at same time (for example after power fail). Now, this MLD report is going to be collided (mostly lost anyway), because every node is sending on the link at same time. If you are not delaying the MLD, there is really no point in delaying the DAD either... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 5 11:12: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 LAA21451 for ; Thu, 5 Feb 2004 11:12:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom6q-0007vr-GZ for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 11:12:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15GC8uv030485 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 11:12:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom6q-0007va-AF for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:12:08 -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 LAA21410 for ; Thu, 5 Feb 2004 11:12:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aom6p-0006uY-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 11:12:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aom5t-0006o9-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 11:11:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aom57-0006iA-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 11:10:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom4p-0007E7-5g; Thu, 05 Feb 2004 11:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom43-0007C7-3V for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 11:09:15 -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 LAA21263 for ; Thu, 5 Feb 2004 11:09:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aom40-0006ZS-00 for ipv6@ietf.org; Thu, 05 Feb 2004 11:09:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aom2v-0006SY-00 for ipv6@ietf.org; Thu, 05 Feb 2004 11:08:05 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aom1y-0006N9-00 for ipv6@ietf.org; Thu, 05 Feb 2004 11:07:07 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id ED2C81525D; Fri, 6 Feb 2004 01:07:05 +0900 (JST) Date: Fri, 06 Feb 2004 01:07:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay In-Reply-To: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> References: <200402051555.i15Ft8Zo031842@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=AWL autolearn=no version=2.60 >>>>> On Thu, 5 Feb 2004 17:55:08 +0200, >>>>> Markku Savela said: >> It should be noted that the Neighbor Solicitation is usually not the >> first message. As stated above, the sending node must join the >> solicited-node multicast address prior to sending the Neighbor >> Solicitation and an MLD report message [9] for the multicast address >> should have been sent at that time. Unfortunately, RFC 2710 [9] does >> not request a random delay to avoid race conditions. Thus, if the >> sending node interpreted the "first message" literally, it would not >> impose a delay for the MLD report or for the Neighbor Solicitation, >> making the race conditions worse. This document therefore suggests >> the following workaround: even if the Neighbor Solicitation is not >> the first message, the same random delay should be imposed when the >> sending node knows the Neighbor Solicitation can be synchronized with >> other nodes. This includes the first Neighbor Solicitation after the >> MLD report message in the above case. > This is silly! I thought the reason for the random delay was to > prevent simultaneus packet sending of all hosts on the link, if they > boot up at same time (for example after power fail). > Now, this MLD report is going to be collided (mostly lost anyway), > because every node is sending on the link at same time. > If you are not delaying the MLD, there is really no point in delaying > the DAD either... Sorry, I don't see the point. With the current RFC2710 and RFC2462 in the power failure (or something similar) case, MLD reports are collided, and then NS for DAD are also collied. With the proposed resolution, MLD reports are collided, but NS for DAD are not (depending on the variance of random timers). I proposed the resolution because I thought the former is worse than the latter. So, I'd see your point if you said the change is *not so effective* because we still have collisions. But I don't see why you called it "silly". 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 Feb 5 11:24: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 LAA22122 for ; Thu, 5 Feb 2004 11:24: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 1AomIO-0000ZO-LM for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 11:24:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15GO4NI002186 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 11:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomIO-0000ZB-BJ for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:24: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 LAA22107 for ; Thu, 5 Feb 2004 11:24:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomIN-0000LE-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 11:24:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomHQ-0000Dt-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 11:23:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AomGe-00008n-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 11:22:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomGP-0000EN-JD; Thu, 05 Feb 2004 11:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomFV-0000DC-SV for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 11:21:05 -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 LAA21972 for ; Thu, 5 Feb 2004 11:21:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomFU-00001M-00 for ipv6@ietf.org; Thu, 05 Feb 2004 11:21:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomEY-0007jc-00 for ipv6@ietf.org; Thu, 05 Feb 2004 11:20:06 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AomE4-0007eL-00 for ipv6@ietf.org; Thu, 05 Feb 2004 11:19:36 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id DF2DD1525D for ; Fri, 6 Feb 2004 01:19:35 +0900 (JST) Date: Fri, 06 Feb 2004 01:19:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis issue 276] possible DoS due to the two-hour rule 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 This issue was originally posted by Ken Powell in February 2000: ====================== begin citing ============================ I recently ran some experiments in our lab to see how our IPv6 implementation responds to sudden network topology changes. In the course of these experiments, I caused the prefix from one LAN (LAN A) to be advertised on the other LAN (LAN B). As expected, all communications between LAN A and LAN B died immediately. The hosts on LAN B treated the hosts on LAN A as on-link. I could not restore communications until both the preferred and valid LAN A prefix lifetimes expired on LAN B's host systems. I was able to force the preferred lifetime to zero by reconfiguring a router to send advertisements with near-zero lifetimes, but the valid lifetime couldn't be reduced below two hours. This behavior follows RFC 2462 section 5.5.3: (snip) Obviously I could easily reset IPv6 on each of the three hosts in our lab to clear this problem. I'm concerned about something like this happening on a corporate network where LAN B has hundreds of client nodes connected to servers that reside on LAN A. Assuming nobody bothered to configure ipsec on the network yet, a malicious attacker could disrupt all the clients by sending a router advertisement on LAN B with LAN A's prefix. I know of nothing a network administrator can do to recover in less than two hours short of resetting IPv6 on each of the client systems (probably with reboots). The above rules from RFC 2462 were intended to block a denial of service attack where a single router advertisement could be used to cause all prefixes to expire. It looks like these same rules make the attack I outlined more effective than it otherwise would be. ====================== end citing ============================ The DoS attack itself is actually covered by draft-ietf-send-psreq-04 (4.2.5 Bogus On-Link Prefix), (and the attack itself is not related to 2462,) so my proposed resolution for this was "do nothing". However, we may still want to note this since his another point is that the attack can be more effective due to the "two-hour" rule specified in RFC2462. I re-read the discussion and found someone had pointed out a possible workaround for this is to use proxy-ND. I believe there is an easier workaround (that no one said before): override the prefix (of the other network) with the L-bit being zero. Still, this may be a minor attack that we can ignore in rfc2462bis. So my first question is: should we describe the issue since the attack can be more effective by a rule described in rfc2462(bis)? Or can we simply ignore this case? My next question is: if we should describe the issue, does it make sense to describe either or both of the workarounds? If only one is suitable, which one? My current impression is we can simply ignore this case. 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 Feb 5 11:31: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 LAA22478 for ; Thu, 5 Feb 2004 11:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomPC-0001qX-2l for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 11:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15GV6Dp007091 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 11:31:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomPB-0001qA-Sr for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:31:05 -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 LAA22469 for ; Thu, 5 Feb 2004 11:31:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomPA-00014w-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 11:31:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomOL-0000zb-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 11:30:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AomNW-0000tA-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 11:29:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomNC-000175-0V; Thu, 05 Feb 2004 11:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomMD-00011P-GZ for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 11:28: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 LAA22331 for ; Thu, 5 Feb 2004 11:27:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomMC-0000lq-00 for ipv6@ietf.org; Thu, 05 Feb 2004 11:28:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomLG-0000gu-00 for ipv6@ietf.org; Thu, 05 Feb 2004 11:27:03 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AomKQ-0000bg-00 for ipv6@ietf.org; Thu, 05 Feb 2004 11:26:10 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 112C715263 for ; Fri, 6 Feb 2004 01:26:10 +0900 (JST) Date: Fri, 06 Feb 2004 01:26:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis] still open issues 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 bothering you all by the bunch of messages. This is the last one for now. (I'm afraid I'll be the "winner" of this week:-) The followings are the issues for rfc2462bis that are still open. I don't have particular proposals for them right now (particularly for the last two), and I'm afraid I won't be able to propose resolutions in the next revision of the draft. I noticed that there were discussions in the ML for (some of) the issues, which I've not completely caught up. Anyway, if you have particular opinions on some of them, please speak up by making a separate thread. If you could start the discussion with summarizing past discussions (if any), it would be great. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp ID 275 Many DAD related issues have been discussed, including if it is okay to omit DAD in some environments or if DAD can be replaced with DIID (duplicate interface ID detection). 277 The semantics of the M/O flags is not very clear. 281 It is not very clear if this document always require a 64-bit Interface ID. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 5 13:38: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 NAA27966 for ; Thu, 5 Feb 2004 13:38:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AooOI-0005jS-LR for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 13:38:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15IcIrV022027 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 13:38:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AooOH-0005jA-TY for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 13:38:17 -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 NAA27933 for ; Thu, 5 Feb 2004 13:38:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AooOF-0006xO-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 13:38:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AooNO-0006rV-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 13:37:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AooMc-0006kR-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 13:36:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AooM7-00055Q-26; Thu, 05 Feb 2004 13:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AooLP-00052A-3b for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 13:35: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 NAA27783 for ; Thu, 5 Feb 2004 13:35:17 -0500 (EST) From: shawn.routhier@windriver.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AooLN-0006bl-00 for ipv6@ietf.org; Thu, 05 Feb 2004 13:35:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AooKT-0006W2-00 for ipv6@ietf.org; Thu, 05 Feb 2004 13:34:22 -0500 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx with esmtp (Exim 4.12) id 1AooJX-0006MF-00 for ipv6@ietf.org; Thu, 05 Feb 2004 13:33:23 -0500 Received: from ala-mta03.windriver.com (ala-mta03 [147.11.57.132]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA08058; Thu, 5 Feb 2004 10:32:34 -0800 (PST) Received: by ala-mta03.wrs.com with Internet Mail Service (5.5.2653.19) id <1JHPZ0BA>; Thu, 5 Feb 2004 10:32:41 -0800 Message-ID: <47DD7107796EF94CBE7873B8F31DF2C3CB0642@ala-mail01.wrs.com> To: brian@innovationslab.net, ipv6@ietf.org Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-rfc2011-update-06.txt Date: Thu, 5 Feb 2004 10:32:40 -0800 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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 The list of changes to the previous drafts can be found in the document itself. The biggest recent change was the modification of objects in the ipAddressTable to allow for the creation or modification of rows in the table. There is one outstanding change that has been agreed to but not incorporated. In the 06 revision objects with a syntax of InetAddressPrefixLength were assigned a constraint of (0..128). After some discussion we decided that this was an inappropriate constraint. Instead the InetAddressPrefixLength TC will be modified to have a constraint of (0..2040), which is the maximum number of bits that an InetAddress can have (maximum of 255 bytes). And the constraints will be removed from the InetAddressPrefixLength objects in this MIB. I haven't acted on several other requests as I had only one request form them and they didn't seem to be required changes. These include: Changing the names of the ipv[4 6]InterfaceAdminStatus to be ipv[4 6]InterfaceEnableStatus, as these refer to enabling v4 or v6 on an interface rather than bringing an interface up or down. Removing one of fragOKs, fragFails or fragReqds. With the suggestion calling for the removal of fragReqds as it has been added in this MIB while the others existed in previous RFCs. The text for the objects requires that fragoks + fragfails == fraqreqds and so only two of them are required. Modifying the compliance section to include two compliance statements one for read only and one for full compliance. I have attempted to construct the compliance statements such that read-only is acceptable but have not cast the statements into two separate sets. regards, Shawn A. Routhier >-----Original Message----- >From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On >Behalf Of Brian >Haberman >Sent: Wednesday, February 04, 2004 4:31 PM >To: ipv6@ietf.org >Subject: IPv6 WG Last Call:draft-ietf-ipv6-rfc2011-update-06.txt > > >All, > This starts a 1 week, working group last call on: > > Title : Management Information Base for the Internet > Protocol (IP) > Author(s) : S. Routhier > Filename : draft-ietf-ipv6-rfc2011-update-06.txt > Pages : 133 > Date : 2004-2-2 > >as a Proposed Standard. Substantive comments should be sent to the >mailing list. Editorial comments can be sent to the editor. The Last >Call will end on Tuesday (02/10/2004) at 17:00 EST. > >Regards, >Brian & Bob >IPv6 WG co-chairs > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 5 20:06: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 UAA21574 for ; Thu, 5 Feb 2004 20:06:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AouRo-0006AS-Iw for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 20:06:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1616KDr023702 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 20:06:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AouRo-0006AD-CA for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 20:06:20 -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 UAA21558 for ; Thu, 5 Feb 2004 20:06:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AouRm-00004W-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:06:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AouQp-00001g-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:05:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AouQ1-0007nf-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:04:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AouPa-0005hk-2B; Thu, 05 Feb 2004 20: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 1AouOz-0005gg-F1 for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 20:03:25 -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 UAA21480 for ; Thu, 5 Feb 2004 20:03:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AouOx-0007jr-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:03:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AouO2-0007hc-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:02:27 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AouNn-0007f3-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:02:11 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1611ddO008705; Thu, 5 Feb 2004 17:01:40 -0800 (PST) Received: from lillen (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 i1611bQ26720; Fri, 6 Feb 2004 02:01:37 +0100 (MET) Date: Thu, 5 Feb 2004 17:00:58 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [2462bis] preferred lifetime and the 'two-hour' rule To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > 1) update the preferred lifetime regardless of whether the valid > lifetime is accepted or not wrt the "two-hour" rule > 2) update the preferred lifetime only when the valid lifetime is > accepted > 3) leave this as implementation dependent > The KAME/BSD implementation behaves as option 1. However, it seems to > me that option 2 makes much more sense because a rejected valid > lifetime indicates a possibility of attack and the other parts of > the information may then be bogus as well. And, in fact, item 2 of I'm trying to understand the utility/danger scale here. An operational possibility is that somebody accidentally configures an incorrect prefix in a router and advertises that with the default lifetimes (which are greater than 2 hours). When that is detected a minute later the operator can - drop the valid lifetime on the hosts down to 2 hours (by starting to advertise the prefix with a 2 hour valid lifetime which decrements over time) If we take alt #1 then the preferred lifetime can be immediately dropped to zero, which will stop the incorrect prefix from being used as a source address for new communication (which is good). Does alt #2 mean that the preferred lifetime would be 2 hours? Or that the preferred lifetime could be announced as zero as long as the valid lifetime is annouced with an acceptable value? I think you are suggesting the second one. And on the danger scale, with alt. #2 an on-link attacker can cause immediate deprecation by advertising the prefix with a valid lifetime = 3 hours and a preferred lifetime = 0, so I don't think it makes a difference whether we choose #1 or #2. I must be missing something. 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 Feb 5 20:37: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 UAA22396 for ; Thu, 5 Feb 2004 20:37: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 1Aouvm-0007hY-Tt for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 20:37:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i161bIjw029601 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 20:37:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aouvm-0007hD-Hi for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 20:37:18 -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 UAA22381 for ; Thu, 5 Feb 2004 20:37:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aouvk-000170-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:37:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aouun-00015i-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:36:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aouuk-00014r-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:36:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AouuY-0007Iq-Hn; Thu, 05 Feb 2004 20:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoutq-0007Hc-3f for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 20:35:18 -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 UAA22321 for ; Thu, 5 Feb 2004 20:35:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoutn-00013x-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:35:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aousp-00012G-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:34:16 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1Aours-0000zw-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:33:16 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i161WidO018676; Thu, 5 Feb 2004 17:32:45 -0800 (PST) Received: from lillen (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 i161WgQ29555; Fri, 6 Feb 2004 02:32:43 +0100 (MET) Date: Thu, 5 Feb 2004 17:32:03 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [rfc2462bis issue 278] 2462bis for "routers" To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > Additionally, adopting this definition also opens up the possibility > of a "half-host, half-router" node, like: > > ------(I1)Node(I2)------- > (I3) > | > | > > where I1 and I2 are "normal" interfaces for which the node is acting > as a router, and I3 is an interface to a "back-door" for which the > node is acting as a host. This node can accept a router advertisement > on interface I3 to configure an address or even configure a "default > route" to I3 (though the latter part is out of scope of 2462bis). > > Should we, if adopting the per-interface definition, explicitly > mention this type of configuration in rfc2462bis? Is there a proposed definition for the per-interface router? I'm asking because we want to avoid having "forward from" and "forward to" interfaces - if the node is a router on a interface it should be able to forward packets both from and to that interface. And if a node is not a router on an interface it should neither forward packets (not explicitly addressed to itself) from that interface nor to that interface. If we decide to add the per-interface definition I'd suggest actually making that a separate document (which can be folded into future RFC 2460 revisions) instead of "hiding it" in some other document. I think your above concern about the default route on I3 can be reduced to a previously unspecified problem; the RFC 2461 silence on multihomed nodes. Per RFC 2461 the default router list is per interface thus there would not be any harm (in the conceptual model) to add that default route on a node that has other interfaces which are router interfaces. If one were to specify how RFC 2461 (and 62) apply to multihomed nodes then one would be faced with this issue. Of course, the above is a bit dishonest because 1) many implementations support multiple interface with 2461 even though the specification is silent about them and 2) I suspect many of those implementations have a global - and not per-interface - default router list. So do we or do we not want to 1. specify the per-interface router definition 2. specify how RFC 2461 (and 62) behave on a multihomed node 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 Feb 5 20:46: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 UAA22827 for ; Thu, 5 Feb 2004 20:46:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aov4Z-0000QO-SC for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 20:46:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i161kNEE001626 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 20:46:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aov4Z-0000Q9-Nh for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 20:46: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 UAA22767 for ; Thu, 5 Feb 2004 20:46:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aov4X-0001bp-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:46:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aov3W-0001X3-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:45:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aov2Y-0001Ta-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:44:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aov2K-0008Fn-LO; Thu, 05 Feb 2004 20:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aov1h-0008AV-ND for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 20:43: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 UAA22610 for ; Thu, 5 Feb 2004 20:43:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aov1f-0001RE-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:43:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aov0g-0001Op-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:42:23 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1Aov0R-0001Ma-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:42:07 -0500 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 i161fQ0J011503; Thu, 5 Feb 2004 17:41:27 -0800 (PST) Received: from lillen (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 i161fOQ01327; Fri, 6 Feb 2004 02:41:24 +0100 (MET) Date: Thu, 5 Feb 2004 17:40:44 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [2462bis] preferred lifetime and the 'two-hour' rule To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Francis Dupont , 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.0 required=5.0 tests=none autolearn=no version=2.60 > So my first point is that we should clearly specify how the preferred > lifetime is updated in 5.5.3 e) of rfc2462bis, mainly for normal > cases. My second point is what we should do about the preferred > lifetime when the valid lifetime is ignored due to the two-hour rule. > > My suggestion to the first point is that the preferred lifetime should > basically be reset to the advertised value (of course!). Yes! > My suggestion to the second point is that we should also ignore the > preferred lifetime if the valid lifetime is ignored due to the > two-hour rule. In my example of the incorrectly advertised prefix that the network admin wants to get rid of this actually makes it a bit harder. If the network admin advertised the prefix with valid=3 hours (decrementing in real time) and preferred=0 then if I've taken my laptop to a meeting for 1.5 hours when I come back the laptop will have StoredValidLifetime=7 days (whatever the original number was) StoredPreferredLifetime=1 day (whatever the original was) and receive packets with valid=1.5 hours preferred=0 and as a result the lifetimes in the advertisement will be ignored and the (incorrect) prefix will remain preferred for a day. This is worse than being able to move the preferred lifetime to zero (thereby deprecating the prefix for future communication). I think following what is in the router advertisement should always be done (in order to give the network admin control) except in very specific cases. There is a specific case to ignore sudden drops in the valid lifetime but I haven't seen an equally strong argument for ignoring the preferred lifetime. > This issue was originally posted by Ken Powell in February 2000: > I was able to force the preferred lifetime to zero by reconfiguring > a router to send advertisements with near-zero lifetimes, but the > valid lifetime couldn't be reduced below two hours. Question: did advertizing the prefix with both lifetimes = 0 not mean that the hosts stopped thinking that the prefix was on-link? The intent was that the 2-hour rule only apply to address autoconfiguration and not to the on-link'ness of the prefixes. That is why it is specified in RFC 2462 and RFC 2461 is silent on the issue. Thus advertising an existing prefix with both lifetimes=0 should remove it from the on-link prefix list (RFC 2461) but keep the addresses as deprecated from 2 hours (RFC 2462). Perhaps this is something we should look into clarifying? 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 Feb 5 20:46: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 UAA22829 for ; Thu, 5 Feb 2004 20:46:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aov4Z-0000Q3-A7 for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 20:46:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i161kNCu001610 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 20:46:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aov4Z-0000Pt-53 for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 20:46: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 UAA22764 for ; Thu, 5 Feb 2004 20:46:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aov4W-0001bk-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:46:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aov3V-0001Wu-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:45:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aov2Y-0001TZ-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:44:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aov2I-0008BA-54; Thu, 05 Feb 2004 20:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aov1f-0008AQ-V8 for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 20:43:24 -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 UAA22607 for ; Thu, 5 Feb 2004 20:43:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aov1d-0001Qw-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:43:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aov0f-0001OU-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:42:21 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1Aov0E-0001Mj-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:41:54 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i161fqi5001329; Thu, 5 Feb 2004 18:41:53 -0700 (MST) Received: from lillen (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 i161foQ01353; Fri, 6 Feb 2004 02:41:50 +0100 (MET) Date: Thu, 5 Feb 2004 17:41:10 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt To: Bob Hinden Cc: Pekka Savola , ipv6@ietf.org In-Reply-To: "Your message with ID" <4.3.2.7.2.20040203111552.02f16710@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Is it only I that find it odd that talking about Multicast DNS is viewed to be in-scope for this document, while talking about the applicability issues for the addresses *defined by this document* is stated to be out of scope?? Erik > > For future study names with Local IPv6 addresses may be resolved > > inside of the site using dynamic naming systems such as Multicast > > DNS. > > > >==> this seems irrelevant and should be removed; above, it already > >states someting general about local naming systems. > > I don't see it doing any harm either. > >==> Add to disadvantages: > > > > - Instead of using global unicast addresses inside the sites, the > > sites may be tempted to start using Local IPv6 addresses excessively, > > instead of using global unicast addresses and reachability restrictions > > such as firewalls or access control lists > > I think this is out of scope for 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 Feb 5 20:57: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 UAA23217 for ; Thu, 5 Feb 2004 20:57: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 1AovF9-00019M-4b for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 20:57:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i161vJtm004414 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 20:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AovF9-000197-07 for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 20:57: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 UAA23188 for ; Thu, 5 Feb 2004 20:57:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AovF6-0002Ea-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:57:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AovE9-0002Az-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:56:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AovDA-00027t-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 20:55:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AovCx-0000o3-Vj; Thu, 05 Feb 2004 20:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AovCF-0000jz-VW for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 20:54:20 -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 UAA23116 for ; Thu, 5 Feb 2004 20:54:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AovCD-00025E-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:54:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AovBH-00022s-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:53:20 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AovAO-0001yP-00 for ipv6@ietf.org; Thu, 05 Feb 2004 20:52:24 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i161ppM14556; Thu, 5 Feb 2004 17:51:51 -0800 X-mProtect: <200402060151> 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 smtpdXUSRQb; Thu, 05 Feb 2004 17:51:46 PST Message-ID: <4022F33E.9000407@iprg.nokia.com> Date: Thu, 05 Feb 2004 17:51:58 -0800 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: Erik Nordmark CC: jinmei@isl.rdc.toshiba.co.jp, ipv6@ietf.org Subject: Re: [rfc2462bis issue 278] 2462bis for "routers" References: 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 Erik Nordmark wrote: >So do we or do we not want to >1. specify the per-interface router definition >2. specify how RFC 2461 (and 62) behave on a multihomed node > Well, from RFC 2460 we have: + router - a node that forwards IPv6 packets not explicitly + addressed to itself. [See Note below]. + ... + Note: it is possible, though unusual, for a device with multiple + interfaces to be configured to forward non-self-destined packets + arriving from some set (fewer than all) of its interfaces, and to + discard non-self-destined packets arriving from its other interfaces. + Such a device must obey the protocol requirements for routers when + receiving packets from, and interacting with neighbors over, the + former (forwarding) interfaces. It must obey the protocol + requirements for hosts when receiving packets from, and interacting + with neighbors over, the latter (non-forwarding) interfaces. and from RFC 2461 we have: + 6.2.2. Becoming An Advertising Interface + + The term "advertising interface" refers to any functioning and + enabled multicast interface that has at least one unicast IP address + assigned to it and whose corresponding AdvSendAdvertisements flag is + TRUE. A router MUST NOT send Router Advertisements out any interface + that is not an advertising interface. Is there really anything more that needs to be said? Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 5 21:27: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 VAA24439 for ; Thu, 5 Feb 2004 21:27:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoviI-0002qD-5B for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 21:27:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i162RQLD010920 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 21:27:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoviH-0002pv-Jq for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 21:27:25 -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 VAA24365 for ; Thu, 5 Feb 2004 21:27:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoviE-0003zl-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 21:27:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aovgz-0003kp-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 21:26:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AovfJ-0003Tn-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 21:24:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aovez-0002FA-Ea; Thu, 05 Feb 2004 21:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoveL-0002Cf-9v for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 21:23:21 -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 VAA23819 for ; Thu, 5 Feb 2004 21:23:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoveI-0003M9-00 for ipv6@ietf.org; Thu, 05 Feb 2004 21:23:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AovdN-0003JQ-00 for ipv6@ietf.org; Thu, 05 Feb 2004 21:22:21 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AovcX-0003G9-00 for ipv6@ietf.org; Thu, 05 Feb 2004 21:21:29 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i162KwdO004345; Thu, 5 Feb 2004 18:20:59 -0800 (PST) Received: from lillen (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 i162KtQ02018; Fri, 6 Feb 2004 03:20:56 +0100 (MET) Date: Thu, 5 Feb 2004 18:20:16 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [rfc2462bis issue 278] 2462bis for "routers" To: Fred Templin Cc: Erik Nordmark , jinmei@isl.rdc.toshiba.co.jp, ipv6@ietf.org In-Reply-To: "Your message with ID" <4022F33E.9000407@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > + router - a node that forwards IPv6 packets not explicitly > + addressed to itself. [See Note below]. > + ... > + Note: it is possible, though unusual, for a device with multiple > + interfaces to be configured to forward non-self-destined packets > + arriving from some set (fewer than all) of its interfaces, and to > + discard non-self-destined packets arriving from its other interfaces. > + Such a device must obey the protocol requirements for routers when > + receiving packets from, and interacting with neighbors over, the > + former (forwarding) interfaces. It must obey the protocol > + requirements for hosts when receiving packets from, and interacting > + with neighbors over, the latter (non-forwarding) interfaces. > Is there really anything more that needs to be said? Is such a box has IFA and IFB as forwarding interfaces and IFC as a non-forwarding interface, how should it behave when a packet is received on IFA addressed to an on-link destination on IFC? (Note the above text talks only about "forwarding from" and IFA is a forwarding interface.) I think the right answer is that it should ignore any "routes" related to IFC when forwarding packets i.e. it needs to follow the subset of the forwarding table that applies to IFA and IFB. But no document states that. As pointed out numerous times, RFC 2461 doesn't say what a multihomed node should do. Example cases are: - sending to a link-local destination; should it send neighbor solicitations out all interfaces? should it require that the application specify the scope id? - when there are routers, the routers do not advertise on-link prefixes or they do advertize and the destination does not match an on-link prefix, what should a multihomed host do when sending a packet to a non-link-local address? should it send the packet to a default router on each interface? if not, how does it select which one? (the router preferences draft might be part of this answer) - when there are default routers on some interfaces but not on all, does that change any of the answers to the above questions? See also appendix A in RFC 2461. 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 Feb 5 21:49: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 VAA25215 for ; Thu, 5 Feb 2004 21:49:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aow3d-0004Zb-C7 for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 21:49:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i162nThA017573 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 21:49:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aow3d-0004ZM-7C for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 21:49: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 VAA25212 for ; Thu, 5 Feb 2004 21:49:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aow3a-0005M2-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 21:49:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aow2i-0005Jb-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 21:48:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aow2Q-0005GR-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 21:48:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aow2E-0004Dt-IC; Thu, 05 Feb 2004 21:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aow1c-0004D5-Go for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 21:47:24 -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 VAA25093 for ; Thu, 5 Feb 2004 21:47:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aow1Z-0005Em-00 for ipv6@ietf.org; Thu, 05 Feb 2004 21:47:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aow0g-0005D3-00 for ipv6@ietf.org; Thu, 05 Feb 2004 21:46:26 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aow0L-0005Au-00 for ipv6@ietf.org; Thu, 05 Feb 2004 21:46:05 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C731E1525D; Fri, 6 Feb 2004 11:46:04 +0900 (JST) Date: Fri, 06 Feb 2004 11:46:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipv6@ietf.org Subject: Re: [2462bis] preferred lifetime and the 'two-hour' rule 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, 5 Feb 2004 17:40:44 -0800 (PST), >>>>> Erik Nordmark said: >> My suggestion to the second point is that we should also ignore the >> preferred lifetime if the valid lifetime is ignored due to the >> two-hour rule. > In my example of the incorrectly advertised prefix that the network admin > wants to get rid of this actually makes it a bit harder. > If the network admin advertised the prefix with valid=3 hours (decrementing > in real time) and preferred=0 then if I've taken my laptop to > a meeting for 1.5 hours when I come back the laptop will have > StoredValidLifetime=7 days (whatever the original number was) > StoredPreferredLifetime=1 day (whatever the original was) > and receive packets with > valid=1.5 hours > preferred=0 > and as a result the lifetimes in the advertisement will be ignored and the > (incorrect) prefix will remain preferred for a day. > This is worse than being able to move the preferred lifetime to zero > (thereby deprecating the prefix for future communication). Hmm, good point. The above story can happen with the suggested resolution and I agree that this is worse. > I think following what is in the router advertisement should always be done > (in order to give the network admin control) except in very specific cases. > There is a specific case to ignore sudden drops in the valid lifetime > but I haven't seen an equally strong argument for ignoring the preferred > lifetime. Okay, I reconsidered this issue. (For reference, I've copied the options below I brought up before:) 1) update the preferred lifetime regardless of whether the valid lifetime is accepted or not wrt the "two-hour" rule 2) update the preferred lifetime only when the valid lifetime is accepted If we take option 1, the preferred lifetime is always updated in non DoS cases. In a DoS case, the preferred lifetime can be set to a very short time (including 0). But this is not very harmful. If we take option 2, the preferred lifetime can be accidentally kept at a large value in non DoS cases, which is bad. In a DoS case, we can avoid the DoS for the preferred lifetime *if the attack also includes a too short valid lifetime*. The attack for the preferred lifetime can still happen if it specifies a large value for the valid lifetime. So, I now think the correct option is 1. Unless someone makes a different point, I'll revise the text accordingly. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 5 22:07: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 WAA25694 for ; Thu, 5 Feb 2004 22:07:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AowKw-0005mw-PD for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 22:07:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1637MDX022242 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 22:07:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AowKv-0005me-QU for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 22:07:21 -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 WAA25651 for ; Thu, 5 Feb 2004 22:07:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AowKs-00060v-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 22:07:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AowJv-0005xp-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 22:06:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AowJ2-0005v9-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 22:05:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AowIh-00058Y-UF; Thu, 05 Feb 2004 22:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AowI2-00056i-Gv for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 22:04:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25521 for ; Thu, 5 Feb 2004 22:04:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AowHz-0005sF-00 for ipv6@ietf.org; Thu, 05 Feb 2004 22:04:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AowH4-0005qn-00 for ipv6@ietf.org; Thu, 05 Feb 2004 22:03:23 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AowGI-0005pJ-00 for ipv6@ietf.org; Thu, 05 Feb 2004 22:02:35 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1546115263; Fri, 6 Feb 2004 12:02:35 +0900 (JST) Date: Fri, 06 Feb 2004 12:02:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipv6@ietf.org Subject: [rfc2462bis issue 276] possible DoS due to the two-hour rule (Re: [2462bis] preferred lifetime and the 'two-hour' rule) 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 I changed the subject because I believe this is a separate issue. >>>>> On Thu, 5 Feb 2004 17:40:44 -0800 (PST), >>>>> Erik Nordmark said: >> This issue was originally posted by Ken Powell in February 2000: >> I was able to force the preferred lifetime to zero by reconfiguring >> a router to send advertisements with near-zero lifetimes, but the >> valid lifetime couldn't be reduced below two hours. > Question: did advertizing the prefix with both lifetimes = 0 not > mean that the hosts stopped thinking that the prefix was on-link? Ahh, another good catch. RFC2461 clearly says this point: Stateless address autoconfiguration [ADDRCONF] may in some circumstances increase the Valid Lifetime of a prefix or ignore it completely in order to prevent a particular denial of service attack. However, since the effect of the same denial of service targeted at the on-link prefix list is not catastrophic (hosts would send packets to a default router and receive a redirect rather than sending packets directly to a neighbor) the Neighbor Discovery protocol does not impose such a check on the prefix lifetime values. (Section 6.3.4) So, this is actually a non-issue. And, in fact, I've implemented the prefix information processing this way, but I totally forgot it... We may probably want to add a similar note in rfc2462bis, but my current impression is that the note in RFC2461 is enough. So, I'll basically do nothing on this. 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 Feb 5 22:33: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 WAA26092 for ; Thu, 5 Feb 2004 22:33:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aowk7-0007pj-Pf for ipv6-archive@odin.ietf.org; Thu, 05 Feb 2004 22:33:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i163XN21030105 for ipv6-archive@odin.ietf.org; Thu, 5 Feb 2004 22:33:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aowk7-0007pU-Jn for ipv6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 22:33: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 WAA26036 for ; Thu, 5 Feb 2004 22:33:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aowk4-0006m4-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 22:33:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aowj6-0006jF-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 22:32:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AowiH-0006hg-00 for ipv6-web-archive@ietf.org; Thu, 05 Feb 2004 22:31:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aowhr-0007LE-I9; Thu, 05 Feb 2004 22:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AowhC-0007KB-KR for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 22:30:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25962 for ; Thu, 5 Feb 2004 22:30:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aowh9-0006eg-00 for ipv6@ietf.org; Thu, 05 Feb 2004 22:30:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AowgC-0006dK-00 for ipv6@ietf.org; Thu, 05 Feb 2004 22:29:20 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1AowfX-0006cG-00 for ipv6@ietf.org; Thu, 05 Feb 2004 22:28:39 -0500 Received: from localhost ([130.194.13.84]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L6A8H1Z42Y905CZO@vaxh.its.monash.edu.au> for ipv6@ietf.org; Fri, 6 Feb 2004 13:59:37 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 316DC39C004; Fri, 06 Feb 2004 13:59:37 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 1ECBE2DC017; Fri, 06 Feb 2004 13:59:37 +1100 (EST) Date: Fri, 06 Feb 2004 13:59:36 +1100 From: Greg Daley Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay To: =?ISO-8859-1?Q?JINMEI_Tatuya_/_=3F=3F=3F=3F?= Cc: Markku Savela , ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <40230318.7000101@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> 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 Jinmei, JINMEI Tatuya / ???? wrote: >>>>>>On Thu, 5 Feb 2004 17:55:08 +0200, >>>>>>Markku Savela said: >>>>> > >>>It should be noted that the Neighbor Solicitation is usually not the >>>first message. As stated above, the sending node must join the >>>solicited-node multicast address prior to sending the Neighbor >>>Solicitation and an MLD report message [9] for the multicast address >>>should have been sent at that time. Unfortunately, RFC 2710 [9] does >>>not request a random delay to avoid race conditions. Thus, if the >>>sending node interpreted the "first message" literally, it would not >>>impose a delay for the MLD report or for the Neighbor Solicitation, >>>making the race conditions worse. This document therefore suggests >>>the following workaround: even if the Neighbor Solicitation is not >>>the first message, the same random delay should be imposed when the >>>sending node knows the Neighbor Solicitation can be synchronized with >>>other nodes. This includes the first Neighbor Solicitation after the >>>MLD report message in the above case. >> > >>This is silly! I thought the reason for the random delay was to >>prevent simultaneus packet sending of all hosts on the link, if they >>boot up at same time (for example after power fail). > > >>Now, this MLD report is going to be collided (mostly lost anyway), >>because every node is sending on the link at same time. > > >>If you are not delaying the MLD, there is really no point in delaying >>the DAD either... > > > Sorry, I don't see the point. With the current RFC2710 and RFC2462 in > the power failure (or something similar) case, MLD reports are > collided, and then NS for DAD are also collied. > > With the proposed resolution, MLD reports are collided, but NS for DAD > are not (depending on the variance of random timers). > > I proposed the resolution because I thought the former is worse than > the latter. So, I'd see your point if you said the change is *not so > effective* because we still have collisions. But I don't see why you > called it "silly". The simultaneous transmission issue is principally a reliability issue. There is some chance on certain link-layers that packets will be significantly delayed or lost when simulataneous transmission occurs. There are very few reasons why one would require MLD reports on link local solicited nodes addresses. The only existing reasons to do MLD on these addresses are so that MLD proxies, and snooping switchescan request multicast transport for those addresses. Unless this is performed correctly, the node performing DAD will not receive DAD defence NA's, even if the DAD NS is sent with random delay. Since there is no random delay with MLD, the reliability issue still exists in these environments. I believe that this may have been what what Markku was trying to communicate. I do not think we should be modifying every node to suit MLD snooping, but it is possible to perhaps suggest a random delay for _both_ the MLD report _and_ the DAD NS (but no explicit delay between them). The DAD NS must come after the MLD report though. In this case, the node could start listenting to the group before sending an MLD report. This is different to MLD/MLDv2, but will not hurt, since the DAD NS is the principle trigger for multicast traffic to that solicited nodes' address. In snooping environments, the node wouldn't get any messages to the group until the MLD report was sent. In any case, it avoids the simultaneous transmission problem. In some systems, the ordering of MLD-report and NS cannot be guaranteed on the output queue. Before transmitting the DAD NS, the node should ensure that either there has been sufficient time between MLD transmission and NS, in order to guarantee packet ordering on the link. Alternatively, explicit indication that transmission has occurred would achieve the same purpose. Greg Daley -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 01:12: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 BAA00629 for ; Fri, 6 Feb 2004 01:12:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AozE6-0000qG-BH for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 01:12:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i166CUsX003233 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 01:12:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AozE6-0000q1-4g for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 01:12:30 -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 BAA00602 for ; Fri, 6 Feb 2004 01:12:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AozE3-0006Gf-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 01:12:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AozD8-0006Di-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 01:11:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AozCK-0006BS-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 01:10:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AozBi-0008SH-8y; Fri, 06 Feb 2004 01:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AozBD-0008PY-D1 for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 01:09:31 -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 BAA00522 for ; Fri, 6 Feb 2004 01:09:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AozBA-00068G-00 for ipv6@ietf.org; Fri, 06 Feb 2004 01:09:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AozAD-00065v-00 for ipv6@ietf.org; Fri, 06 Feb 2004 01:08:30 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1Aoz9l-00062c-00 for ipv6@ietf.org; Fri, 06 Feb 2004 01:08:01 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 22:07:33 -0800 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Feb 2004 22:07:37 -0800 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.1069); Thu, 5 Feb 2004 22:07:27 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 22:07:30 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 5 Feb 2004 22:07:33 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Date: Thu, 5 Feb 2004 22:07:25 -0800 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Thread-Index: AcPsUtpS+aiha09dREmIUTMqlLzTVAAIkG7Q From: "Christian Huitema" To: "Bob Hinden" Cc: X-OriginalArrivalTime: 06 Feb 2004 06:07:33.0736 (UTC) FILETIME=[82DE0E80:01C3EC77] 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 what I have read so far, the monetary payment appears to be one of the weakest point of the proposal. I suggest that the monetary consideration in the draft be removed, and that the precise method used to implement the registration be left to the registry. Specifically, I suggest in section " 3.2.1 Centrally Assigned Global IDs" to replace the phrase: - One time non-refundable allocation fee per allocation that is affordable by a broad spectrum of end users when considered globally. By: - Allocation on a permanent basis, without any need for renewal and without any procedure for de-allocation. I would also delete the phrase: "They should also accept a variety of payment methods and currencies." Then, I would replace the paragraph: The reason for the use of an allocation fee for each prefix is to allow this service function to operate on a cost recovery basis. An acknowledged side-effect of such a mechanism is that it provides some impediment to any hoarding of the these allocations. The consideration of affordability is intended to keep the cost low enough so as not create a barrier to anyone needing one. The charge is one time to eliminate the need for an ongoing relationship with the allocation authority, while acknowledging the service costs for both the registration function and the enduring escrow service. The charge is non-refundable in order to keep overhead low. By a more neutral: The allocation service should include sufficient provisions to avoid hoarding of numbers. This can be accomplished by various ways, e.g.,=20 requiring an exchange of documents, a verbal contact, or a proof that the request is on behalf of a human rather than a machine. The service may charge a small fee in order to cover its costs, but the fee should be low enough to not create a barrier to anyone needing one. The precise mechanisms should be decided by the registration authority. Doing these edits will clearly express our intent, without dictating how the registration service chooses to operate. For all we know, we may find a volunteer who runs the service for free. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 01:16: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 BAA00827 for ; Fri, 6 Feb 2004 01:16:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AozHD-0001PB-4O for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 01:15:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i166Fh66005388 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 01:15:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AozHC-0001Oo-Un for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 01:15:43 -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 BAA00815 for ; Fri, 6 Feb 2004 01:15:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AozHA-0006Tt-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 01:15:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AozG6-0006Qk-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 01:14:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AozFg-0006Ns-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 01:14:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AozFZ-0000yr-GX; Fri, 06 Feb 2004 01:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AozFA-0000wY-03 for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 01:13:36 -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 BAA00700 for ; Fri, 6 Feb 2004 01:13:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AozF7-0006M1-00 for ipv6@ietf.org; Fri, 06 Feb 2004 01:13:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AozEH-0006IW-00 for ipv6@ietf.org; Fri, 06 Feb 2004 01:12:42 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AozDQ-0006Bs-00 for ipv6@ietf.org; Fri, 06 Feb 2004 01:11:48 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 22:09:35 -0800 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Feb 2004 22:11:18 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 22:11:13 -0800 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); Thu, 5 Feb 2004 22:11:17 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 5 Feb 2004 22:11:18 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Date: Thu, 5 Feb 2004 22:11:14 -0800 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Thread-Index: AcPsUtpS+aiha09dREmIUTMqlLzTVAAJMoLA From: "Christian Huitema" To: "Erik Nordmark" , "Bob Hinden" Cc: "Pekka Savola" , X-OriginalArrivalTime: 06 Feb 2004 06:11:18.0367 (UTC) FILETIME=[08C206F0:01C3EC78] 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 > Is it only I that find it odd that talking about Multicast DNS > is viewed to be in-scope for this document, while talking about the > applicability issues for the addresses *defined by this document* > is stated to be out of scope?? I agree with Erik on this point. > > > For future study names with Local IPv6 addresses may be resolved > > > inside of the site using dynamic naming systems such as Multicast > > > DNS. > > > > > >=3D=3D> this seems irrelevant and should be removed; above, it = already > > >states someting general about local naming systems. > > > > I don't see it doing any harm either. When in doubt, leave it out. It does not bring anything to the document, and any non-trivial assertion about operation of the DNS ends up creating controversies. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 01:54: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 BAA01509 for ; Fri, 6 Feb 2004 01:54: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 1Aozrq-0003CR-Ps for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 01:53:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i166rY39012293 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 01:53:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aozrq-0003CC-Im for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 01:53:34 -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 BAA01502 for ; Fri, 6 Feb 2004 01:53:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aozrn-00007J-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 01:53:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aozqq-00004r-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 01:52:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AozqZ-00002Q-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 01:52:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AozqL-0002u8-Sv; Fri, 06 Feb 2004 01: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 1Aozpu-0002t0-F6 for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 01:51:34 -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 BAA01449 for ; Fri, 6 Feb 2004 01:51:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aozpr-00001l-00 for ipv6@ietf.org; Fri, 06 Feb 2004 01:51:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aozp0-0007nS-00 for ipv6@ietf.org; Fri, 06 Feb 2004 01:50:39 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aozoa-0007jT-00 for ipv6@ietf.org; Fri, 06 Feb 2004 01:50:13 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i166nY905681; Fri, 6 Feb 2004 08:49:34 +0200 Date: Fri, 6 Feb 2004 08:49:34 +0200 (EET) From: Pekka Savola To: Bob Hinden cc: ipv6@ietf.org Subject: implemenation req. vs operational advice [Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt] In-Reply-To: <4.3.2.7.2.20040204092106.03afdc28@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 4 Feb 2004, Bob Hinden wrote: > > > I agree this could be stated better. I think it would be good to > > > change it to "Any router that is used between sites....", as it is > > > not the routing protocols doing the filtering, but the router based > > > on it's configuration. > > > >But then it's an operational guidance, right? Maybe not uppercase > >material? > > I don't have any problem making this change, but I don't understand > the difference between upper and lower case in these sections. [and:] > > > Routers that maintain peering arrangements between Autonomous > > > Systems throughout the Internet SHOULD obey the recommendations for > > > site border routers unless configured otherwise. > > > >Ok, that's understandable. But again, why use an uppercase SHOULD > >keyword? This is a requirement for operators, not a protocol > >interoperability issue? > > As above, please explain the difference? As far as I can see, upper-case MUST/SHOULDs are something implementations should do. In addition to those, specifications often also include some language giving advice (or even stronger than that) to operators of the products based on those implementations what they should do. IMHO, the document should be very clear which statements are "operator advice/requirements" which "implementation requirements".. because the implementors (from whom we'll be collecting implementation reports etc.) *cannot* ensure that such advice/ops-reqs are followed -- if they could, it would be an implementation requirement. One way to achieve this would be to describe operational aspects in a separate section (e.g., "Operational Considerations and Requirements") which should make this clearer. Another way could be avoiding upper-case keywords and stating clearly that these are requirements or advice placed on the operators of the specification, not the implementers. Hope this clarified how I see the difference between an implementation requirement and operational advice. -- 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 Feb 6 05:13: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 FAA18907 for ; Fri, 6 Feb 2004 05:13:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2yS-0006bz-SU for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 05:12:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16ACaU2025409 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 05:12:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2yS-0006bk-El for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 05:12:36 -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 FAA18864 for ; Fri, 6 Feb 2004 05:12:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2yP-0000zu-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 05:12:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap2xQ-0000wM-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 05:11:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2wZ-0000sy-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 05:10:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2w0-0005zW-Ar; Fri, 06 Feb 2004 05:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2vd-0005u4-SI for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 05:09:41 -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 FAA18759 for ; Fri, 6 Feb 2004 05:09:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2va-0000pw-00 for ipv6@ietf.org; Fri, 06 Feb 2004 05:09:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap2ub-0000n8-00 for ipv6@ietf.org; Fri, 06 Feb 2004 05:08:38 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2uO-0000kZ-00 for ipv6@ietf.org; Fri, 06 Feb 2004 05:08:24 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i16A7qS25155; Fri, 6 Feb 2004 02:07:52 -0800 X-mProtect: <200402061007> Nokia Silicon Valley Messaging Protection Received: from merced.iprg.nokia.com (205.226.12.76, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdojNKWT; Fri, 06 Feb 2004 02:07:50 PST Message-Id: <4.3.2.7.2.20040206020235.022a7658@127.0.0.1> X-Sender: hinden@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 02:04:35 -0800 To: Erik Nordmark From: Bob Hinden Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Cc: ipv6@ietf.org In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20040203111552.02f16710@mailhost.iprg.nokia.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 Erik, At 05:41 PM 2/5/2004, Erik Nordmark wrote: >Is it only I that find it odd that talking about Multicast DNS >is viewed to be in-scope for this document, while talking about the >applicability issues for the addresses *defined by this document* >is stated to be out of scope?? Reasonable point. I will remove the reference to Multicast DNS. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 05:14: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 FAA18976 for ; Fri, 6 Feb 2004 05:14:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2zZ-0006da-4I for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 05:13:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16ADjpv025515 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 05:13:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2zX-0006dS-RE for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 05:13:43 -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 FAA18967 for ; Fri, 6 Feb 2004 05:13:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2zU-00015D-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 05:13:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap2yc-00011t-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 05:12:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2xx-0000y7-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 05:12:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2xu-0006Kg-Ho; Fri, 06 Feb 2004 05:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2xV-0006Jd-Lt for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 05:11:37 -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 FAA18828 for ; Fri, 6 Feb 2004 05:11:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2xS-0000we-00 for ipv6@ietf.org; Fri, 06 Feb 2004 05:11:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap2wf-0000ts-00 for ipv6@ietf.org; Fri, 06 Feb 2004 05:10:45 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2vr-0000nZ-00 for ipv6@ietf.org; Fri, 06 Feb 2004 05:09:56 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i16A9GH27308; Fri, 6 Feb 2004 02:09:16 -0800 X-mProtect: <200402061009> Nokia Silicon Valley Messaging Protection Received: from merced.iprg.nokia.com (205.226.12.76, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdcG7J15; Fri, 06 Feb 2004 02:09:12 PST Message-Id: <4.3.2.7.2.20040206020521.05159798@127.0.0.1> X-Sender: hinden@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 02:05:58 -0800 To: Christian Huitema From: Bob Hinden Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Cc: Erik Nordmark , "Bob Hinden" , Pekka Savola , 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Christian, At 10:11 PM 2/5/2004, Christian Huitema wrote: > > Is it only I that find it odd that talking about Multicast DNS > > is viewed to be in-scope for this document, while talking about the > > applicability issues for the addresses *defined by this document* > > is stated to be out of scope?? > >I agree with Erik on this point. > > > > > For future study names with Local IPv6 addresses may be >resolved > > > > inside of the site using dynamic naming systems such as >Multicast > > > > DNS. > > > > > > > >==> this seems irrelevant and should be removed; above, it already > > > >states someting general about local naming systems. > > > > > > I don't see it doing any harm either. > >When in doubt, leave it out. It does not bring anything to the document, >and any non-trivial assertion about operation of the DNS ends up >creating controversies. Agreed. I will remove it. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 05: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 FAA19136 for ; Fri, 6 Feb 2004 05:18: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 1Ap33M-00070m-KL for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 05:17:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16AHeO5026949 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 05:17:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap33M-00070a-20 for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 05:17:40 -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 FAA19129 for ; Fri, 6 Feb 2004 05:17:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap33I-0001Kv-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 05:17:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap32U-0001IQ-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 05:16:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap31z-0001Ez-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 05:16:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap31n-0006iG-0Z; Fri, 06 Feb 2004 05:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap31M-0006hY-Ax for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 05:15:36 -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 FAA19023 for ; Fri, 6 Feb 2004 05:15:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap31J-0001CN-00 for ipv6@ietf.org; Fri, 06 Feb 2004 05:15:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap30M-00019O-00 for ipv6@ietf.org; Fri, 06 Feb 2004 05:14:35 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2zY-00012k-00 for ipv6@ietf.org; Fri, 06 Feb 2004 05:13:44 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i16ADCL05387; Fri, 6 Feb 2004 02:13:12 -0800 X-mProtect: <200402061013> Nokia Silicon Valley Messaging Protection Received: from merced.iprg.nokia.com (205.226.12.76, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdm1fWmM; Fri, 06 Feb 2004 02:13:10 PST Message-Id: <4.3.2.7.2.20040206020810.022a7658@127.0.0.1> X-Sender: hinden@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 02:09:56 -0800 To: Christian Huitema From: Bob Hinden Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Cc: Bob Hinden , ipv6@ietf.org 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Christian, At 10:07 PM 2/5/2004, Christian Huitema wrote: > From what I have read so far, the monetary payment appears to be one of >the weakest point of the proposal. I suggest that the monetary >consideration in the draft be removed, and that the precise method used >to implement the registration be left to the registry. Specifically, I >suggest in section " >3.2.1 Centrally Assigned Global IDs" to replace the phrase: > > - One time non-refundable allocation fee per allocation that is > affordable by a broad spectrum of end users when considered > globally. > >By: > > - Allocation on a permanent basis, without any need for renewal >and > without any procedure for de-allocation. > >I would also delete the phrase: "They should also accept a variety of >payment methods and currencies." > >Then, I would replace the paragraph: > > The reason for the use of an allocation fee for each prefix is to > allow this service function to operate on a cost recovery basis. An > acknowledged side-effect of such a mechanism is that it provides some > impediment to any hoarding of the these allocations. The > consideration of affordability is intended to keep the cost low > enough so as not create a barrier to anyone needing one. The charge > is one time to eliminate the need for an ongoing relationship with > the allocation authority, while acknowledging the service costs for > both the registration function and the enduring escrow service. The > charge is non-refundable in order to keep overhead low. > >By a more neutral: > > The allocation service should include sufficient provisions to avoid > hoarding of numbers. This can be accomplished by various ways, e.g., > requiring an exchange of documents, a verbal contact, or a proof that > > the request is on behalf of a human rather than a machine. The >service > may charge a small fee in order to cover its costs, but the fee >should > be low enough to not create a barrier to anyone needing one. The >precise > mechanisms should be decided by the registration authority. > >Doing these edits will clearly express our intent, without dictating how >the registration service chooses to operate. For all we know, we may >find a volunteer who runs the service for free. I agree it will remove a sticking point from the document while still expressing our intent. Unless someone objects, I will make this change. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 05:40: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 FAA19688 for ; Fri, 6 Feb 2004 05:40:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3Oc-0000Ur-B5 for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 05:39:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Adc6q001903 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 05:39:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3Oc-0000Uc-5O for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 05:39: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 FAA19680 for ; Fri, 6 Feb 2004 05:39:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap3OY-0002JU-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 05:39:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap3Nb-0002Gx-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 05:38:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap3NH-0002Ep-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 05:38:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3N5-0008Qu-7t; Fri, 06 Feb 2004 05:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3Mj-0008L6-3o for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 05:37:41 -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 FAA19628 for ; Fri, 6 Feb 2004 05:37:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap3Mf-0002EV-00 for ipv6@ietf.org; Fri, 06 Feb 2004 05:37:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap3Ll-0002CF-00 for ipv6@ietf.org; Fri, 06 Feb 2004 05:36:42 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap3L7-00027K-00; Fri, 06 Feb 2004 05:36:02 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i16AZS714948; Fri, 6 Feb 2004 04:35:28 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 6 Feb 2004 11:35:26 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC521@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Juergen Schoenwaelder'" , raraghun@cisco.com Cc: ipv6mib@ibr.cs.tu-bs.de, ipv6@ietf.org, tsvwg@ietf.org Subject: RE: [ipv6mib] Discontinuity timer for TCP-MIB counters Date: Fri, 6 Feb 2004 11:32:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 W.r.t. > Here are my 3 thoughs on this: > > 1) So far, sysUpTime has been used by the existing TCP-MIB objects. > Introducing a new discontinuity indicator now raises the question > whether doing so breaks existing implementations. > Good point! > 2) Personally, I doubt that there will be many implementations where > TCP can experience discontinuities that do not also affect other > parts of the networking stack or the whole system. > OK, that is what we need to know. > 3) I do see the problem that sysUpTime might be more frequently reset > as we like due to some other MIBs which do not use explicit > discontinuity indicators and experience more frequent > resets. However, the root of the problem is then really in those > MIBs, not in the TCP-MIB. (Sure, by introducing a discontinuity > indicator for the TCP-MIB we can protect against other misbehaving > MIBs - but is this going to set a precedence which at the end > requires a CLR that better every MIB module has at least one, > perhaps multiple discontinuity indicators?) > You can understand that those "other MIB modules" will also use argument 1) to not have to change, rigth? > In the case of the TCP-MIB, I believe 1) is the killing argument. To > introduce a new discontinuity indicator changes the implicit semantics > of existing objects and would require to introduce new objects, which > I think is prohibitive. > > Conclusion: Spell out that sysUpTime is used as a discontinuity > indicator for the counters. > I can live with that if that is the consensus. Bert > /js -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 06:48: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 GAA21743 for ; Fri, 6 Feb 2004 06:48:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4ST-0006Ao-6Y for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 06:47:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16BlfUa023724 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 06:47:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4ST-0006AZ-20 for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 06:47:41 -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 GAA21712 for ; Fri, 6 Feb 2004 06:47:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4SP-00063n-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:47:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap4RR-00060w-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:46:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Qz-0005yr-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:46:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4Qt-0005sT-0g; Fri, 06 Feb 2004 06:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4QW-0005r1-SM for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 06:45:41 -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 GAA21663 for ; Fri, 6 Feb 2004 06:45:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4QS-0005y2-00 for ipv6@ietf.org; Fri, 06 Feb 2004 06:45:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap4PW-0005vm-00 for ipv6@ietf.org; Fri, 06 Feb 2004 06:44:39 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4OX-0005td-00 for ipv6@ietf.org; Fri, 06 Feb 2004 06:43:37 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id B00236A907; Fri, 6 Feb 2004 13:43:38 +0200 (EET) Message-ID: <40237D89.1080904@kolumbus.fi> Date: Fri, 06 Feb 2004 13:42:01 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: JINMEI Tatuya , Markku Savela , ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> In-Reply-To: <40230318.7000101@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greg Daley wrote: > I do not think we should be modifying every node to suit > MLD snooping, but it is possible to perhaps suggest > a random delay for _both_ the MLD report _and_ the DAD > NS (but no explicit delay between them). The DAD NS must > come after the MLD report though. What is important here is to avoid the collisions. The collisions are avoided if there is some random delay before you start sending packets. Given that the protocols impose an ordering (MLD first and DAD after that), a delay in MLD will impose an equivalent delay in DAD. My conclusion is that the right thing is to update RFC 2710 and require a delay. This removes collisions from both MLD and DAD. (We could still keep the requirement in 2462bis that if the DAD message is the first message to be sent then you should add a delay, but in that case we need to explain that if you follow the MLD spec then it never is the first message.) > In this case, the node could start listenting to the group > before sending an MLD report. This is different to MLD/MLDv2, > but will not hurt, since the DAD NS is the principle > trigger for multicast traffic to that solicited nodes' address. > > In snooping environments, the node wouldn't get any messages > to the group until the MLD report was sent. > In any case, it avoids the simultaneous transmission problem. Listening before you send the MLD report is possible, but should be optional since, as you say, it does not always work. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 06:56: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 GAA22047 for ; Fri, 6 Feb 2004 06:56:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4aJ-00072e-0y for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 06:55:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16BtksI027062 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 06:55:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4aI-00072P-TH for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 06:55:46 -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 GAA22039 for ; Fri, 6 Feb 2004 06:55:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4aE-0006Xa-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:55:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap4ZL-0006UK-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:54:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Ys-0006Ql-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:54:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4Yc-0006eW-HV; Fri, 06 Feb 2004 06:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4YJ-0006dq-Py for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 06:53:43 -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 GAA21943 for ; Fri, 6 Feb 2004 06:53:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4YF-0006P4-00 for ipv6@ietf.org; Fri, 06 Feb 2004 06:53:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap4XO-0006MT-00 for ipv6@ietf.org; Fri, 06 Feb 2004 06:52:47 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Wy-0006JC-00 for ipv6@ietf.org; Fri, 06 Feb 2004 06:52:20 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id A957D6A90A; Fri, 6 Feb 2004 13:52:21 +0200 (EET) Message-ID: <40237F94.4070104@kolumbus.fi> Date: Fri, 06 Feb 2004 13:50:44 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JINMEI Tatuya Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 278] 2462bis for "routers" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit JINMEI Tatuya wrote: > The autoconfiguration process specified in this document applies only > to hosts and not routers. Since host autoconfiguration uses > information advertised by routers, routers will need to be configured > by some other means. However, it is expected that routers will > generate link-local addresses using the mechanism described in this > document. In addition, routers are expected to successfully pass the > Duplicate Address Detection procedure described in this document on > all addresses prior to assigning them to an interface. Strictly speaking, routers need to be configured with prefixes as well as possibly some routing information, or at least information sufficient to run routing protocols. It is not clear to me that their global IP addresses have to configured. It could be based on its own prefix + IID information, or am I missing something? Why is there a difference above for link-local and global addresses? --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 08:04: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 IAA24090 for ; Fri, 6 Feb 2004 08:04:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap5e5-0002yQ-9H for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 08:03:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16D3j2g011429 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 08:03:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap5e5-0002yG-4G for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 08:03: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 IAA24087 for ; Fri, 6 Feb 2004 08:03:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap5e4-0002cH-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 08:03:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap5d6-0002ZM-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 08:02:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap5cr-0002Wm-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 08:02:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap5cP-0002Yx-C7; Fri, 06 Feb 2004 08:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap5c5-0002Ui-BH for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 08:01:41 -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 IAA23938 for ; Fri, 6 Feb 2004 08:01:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap5c4-0002Vz-00 for ipv6@ietf.org; Fri, 06 Feb 2004 08:01:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap5b5-0002U5-00 for ipv6@ietf.org; Fri, 06 Feb 2004 08:00:40 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Ap5am-0002SI-00 for ipv6@ietf.org; Fri, 06 Feb 2004 08:00:20 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i16D0JqY008544 for ; Fri, 6 Feb 2004 14:00:19 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 6 Feb 2004 14:00:19 +0100 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJS1882; Fri, 6 Feb 2004 14:00:35 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Feb 2004 13:59:40 +0100 Message-ID: X-Sybari-Trust: 817d1961 6b512624 7e80e808 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Jari Arkko'" , ipv6@ietf.org Subject: RE: [rfc2462bis issue 278] 2462bis for "routers" Date: Fri, 6 Feb 2004 13:59:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 06 Feb 2004 13:00:19.0261 (UTC) FILETIME=[2C4546D0:01C3ECB1] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 > JINMEI Tatuya wrote: > > > The autoconfiguration process specified in this document > applies only > > to hosts and not routers. Since host autoconfiguration uses > > information advertised by routers, routers will need to > be configured > > by some other means. However, it is expected that routers will > > generate link-local addresses using the mechanism > described in this > > document. In addition, routers are expected to > successfully pass the > > Duplicate Address Detection procedure described in this > document on > > all addresses prior to assigning them to an interface. > > Strictly speaking, routers need to be configured with prefixes as > well as possibly some routing information, or at least information > sufficient to run routing protocols. > > It is not clear to me that their global IP addresses have to > configured. > It could be based on its own prefix + IID information, or am I missing > something? Well, the prefix is configured, so in that sense regardless of how the address is installed on the interface then it IS configured and not formed on the basis of learned prefixes in RAs. Why is there a difference above for link-local and global > addresses? > Because link-local addresses can be formed solely on the basis of the link identifier which is hardcoded not configured. BR, Karen This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 08:07: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 IAA24207 for ; Fri, 6 Feb 2004 08:07:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap5h5-0003RF-1a for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 08:06:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16D6pfV013211 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 08:06:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap5h4-0003R0-Sd for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 08:06:50 -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 IAA24197 for ; Fri, 6 Feb 2004 08:06:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap5h3-0002od-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 08:06:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap5g3-0002km-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 08:05:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap5fa-0002hd-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 08:05:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap5fL-00034g-76; Fri, 06 Feb 2004 08:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap5f4-0002zd-KV for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 08:04:46 -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 IAA24135 for ; Fri, 6 Feb 2004 08:04:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap5f3-0002gA-00 for ipv6@ietf.org; Fri, 06 Feb 2004 08:04:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap5e8-0002cu-00 for ipv6@ietf.org; Fri, 06 Feb 2004 08:03:48 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap5dY-0002Yi-00 for ipv6@ietf.org; Fri, 06 Feb 2004 08:03:12 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGV51A>; Fri, 6 Feb 2004 08:02:44 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04210E@ftmail.lab.flarion.com> From: Soliman Hesham To: "'JINMEI Tatuya / ????'" , ipv6@ietf.org Subject: RE: [rfc2462bis issue 280] interface failure upon DAD failure Date: Fri, 6 Feb 2004 08:02:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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 > and my current feeling about the resolution is: > > + keep SHOULD for the interface if the interface identifier > is derived > from the layer 2 address, with the original intention Thomas > explained. > + allow MAY for the other cases (does this help the 3GPP case?) => Agreed with the above. Basically the 3GPP case is just an example where MAC addresses are not assigned to interfaces, which is very different from Ethernet. In other words, you can think of it as a link layer that has no MAC addresses (seen by the IP layer). So address duplication is completely decoupled from MAC address duplication. > + remove the current resolution: "MAY try an automatic recovery" => I'm fine with explaining the two cases above. This makes it clear that any address not derived from a MAC address can be disabled without disabling the interface. A host can then generate another address and try again. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 12:24: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 MAA06165 for ; Fri, 6 Feb 2004 12:24:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9ho-0004V9-9v for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 12:23:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16HNqRT017296 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 12:23:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9ho-0004Ut-3S for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 12:23: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 MAA06161 for ; Fri, 6 Feb 2004 12:23:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9hm-0004vV-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 12:23:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap9gq-0004sz-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 12:22:52 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap9gg-0004qS-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 12:22:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ap9gg-0004n1-IV for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 12:22:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9g4-0004Go-B4; Fri, 06 Feb 2004 12:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9ft-0004F6-BD for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 12:21:53 -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 MAA06094 for ; Fri, 6 Feb 2004 12:21:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9fr-0004pp-00 for ipv6@ietf.org; Fri, 06 Feb 2004 12:21:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap9fN-0004lY-00 for ipv6@ietf.org; Fri, 06 Feb 2004 12:21:21 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9eN-0004bT-00 for ipv6@ietf.org; Fri, 06 Feb 2004 12:20:19 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i16HKJOK018693 for ; Fri, 6 Feb 2004 10:20:19 -0700 (MST) 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 <0HSO00BJAATTMD@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Fri, 06 Feb 2004 10:20:18 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HSO00M9XATS1P@mail.sun.net> for ipv6@ietf.org; Fri, 06 Feb 2004 10:20:17 -0700 (MST) Date: Fri, 06 Feb 2004 09:24:03 -0800 From: Alain Durand Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt In-reply-to: To: Christian Huitema Cc: ipv6@ietf.org, Bob Hinden Message-id: <424A998C-58C9-11D8-8E73-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT While doing those edits, why not also remove the dictate to give permanent allocations from this document? After all, this is also an operational/business discussion, not a technical one. - Alain. On Feb 5, 2004, at 10:07 PM, Christian Huitema wrote: > From what I have read so far, the monetary payment appears to be one of > the weakest point of the proposal. I suggest that the monetary > consideration in the draft be removed, and that the precise method used > to implement the registration be left to the registry. Specifically, I > suggest in section " > 3.2.1 Centrally Assigned Global IDs" to replace the phrase: > > - One time non-refundable allocation fee per allocation that is > affordable by a broad spectrum of end users when considered > globally. > > By: > > - Allocation on a permanent basis, without any need for renewal > and > without any procedure for de-allocation. > > rder to keep overhead low. > > By a more neutral: > > The allocation service should include sufficient provisions to avoid > hoarding of numbers. This can be accomplished by various ways, e.g., > requiring an exchange of documents, a verbal contact, or a proof > that > > the request is on behalf of a human rather than a machine. The > service > may charge a small fee in order to cover its costs, but the fee > should > be low enough to not create a barrier to anyone needing one. The > precise > mechanisms should be decided by the registration authority. > > Doing these edits will clearly express our intent, without dictating > how > the registration service chooses to operate. For all we know, we may > find a volunteer who runs the service for free. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 12:57: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 MAA07200 for ; Fri, 6 Feb 2004 12:57: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 1ApADk-0006tn-CL for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 12:56:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16HuqAg026513 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 12:56:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApADk-0006tY-72 for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 12:56: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 MAA07186 for ; Fri, 6 Feb 2004 12:56:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApADi-0006tN-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 12:56:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApACp-0006qg-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 12:55:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApACA-0006nj-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 12:55:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApABy-0006XF-Vj; Fri, 06 Feb 2004 12:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApABp-0006Wj-5a for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 12:54:53 -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 MAA07142 for ; Fri, 6 Feb 2004 12:54:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApABn-0006mj-00 for ipv6@ietf.org; Fri, 06 Feb 2004 12:54:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApAAs-0006kA-00 for ipv6@ietf.org; Fri, 06 Feb 2004 12:53:55 -0500 Received: from oak3a.cats.ohiou.edu ([132.235.8.151]) by ietf-mx with esmtp (Exim 4.12) id 1ApAAK-0006hK-00 for ipv6@ietf.org; Fri, 06 Feb 2004 12:53:20 -0500 Received: from 132.235.232.96 by pm4 (PureMessage); Fri Feb 6 12:42:20 2004 Received: from hkruse2003a (dhcp-232-096.cns.ohiou.edu [132.235.232.96]) (authenticated bits=0) by oak2a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id i16HgJPH1187430 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 6 Feb 2004 12:42:19 -0500 (EST) Date: Fri, 06 Feb 2004 12:40:33 -0500 From: Hans Kruse To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Message-ID: <317710281.1076071233@hkruse2003a> In-Reply-To: <424A998C-58C9-11D8-8E73-00039376A6AA@sun.com> References: <424A998C-58C9-11D8-8E73-00039376A6AA@sun.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-Spam: Gauge=IIIIIIII, Probability=8%, Report='QUOTED_EMAIL_TEXT 0, IN_REP_TO 0' X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-PMX-Version: 4.1.1.86173 (pm4) X-PMX-Start: Fri Feb 6 12:42:20 2004 X-PMX-Stop: Fri Feb 6 12:42:20 2004 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 disagree; the technical issue is stability. We want these allocations to be permanent to make them attractive in a technical analysis -- this encourages their use in those cases where we believe they should be used (as opposed to having users preferentially use self-assigned prefixes which they perceive to be permanent). --On Friday, February 06, 2004 09:24 -0800 Alain Durand wrote: > While doing those edits, why not also remove the dictate to give > permanent allocations from this document? After all, this is also an > operational/business discussion, not a technical one. > > - Alain. > > > On Feb 5, 2004, at 10:07 PM, Christian Huitema wrote: > >> From what I have read so far, the monetary payment appears to be one of >> the weakest point of the proposal. I suggest that the monetary >> consideration in the draft be removed, and that the precise method used >> to implement the registration be left to the registry. Specifically, I >> suggest in section " >> 3.2.1 Centrally Assigned Global IDs" to replace the phrase: >> >> - One time non-refundable allocation fee per allocation that is >> affordable by a broad spectrum of end users when considered >> globally. >> >> By: >> >> - Allocation on a permanent basis, without any need for renewal >> and >> without any procedure for de-allocation. >> >> rder to keep overhead low. >> >> By a more neutral: >> >> The allocation service should include sufficient provisions to avoid >> hoarding of numbers. This can be accomplished by various ways, e.g., >> requiring an exchange of documents, a verbal contact, or a proof >> that >> >> the request is on behalf of a human rather than a machine. The >> service >> may charge a small fee in order to cover its costs, but the fee >> should >> be low enough to not create a barrier to anyone needing one. The >> precise >> mechanisms should be decided by the registration authority. >> >> Doing these edits will clearly express our intent, without dictating >> how >> the registration service chooses to operate. For all we know, we may >> find a volunteer who runs the service for free. >> > > > > > -------------------------------------------------------------------- > 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 Fri Feb 6 15:11: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 PAA13253 for ; Fri, 6 Feb 2004 15:11:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCJT-00008Z-QH for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 15:10:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16KAt8Z000523 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 15:10:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCJT-00008M-Ks for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 15:10:55 -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 PAA13169 for ; Fri, 6 Feb 2004 15:10:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApCJQ-0000Z2-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 15:10:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApCIS-0000T5-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 15:09:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApCHT-0000Kf-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 15:08:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCGg-0007J4-55; Fri, 06 Feb 2004 15:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCFk-0006cF-2U for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 15:07: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 PAA12779 for ; Fri, 6 Feb 2004 15:07:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApCFh-0000FD-00 for ipv6@ietf.org; Fri, 06 Feb 2004 15:07:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApCEg-0000Bt-00 for ipv6@ietf.org; Fri, 06 Feb 2004 15:05:58 -0500 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1ApCE2-00008t-00 for ipv6@ietf.org; Fri, 06 Feb 2004 15:05:19 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1ApCE1-0004bu-00 for ; Fri, 06 Feb 2004 20:05:17 +0000 Date: Fri, 6 Feb 2004 20:05:17 +0000 To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Message-ID: <20040206200517.GB14821@fysh.org> References: <424A998C-58C9-11D8-8E73-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424A998C-58C9-11D8-8E73-00039376A6AA@sun.com> User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 Durand wrote: >While doing those edits, why not also remove the dictate to give >permanent allocations from this document? >After all, this is also an operational/business discussion, not a >technical one. It looks pretty technical to me. Permanent versus temporary allocation fundamentally affects the ways the prefix can be used. This is quite unlike the issue of the allocation procedure. By the way, do you see any redeeming features in the idea of temporary allocation of these prefixes? I see only greater complexity and reduced utility. -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 6 16:58: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 QAA24164 for ; Fri, 6 Feb 2004 16:58:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDz0-0002sW-Uk for ipv6-archive@odin.ietf.org; Fri, 06 Feb 2004 16:57:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Lvsp9011056 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 16:57:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDz0-0002sF-Q8 for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 16:57:54 -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 QAA23913 for ; Fri, 6 Feb 2004 16:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApDyy-0005Dz-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 16:57:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApDwq-0004lL-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 16:55:41 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ApDuw-0004JM-01 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 16:53:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ApDma-00085K-9w for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 16:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDTD-0008Ik-1K; Fri, 06 Feb 2004 16: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 1ApDSW-0008DS-VI for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 16:24:20 -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 QAA18366 for ; Fri, 6 Feb 2004 16:24:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApDSU-0006Ny-00 for ipv6@ietf.org; Fri, 06 Feb 2004 16:24:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApDQ2-0005qr-00 for ipv6@ietf.org; Fri, 06 Feb 2004 16:21:47 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApDNm-0005Mb-00 for ipv6@ietf.org; Fri, 06 Feb 2004 16:19:26 -0500 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i16LJNOr003821 for ; Fri, 6 Feb 2004 21:19:23 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA25140 for ; Fri, 6 Feb 2004 21:19:20 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i16LJKO02740 for ipv6@ietf.org; Fri, 6 Feb 2004 21:19:20 GMT Date: Fri, 6 Feb 2004 21:19:20 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Message-ID: <20040206211920.GB2673@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <424A998C-58C9-11D8-8E73-00039376A6AA@sun.com> <20040206200517.GB14821@fysh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040206200517.GB14821@fysh.org> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, Feb 06, 2004 at 08:05:17PM +0000, Zefram wrote: > Alain Durand wrote: > >While doing those edits, why not also remove the dictate to give > >permanent allocations from this document? > >After all, this is also an operational/business discussion, not a > >technical one. > > It looks pretty technical to me. Permanent versus temporary allocation > fundamentally affects the ways the prefix can be used. This is quite > unlike the issue of the allocation procedure. > > By the way, do you see any redeeming features in the idea of temporary > allocation of these prefixes? I see only greater complexity and reduced > utility. One snag is that if they are temporary, it will inevitably lead to "returns" that don't happen, and the original and new "owners" both using the prefix, which will cause confusion/ambiguity/lack of uniqueness, which is thus breaking the original goal of the draft. There's enough under the /7 to not need to have temporary allocations. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Feb 7 01:39: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 BAA12409 for ; Sat, 7 Feb 2004 01:39: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 1ApM7Y-00027A-JU for ipv6-archive@odin.ietf.org; Sat, 07 Feb 2004 01:39:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i176dGWL008120 for ipv6-archive@odin.ietf.org; Sat, 7 Feb 2004 01:39:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApM7Y-00026t-BR for ipv6-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 01:39:16 -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 BAA12397 for ; Sat, 7 Feb 2004 01:39:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApM7V-0001nK-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 01:39:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApM6Z-0001k7-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 01:38:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApM5n-0001h3-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 01:37:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApM5O-0001SZ-Me; Sat, 07 Feb 2004 01:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApM4h-0001RK-3A for ipv6@optimus.ietf.org; Sat, 07 Feb 2004 01: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 BAA12331 for ; Sat, 7 Feb 2004 01:36:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApM4d-0001dK-00 for ipv6@ietf.org; Sat, 07 Feb 2004 01:36:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApM3i-0001aE-00 for ipv6@ietf.org; Sat, 07 Feb 2004 01:35:19 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1ApM3N-0001Wx-00 for ipv6@ietf.org; Sat, 07 Feb 2004 01:34:57 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i176YwVo010257 for ; Fri, 6 Feb 2004 23:34:58 -0700 (MST) 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 <0HSP002MZBM9YH@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Fri, 06 Feb 2004 23:34:58 -0700 (MST) Received: from [192.168.1.2] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HSP00MRZBM81P@mail.sun.net> for ipv6@ietf.org; Fri, 06 Feb 2004 23:34:57 -0700 (MST) Date: Fri, 06 Feb 2004 22:38:43 -0800 From: Alain Durand Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt In-reply-to: <20040206211920.GB2673@login.ecs.soton.ac.uk> To: ipv6@ietf.org Cc: Alain Durand Message-id: <45BB94DF-5938-11D8-9A8D-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <424A998C-58C9-11D8-8E73-00039376A6AA@sun.com> <20040206200517.GB14821@fysh.org> <20040206211920.GB2673@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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Trying to make a synthesized answer... I think people are confusing the notion of 'permanent' and 'stable' addresses. The case made for those local addresses was to be independent from ISP, either to isolate from ISP changes or in the case of intermittent connection. This require 'stable' addresses. i.e addresses that are stable for a long enough period of time, here define long enough by for the lifetime of your operations. This has nothing to do with 'permanent', which means until the end of the times. So, I argue that 'permanent' is not a technical requirement. Now, if we have multiple registries, it is up to them to find a business model that makes sense for them. If it is easier/simpler to come with a one time fee model, fine. If they think they cannot recover the costs of operation like that, they may opt for a recurrent fee model. This would not mean that the prefixes won't be stable, they would be as long as their owner keeps maintaining the subscription. So I argue that the choice of a one time fee vs recurrent fee is an operational/economical discussion that would be better kept out of this document. As a side note, there are several issues with the 'permanent allocation, one time fee' model: - This is really symptomatic of a consumer society where people do not think about waste management, where resources are perceived unlimited and it is free spending. - The business model is based on the assumption that the new comers will pay for the management of the database so the previous customer won't have to pay for it. I think this is completely broken, as it is fundamentally a pyramid scheme. Remember those chain letters asking you to send money to 10 people and forward it to 20 others? - It is unclear what happen when a company is acquired by another one or when the addresses are registered to a person and that person dies. Are those addresses considered as part of the assets of the company/person? Are they transferable? - It would be the first time that the IETF would sanctify the sale (and not the stewardship) of chunks of address space. This is a fundamental departure from what has been done in the past. - Alain. On Feb 6, 2004, at 1:19 PM, Tim Chown wrote: > On Fri, Feb 06, 2004 at 08:05:17PM +0000, Zefram wrote: >> Alain Durand wrote: >>> While doing those edits, why not also remove the dictate to give >>> permanent allocations from this document? >>> After all, this is also an operational/business discussion, not a >>> technical one. >> >> It looks pretty technical to me. Permanent versus temporary >> allocation >> fundamentally affects the ways the prefix can be used. This is quite >> unlike the issue of the allocation procedure. >> >> By the way, do you see any redeeming features in the idea of temporary >> allocation of these prefixes? I see only greater complexity and >> reduced >> utility. > > One snag is that if they are temporary, it will inevitably lead to > "returns" > that don't happen, and the original and new "owners" both using the > prefix, > which will cause confusion/ambiguity/lack of uniqueness, which is thus > breaking > the original goal of the draft. There's enough under the /7 to not > need to > have temporary allocations. > > 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 Sat Feb 7 06:52: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 GAA01332 for ; Sat, 7 Feb 2004 06:52:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApR0f-0007uj-7s for ipv6-archive@odin.ietf.org; Sat, 07 Feb 2004 06:52:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17BqT5k030418 for ipv6-archive@odin.ietf.org; Sat, 7 Feb 2004 06:52:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApR0e-0007uX-Vd for ipv6-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 06:52: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 GAA01319 for ; Sat, 7 Feb 2004 06:52:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApR0a-00060R-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 06:52:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApQzw-0005uh-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 06:51:45 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ApQyr-0005hu-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 06:50:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ApQys-00049u-L8 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 06:50:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApQyL-0007L5-1v; Sat, 07 Feb 2004 06:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApQxW-0007FJ-1q for ipv6@optimus.ietf.org; Sat, 07 Feb 2004 06:49:16 -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 GAA00906 for ; Sat, 7 Feb 2004 06:49:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApQxR-0005Qh-00 for ipv6@ietf.org; Sat, 07 Feb 2004 06:49:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApQwJ-0005Bp-00 for ipv6@ietf.org; Sat, 07 Feb 2004 06:48:00 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx with esmtp (Exim 4.12) id 1ApQuo-0004sp-00 for ipv6@ietf.org; Sat, 07 Feb 2004 06:46:26 -0500 Received: from localhost ([130.194.13.83]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L6C52YJ3NC935EVV@vaxc.its.monash.edu.au> for ipv6@ietf.org; Sat, 07 Feb 2004 22:44:20 +1100 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id ED41E23C004; Sat, 07 Feb 2004 22:44:19 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by splat.its.monash.edu.au (Postfix) with ESMTP id D9FE6164009; Sat, 07 Feb 2004 22:44:19 +1100 (EST) Date: Sat, 07 Feb 2004 22:44:19 +1100 From: Gregory Daley Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay To: Jari Arkko Cc: greg.daley@eng.monash.edu.au, JINMEI Tatuya , Markku Savela , ipv6@ietf.org Message-id: <4dae174de5a6.4de5a64dae17@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en 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 Jari, ----- Original Message ----- From: Jari Arkko Date: Friday, February 6, 2004 10:42 pm Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay > Greg Daley wrote: > > > I do not think we should be modifying every node to suit > > MLD snooping, but it is possible to perhaps suggest > > a random delay for _both_ the MLD report _and_ the DAD > > NS (but no explicit delay between them). The DAD NS must > > come after the MLD report though. > > What is important here is to avoid the collisions. The collisions > are avoided if there is some random delay before you start sending > packets. Given that the protocols impose an ordering (MLD first and > DAD after that), a delay in MLD will impose an equivalent delay > in DAD. That's sufficient. > My conclusion is that the right thing is to update RFC 2710 > and require a delay. This removes collisions from both MLD > and DAD. I think that the problem there may be that RFC-2710 is being replaced by MLDv2. The IPv6 node reqs document had a MUST for MLDv1, and SHOULD for MLDv2 (last I saw). This could lead to many of the hosts exhibiting the colliding behaviour for MLDv1, even if the changes go into MLDv2. Will we effectively need MLDv1(the second)? > (We could still keep the requirement in 2462bis that if the DAD > message is the first message to be sent then you should add > a delay, but in that case we need to explain that if you > follow the MLD spec then it never is the first message.) > > > In this case, the node could start listenting to the group > > before sending an MLD report. This is different to MLD/MLDv2, > > but will not hurt, since the DAD NS is the principle > > trigger for multicast traffic to that solicited nodes' address. > > > > In snooping environments, the node wouldn't get any messages > > to the group until the MLD report was sent. > > In any case, it avoids the simultaneous transmission problem. > > Listening before you send the MLD report is possible, but should > be optional since, as you say, it does not always work. Since you've not sent any packets on the link, it may not hurt though... Whether it's worth specifying here (listen before you're a listener) is another matter. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Feb 7 08:50: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 IAA03098 for ; Sat, 7 Feb 2004 08:50:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApSqs-0006z0-Gt for ipv6-archive@odin.ietf.org; Sat, 07 Feb 2004 08:50:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17DoUZV026836 for ipv6-archive@odin.ietf.org; Sat, 7 Feb 2004 08:50:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApSqs-0006yl-AG for ipv6-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 08:50:30 -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 IAA03084 for ; Sat, 7 Feb 2004 08:50:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApSqr-0005vS-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 08:50:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApSpu-0005s0-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 08:49:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApSpL-0005om-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 08:48:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApSoU-0006bF-9k; Sat, 07 Feb 2004 08:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApSo1-0006aC-Fa for ipv6@optimus.ietf.org; Sat, 07 Feb 2004 08:47:33 -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 IAA03021 for ; Sat, 7 Feb 2004 08:47:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApSo0-0005k7-00 for ipv6@ietf.org; Sat, 07 Feb 2004 08:47:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApSn3-0005gI-00 for ipv6@ietf.org; Sat, 07 Feb 2004 08:46:33 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1ApSmF-0005cR-00 for ipv6@ietf.org; Sat, 07 Feb 2004 08:45:43 -0500 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id i17Djep08482; Sat, 7 Feb 2004 05:45:40 -0800 (PST) From: Bill Manning Message-Id: <200402071345.i17Djep08482@boreas.isi.edu> Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt In-Reply-To: <20040206211920.GB2673@login.ecs.soton.ac.uk> from Tim Chown at "Feb 6, 4 09:19:20 pm" To: tjc@ecs.soton.ac.uk (Tim Chown) Date: Sat, 7 Feb 2004 05:45:40 -0800 (PST) Cc: ipv6@ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit % One snag is that if they are temporary, it will inevitably lead to "returns" % that don't happen, and the original and new "owners" both using the prefix, % which will cause confusion/ambiguity/lack of uniqueness, which is thus breaking % the original goal of the draft. There's enough under the /7 to not need to % have temporary allocations. actaully, all delegations are temporary, unless we are creating property/ownership rights. % Tim --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 Feb 7 17:16: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 RAA15862 for ; Sat, 7 Feb 2004 17:16:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apajv-00076s-I8 for ipv6-archive@odin.ietf.org; Sat, 07 Feb 2004 17:15:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17MFpoE027324 for ipv6-archive@odin.ietf.org; Sat, 7 Feb 2004 17:15:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apajv-00076d-CJ for ipv6-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 17:15: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 RAA15844 for ; Sat, 7 Feb 2004 17:15:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apajt-0002q9-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 17:15:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apaj5-0002ly-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 17:15:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Apaig-0002hM-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 17:14:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apai9-0006ug-J0; Sat, 07 Feb 2004 17:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apai4-0006uR-Dt for ipv6@optimus.ietf.org; Sat, 07 Feb 2004 17:13:59 -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 RAA15751 for ; Sat, 7 Feb 2004 17:13:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apai2-0002h9-00 for ipv6@ietf.org; Sat, 07 Feb 2004 17:13:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apah3-0002cN-00 for ipv6@ietf.org; Sat, 07 Feb 2004 17:12:54 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1Apaga-0002Xr-00 for ipv6@ietf.org; Sat, 07 Feb 2004 17:12:25 -0500 Received: from localhost ([130.194.13.81]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L6CQQDVZ7Y90567K@vaxh.its.monash.edu.au> for ipv6@ietf.org; Sun, 8 Feb 2004 09:04:07 +1100 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 6CB351B000C; Sun, 08 Feb 2004 09:04:07 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 5DC4E124009; Sun, 08 Feb 2004 09:04:07 +1100 (EST) Date: Sun, 08 Feb 2004 09:04:07 +1100 From: Gregory Daley Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay To: Jari Arkko Cc: JINMEI Tatuya , Markku Savela , ipv6@ietf.org Message-id: <4e09cb4e1a83.4e1a834e09cb@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en 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 Jari, ----- Original Message ----- From: Jari Arkko Date: Sunday, February 8, 2004 3:44 am Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay > Gregory Daley wrote: > > Hi Jari, > > > > ----- Original Message ----- > > From: Jari Arkko > > Date: Friday, February 6, 2004 10:42 pm -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Feb 7 23:49: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 XAA23643 for ; Sat, 7 Feb 2004 23:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApgsO-0005FU-Qf for ipv6-archive@odin.ietf.org; Sat, 07 Feb 2004 23:49:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i184n0KG020175 for ipv6-archive@odin.ietf.org; Sat, 7 Feb 2004 23:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApgsO-0005FK-68 for ipv6-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 23:49:00 -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 XAA23640 for ; Sat, 7 Feb 2004 23:48:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApgsM-0007Ov-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 23:48:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApgrQ-0007LV-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 23:48:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Apgr2-0007Hs-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 23:47:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApgqT-00051v-Fl; Sat, 07 Feb 2004 23:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApgqR-00051g-5L for ipv6@optimus.ietf.org; Sat, 07 Feb 2004 23:46:59 -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 XAA23583 for ; Sat, 7 Feb 2004 23:46:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApgqP-0007H5-00 for ipv6@ietf.org; Sat, 07 Feb 2004 23:46:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApgpS-0007DQ-00 for ipv6@ietf.org; Sat, 07 Feb 2004 23:45:59 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apgoi-00079u-00 for ipv6@ietf.org; Sat, 07 Feb 2004 23:45:12 -0500 Received: from localhost ([130.194.13.81]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L6D4HQJD7E935EAA@vaxc.its.monash.edu.au> for ipv6@ietf.org; Sun, 08 Feb 2004 15:38:01 +1100 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id C06991B000C; Sun, 08 Feb 2004 15:38:00 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by kapow.its.monash.edu.au (Postfix) with ESMTP id B1D67124009; Sun, 08 Feb 2004 15:38:00 +1100 (EST) Date: Sun, 08 Feb 2004 15:38:00 +1100 From: Gregory Daley Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay To: Jari Arkko Cc: JINMEI Tatuya , Markku Savela , ipv6@ietf.org Message-id: <4f461f4f08f5.4f08f54f461f@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en 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 (Sorry, there seems to have been a problem with my previous post). Hi Jari, ----- Original Message ----- From: Jari Arkko Date: Sunday, February 8, 2004 3:44 am Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay > Gregory Daley wrote: > > Hi Jari, > > > > ----- Original Message ----- > > From: Jari Arkko > > Date: Friday, February 6, 2004 10:42 pm > > Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS > delay> > > > >>Greg Daley wrote: > >> > >> > >>>I do not think we should be modifying every node to suit > >>>MLD snooping, but it is possible to perhaps suggest > >>>a random delay for _both_ the MLD report _and_ the DAD > >>>NS (but no explicit delay between them). The DAD NS must > >>>come after the MLD report though. > >> > >>What is important here is to avoid the collisions. The collisions > >>are avoided if there is some random delay before you start sending > >>packets. Given that the protocols impose an ordering (MLD first and > >>DAD after that), a delay in MLD will impose an equivalent delay > >>in DAD. > > > > > > That's sufficient. > > Ok, so now we agree what needs to be done protocol wise, the > rest is just a documentation issue ;-) > > >>My conclusion is that the right thing is to update RFC 2710 > >>and require a delay. This removes collisions from both MLD > >>and DAD. > > > > > > I think that the problem there may be that RFC-2710 is > > being replaced by MLDv2. > > > > The IPv6 node reqs document had a MUST for MLDv1, and > > SHOULD for MLDv2 (last I saw). This could lead to many > > of the hosts exhibiting the colliding behaviour for MLDv1, > > even if the changes go into MLDv2. > > > > Will we effectively need MLDv1(the second)? > > I see the problem. I do not have a strong opinion on which > document should explain what the correct behaviour is, as > long as the document boundaries do not force us to specify > suboptimal behaviour. For instance, if RFC 2462bis can explain > that the delay should actually be before the MLD packet, that > would be also sufficient. [If you think it sounds strange that > 2462bis would be saying what to do for MLD, lets not forget > that MLD is invoked because 2462bis needs the multicast > listening service.] If people think it is appropriate to update 2462 with the address config related MLD procedures, that seems fine to me. Taking text from Jinmei san's proposal: "... It should be noted that the Neighbor Solicitation is usually not the first message. As stated above, the sending node must join the solicited-node multicast address prior to sending the Neighbor Solicitation and an MLD report message [9] for the multicast address should have been sent at that time. RFC 2710 [9] does not request a random delay when sending an initial group report for solicited nodes' addresses. Even if this is the case, a node SHOULD delay (as described above) before initial transmission of the MLD report when joining the solicited nodes' address, if this is the first transmission on a link. In this case, an NS for the purposes of DAD which is subsequently transmitted doesn't require additional delays, since it will not be synchronized with other nodes configuring on the link. In some cases it is possible for a node to start listening to the group during the delay period before MLD report transmission, although in some link-layer environments no multicast reception will be available until the report is sent. ..." Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 8 00:05: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 AAA24010 for ; Sun, 8 Feb 2004 00:05:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aph8I-0006aW-FA for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 00:05:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1855Q5P025318 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 00:05:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aph8I-0006aH-92 for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 00:05: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 AAA23986 for ; Sun, 8 Feb 2004 00:05:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aph8G-0000lx-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 00:05:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aph79-0000hC-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 00:04:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aph6E-0000dW-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 00:03:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aph5y-0006BP-Dt; Sun, 08 Feb 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 1Aph5L-0006Ar-CG for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 00:02: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 AAA23933 for ; Sun, 8 Feb 2004 00:02:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aph5J-0000aC-00 for ipv6@ietf.org; Sun, 08 Feb 2004 00:02:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aph4Y-0000WD-00 for ipv6@ietf.org; Sun, 08 Feb 2004 00:01:35 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1Aph3k-0000Lc-00 for ipv6@ietf.org; Sun, 08 Feb 2004 00:00:44 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 66CB565B for ; Sun, 8 Feb 2004 00:00:13 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 08 Feb 2004 00:00:13 -0500 Message-Id: <20040208050013.66CB565B@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 --------+------+--------+----------+------------------------ 19.61% | 20 | 19.23% | 108968 | jinmei@isl.rdc.toshiba.co.jp 5.88% | 6 | 8.36% | 47380 | pekkas@netcore.fi 5.88% | 6 | 7.79% | 44114 | bob.hinden@nokia.com 4.90% | 5 | 5.10% | 28913 | greg.daley@eng.monash.edu.au 4.90% | 5 | 4.51% | 25566 | jari.arkko@kolumbus.fi 4.90% | 5 | 4.47% | 25330 | erik.nordmark@sun.com 4.90% | 5 | 4.42% | 25031 | brian@innovationslab.net 4.90% | 5 | 3.95% | 22406 | j.schoenwaelder@iu-bremen.de 3.92% | 4 | 3.37% | 19090 | heard@pobox.com 3.92% | 4 | 3.03% | 17154 | bwijnen@lucent.com 2.94% | 3 | 3.67% | 20796 | adamson@us.ibm.com 2.94% | 3 | 3.31% | 18755 | shawn.routhier@windriver.com 2.94% | 3 | 2.82% | 15979 | huitema@windows.microsoft.com 1.96% | 2 | 2.20% | 12475 | alain.durand@sun.com 0.98% | 1 | 2.92% | 16541 | brc@zurich.ibm.com 1.96% | 2 | 1.86% | 10550 | internet-drafts@ietf.org 1.96% | 2 | 1.71% | 9668 | mukesh.gupta@nokia.com 1.96% | 2 | 1.60% | 9092 | soohong.park@samsung.com 1.96% | 2 | 1.56% | 8863 | msa@burp.tkv.asdf.org 1.96% | 2 | 1.32% | 7500 | mark.andrews@isc.org 0.98% | 1 | 1.30% | 7364 | russell_brian@bah.com 0.98% | 1 | 1.10% | 6252 | kruse@ohio.edu 0.98% | 1 | 1.02% | 5770 | francis.dupont@enst-bretagne.fr 0.98% | 1 | 0.99% | 5628 | mbagnulo@ing.uc3m.es 0.98% | 1 | 0.98% | 5552 | karen.e.nielsen@ericsson.com 0.98% | 1 | 0.94% | 5306 | raraghun@cisco.com 0.98% | 1 | 0.91% | 5163 | schoenw@ibr.cs.tu-bs.de 0.98% | 1 | 0.82% | 4645 | ftemplin@iprg.nokia.com 0.98% | 1 | 0.79% | 4491 | tjc@ecs.soton.ac.uk 0.98% | 1 | 0.70% | 3991 | sra+ipng@hactrn.net 0.98% | 1 | 0.70% | 3979 | jeroen@unfix.org 0.98% | 1 | 0.66% | 3765 | h.soliman@flarion.com 0.98% | 1 | 0.62% | 3531 | zefram@fysh.org 0.98% | 1 | 0.61% | 3471 | bmanning@isi.edu 0.98% | 1 | 0.61% | 3469 | mailman-owner@www1.ietf.org --------+------+--------+----------+------------------------ 100.00% | 102 |100.00% | 566548 | 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 Feb 8 06:23: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 GAA16039 for ; Sun, 8 Feb 2004 06:23:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apn1t-0003Uw-Ck for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 06:23:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18BNDs0013321 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 06:23:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apn1s-0003Sm-U6 for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 06:23:12 -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 GAA16030 for ; Sun, 8 Feb 2004 06:23:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apn1p-0005RE-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 06:23:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apn0s-0005N6-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 06:22:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Apn0C-0005JU-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 06:21:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apmzm-0003A3-Aj; Sun, 08 Feb 2004 06:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apmz3-00038Y-BM for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 06:20:17 -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 GAA15985 for ; Sun, 8 Feb 2004 06:20:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apmyz-0005FX-00 for ipv6@ietf.org; Sun, 08 Feb 2004 06:20:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apmy4-0005BZ-00 for ipv6@ietf.org; Sun, 08 Feb 2004 06:19:17 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Apmxb-00057N-00 for ipv6@ietf.org; Sun, 08 Feb 2004 06:18:47 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 6272E1525D; Sun, 8 Feb 2004 20:18:41 +0900 (JST) Date: Sun, 08 Feb 2004 20:18:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jari Arkko Cc: ipv6@ietf.org, Erik Nordmark Subject: Re: [rfc2462bis issue 271] retaining addresses in stable storage In-Reply-To: <40237BBF.5060701@kolumbus.fi> References: <40237BBF.5060701@kolumbus.fi> 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, 06 Feb 2004 13:34:23 +0200, >>>>> Jari Arkko said: >> To address rfc2462bis issue 271, "An implementation may want to use >> stable storage for autoconfigured addresses", I've added the following >> new (sub)section: >> >> ================================================================ >> 5.7 Retaining Configured Addresses for Stability >> >> It is reasoanble that implementations that have stable storage retain > nit: reasonable Thanks. (snip) > Perhaps there was a discussion about this on the list that I missed, As far as I know, there was no further discussion on this. You can search in a thread about this subject at: http://www.atm.tut.fi/list-archive/ipng/msg04383.html At least there was no replies to the main point within this particular thread (the only response to the message was not directly related to the RFC2462bis issue). > but I think there are two separate issues here: > 1) Router and connectivity goes away for a while. > 2) Host itself reboots. These two issues are not actually so separate, IMO. The problem is, as I see it, a situation like this: - a "router" announces a global prefix by RA in a zeroconf environment. - a host in this link configures a global address using stateless address autoconfiguration and communicates with other nodes in the link by the global address - the host reboots for some reason. - while the host is booting, the router somehow stops working. - then the host loses its global address, and ends up communicating with other nodes in the link using link-local addresses. So the problem is a mixture of 1 and 2. > Stable storage as such addresses primarily the second scenario. But > I think the proposed text may not be very clear with respect to what > exactly is going to be done to assist the first scenario. Do you mean the first scenario only? If so, it is out of scope of the proposed text. > For instance, > if you delete your only router from the Default Router list, what is > impact on the global addresses do you wish to have? Deprecate the > addresses, remove them, continue as-is, or what? I'm not really sure what you mean by "delete"...probably delete the router when the router lifetime expires during the router failure? And if so, the answer is very clear: "continue as is" until the address lifetime expires. And, in my understanding, the sense of RFC2462 is to use a large lifetime for prefixes so that the address and prefix can be valid even if the advertising router goes away "for a while". > What if the host > does NOT reboot but the router just goes away for a while, hopefully > we are using the stable storage in this case too, but what about DAD? Are you worrying about the case where the address/prefix lifetime is too short and it expires while the router goes away? If so, I'd say this case is against the usual sense of RFC2462 and is out of scope of the stable storage technique described in this section. 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 Feb 8 06:35: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 GAA16390 for ; Sun, 8 Feb 2004 06:35:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApnDU-0004JL-Og for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 06:35:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18BZCMP016565 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 06:35:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApnDU-0004J6-KQ for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 06:35:12 -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 GAA16339 for ; Sun, 8 Feb 2004 06:35:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApnDQ-0006HE-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 06:35:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApnCS-0006Cd-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 06:34:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApnBX-000697-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 06:33:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApnBO-0003zL-Ca; Sun, 08 Feb 2004 06:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApnAf-0003yB-Tk for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 06:32:20 -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 GAA16285 for ; Sun, 8 Feb 2004 06:32:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApnAb-00064x-00 for ipv6@ietf.org; Sun, 08 Feb 2004 06:32:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apn9m-000618-00 for ipv6@ietf.org; Sun, 08 Feb 2004 06:31:22 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Apn9N-0005w9-00 for ipv6@ietf.org; Sun, 08 Feb 2004 06:30:57 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AB6411525D; Sun, 8 Feb 2004 20:30:58 +0900 (JST) Date: Sun, 08 Feb 2004 20:31:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: greg.daley@eng.monash.edu.au Cc: Markku Savela , ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay In-Reply-To: <40230318.7000101@eng.monash.edu.au> References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> 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, 06 Feb 2004 13:59:36 +1100, >>>>> Greg Daley said: > The only existing reasons to do MLD on these addresses are > so that MLD proxies, and snooping switchescan request > multicast transport for those addresses. Unless this > is performed correctly, the node performing DAD > will not receive DAD defence NA's, even if the DAD NS is > sent with random delay. > Since there is no random delay with MLD, the reliability issue > still exists in these environments. I believe that this may > have been what what Markku was trying to communicate. Okay, this is a valid point. I actually thought what Markku wanted to say could be something related to MLD snooping, but it was not very clear just from his message, at least to me (so I simply asked his intention in my previous message). For the spec/documentation wise discussion, I'll reply to later messages. 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 Feb 8 08:24: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 IAA18196 for ; Sun, 8 Feb 2004 08:24: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 1Apov2-0001Pe-7Z for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 08:24:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18DOGDH005427 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 08:24:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apov2-0001PS-1F for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 08:24:16 -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 IAA18179 for ; Sun, 8 Feb 2004 08:24:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apov1-0005WN-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 08:24:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apou6-0005SP-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 08:23:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApotM-0005OU-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 08:22:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aposr-00017k-QS; Sun, 08 Feb 2004 08:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apos8-00016j-T4 for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 08:21:17 -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 IAA18120 for ; Sun, 8 Feb 2004 08:21:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apos7-0005Jm-00 for ipv6@ietf.org; Sun, 08 Feb 2004 08:21:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AporB-0005GC-00 for ipv6@ietf.org; Sun, 08 Feb 2004 08:20:18 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Apoqx-0005CY-00 for ipv6@ietf.org; Sun, 08 Feb 2004 08:20:03 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7163A15263; Sun, 8 Feb 2004 22:20:01 +0900 (JST) Date: Sun, 08 Feb 2004 22:20:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Gregory Daley Cc: Jari Arkko , ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay In-Reply-To: <4dae174de5a6.4de5a64dae17@mail1.monash.edu.au> References: <4dae174de5a6.4de5a64dae17@mail1.monash.edu.au> 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, 07 Feb 2004 22:44:19 +1100, >>>>> Gregory Daley said: >> My conclusion is that the right thing is to update RFC 2710 >> and require a delay. This removes collisions from both MLD >> and DAD. > I think that the problem there may be that RFC-2710 is > being replaced by MLDv2. > The IPv6 node reqs document had a MUST for MLDv1, and > SHOULD for MLDv2 (last I saw). This could lead to many > of the hosts exhibiting the colliding behaviour for MLDv1, > even if the changes go into MLDv2. Actually, the latest node req document says SHOULD for MLDv2 and MAY for MLDv1: Nodes that need to join multicast groups SHOULD implement MLDv2 [MLDv2]. However, if the node has applications, which only need support for Any-Source Multicast [RFC3569], the node MAY implement MLDv1 [MLDv1] instead. (draft-ietf-ipv6-node-requirements-07.txt, Section 4.6) Unfortunately, MLDv2 is now in the RFC editor queue, and I'm afraid it's too late to put this kind of change at this stage (even if we agree that the change itself is a good idea). Assuming neither MLDv1 nor MLDv2 can soon be updated, we'll have to deal with the collision issue within rfc2462bis. Possible options, through discussions so far, are: 1. no change in rfc2462bis (expecting MLDv1 and/or MLDv2 will eventually be updated with a random delay) 2. the original proposal of mine (expecting MLDv1 and/or MLDv2 will eventually be updated with a random delay): impose a random delay even for the first NS after the corresponding MLD when the sending node knows there is no delay for the MLD. 3. Greg's suggestion: require a random delay before the first MLD (in rfc2462bis). Now that we are updating rfc2462bis, I don't think option 1 should be taken. This way we'd just neglect an obvious problem while we have a good chance to fix it. The other options may require a change to existing implementations, but I believe we can accept that. Regarding option 2: pro: this can make DAD work if MLD-snooping switches are not used pro: we can keep the issue separate from the MLD specs (we do not have to worry about "spec-violation") con: MLD packets still collide, which also make DAD unworkable if MLD-snooping switches are used Regarding option 3: pro: this is a complete solution of the problem, which works with MLD snooping switches con: this can be regarded as spec-violation, and we may have to worry about conflict with MLD updates in the future I slightly prefer option 1, considering the deployment status of MLD-snooping switches. But it's not a strong opinion. If others prefer option 2 and the wg can agree on this, I'll follow the decision. 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 Feb 8 08:48: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 IAA18632 for ; Sun, 8 Feb 2004 08:48:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AppIH-0002wu-W3 for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 08:48:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18DmH64011330 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 08:48:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AppIH-0002wf-Pm for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 08:48:17 -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 IAA18607 for ; Sun, 8 Feb 2004 08:48:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AppIG-000718-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 08:48:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AppHG-0006wh-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 08:47:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AppGN-0006t8-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 08:46:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AppG7-0002dC-0A; Sun, 08 Feb 2004 08:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AppFM-0002Wh-AE for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 08:45:16 -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 IAA18557 for ; Sun, 8 Feb 2004 08:45:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AppFL-0006pl-00 for ipv6@ietf.org; Sun, 08 Feb 2004 08:45:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AppEN-0006mU-00 for ipv6@ietf.org; Sun, 08 Feb 2004 08:44:16 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AppDt-0006jG-00 for ipv6@ietf.org; Sun, 08 Feb 2004 08:43:45 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 61D0F1525D; Sun, 8 Feb 2004 22:43:44 +0900 (JST) Date: Sun, 08 Feb 2004 22:43:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jari Arkko Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 278] 2462bis for "routers" In-Reply-To: <40237F94.4070104@kolumbus.fi> References: <40237F94.4070104@kolumbus.fi> 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, 06 Feb 2004 13:50:44 +0200, >>>>> Jari Arkko said: > JINMEI Tatuya wrote: >> The autoconfiguration process specified in this document applies only >> to hosts and not routers. Since host autoconfiguration uses >> information advertised by routers, routers will need to be configured >> by some other means. However, it is expected that routers will >> generate link-local addresses using the mechanism described in this >> document. In addition, routers are expected to successfully pass the >> Duplicate Address Detection procedure described in this document on >> all addresses prior to assigning them to an interface. > Strictly speaking, routers need to be configured with prefixes as > well as possibly some routing information, or at least information > sufficient to run routing protocols. > It is not clear to me that their global IP addresses have to configured. > It could be based on its own prefix + IID information, or am I missing > something? Why is there a difference above for link-local and global > addresses? (Note that the quoted part above from my message is not my own proposal; the text is in RFC2462. So, what I'm saying here is my understanding of RFC2462) The difference is whether the configuring node needs an RA from other routers to configure the (link-local or global) address. More specifically, what the above part wants to say is, in my understanding: - Section 5.3 (Creation of Link-Local Addresses) should apply to all nodes: hosts and routers - Section 5.5 (Creation of Global and Site-Local Addresses) should only apply to hosts, not to routers If this is not clear enough in RFC2462, this can be an issue in rfc2462bis. I myself this is already pretty clear in RFC2462 though. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 8 09:19: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 JAA19909 for ; Sun, 8 Feb 2004 09:19:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Appm6-0005Av-3A for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 09:19:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18EJ6t3019887 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 09:19:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Appm5-0005Ad-Sp for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 09:19:05 -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 JAA19765 for ; Sun, 8 Feb 2004 09:19:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Appm4-00025f-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 09:19:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Appkb-0001p4-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 09:17:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Appjj-0001jp-02 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 09:16:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AppZz-00067b-7J for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 09:06:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AppZT-00046u-2N; Sun, 08 Feb 2004 09:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AppYm-00045w-04 for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 09:05:20 -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 JAA19599 for ; Sun, 8 Feb 2004 09:05:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AppYk-00018l-00 for ipv6@ietf.org; Sun, 08 Feb 2004 09:05:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AppXm-000157-00 for ipv6@ietf.org; Sun, 08 Feb 2004 09:04:19 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AppX7-0000wo-00 for ipv6@ietf.org; Sun, 08 Feb 2004 09:03:37 -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 i18E35V27133; Sun, 8 Feb 2004 06:03:05 -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 i18EDWlN014367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 8 Feb 2004 06:13:35 -0800 Message-ID: <4026418E.2060900@innovationslab.net> Date: Sun, 08 Feb 2004 09:02:54 -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: greg.daley@eng.monash.edu.au CC: JINMEI Tatuya / ???? , Markku Savela , ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> In-Reply-To: <40230318.7000101@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greg Daley wrote: > Hi Jinmei, > > JINMEI Tatuya / ???? wrote: > >>>>>>> On Thu, 5 Feb 2004 17:55:08 +0200, Markku Savela >>>>>>> said: >>>>>> >>>>>> >> >>>> It should be noted that the Neighbor Solicitation is usually not the >>>> first message. As stated above, the sending node must join the >>>> solicited-node multicast address prior to sending the Neighbor >>>> Solicitation and an MLD report message [9] for the multicast address >>>> should have been sent at that time. Unfortunately, RFC 2710 [9] does >>>> not request a random delay to avoid race conditions. Thus, if the >>>> sending node interpreted the "first message" literally, it would not >>>> impose a delay for the MLD report or for the Neighbor Solicitation, >>>> making the race conditions worse. This document therefore suggests >>>> the following workaround: even if the Neighbor Solicitation is not >>>> the first message, the same random delay should be imposed when the >>>> sending node knows the Neighbor Solicitation can be synchronized with >>>> other nodes. This includes the first Neighbor Solicitation after the >>>> MLD report message in the above case. >>> >>> >> >>> This is silly! I thought the reason for the random delay was to >>> prevent simultaneus packet sending of all hosts on the link, if they >>> boot up at same time (for example after power fail). >> >> >> >>> Now, this MLD report is going to be collided (mostly lost anyway), >>> because every node is sending on the link at same time. >> >> >> >>> If you are not delaying the MLD, there is really no point in delaying >>> the DAD either... >> >> >> >> Sorry, I don't see the point. With the current RFC2710 and RFC2462 in >> the power failure (or something similar) case, MLD reports are >> collided, and then NS for DAD are also collied. >> >> With the proposed resolution, MLD reports are collided, but NS for DAD >> are not (depending on the variance of random timers). >> >> I proposed the resolution because I thought the former is worse than >> the latter. So, I'd see your point if you said the change is *not so >> effective* because we still have collisions. But I don't see why you >> called it "silly". > > > The simultaneous transmission issue is principally a > reliability issue. There is some chance on certain link-layers > that packets will be significantly delayed or lost when > simulataneous transmission occurs. > > There are very few reasons why one would require MLD reports > on link local solicited nodes addresses. > > The only existing reasons to do MLD on these addresses are > so that MLD proxies, and snooping switchescan request > multicast transport for those addresses. Unless this > is performed correctly, the node performing DAD > will not receive DAD defence NA's, even if the DAD NS is > sent with random delay. This is the case. MLD Report messages on link-local groups is to ensure the proper behavior in snooping switches. > > Since there is no random delay with MLD, the reliability issue > still exists in these environments. I believe that this may > have been what what Markku was trying to communicate. Group management protocols can be considered a low-level member of the routing protocols. That means, random delays in sending state changes affect the routing/forwarding infrastructure of the network. Introducing delays in the sending of those state changes doesn't seem to be the approach to take here. And reliability is addressed by scheduling multiple Report messages to be transmitted. Keep in mind that there is a delay invoked for sending a Report when it is triggered by a valid Query message. But that will not typically apply to the NDP case. > > I do not think we should be modifying every node to suit > MLD snooping, but it is possible to perhaps suggest > a random delay for _both_ the MLD report _and_ the DAD > NS (but no explicit delay between them). The DAD NS must > come after the MLD report though. Given my point above, I would argue that we shouldn't add a delay to MLD messages. The MLD Report will get generated as soon as the ND performs the ADD_MEMBERSHIP socket call on the solicited-node address. If the ND code then introduces a delay after that for the initial message the ordering should be ensured and a random delay generated. > > In this case, the node could start listenting to the group > before sending an MLD report. This is different to MLD/MLDv2, > but will not hurt, since the DAD NS is the principle > trigger for multicast traffic to that solicited nodes' address. True, nodes can listen to for a group without explicitly joining it. > > In snooping environments, the node wouldn't get any messages > to the group until the MLD report was sent. > In any case, it avoids the simultaneous transmission problem. > > In some systems, the ordering of MLD-report and NS > cannot be guaranteed on the output queue. Before transmitting > the DAD NS, the node should ensure that either there has been > sufficient time between MLD transmission and NS, in order > to guarantee packet ordering on the link. > Alternatively, explicit indication that transmission has occurred > would achieve the same purpose. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 8 09:29: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 JAA20211 for ; Sun, 8 Feb 2004 09:29: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 1Appvx-0005xJ-3W for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 09:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18ETHTQ022887 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 09:29:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Appvw-0005x4-VE for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 09:29:17 -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 JAA20185 for ; Sun, 8 Feb 2004 09:29:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Appvv-0002y3-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 09:29:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Appuy-0002tr-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 09:28:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Appu2-0002q7-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 09:27:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apptm-0005bX-9V; Sun, 08 Feb 2004 09:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Appt4-0005aj-ID for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 09:26:18 -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 JAA20132 for ; Sun, 8 Feb 2004 09:26:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Appt2-0002ll-00 for ipv6@ietf.org; Sun, 08 Feb 2004 09:26:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apps8-0002iJ-00 for ipv6@ietf.org; Sun, 08 Feb 2004 09:25:20 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1ApprX-0002ei-00 for ipv6@ietf.org; Sun, 08 Feb 2004 09:24:43 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2351E15265; Sun, 8 Feb 2004 23:24:42 +0900 (JST) Date: Sun, 08 Feb 2004 23:24:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 278] 2462bis for "routers" 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, 5 Feb 2004 17:32:03 -0800 (PST), >>>>> Erik Nordmark said: > So do we or do we not want to > 1. specify the per-interface router definition > 2. specify how RFC 2461 (and 62) behave on a multihomed node Hmm, I see the discussion about the definition of per-interface router leads us to the more generic (and difficult) issues: ND/autoconf for a multihomed node (host). Although opinions on this may vary, my impression is that the generic issue is beyond the scope of 2461/2462bis. It would require a large amount of time for discussion and would require significant changes to implementations. This does not meet the original purpose of 2461/2462bis. However, I also think per-interface stateless address autoconfiguration is relatively trivial and can be consistent with the current RFC2461 spec (and with 2461bis probably). That is, I think we can allow a node to receive an RA on a non-advertising interface (per RFC2461) to configure a global address on the interface without going into further on the multihome issues. In any event, I don't have a strong opinion on this. If we can quickly reach a consensus about the per-interface address autoconfiguration, I'll revise the rfc2462bis text accordingly. Otherwise, I'd simply leave the current text as is (it would be a bit ambiguous as currently is, though). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 8 12:22: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 MAA25360 for ; Sun, 8 Feb 2004 12:22: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 1ApsdT-0005OQ-6S for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 12:22:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18HMNFL020724 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 12:22:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApsdT-0005OB-2L for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 12:22: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 MAA25305 for ; Sun, 8 Feb 2004 12:22:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApsdR-0000KI-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 12:22:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApscS-0000Db-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 12:21:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApsbV-00006u-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 12:20:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApsbG-0004k8-FU; Sun, 08 Feb 2004 12:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApsaU-0004hJ-Dk for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 12:19:18 -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 MAA25194 for ; Sun, 8 Feb 2004 12:19:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApsaT-0007jA-00 for ipv6@ietf.org; Sun, 08 Feb 2004 12:19:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApsZ8-0007SF-00 for ipv6@ietf.org; Sun, 08 Feb 2004 12:17:55 -0500 Received: from web80505.mail.yahoo.com ([66.218.79.75]) by ietf-mx with smtp (Exim 4.12) id 1ApsX0-0006y7-00 for ipv6@ietf.org; Sun, 08 Feb 2004 12:15:42 -0500 Message-ID: <20040208171511.77253.qmail@web80505.mail.yahoo.com> Received: from [63.197.18.101] by web80505.mail.yahoo.com via HTTP; Sun, 08 Feb 2004 09:15:11 PST Date: Sun, 8 Feb 2004 09:15:11 -0800 (PST) From: Fred Templin Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay To: jinmei@isl.rdc.toshiba.co.jp Cc: ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-619340665-1076260511=:72874" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-619340665-1076260511=:72874 Content-Type: text/plain; charset=us-ascii Jinmei, Do you have a timeframe for when you will be posting RFC2462(bis) to the I-D repository? Thanks - Fred osprey67@yahoo.com JINMEI Tatuya / $B?@L@C#:H(B wrote: >>>>> On Sun, 08 Feb 2004 09:02:54 -0500, >>>>> Brian Haberman said: > Given my point above, I would argue that we shouldn't add a delay to > MLD messages. So, do you have any opinion among the options I raised in this thread? 1. no change in rfc2462bis (expecting MLDv1 and/or MLDv2 will eventually be updated with a random delay) 2. the original proposal of mine (expecting MLDv1 and/or MLDv2 will eventually be updated with a random delay): impose a random delay even for the first NS after the corresponding MLD when the sending node knows there is no delay for the MLD. 3. Greg's suggestion: require a random delay before the first MLD (in rfc2462bis). (including "4. none of above"). Apparently you'd reject option 3 from your point. I also know that you are NOT expecting MLDv1/v2 will be updated with a random delay, even if you prefer option 1 or 2 itself. 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 -------------------------------------------------------------------- --0-619340665-1076260511=:72874 Content-Type: text/html; charset=us-ascii
Jinmei,
 
Do you have a timeframe for when you will be posting RFC2462(bis)
to the I-D repository?
 
Thanks - Fred
osprey67@yahoo.com

JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp> wrote:
>>>>> On Sun, 08 Feb 2004 09:02:54 -0500,
>>>>> Brian Haberman said:

> Given my point above, I would argue that we shouldn't add a delay to
> MLD messages.

So, do you have any opinion among the options I raised in this thread?

1. no change in rfc2462bis (expecting MLDv1 and/or MLDv2 will
eventually be updated with a random delay)
2. the original proposal of mine (expecting MLDv1 and/or MLDv2 will
eventually be updated with a random delay):
impose a random delay even for the first NS after the corresponding
MLD when the sending node knows there is no delay for the MLD.
3. Greg's suggestion:
require a random delay before the first MLD (in rfc2462bis).

(including "4. none of above").

Apparently you'd reject option 3 from your point. I also know that
you! are NOT expecting MLDv1/v2 will be updated with a random delay,
even if you prefer option 1 or 2 itself.

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
--------------------------------------------------------------------
--0-619340665-1076260511=:72874-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 8 12:44: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 MAA25647 for ; Sun, 8 Feb 2004 12:44:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apsym-0006ia-M3 for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 12:44:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18HiOI1025818 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 12:44:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apsym-0006iL-Go for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 12:44:24 -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 MAA25635 for ; Sun, 8 Feb 2004 12:44:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apsyl-0001jb-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 12:44:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apsxm-0001f8-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 12:43:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Apswq-0001au-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 12:42:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApswU-0006CS-8W; Sun, 08 Feb 2004 12:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apsvr-0006Bc-Py for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 12:41: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 MAA25582 for ; Sun, 8 Feb 2004 12:41:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apsvq-0001Vy-00 for ipv6@ietf.org; Sun, 08 Feb 2004 12:41:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apsuw-0001Ru-00 for ipv6@ietf.org; Sun, 08 Feb 2004 12:40:27 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ApsuS-0001O5-00 for ipv6@ietf.org; Sun, 08 Feb 2004 12:39:56 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 8E0096A90B; Sun, 8 Feb 2004 19:39:49 +0200 (EET) Message-ID: <40267400.2030009@kolumbus.fi> Date: Sun, 08 Feb 2004 19:38:08 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman , JINMEI Tatuya / ???? Cc: greg.daley@eng.monash.edu.au, Markku Savela , ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> In-Reply-To: <4026418E.2060900@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian Haberman wrote: > Group management protocols can be considered a low-level member > of the routing protocols. That means, random delays in sending > state changes affect the routing/forwarding infrastructure of the > network. Introducing delays in the sending of those state changes > doesn't seem to be the approach to take here. And reliability is > addressed by scheduling multiple Report messages to be transmitted. I agree that group management protocols can be consider to be routing protocols. But in the case that we are talking about here, the multicast address is a link local mc address. As a result, the routing/forwarding infrastructure of the network is not affected, as far as I can see. It is possible that some L2 device is affected. And the router will process the MLD message. But (perhaps I'm dense) I don't see how a router would change its routing or forwarding behaviour due to seeing a change in the link local multicast behaviour. Even if there would be a change, I do not see why it follows that delays are prohibited. As I see it, we have a number of somewhat conflicting factors: - desire to provide service in a timely manner - desire to avoid packet storms upon booting many nodes simultaneously - desire to accommodate snooping switches The second factor may dictate that some delay be used, even if the first factor would lead to sending all messages immediately. Also, Jinmei wrote: > Regarding option 3: > pro: this is a complete solution of the problem, which works with > MLD snooping switches > con: this can be regarded as spec-violation, and we may have to > worry about conflict with MLD updates in the future Why do you consider this as a spec violation? Because then 2462bis would appear to say something that is different than what MLD specs say, or because ND specs should not say anything about MLD? I think the right engineering solutions should be adopted, without too much regard into the documentation boundaries. Having said that, if you worry about the document boundary, you can simply say "delay joining to the multicast group by a random delay. Once you have joined, send the ND packet." --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 8 14:34: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 OAA29095 for ; Sun, 8 Feb 2004 14:34:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApuhI-0004Xj-AO for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 14:34:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18JYSgu017456 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 14:34:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApuhH-0004XT-QG for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 14:34: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 OAA29090 for ; Sun, 8 Feb 2004 14:34:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApuhF-0002sT-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 14:34:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApugJ-0002p7-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 14:33:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApugE-0002lo-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 14:33:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apuft-0004EF-Bo; Sun, 08 Feb 2004 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApufM-0004Dk-B8 for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 14:32: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 OAA29062 for ; Sun, 8 Feb 2004 14:32:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApufJ-0002lA-00 for ipv6@ietf.org; Sun, 08 Feb 2004 14:32:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApueM-0002hp-00 for ipv6@ietf.org; Sun, 08 Feb 2004 14:31:27 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1Apudf-0002bL-00 for ipv6@ietf.org; Sun, 08 Feb 2004 14:30:43 -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 i18JUCV28859; Sun, 8 Feb 2004 11:30:12 -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 i18JeglN015355 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 8 Feb 2004 11:40:45 -0800 Message-ID: <40268E36.8050109@innovationslab.net> Date: Sun, 08 Feb 2004 14:29:58 -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: Jari Arkko CC: JINMEI Tatuya / ???? , greg.daley@eng.monash.edu.au, Markku Savela , ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40267400.2030009@kolumbus.fi> In-Reply-To: <40267400.2030009@kolumbus.fi> 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 Jari Arkko wrote: > Brian Haberman wrote: > >> Group management protocols can be considered a low-level member >> of the routing protocols. That means, random delays in sending >> state changes affect the routing/forwarding infrastructure of the >> network. Introducing delays in the sending of those state changes >> doesn't seem to be the approach to take here. And reliability is >> addressed by scheduling multiple Report messages to be transmitted. > > > I agree that group management protocols can be consider to be > routing protocols. But in the case that we are talking about > here, the multicast address is a link local mc address. As a result, > the routing/forwarding infrastructure of the network is not affected, > as far as I can see. It is possible that some L2 device is affected. > And the router will process the MLD message. But (perhaps I'm dense) > I don't see how a router would change its routing or forwarding > behaviour due to seeing a change in the link local multicast > behaviour. In the case of link-local addresses, a router would not change its behavior. L2 switches that implement snooping will. > > Even if there would be a change, I do not see why it follows that > delays are prohibited. As I see it, we have a number of somewhat > conflicting factors: > > - desire to provide service in a timely manner 2710 does this by mandating that nodes that join a multicast group send N Report messages immediately. > - desire to avoid packet storms upon booting many nodes simultaneously 2710 accomplishes this by using message suppression. If a node hears a Report for the same group, it cancels the transmission of any pending Reports it has for the group. > - desire to accommodate snooping switches > > The second factor may dictate that some delay be used, even > if the first factor would lead to sending all messages immediately. > > Also, Jinmei wrote: > >> Regarding option 3: >> pro: this is a complete solution of the problem, which works with >> MLD snooping switches >> con: this can be regarded as spec-violation, and we may have to >> worry about conflict with MLD updates in the future > > > Why do you consider this as a spec violation? Because then 2462bis > would appear to say something that is different than what MLD specs > say, or because ND specs should not say anything about MLD? It is not that it shouldn't say anything about MLD, I believe the comment is directed at the fact that in this case, 2462bis would contradict what is documented in the current MLD specs. > > I think the right engineering solutions should be adopted, without > too much regard into the documentation boundaries. Having said that, > if you worry about the document boundary, you can simply say "delay > joining to the multicast group by a random delay. Once you have joined, > send the ND packet." So you want to impose this delay factor on all multicast groups? Or do you want the MLD spec to be more complicated and say do X for link-local groups and Y for all other scopes? I definitely want to avoid having that kind of logic in the MLD specs. Overall, I think the biggest issue here is the differences in the way MLD and ND were designed. And we have additional complexity in the fact that MLDv1 and MLDv2 have some fundamental differences in how they behave. 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 Sun Feb 8 14:38: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 OAA29427 for ; Sun, 8 Feb 2004 14:38:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApulA-0005Pm-Jr for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 14:38:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18JcSfX020808 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 14:38:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApulA-0005PX-Eo for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 14:38: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 OAA29388 for ; Sun, 8 Feb 2004 14:38:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apul7-0003Eo-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 14:38:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApukC-000396-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 14:37:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApujF-00033F-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 14:36:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apuiq-0004eh-14; Sun, 08 Feb 2004 14:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApuiJ-0004bm-OY for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 14:35:31 -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 OAA29177 for ; Sun, 8 Feb 2004 14:35:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApuiH-0002xX-00 for ipv6@ietf.org; Sun, 08 Feb 2004 14:35:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApuhJ-0002t7-00 for ipv6@ietf.org; Sun, 08 Feb 2004 14:34:29 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1ApugZ-0002lm-00 for ipv6@ietf.org; Sun, 08 Feb 2004 14:33:43 -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 i18JXCV28870; Sun, 8 Feb 2004 11:33:12 -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 i18JhilN015361 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 8 Feb 2004 11:43:47 -0800 Message-ID: <40268EED.1080005@innovationslab.net> Date: Sun, 08 Feb 2004 14:33:01 -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: JINMEI Tatuya CC: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@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 I don't like the idea of a random delay in the MLD Reports. As I said in another note, it either adversely affects the logic in the MLD specs or causes application delays for non-LL groups. Is having a delay in the NS transmission alone sufficient? So that the Report is sent immediately and the NS is delayed. Regards, Brian JINMEI wrote: >>>>>>On Sun, 08 Feb 2004 09:02:54 -0500, >>>>>>Brian Haberman said: > > >>Given my point above, I would argue that we shouldn't add a delay to >>MLD messages. > > > So, do you have any opinion among the options I raised in this thread? > > 1. no change in rfc2462bis (expecting MLDv1 and/or MLDv2 will > eventually be updated with a random delay) > 2. the original proposal of mine (expecting MLDv1 and/or MLDv2 will > eventually be updated with a random delay): > impose a random delay even for the first NS after the corresponding > MLD when the sending node knows there is no delay for the MLD. > 3. Greg's suggestion: > require a random delay before the first MLD (in rfc2462bis). > > (including "4. none of above"). > > Apparently you'd reject option 3 from your point. I also know that > you are NOT expecting MLDv1/v2 will be updated with a random delay, > even if you prefer option 1 or 2 itself. > > 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 Sun Feb 8 15:36: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 PAA01836 for ; Sun, 8 Feb 2004 15:36:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApvfJ-0000uy-02 for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 15:36:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18KaSaP003522 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 15:36:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApvfI-0000uj-QN for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 15:36: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 PAA01808 for ; Sun, 8 Feb 2004 15:36:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApvfH-00078F-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 15:36:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApveI-00073I-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 15:35:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApvdJ-0006xR-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 15:34:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apvcv-0000Yp-H8; Sun, 08 Feb 2004 15:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApvcP-0000YN-2W for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 15:33: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 PAA01663 for ; Sun, 8 Feb 2004 15:33:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApvcN-0006va-00 for ipv6@ietf.org; Sun, 08 Feb 2004 15:33:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApvbS-0006sK-00 for ipv6@ietf.org; Sun, 08 Feb 2004 15:32:31 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Apvb2-0006om-00 for ipv6@ietf.org; Sun, 08 Feb 2004 15:32:04 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i18KVoHd011219; Sun, 8 Feb 2004 22:31:50 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i18KVlPS011214; Sun, 8 Feb 2004 22:31:47 +0200 Date: Sun, 8 Feb 2004 22:31:47 +0200 Message-Id: <200402082031.i18KVlPS011214@burp.tkv.asdf.org> From: Markku Savela To: brian@innovationslab.net CC: jari.arkko@kolumbus.fi, jinmei@isl.rdc.toshiba.co.jp, greg.daley@eng.monash.edu.au, ipv6@ietf.org In-reply-to: <40268E36.8050109@innovationslab.net> (message from Brian Haberman on Sun, 08 Feb 2004 14:29:58 -0500) Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40267400.2030009@kolumbus.fi> <40268E36.8050109@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=none autolearn=no version=2.60 > From: Brian Haberman > > - desire to avoid packet storms upon booting many nodes simultaneously > > 2710 accomplishes this by using message suppression. If a node hears a > Report for the same group, it cancels the transmission of any pending > Reports it has for the group. Above will totally fail with ND multicast groups. Their design goal is that each host is only on one group. It is highly unlikely that listening would hear a duplicate join for the solicited node multicast address. I've already said my differing opinion on this way back earlier, but apparently I lost the vote. But, just to make clear: sending MLD messages for link local multicast groups is waste of time and specification effort. If you have layer 2 sniffers, they can (and most likely must) sniff the normal ND traffic too. A ND DAD contains exactly the same information content as MLD join for the solicited node group. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 8 17:28: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 RAA04868 for ; Sun, 8 Feb 2004 17:28:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxOo-0007uj-Jj for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 17:27:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18MRYXV030415 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 17:27:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxOo-0007uU-ET for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 17:27:34 -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 RAA04843 for ; Sun, 8 Feb 2004 17:27:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApxOm-0007Pg-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 17:27:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApxNn-0007KN-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 17:26:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApxMr-0007EV-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 17:25:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxMO-0007Ve-2H; Sun, 08 Feb 2004 17:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxI7-0007Bm-FG for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 17:20: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 RAA04623 for ; Sun, 8 Feb 2004 17:20:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApxI5-0006qW-00 for ipv6@ietf.org; Sun, 08 Feb 2004 17:20:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApxHE-0006lg-00 for ipv6@ietf.org; Sun, 08 Feb 2004 17:19:44 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ApxGW-0006dw-00; Sun, 08 Feb 2004 17:19:00 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i18MIRGv007471; Sun, 8 Feb 2004 14:18:27 -0800 (PST) Received: from cisco.com (rtp-vpn1-400.cisco.com [10.82.225.144]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQC15232; Sun, 8 Feb 2004 14:18:25 -0800 (PST) Message-ID: <4026B5B0.2050707@cisco.com> Date: Sun, 08 Feb 2004 14:18:24 -0800 From: Rajiv Raghunarayan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: ipv6mib@ibr.cs.tu-bs.de, ipv6@ietf.org, tsvwg@ietf.org Subject: Re: [ipv6mib] Discontinuity timer for TCP-MIB counters References: <402302BA.4020000@cisco.com> <200402060855.i168t1iV015037@hansa.ibr.cs.tu-bs.de> In-Reply-To: <200402060855.i168t1iV015037@hansa.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Juergen, Thanks for the feedback. My comments inline. Juergen Schoenwaelder wrote: >>>>>>Rajiv Raghunarayan writes: > > > Rajiv> The IESG review suggested that we provide a discontinuity timer > Rajiv> for the counters in the mib - could be via sysUpTime or a new > Rajiv> discontinuity object. But we state it either way. > > Here are my 3 thoughs on this: > > 1) So far, sysUpTime has been used by the existing TCP-MIB objects. > Introducing a new discontinuity indicator now raises the question > whether doing so breaks existing implementations. Yep. It would probably break implementations if 2) were to be an incorrect assumption for any implementation. Else, I think we shouldn't be affecting other implementations (but those case wouldn't need a separate discontinuity indicator as well!)? > > 2) Personally, I doubt that there will be many implementations where > TCP can experience discontinuities that do not also affect other > parts of the networking stack or the whole system. I suspected that, but wasn't sure. > > 3) I do see the problem that sysUpTime might be more frequently reset > as we like due to some other MIBs which do not use explicit > discontinuity indicators and experience more frequent > resets. However, the root of the problem is then really in those > MIBs, not in the TCP-MIB. (Sure, by introducing a discontinuity > indicator for the TCP-MIB we can protect against other misbehaving > MIBs - but is this going to set a precedence which at the end > requires a CLR that better every MIB module has at least one, > perhaps multiple discontinuity indicators?) Agreed. > > In the case of the TCP-MIB, I believe 1) is the killing argument. To > introduce a new discontinuity indicator changes the implicit semantics > of existing objects and would require to introduce new objects, which > I think is prohibitive. > > Conclusion: Spell out that sysUpTime is used as a discontinuity > indicator for the counters. I've modified the mib to indicate it - will submit the mib, if I do not receive any arguments to the contrary in the next couple of days. Thanks, Rajiv. > > /js > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 8 18:07: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 SAA06121 for ; Sun, 8 Feb 2004 18:07:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apy0b-0004mD-Ck for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 18:06:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18N6b1A018355 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 18:06:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apy0b-0004ly-8I for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 18:06:37 -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 SAA06078 for ; Sun, 8 Feb 2004 18:06:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apy0Y-0002PP-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 18:06:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apxzc-0002LU-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 18:05:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApxzS-0002Hi-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 18:05:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apxz5-00046o-6d; Sun, 08 Feb 2004 18:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apxye-000400-L0 for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 18:04:36 -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 SAA05854 for ; Sun, 8 Feb 2004 18:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apxyb-0002GU-00 for ipv6@ietf.org; Sun, 08 Feb 2004 18:04:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apxxg-0002Bu-00 for ipv6@ietf.org; Sun, 08 Feb 2004 18:03:37 -0500 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1Apxx3-00027v-00 for ipv6@ietf.org; Sun, 08 Feb 2004 18:02:57 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id SAA19157; Sun, 8 Feb 2004 18:02:50 -0500 (EST) Date: Sun, 8 Feb 2004 18:02:50 -0500 (EST) From: Dan Lanciani Message-Id: <200402082302.SAA19157@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.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=2.2 required=5.0 tests=MLM autolearn=no version=2.60 Alain Durand wrote: |I think people are confusing the notion of 'permanent' and 'stable' |addresses. On the contrary, I think that it has not yet been demonstrated that they are different for practical purposes. An address that has been around for 100 years but which disappears 24 hours after you start using it is not stable. |The case made for those local addresses was to be independent from ISP, |either to isolate from ISP changes or in the case of intermittent |connection. The case was made for addresses that are independent of address renting entities that can (by error or intent) invalidate the addresses at any time. It just happens that at the moment the ISPs are the primary source of rented addresses for most end users. |This require 'stable' addresses. i.e addresses that are stable for a |long enough period of |time, here define long enough by for the lifetime of your operations. |This has nothing to do with 'permanent', which means until the end of |the times. In the past we were unable to come up with a value for ``long enough'' which is in any meaningful way different from ``forever.'' |So, I argue that 'permanent' is not a technical requirement. Are you are prepared to come up with a useful definition of ``long enough'' to replace ``permanent?'' Or do you just want to remove ``permanent'' from the requirements with no replacement, IMHO destroying the value of these addresses? If you do have a useful definition, why didn't you propose it when this issue was being discussed? |Now, if we have multiple registries, it is up to them to find a |business model |that makes sense for them. If it is easier/simpler to come with a one |time fee |model, fine. If they think they cannot recover the costs of operation |like that, |they may opt for a recurrent fee model. And of course, the logical extension of this is to note that you can already rent a block of addresses from an ISP so we really don't need these new non-permanent addresses at all. We've been down this road before. |This would not mean that the |prefixes won't |be stable, they would be as long as their owner keeps maintaining the |subscription. You are making the standard fallacious assumption that the allocation service/ ISP/whatever is infallible and philanthropic. What happens when the service goes bankrupt? Don't imagine that the bankruptcy court is going to ignore that subscription income and just let the customers keep their addresses. What happens when the service gets greedy and (after enough people are dependent) raises the rates? You think that can be avoided by contract? That brings us back to the question of how long a contract is ''long enough?'' |So I argue that the choice of a one time fee vs recurrent fee is an |operational/economical |discussion that would be better kept out of this document. I argue that allowing recurring fees destroys the value of these addresses. |As a side note, there are several issues with the 'permanent |allocation, one time fee' model: | |- This is really symptomatic of a consumer society where people do not |think about waste management, | where resources are perceived unlimited and it is free spending. This whole endless addressing debate is symptomatic of a society that has discovered a way to create ongoing revenue streams from abstract number allocations by artificially limiting their availability--and is loathe to give it up. The scarcity argument worked (with a lot of help from "reserved" blocks) for IPv4. IPv6 was supposed to eliminate the address scarcity, but outdated routing scaling arguments kept that vast new address space out of the hands of end users, preserving the rental status quo. Now finally we have an address format that effectively costs too little to measure and we are falling back to ecological ``waste'' arguments to jack up its price. This is really scraping the bottom of the barrel. |- The business model is based on the assumption that the new comers |will pay for the | management of the database so the previous customer won't have to pay |for it. | I think this is completely broken, as it is fundamentally a pyramid |scheme. | Remember those chain letters asking you to send money to 10 people |and forward it to 20 others? Your analogy is so wrong that it is difficult to know where to begin to explain its flaws. Consider that the per-victim promised outlay in a pyramid scheme remains more-or-less constant as the number of victims grows without bounds. The per-address cost of maintaining a database shrinks rapidly as the number of addresses grows because it is the *total* cost that remains more-or-less constant. For the database in question, the total cost is small enough in the first place that the per-address cost is likely too small to measure accurately, assuming any reasonable number of subscribers. (And if there are no subscribers we really don't care about the whole thing.) In any case, the actual cost of maintaining an individual address would be swamped by the costs of billing the renter for that address. But even the premise behind your analogy is wrong. A one-time payment does not in any way imply that ``new comers'' are paying to support previous customers. The future value of money is well understood. If the cost of maintaining an address in the database can be expressed as a recurring fee then it can also be expressed as a one-time fee. A recurring fee is just a way to hide the true cost from the customer. It also decouples the fee from the cost of maintaining the database (because the billing and other administrative overhead will dominate the computation), allowing lots of wiggle room for little extra expenses. And most people won't even do the annuity calculation to determine their equivalent up-front cost. |- It is unclear what happen when a company is acquired by another one |or when | the addresses are registered to a person and that person dies. | Are those addresses considered as part of the assets of the |company/person? Are they transferable? The answers must be yes & yes if this proposal is to be useful. |- It would be the first time that the IETF would sanctify the sale (and |not the stewardship) of | chunks of address space. This is a fundamental departure from what |has been done | in the past. In the beginning, address assignments were in effect permanent. The whole multi-level-marketing address rental system (which itself was a fundamental departure from what had been done in the past) grew out of a supposed need to conserve routing table space. The reason was later changed to a need to conserve actual address space and recently has again become a routing argument (this time computation). None of these excuses apply to the local address format being discussed, and the argument that it is now tradition to deny end users address space is not compelling. 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 Sun Feb 8 18:12: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 SAA06633 for ; Sun, 8 Feb 2004 18:12:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apy5U-0006lA-Rb for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 18:11:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18NBeea025977 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 18:11:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apy5U-0006kt-Kd for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 18:11:40 -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 SAA06584 for ; Sun, 8 Feb 2004 18:11:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apy5S-0002nm-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 18:11:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apy4Q-0002j4-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 18:10:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Apy46-0002fa-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 18:10:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apy3v-0005ts-I7; Sun, 08 Feb 2004 18:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apy3W-0005nP-8Y for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 18:09: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 SAA06411 for ; Sun, 8 Feb 2004 18:09:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apy3T-0002f1-00 for ipv6@ietf.org; Sun, 08 Feb 2004 18:09:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apy2X-0002ae-00 for ipv6@ietf.org; Sun, 08 Feb 2004 18:08:37 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1Apy1i-0002RP-00 for ipv6@ietf.org; Sun, 08 Feb 2004 18:07:47 -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 i18N7GV30027; Sun, 8 Feb 2004 15:07:16 -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 i18NHjlN016246 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 8 Feb 2004 15:17:49 -0800 Message-ID: <4026C112.2070406@innovationslab.net> Date: Sun, 08 Feb 2004 18:06:58 -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: Markku Savela CC: jari.arkko@kolumbus.fi, jinmei@isl.rdc.toshiba.co.jp, greg.daley@eng.monash.edu.au, ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40267400.2030009@kolumbus.fi> <40268E36.8050109@innovationslab.net> <200402082031.i18KVlPS011214@burp.tkv.asdf.org> In-Reply-To: <200402082031.i18KVlPS011214@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Markku, Markku Savela wrote: >>From: Brian Haberman > > >>>- desire to avoid packet storms upon booting many nodes simultaneously >> >>2710 accomplishes this by using message suppression. If a node hears a >>Report for the same group, it cancels the transmission of any pending >>Reports it has for the group. > > > Above will totally fail with ND multicast groups. Their design goal is > that each host is only on one group. It is highly unlikely that > listening would hear a duplicate join for the solicited node multicast > address. It is not a failure, it is just not useful for solicited-node multicast addresses. But, you also snipped a part of the note that pointed out that ND and MLD were designed with differing techniques to deal with reliability. > > I've already said my differing opinion on this way back earlier, but > apparently I lost the vote. But, just to make clear: > > sending MLD messages for link local multicast groups is waste of > time and specification effort. If you have layer 2 sniffers, they > can (and most likely must) sniff the normal ND traffic too. A ND DAD > contains exactly the same information content as MLD join for the > solicited node group. And the MLD Report for the solicted-node multicast address will cause the L2 sniffer to forward the ND DAD message to any other port that has joined the same multicast group. If two nodes are DAD'ing for the same unicast address, the L2 sniffer will need to forward those NS messages to all ports where the solicited-node address has been joined. 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 Sun Feb 8 21:10: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 VAA12052 for ; Sun, 8 Feb 2004 21:10: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 1Aq0s7-0008NP-4B for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 21:10:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i192A3es032190 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 21:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq0s6-0008N4-Qh for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 21:10: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 VAA12046 for ; Sun, 8 Feb 2004 21:10:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq0s4-0001Vb-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 21:10:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq0rS-0001OT-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 21:09:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq0qe-0001Fi-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 21:08:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq0qA-0007wT-O6; Sun, 08 Feb 2004 21:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq0pu-0007rI-Op for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 21:07:46 -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 VAA11864 for ; Sun, 8 Feb 2004 21:07:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq0ps-0001CA-00 for ipv6@ietf.org; Sun, 08 Feb 2004 21:07:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq0ow-00017D-00 for ipv6@ietf.org; Sun, 08 Feb 2004 21:06:47 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aq0oH-00012a-00 for ipv6@ietf.org; Sun, 08 Feb 2004 21:06:06 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AFF6D15272; Mon, 9 Feb 2004 11:05:59 +0900 (JST) Date: Mon, 09 Feb 2004 11:06:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Fred Templin Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay In-Reply-To: <20040208171511.77253.qmail@web80505.mail.yahoo.com> References: <20040208171511.77253.qmail@web80505.mail.yahoo.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 >>>>> On Sun, 8 Feb 2004 09:15:11 -0800 (PST), >>>>> Fred Templin said: > Do you have a timeframe for when you will be posting RFC2462(bis) > to the I-D repository? I'll post it as a wg document (draft-ietf-ipv6-rfc2462bis-00.txt) by the cutoff date for initial submissions (Feb. 9th). That is, I'll post the draft very soon. 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 Feb 8 21:33: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 VAA12576 for ; Sun, 8 Feb 2004 21:33:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1E5-0001We-St for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 21:32:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i192Wjas005654 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 21:32:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1E4-0001T7-Vi for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 21:32: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 VAA12564 for ; Sun, 8 Feb 2004 21:32:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1E2-0003CF-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 21:32:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq1D6-00037p-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 21:31:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1Ci-00033O-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 21:31:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1CQ-0000xe-Cy; Sun, 08 Feb 2004 21:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1C8-0000wO-84 for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 21:30:44 -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 VAA12516 for ; Sun, 8 Feb 2004 21:30:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1C5-00032P-00 for ipv6@ietf.org; Sun, 08 Feb 2004 21:30:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq1B7-0002yT-00 for ipv6@ietf.org; Sun, 08 Feb 2004 21:29:42 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1AS-0002uU-00 for ipv6@ietf.org; Sun, 08 Feb 2004 21:29:00 -0500 Received: from localhost ([130.194.13.84]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L6EAEW1QY291ZPMN@vaxc.its.monash.edu.au> for ipv6@ietf.org; Mon, 09 Feb 2004 11:38:24 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 90D3139C018; Mon, 09 Feb 2004 11:38:18 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 73F192DC012; Mon, 09 Feb 2004 11:38:18 +1100 (EST) Date: Mon, 09 Feb 2004 11:38:18 +1100 From: Greg Daley Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay To: Brian Haberman Cc: JINMEI Tatuya , ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <4026D67A.2090007@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40268EED.1080005@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 Hi Brian, Brian Haberman wrote: > I don't like the idea of a random delay in the MLD Reports. As I > said in another note, it either adversely affects the logic in the > MLD specs or causes application delays for non-LL groups. > > Is having a delay in the NS transmission alone sufficient? So that > the Report is sent immediately and the NS is delayed. > > Regards, > Brian I think what Jari asked was not a modification to the semantics of reporting group joins. I think that what Jari proposed was actually that we delay DAD (which entails both the operation of beginning listening to a group and the NS transmission). To put it another way, we don't actually configure the address until the random delay timer has expired. The delay's expiration is a precondition for address configuration, in this case. In this way, joining the group occurs when the group is first listened to (in accordance with MLDvX) and the NS transmission is similarly delayed. Delaying only the NS is insufficient, as the statement in RFC-2462 is for two purposes: 1. Increased reliability of DAD NS tranmission. 2. Protection of the link against packet storms. Relying only on the MLD report replay mechanisms only achieves the first of these goals, and not the second, since the MLD transmissions may be synchronized for the first report. Delaying both provides superior protection of the link, and gains the same reliability mechanisms already available without requiring change to the MLD specifications. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 8 21:48: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 VAA13305 for ; Sun, 8 Feb 2004 21:48:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1SX-0003DP-RB for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 21:47:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i192lfuT012359 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 21:47:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1SX-0003DG-Jk for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 21:47:41 -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 VAA13293 for ; Sun, 8 Feb 2004 21:47:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1SU-0004ZO-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 21:47:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq1RX-0004Vp-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 21:46:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1R5-0004SS-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 21:46:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1Qx-0002vM-3L; Sun, 08 Feb 2004 21:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1Qe-0002um-8U for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 21:45:44 -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 VAA13261 for ; Sun, 8 Feb 2004 21:45:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1Qb-0004Rz-00 for ipv6@ietf.org; Sun, 08 Feb 2004 21:45:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq1Pg-0004OM-00 for ipv6@ietf.org; Sun, 08 Feb 2004 21:44:44 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1PM-0004Kc-00 for ipv6@ietf.org; Sun, 08 Feb 2004 21:44:24 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A703115267; Mon, 9 Feb 2004 11:44:24 +0900 (JST) Date: Mon, 09 Feb 2004 11:44:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay In-Reply-To: <40268EED.1080005@innovationslab.net> References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40268EED.1080005@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 Sun, 08 Feb 2004 14:33:01 -0500, >>>>> Brian Haberman said: > I don't like the idea of a random delay in the MLD Reports. As I > said in another note, it either adversely affects the logic in the > MLD specs or causes application delays for non-LL groups. > Is having a delay in the NS transmission alone sufficient? So that > the Report is sent immediately and the NS is delayed. I read this to mean you support option 2 (but without expecting any future change in the MLD spec). I can live with this, but as others pointed out, this approach may cause a trouble when we are using MLD snooping switches and the first MLD reports for DAD NSs collide: the reports will be lost due to the collisions, then the MLD filter in the snooping switches isn't configured correctly, then DAD NSs can be dropped due to the filter even if there is an address duplication and other nodes are listening to the solicited-multicast group. 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 Feb 8 22: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 WAA14247 for ; Sun, 8 Feb 2004 22:18:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1vg-0005O2-SW for ipv6-archive@odin.ietf.org; Sun, 08 Feb 2004 22:17:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i193HmXw020697 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 22:17:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1vg-0005Nk-8M for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 22:17:48 -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 WAA14233 for ; Sun, 8 Feb 2004 22:17:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1vd-00079E-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 22:17:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq1ui-00074v-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 22:16:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1uO-00070R-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 22:16:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1tz-00053x-QD; Sun, 08 Feb 2004 22:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1tg-00050n-0z for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 22:15:44 -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 WAA14151 for ; Sun, 8 Feb 2004 22:15:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1tc-0006zl-00 for ipv6@ietf.org; Sun, 08 Feb 2004 22:15:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq1si-0006wM-00 for ipv6@ietf.org; Sun, 08 Feb 2004 22:14:44 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1sW-0006sp-00 for ipv6@ietf.org; Sun, 08 Feb 2004 22:14:32 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 70FEE1525D; Mon, 9 Feb 2004 12:14:31 +0900 (JST) Date: Mon, 09 Feb 2004 12:14:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jari Arkko Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay In-Reply-To: <40267400.2030009@kolumbus.fi> References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40267400.2030009@kolumbus.fi> 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 Sun, 08 Feb 2004 19:38:08 +0200, >>>>> Jari Arkko said: >> Regarding option 3: >> pro: this is a complete solution of the problem, which works with >> MLD snooping switches >> con: this can be regarded as spec-violation, and we may have to >> worry about conflict with MLD updates in the future > Why do you consider this as a spec violation? Because then 2462bis > would appear to say something that is different than what MLD specs > say, or because ND specs should not say anything about MLD? What I'm worrying about is to make a hidden requirement to MLD in the address autoconfiguration spec (I admit "spec-violation" is not an appropriate term - "spec boundary violation" is perhaps better?). > I think the right engineering solutions should be adopted, without > too much regard into the documentation boundaries. In general, I agree. > Having said that, > if you worry about the document boundary, you can simply say "delay > joining to the multicast group by a random delay. Once you have joined, > send the ND packet." Hmm, I tend to agree with this wording. Yes, this can still be considered as boundary violation with wording trick, but I think this makes it clear that the delay is only for DAD NSs and this minimizes effects to the MLD spec. And, of course, this is a perfect solution to the collision problem. 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 Feb 9 01:37: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 BAA20062 for ; Mon, 9 Feb 2004 01:37:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq52K-0000fl-LM for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 01:36:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i196aqLL002579 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 01:36:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq52K-0000fW-GW for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 01:36: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 BAA20049 for ; Mon, 9 Feb 2004 01:36:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq52H-0006lh-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 01:36:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq51L-0006ht-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 01:35:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq512-0006ds-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 01:35:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq50Z-0000MP-Ox; Mon, 09 Feb 2004 01:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq50K-0000Ll-0x for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 01:34:48 -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 BAA19980 for ; Mon, 9 Feb 2004 01:34:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq50G-0006dJ-00 for ipv6@ietf.org; Mon, 09 Feb 2004 01:34:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq4zI-0006ZL-00 for ipv6@ietf.org; Mon, 09 Feb 2004 01:33:45 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aq4yJ-0006S0-00 for ipv6@ietf.org; Mon, 09 Feb 2004 01:32:43 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E525615210; Mon, 9 Feb 2004 15:32:42 +0900 (JST) Date: Mon, 09 Feb 2004 15:32:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jari Arkko Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay In-Reply-To: References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40267400.2030009@kolumbus.fi> 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, 09 Feb 2004 12:14:35 +0900, >>>>> JINMEI Tatuya said: >> Having said that, >> if you worry about the document boundary, you can simply say "delay >> joining to the multicast group by a random delay. Once you have joined, >> send the ND packet." > Hmm, I tend to agree with this wording. Yes, this can still be > considered as boundary violation with wording trick, but I think this > makes it clear that the delay is only for DAD NSs and this minimizes > effects to the MLD spec. And, of course, this is a perfect solution > to the collision problem. How about this one? (this may still be controversial, and if so, please continue the discussion. But since the cutoff deadline is looming, I'll submit the draft with the proposed text below anyway.) If the Neighbor Solicitation is going to be the first message to be sent from an interface after interface (re)initialization, the node should delay joining the solicited-node multicast address by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in RFC 2461 [5]. This serves to alleviate congestion when many nodes start up on the link at the same time, such as after a power failure, and may help to avoid race conditions when more than one node is trying to solicit for the same address at the same time. Note that the delay for joining the multicast address implicitly means delaying transmission of the corresponding MLD report message [9]. Since RFC 2710 [9] does not request a random delay to avoid race conditions, only delaying Neighbor Solicitation would cause congestion by the MLD report messages. The congestion would then prevent MLD-snooping switches from working correctly, and, as a result, prevent Duplicate Address Detection from working. The requirement to include the delay for the MLD report in this case avoids this scenario. In order to improve the robustness of the Duplicate Address Detection algorithm, an interface MUST receive and process datagrams sent to the all-nodes multicast address or solicited-node multicast address of the tentative address while the delaying period. This does not necessarily conflict with the requirement that joining the multicast group be delayed. In fact, in some cases it is possible for a node to start listening to the group during the delay period before MLD report transmission. It should be noted, however, that in some link-layer environments, particularly with MLD-snooping switches, no multicast reception will be available until the MLD report is sent. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 9 02:57: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 CAA05622 for ; Mon, 9 Feb 2004 02:57:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq6Hq-0005si-6n for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 02:56:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i197uvdC022599 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 02:56:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq6Hp-0005sM-BQ for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 02:56: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 CAA05617 for ; Mon, 9 Feb 2004 02:56:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq6Hl-0005YY-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 02:56:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq6Gt-0005UQ-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 02:55:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq6GN-0005QK-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 02:55:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq6G1-0005Yb-FR; Mon, 09 Feb 2004 02:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq6Fp-0005Xd-Ph for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 02:54:53 -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 CAA05525 for ; Mon, 9 Feb 2004 02:54:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq6Fl-0005Pp-00 for ipv6@ietf.org; Mon, 09 Feb 2004 02:54:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq6En-0005M8-00 for ipv6@ietf.org; Mon, 09 Feb 2004 02:53:49 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Aq6Eh-0005IX-00 for ipv6@ietf.org; Mon, 09 Feb 2004 02:53:43 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id A75E56A901; Mon, 9 Feb 2004 09:53:38 +0200 (EET) Message-ID: <40273C1C.4050807@kolumbus.fi> Date: Mon, 09 Feb 2004 09:51:56 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JINMEI Tatuya Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40267400.2030009@kolumbus.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit JINMEI Tatuya wrote: > How about this one? (this may still be controversial, and if so, > please continue the discussion. But since the cutoff deadline is > looming, I'll submit the draft with the proposed text below anyway.) > > If the Neighbor Solicitation is going to be the first message to be > sent from an interface after interface (re)initialization, the node > should delay joining the solicited-node multicast address by a random > delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in RFC > 2461 [5]. This serves to alleviate congestion when many nodes start > up on the link at the same time, such as after a power failure, and > may help to avoid race conditions when more than one node is trying > to solicit for the same address at the same time. > > Note that the delay for joining the multicast address implicitly > means delaying transmission of the corresponding MLD report message > [9]. Since RFC 2710 [9] does not request a random delay to avoid race > conditions, only delaying Neighbor Solicitation would cause > congestion by the MLD report messages. The congestion would then > prevent MLD-snooping switches from working correctly, and, as a > result, prevent Duplicate Address Detection from working. The > requirement to include the delay for the MLD report in this case > avoids this scenario. > > In order to improve the robustness of the Duplicate Address Detection > algorithm, an interface MUST receive and process datagrams sent to > the all-nodes multicast address or solicited-node multicast address > of the tentative address while the delaying period. This does not > necessarily conflict with the requirement that joining the multicast > group be delayed. In fact, in some cases it is possible for a node to > start listening to the group during the delay period before MLD > report transmission. It should be noted, however, that in some > link-layer environments, particularly with MLD-snooping switches, no > multicast reception will be available until the MLD report is sent. Looks very good. Thanks! --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 9 03:15: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 DAA06115 for ; Mon, 9 Feb 2004 03:15:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq6ZD-0007PV-2k for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 03:14:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i198EtDo028482 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 03:14:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq6ZC-0007PJ-9t for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 03:14:54 -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 DAA06102 for ; Mon, 9 Feb 2004 03:14:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq6ZA-0006vv-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 03:14:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq6YB-0006rc-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 03:13:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq6Xd-0006nb-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 03:13:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq6XM-00071J-Kw; Mon, 09 Feb 2004 03:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq6XC-000706-Qj for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 03:12:50 -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 DAA06039 for ; Mon, 9 Feb 2004 03:12:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq6XA-0006n5-00 for ipv6@ietf.org; Mon, 09 Feb 2004 03:12:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq6WB-0006j8-00 for ipv6@ietf.org; Mon, 09 Feb 2004 03:11:48 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aq6VM-0006f7-00 for ipv6@ietf.org; Mon, 09 Feb 2004 03:10:56 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 85D9015210 for ; Mon, 9 Feb 2004 17:10:56 +0900 (JST) Date: Mon, 09 Feb 2004 17:10:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis] obsolete text in the interface id definition 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 I've added one last (minor) issue for rfc2462bis: RFC2462 says in Section 2: interface identifier - a link-dependent identifier for an interface ... In many cases, the identifier will be the same as the interface's link- layer address. Apparently, the last sentece was simply copied from RFC1971: interface token - a link-dependent identifier for an interface that is ... In many cases, the token will be the same as the interface's But this does not really match the latest status, since the interface identifier is not *the same as* the interface's link-layer address; the identifier is *derived* from the link-layer address and is formed based on the EUI-64 format of the link-layer address. So, the proposed resolution is to update the last sentence of the definition to: In many cases, the identifier will be derived from the interface's link-layer address. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. this issue is recorded as issue 324 at the issue tracker. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 9 06:12: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 GAA12353 for ; Mon, 9 Feb 2004 06:12: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 1Aq9Ke-0004zP-05 for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 06:12:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19BC3VQ019175 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 06:12:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9Kd-0004zC-Py for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 06:12:03 -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 GAA12347 for ; Mon, 9 Feb 2004 06:11:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9Ka-0007OR-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 06:12:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq9Jf-0007JV-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 06:11:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9Is-0007Eb-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 06:10:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9Hi-0004TO-0x; Mon, 09 Feb 2004 06:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9Gk-0004P1-NO for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 06:08:03 -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 GAA12210 for ; Mon, 9 Feb 2004 06:07:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9Gh-00071H-00 for ipv6@ietf.org; Mon, 09 Feb 2004 06:07:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq9Fp-0006wM-00 for ipv6@ietf.org; Mon, 09 Feb 2004 06:07:05 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Aq9Ey-0006qB-00 for ipv6@ietf.org; Mon, 09 Feb 2004 06:06:12 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i19B628n019236; Mon, 9 Feb 2004 13:06:02 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i19B5uhj019233; Mon, 9 Feb 2004 13:05:56 +0200 Date: Mon, 9 Feb 2004 13:05:56 +0200 Message-Id: <200402091105.i19B5uhj019233@burp.tkv.asdf.org> From: Markku Savela To: brian@innovationslab.net CC: jari.arkko@kolumbus.fi, jinmei@isl.rdc.toshiba.co.jp, greg.daley@eng.monash.edu.au, ipv6@ietf.org In-reply-to: <4026C112.2070406@innovationslab.net> (message from Brian Haberman on Sun, 08 Feb 2004 18:06:58 -0500) Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40267400.2030009@kolumbus.fi> <40268E36.8050109@innovationslab.net> <200402082031.i18KVlPS011214@burp.tkv.asdf.org> <4026C112.2070406@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=none autolearn=no version=2.60 > From: Brian Haberman > Markku Savela wrote: > >>From: Brian Haberman > >>>- desire to avoid packet storms upon booting many nodes simultaneously > >> > >>2710 accomplishes this by using message suppression. If a node hears a > >>Report for the same group, it cancels the transmission of any pending > >>Reports it has for the group. > > > > > > Above will totally fail with ND multicast groups. Their design goal is > > that each host is only on one group. It is highly unlikely that > > listening would hear a duplicate join for the solicited node multicast > > address. > > It is not a failure, it is just not useful for solicited-node multicast > addresses. But, you also snipped a part of the note that pointed out > that ND and MLD were designed with differing techniques to deal with > reliability. Perhaps MLD has evolved since I last looked at the WG group. However, I believe using MLD snooping switches makes your network unreliable. Let me iterate my reasoning (maybe MLDv2 has been fixed since, but..). All of the following relates only to solicited node multicast groups: - if MLD join on DAD is lost, it does not only break DAD, it also makes that node invisible to all other nodes behind the snooping swith (because no ND traffic related to that group is passed through). - to recover, someone is supposed to request MLD report from all nodes on the link. - who sends this request? As far as I understand, only multicast routers are requesting those reports? Is running a multicast router now obligatory MUST on every link? - ok, you can say the snooping switch sends the report request occasionally. But, then the switch must have IPv6 link local address, it must implement at least part of the IPv6 ND. It might as well note the ND DAD messages. - when report request is sent, EVERY node on the link going to reply, and without a delay. Isn't this going to raise the probability that some of the replies are lost? If so, then again we have some nodes, whose ND is not working over the switch. How do recover from this cycle? - if your switch boots, it has to request reports from all links, and it can enable the filtering only after it is sure that it has a complete picture of joined groups. Again, a storm of replies, possibility of lost answers? Are such switches used to bridge WLAN's? Are existing MLD snooping switches currently really trying to work on link local groups (and especieally solicited node)? Or, are they just passing all and ingoring link local groups? Have they really though over the issues above? Is this a "snake oil" product, as far as solicited node groups are considered? :-) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 9 06:30: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 GAA13023 for ; Mon, 9 Feb 2004 06:30: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 1Aq9cJ-00065K-Td for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 06:30:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19BUJ6p023384 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 06:30:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9cJ-000655-Pb for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 06:30: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 GAA12979 for ; Mon, 9 Feb 2004 06:30:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9cF-0001LT-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 06:30:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq9bK-0001Ba-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 06:29:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9aS-00013g-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 06:28:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9a6-0005R8-Kb; Mon, 09 Feb 2004 06:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9ZK-0005OV-4c for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 06:27:14 -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 GAA12786 for ; Mon, 9 Feb 2004 06:27:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9ZF-0000vS-00 for ipv6@ietf.org; Mon, 09 Feb 2004 06:27:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq9YK-0000pK-00 for ipv6@ietf.org; Mon, 09 Feb 2004 06:26:13 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9XZ-0000h5-00 for ipv6@ietf.org; Mon, 09 Feb 2004 06:25:25 -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 i19BOtV01575 for ; Mon, 9 Feb 2004 03:24:55 -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 i19BZRlN019041 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 9 Feb 2004 03:35:33 -0800 Message-ID: <40276DEA.40305@innovationslab.net> Date: Mon, 09 Feb 2004 06:24:26 -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: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40268EED.1080005@innovationslab.net> <4026D67A.2090007@eng.monash.edu.au> In-Reply-To: <4026D67A.2090007@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Greg, Greg Daley wrote: > Hi Brian, > > Brian Haberman wrote: > >> I don't like the idea of a random delay in the MLD Reports. As I >> said in another note, it either adversely affects the logic in the >> MLD specs or causes application delays for non-LL groups. >> >> Is having a delay in the NS transmission alone sufficient? So that >> the Report is sent immediately and the NS is delayed. >> >> Regards, >> Brian > > > I think what Jari asked was not a modification to the semantics > of reporting group joins. > > I think that what Jari proposed was actually that we delay DAD > (which entails both the operation of beginning listening to > a group and the NS transmission). So, in logic-wise it would look like: 1. Generate the solicited-node multicast address 2. Wait for random timer expiry 3. Perform ADD_MEMBERSHIP call on the socket 4. Send DAD I think I can live with that for the time being. > > To put it another way, we don't actually configure the address > until the random delay timer has expired. The delay's expiration > is a precondition for address configuration, in this case. > > In this way, joining the group occurs when the group is first > listened to (in accordance with MLDvX) and the NS transmission is > similarly delayed. OK. > > Delaying only the NS is insufficient, as the statement in RFC-2462 > is for two purposes: > > 1. Increased reliability of DAD NS tranmission. > > 2. Protection of the link against packet storms. > > Relying only on the MLD report replay mechanisms only achieves > the first of these goals, and not the second, since the MLD > transmissions may be synchronized for the first report. > > Delaying both provides superior protection of the link, and > gains the same reliability mechanisms already available without > requiring change to the MLD specifications. Given the above proposal, I can accept this approach. It isolates the delay to NDP rather than affecting all users of MLD. 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 Mon Feb 9 06:41: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 GAA13421 for ; Mon, 9 Feb 2004 06:41:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9mh-0007AW-QX for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 06:41:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Bf3rc027550 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 06:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9mh-0007AH-6U for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 06:41:03 -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 GAA13400 for ; Mon, 9 Feb 2004 06:40:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9md-0002dg-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 06:40:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq9lh-0002Y6-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 06:40:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9l1-0002TM-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 06:39:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9kj-0006l3-FP; Mon, 09 Feb 2004 06:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9kg-0006kY-Vx for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 06:38:59 -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 GAA13323 for ; Mon, 9 Feb 2004 06:38:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9kc-0002Rj-00 for ipv6@ietf.org; Mon, 09 Feb 2004 06:38:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq9jf-0002MM-00 for ipv6@ietf.org; Mon, 09 Feb 2004 06:37:56 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9ik-0002Bv-00 for ipv6@ietf.org; Mon, 09 Feb 2004 06:36:58 -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 i19BaSV01639 for ; Mon, 9 Feb 2004 03:36:28 -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 i19Bl2lN019061 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 9 Feb 2004 03:47:06 -0800 Message-ID: <402770A1.3070804@innovationslab.net> Date: Mon, 09 Feb 2004 06:36:01 -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: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40267400.2030009@kolumbus.fi> <40268E36.8050109@innovationslab.net> <200402082031.i18KVlPS011214@burp.tkv.asdf.org> <4026C112.2070406@innovationslab.net> <200402091105.i19B5uhj019233@burp.tkv.asdf.org> In-Reply-To: <200402091105.i19B5uhj019233@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Markku, Markku Savela wrote: >>From: Brian Haberman >>Markku Savela wrote: >> >>>>From: Brian Haberman >>>> >>>>>- desire to avoid packet storms upon booting many nodes simultaneously >>>> >>>>2710 accomplishes this by using message suppression. If a node hears a >>>>Report for the same group, it cancels the transmission of any pending >>>>Reports it has for the group. >>> >>> >>>Above will totally fail with ND multicast groups. Their design goal is >>>that each host is only on one group. It is highly unlikely that >>>listening would hear a duplicate join for the solicited node multicast >>>address. >> >>It is not a failure, it is just not useful for solicited-node multicast >>addresses. But, you also snipped a part of the note that pointed out >>that ND and MLD were designed with differing techniques to deal with >>reliability. > > > Perhaps MLD has evolved since I last looked at the WG group. However, > I believe using MLD snooping switches makes your network unreliable. > > Let me iterate my reasoning (maybe MLDv2 has been fixed since, > but..). All of the following relates only to solicited node multicast > groups: > > - if MLD join on DAD is lost, it does not only break DAD, it also > makes that node invisible to all other nodes behind the snooping > swith (because no ND traffic related to that group is passed > through). Correct, to a degree. The node sends N Reports in a particular window in order to deal with random packet loss. The node is invisible until the switch processes the Report and adds forwarding state for the requested multicast address. > > - to recover, someone is supposed to request MLD report from all nodes > on the link. > > - who sends this request? As far as I understand, only multicast > routers are requesting those reports? Is running a multicast router > now obligatory MUST on every link? Not at all. Snooping switches take on the role of Querier in all IGMP snooping devices that I know of. They send out Queries on all ports setup for snooping. Much of the detail is outlined in draft-ietf-magma-snoop-10.txt. In addition, draft-ietf-magma-igmp-proxy-04.txt may be useful in some cases as well. > > - ok, you can say the snooping switch sends the report request > occasionally. But, then the switch must have IPv6 link local > address, it must implement at least part of the IPv6 ND. It might as > well note the ND DAD messages. If it sends MLD messages, it will need to conform to the MLD spec. And for IPv6, it gets a little more complicated than it did for v4. That is due to the inclusion of MLD and ND messages inside of ICMPv6. Now the switch has to be able to parse ICMPv6 messages in order to find the messages of interest. > > - when report request is sent, EVERY node on the link going to reply, > and without a delay. Isn't this going to raise the probability that > some of the replies are lost? If so, then again we have some nodes, > whose ND is not working over the switch. How do recover from this > cycle? Message suppression helps in 2710 if the group address is the same. Otherwise the randomized delay in sending the remaining N-1 messages will offer recovery from packet loss. > > - if your switch boots, it has to request reports from all links, and > it can enable the filtering only after it is sure that it has a > complete picture of joined groups. Again, a storm of replies, > possibility of lost answers? Possibly. That is why MLD sends N Reports. > > Are such switches used to bridge WLAN's? I have no idea. > > Are existing MLD snooping switches currently really trying to work on > link local groups (and especieally solicited node)? Or, are they just > passing all and ingoring link local groups? Have they really though > over the issues above? Is this a "snake oil" product, as far as > solicited node groups are considered? :-) The purpose of the above referenced snooping draft is supposed to help switch vendors "do the right thing". Most switches deployed today do not recognize IPv6 multicast addresses at all. In fact, IGMP snooping switches adversely affect IPv6 multicast in odd ways. So, I have heard all sorts of instances where IGMP snooping had to be disabled in order to allow IPv6 to work. 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 Mon Feb 9 09:19: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 JAA20370 for ; Mon, 9 Feb 2004 09:19: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 1AqCFD-0004gg-Tr for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 09:18:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19EId2N018012 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 09:18:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCFD-0004gR-P5 for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 09:18: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 JAA20347 for ; Mon, 9 Feb 2004 09:18:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCFC-0002Qo-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 09:18:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCDv-0002Kq-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 09:17:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqCDJ-0002EZ-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 09:16:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCCh-0004LW-2r; Mon, 09 Feb 2004 09:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCC3-0004KM-FD for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 09:15: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 JAA20084 for ; Mon, 9 Feb 2004 09:15:20 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCC1-00023Y-00 for ipv6@ietf.org; Mon, 09 Feb 2004 09:15:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCB0-0001vI-00 for ipv6@ietf.org; Mon, 09 Feb 2004 09:14:18 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqCA9-0001of-00 for ipv6@ietf.org; Mon, 09 Feb 2004 09:13:25 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19EDMv28736 for ; Mon, 9 Feb 2004 16:13:23 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 16:13:21 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 16:13:18 +0200 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 issue 280] interface failure upon DAD failure Date: Mon, 9 Feb 2004 16:13:16 +0200 Message-ID: Thread-Topic: [rfc2462bis issue 280] interface failure upon DAD failure Thread-Index: AcPsAKFa9ZXqA3f7THqr/mqAmUvcgwDFg0gg To: , X-OriginalArrivalTime: 09 Feb 2004 14:13:18.0836 (UTC) FILETIME=[DDF0A340:01C3EF16] 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, > - Thomas made a good point about the rationale of the SHOULD (DAD > failure for an EUI-64 based address likely indicates MAC address > duplication). We should also note that John (Loughney) pointed out > the assumption in 2462 is not necessarily met for the 3GPP case (I > don't know what exactly he wanted to say, though) I discussed this with Thomas at the last IETF, and as long as the SHOULD covers only DAD failures for EUI-64 based addresses, than it covers my concerns. thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 9 09:24: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 JAA20591 for ; Mon, 9 Feb 2004 09:24: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 1AqCKU-000591-2r for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 09:24:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19EO6nj019769 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 09:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCKT-00058m-UL for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 09:24:05 -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 JAA20563 for ; Mon, 9 Feb 2004 09:24:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCKS-0002uy-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 09:24:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCJW-0002pZ-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 09:23:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqCIY-0002ku-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 09:22:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCIT-0004oe-GD; Mon, 09 Feb 2004 09:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCHY-0004nn-Vd for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 09:21:05 -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 JAA20494 for ; Mon, 9 Feb 2004 09:21:01 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCHX-0002gI-00 for ipv6@ietf.org; Mon, 09 Feb 2004 09:21:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCGc-0002c4-00 for ipv6@ietf.org; Mon, 09 Feb 2004 09:20:06 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqCFf-0002WX-00 for ipv6@ietf.org; Mon, 09 Feb 2004 09:19:07 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19EIDq04375 for ; Mon, 9 Feb 2004 16:18:38 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 16:18:13 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 16:18:12 +0200 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] obsolete text in the interface id definition Date: Mon, 9 Feb 2004 16:18:11 +0200 Message-ID: Thread-Topic: [rfc2462bis] obsolete text in the interface id definition Thread-Index: AcPu5J9MANvkaZG/TxKA8iHuX2DPWAAMuU7A To: , X-OriginalArrivalTime: 09 Feb 2004 14:18:12.0774 (UTC) FILETIME=[8D240460:01C3EF17] 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, > I've added one last (minor) issue for rfc2462bis: > > RFC2462 says in Section 2: > > interface identifier - a link-dependent identifier for an interface > ... > In many > cases, the identifier will be the same as the > interface's link- > layer address. > > Apparently, the last sentece was simply copied from RFC1971: > > interface token > - a link-dependent identifier for an interface that is > ... > In many > cases, the token will be the same as the interface's > > But this does not really match the latest status, since the interface > identifier is not *the same as* the interface's link-layer address; > the identifier is *derived* from the link-layer address and is formed > based on the EUI-64 format of the link-layer address. > > So, the proposed resolution is to update the last sentence of the > definition to: > > In many cases, the identifier > will be derived from the interface's link-layer address. OK with me. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 9 11:28: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 LAA26050 for ; Mon, 9 Feb 2004 11:28:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEGa-0002t1-Gc for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 11:28:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19GSChL011089 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 11:28:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEGa-0002sm-7D for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 11:28:12 -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 LAA26010 for ; Mon, 9 Feb 2004 11:28:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEGZ-0005SL-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 11:28:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEFf-0005Mq-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 11:27:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqEEv-0005Hf-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 11:26:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEEV-0002XH-0U; Mon, 09 Feb 2004 11:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEDg-0002W2-5O for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 11:25:12 -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 LAA25910 for ; Mon, 9 Feb 2004 11:25:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEDf-0005Ax-00 for ipv6@ietf.org; Mon, 09 Feb 2004 11:25:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqECk-00056I-00 for ipv6@ietf.org; Mon, 09 Feb 2004 11:24:15 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1AqEBr-00051W-00 for ipv6@ietf.org; Mon, 09 Feb 2004 11:23:19 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i19GNIOK020703 for ; Mon, 9 Feb 2004 09:23:19 -0700 (MST) 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 <0HST001ZLS6U1G@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 09 Feb 2004 09:23:18 -0700 (MST) Received: from [192.168.1.103] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HST0062PS6S0E@mail.sun.net> for ipv6@ietf.org; Mon, 09 Feb 2004 09:23:18 -0700 (MST) Date: Mon, 09 Feb 2004 08:27:04 -0800 From: Alain Durand Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt In-reply-to: <200402071345.i17Djep08482@boreas.isi.edu> To: Bill Manning Cc: tjc@ecs.soton.ac.uk (Tim Chown), ipv6@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200402071345.i17Djep08482@boreas.isi.edu> 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 Feb 7, 2004, at 5:45 AM, Bill Manning wrote: > % One snag is that if they are temporary, it will inevitably lead to > "returns" > % that don't happen, and the original and new "owners" both using the > prefix, > % which will cause confusion/ambiguity/lack of uniqueness, which is > thus breaking > % the original goal of the draft. There's enough under the /7 to not > need to > % have temporary allocations. > > actaully, all delegations are temporary, unless we are creating > property/ownership rights. Bill, This is exactly what the local addr draft is all about with the current text that makes allocation permanent. As a side note, the document talks about allocations, not delegations. - 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 Feb 9 12:18: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 MAA28790 for ; Mon, 9 Feb 2004 12:18:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF33-0007az-B5 for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 12:18:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19HIHJs029194 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 12:18:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF32-0007an-Do for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 12:18:16 -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 MAA28771 for ; Mon, 9 Feb 2004 12:18:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqF31-0003Df-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 12:18:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqF1w-00038A-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 12:17:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqF18-00033N-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 12:16:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF0t-00079F-DU; Mon, 09 Feb 2004 12:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF00-00077v-E7 for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 12:15:08 -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 MAA28698 for ; Mon, 9 Feb 2004 12:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEzy-0002yV-00 for ipv6@ietf.org; Mon, 09 Feb 2004 12:15:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEz0-0002uS-00 for ipv6@ietf.org; Mon, 09 Feb 2004 12:14:06 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1AqEy1-0002n9-00 for ipv6@ietf.org; Mon, 09 Feb 2004 12:13:05 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i19HD5OK016542 for ; Mon, 9 Feb 2004 10:13:05 -0700 (MST) 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 <0HST0015ZUHT1K@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 09 Feb 2004 10:13:05 -0700 (MST) Received: from [192.168.1.103] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HST00670UHQ0E@mail.sun.net> for ipv6@ietf.org; Mon, 09 Feb 2004 10:13:04 -0700 (MST) Date: Mon, 09 Feb 2004 09:16:49 -0800 From: Alain Durand Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt In-reply-to: <200402082302.SAA19157@ss10.danlan.com> To: Dan Lanciani Cc: ipv6@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200402082302.SAA19157@ss10.danlan.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 Feb 8, 2004, at 3:02 PM, Dan Lanciani wrote: > > In the past we were unable to come up with a value for ``long enough'' > which > is in any meaningful way different from ``forever.'' There is a simple business model to solve this problem: long enough == as long as you pay for it. This is the same as any other utility. You get gaz, water & electricity as long as you pay for it. > You are making the standard fallacious assumption that the allocation > service/ > ISP/whatever is infallible and philanthropic. What happens when the > service > goes bankrupt? Don't imagine that the bankruptcy court is going to > ignore that > subscription income and just let the customers keep their addresses. > What > happens when the service gets greedy and (after enough people are > dependent) > raises the rates? You think that can be avoided by contract? That > brings us > back to the question of how long a contract is ''long enough?'' This is the exact reason why we should not create a monopoly but foster healthy competition. If you're not happy with network solution for your DNS name danlan.com, you can switch to another one. We can have the same model here. > In any case, the actual cost of > maintaining an individual address would be swamped by the costs of > billing the > renter for that address. Billing & recurrent fees is a way to guaranty that the database will be maintainable. With permanent allocation, the day you get close to exhausting the pool of new subscribers, the rate of new subscription may not be enough to recover the cost of maintaining the database. > But even the premise behind your analogy is wrong. A one-time payment > does > not in any way imply that ``new comers'' are paying to support previous > customers. The future value of money is well understood. If the cost > of > maintaining an address in the database can be expressed as a recurring > fee > then it can also be expressed as a one-time fee. A recurring fee is > just a > way to hide the true cost from the customer. It also decouples the fee > from the cost of maintaining the database (because the billing and > other > administrative overhead will dominate the computation), allowing lots > of > wiggle room for little extra expenses. And most people won't even do > the > annuity calculation to determine their equivalent up-front cost. I'm not sure the future value of money is that well understood for infinite length of time... Actually, I'm sure of the opposite. - 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 Feb 9 12:25: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 MAA29274 for ; Mon, 9 Feb 2004 12:25:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF9l-00009i-Bx for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 12:25:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19HPDnm000501 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 12:25:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF9j-00007e-ES for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 12:25:11 -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 MAA29229 for ; Mon, 9 Feb 2004 12:25:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqF9h-0003u3-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 12:25:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqF8k-0003nK-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 12:24:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqF7k-0003gA-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 12:23:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF7d-0007vb-Q0; Mon, 09 Feb 2004 12:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF6t-0007v6-ED for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 12:22:15 -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 MAA29008 for ; Mon, 9 Feb 2004 12:22:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqF6s-0003aG-00 for ipv6@ietf.org; Mon, 09 Feb 2004 12:22:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqF5v-0003Uy-00 for ipv6@ietf.org; Mon, 09 Feb 2004 12:21:15 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqF5T-0003QV-00 for ipv6@ietf.org; Mon, 09 Feb 2004 12:20:47 -0500 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i19HKaOr015436 for ; Mon, 9 Feb 2004 17:20:36 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA20080 for ; Mon, 9 Feb 2004 17:20:33 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i19HKXV29594 for ipv6@ietf.org; Mon, 9 Feb 2004 17:20:33 GMT Date: Mon, 9 Feb 2004 17:20:33 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Message-ID: <20040209172033.GL16789@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <200402071345.i17Djep08482@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Feb 09, 2004 at 08:27:04AM -0800, Alain Durand wrote: > > Bill, > > This is exactly what the local addr draft is all about with the current > text that makes > allocation permanent. > > As a side note, the document talks about allocations, not delegations. > > - Alain. OK, but I think we can have some statement to say that there is a tradeoff when you reuse previous temporary allocations because such reuse may lead to ambiguity. With 1,000 billion /48's available under a /8 you have a lot of capacity before you need to re-allocate. You could say that "returns" should not be reused until those 1,000 billion /48's have been allocated from under the FC00::/8 prefix? (Though that would be a kind of excuse for sites to not pay recurrent registration fees :) Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 9 12:27: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 MAA29435 for ; Mon, 9 Feb 2004 12:27:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFBk-0000TW-IH for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 12:27:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19HRG7U001820 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 12:27:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFBk-0000TF-DM for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 12:27:16 -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 MAA29377 for ; Mon, 9 Feb 2004 12:27:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFBj-00049J-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 12:27:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqFAp-00042V-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 12:26:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqF9r-0003vZ-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 12:25:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF9c-0008QJ-Mn; Mon, 09 Feb 2004 12:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF8l-0008Jy-93 for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 12:24:11 -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 MAA29167 for ; Mon, 9 Feb 2004 12:24:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqF8j-0003nF-00 for ipv6@ietf.org; Mon, 09 Feb 2004 12:24:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqF7j-0003g4-00 for ipv6@ietf.org; Mon, 09 Feb 2004 12:23:08 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqF6l-0003ZF-00 for ipv6@ietf.org; Mon, 09 Feb 2004 12:22:07 -0500 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i19HM7Or015482 for ; Mon, 9 Feb 2004 17:22:07 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA20281 for ; Mon, 9 Feb 2004 17:22:03 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i19HM3c29614 for ipv6@ietf.org; Mon, 9 Feb 2004 17:22:03 GMT Date: Mon, 9 Feb 2004 17:22:03 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Message-ID: <20040209172203.GM16789@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <200402082302.SAA19157@ss10.danlan.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 Mon, Feb 09, 2004 at 09:16:49AM -0800, Alain Durand wrote: > > Billing & recurrent fees is a way to guaranty that the database will be > maintainable. With 1,000 billion entries, it might also become a large database... Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 9 13:31:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02898 for ; Mon, 9 Feb 2004 13:31: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 1AqGBg-0005Vt-Eb for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 13:31:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19IVGoi021187 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 13:31:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGBg-0005Ve-9Y for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 13:31:16 -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 NAA02872 for ; Mon, 9 Feb 2004 13:31:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGBe-0002uX-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 13:31:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGAl-0002nG-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 13:30:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqG9s-0002eE-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 13:29:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqG9V-00050d-3J; Mon, 09 Feb 2004 13:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqG9C-0004wc-Gi for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 13:28:42 -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 NAA02603 for ; Mon, 9 Feb 2004 13:28:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqG9A-0002X5-00 for ipv6@ietf.org; Mon, 09 Feb 2004 13:28:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqG8N-0002MZ-00 for ipv6@ietf.org; Mon, 09 Feb 2004 13:27:52 -0500 Received: from emerson.torrentnet.com ([198.78.51.110]) by ietf-mx with esmtp (Exim 4.12) id 1AqG6z-00027K-00 for ipv6@ietf.org; Mon, 09 Feb 2004 13:26:25 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i19IQN778909; Mon, 9 Feb 2004 13:26:23 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i19IQNo86909; Mon, 9 Feb 2004 13:26:23 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id NAA05276; Mon, 9 Feb 2004 13:26:23 -0500 (EST) Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt From: Steven Blake To: Tim Chown Cc: ipv6@ietf.org In-Reply-To: <20040209172203.GM16789@login.ecs.soton.ac.uk> References: <200402082302.SAA19157@ss10.danlan.com> <20040209172203.GM16789@login.ecs.soton.ac.uk> Content-Type: text/plain Organization: Ericsson IP Infrastructure Message-Id: <1076351182.14073.7.camel@newcastle.torrentnet.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 09 Feb 2004 13:26:22 -0500 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.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2004-02-09 at 12:22, Tim Chown wrote: > On Mon, Feb 09, 2004 at 09:16:49AM -0800, Alain Durand wrote: > > > > Billing & recurrent fees is a way to guaranty that the database will be > > maintainable. > > With 1,000 billion entries, it might also become a large database... That's why proof of ownership should be distributed to the prefix recipient, who would hold on to an allocation statement signed by an escrowed key. The registries just need to escrow their keys, and maintain enough state to ensure that they don't issue duplicate allocations. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 9 14:55: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 OAA07252 for ; Mon, 9 Feb 2004 14:55:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHUy-0003wo-V3 for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 14:55:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19JtGQq015174 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 14:55:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHUy-0003wf-QE for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 14:55:16 -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 OAA07230 for ; Mon, 9 Feb 2004 14:55:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHUw-0003G0-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 14:55:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHU1-0003B7-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 14:54:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqHT8-00036Y-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 14:53:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHSo-0003cm-34; Mon, 09 Feb 2004 14:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHS3-0003c9-0v for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 14:52:15 -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 OAA07137 for ; Mon, 9 Feb 2004 14:52:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHS0-00030u-00 for ipv6@ietf.org; Mon, 09 Feb 2004 14:52:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHR7-0002vx-00 for ipv6@ietf.org; Mon, 09 Feb 2004 14:51:18 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AqHQ1-0002n8-00 for ipv6@ietf.org; Mon, 09 Feb 2004 14:50:09 -0500 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id i19Jo1618397; Mon, 9 Feb 2004 11:50:01 -0800 (PST) From: Bill Manning Message-Id: <200402091950.i19Jo1618397@boreas.isi.edu> Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt In-Reply-To: <1076351182.14073.7.camel@newcastle.torrentnet.com> from Steven Blake at "Feb 9, 4 01:26:22 pm" To: slblake@torrentnet.com (Steven Blake) Date: Mon, 9 Feb 2004 11:50:01 -0800 (PST) Cc: tjc@ecs.soton.ac.uk, ipv6@ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit % > On Mon, Feb 09, 2004 at 09:16:49AM -0800, Alain Durand wrote: % > > % > > Billing & recurrent fees is a way to guaranty that the database will be % > > maintainable. % > % > With 1,000 billion entries, it might also become a large database... % % That's why proof of ownership should be distributed to the prefix % recipient, who would hold on to an allocation statement signed by an % escrowed key. % % The registries just need to escrow their keys, and maintain enough state % to ensure that they don't issue duplicate allocations. % % % Regards, % % =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= % Steven L. Blake I'd -REALLY- like to get the IETF legal team involved if this WG is seriously contemplating turning IP prefixes into owned property. 1,000 billion registrations at 1.0 eu per anum is an -HUGE- business. --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 Mon Feb 9 20:45: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 UAA09669 for ; Mon, 9 Feb 2004 20:45:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMxC-0002fh-2E for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 20:44:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A1ikcb010263 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 20:44:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMxB-0002fS-S9 for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 20:44: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 UAA09609 for ; Mon, 9 Feb 2004 20:44:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqMx9-0001MD-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 20:44:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqMw4-0001DG-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 20:43:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqMvH-00017Q-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 20:42:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMuX-0002QK-2J; Mon, 09 Feb 2004 20:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMu0-0002Pl-6q for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 20:41: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 UAA09483 for ; Mon, 9 Feb 2004 20:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqMtx-00012Y-00 for ipv6@ietf.org; Mon, 09 Feb 2004 20:41:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqMt0-0000yp-00 for ipv6@ietf.org; Mon, 09 Feb 2004 20:40:27 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AqMsh-0000v4-00; Mon, 09 Feb 2004 20:40:08 -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 i1A1dWV07552; Mon, 9 Feb 2004 17:39:32 -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 i1A1o8lN022511 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 9 Feb 2004 17:50:11 -0800 Message-ID: <40283639.9020402@innovationslab.net> Date: Mon, 09 Feb 2004 20:39:05 -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: The IESG , Margaret Wasserman , Thomas Narten CC: IPv6 Mailing List Subject: Request To Advance : "Deprecating Site Local Addresses" 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 & Thomas, On behalf of the IPv6 working group, the chairs request the advancement of: Title : Deprecating Site Local Addresses Author(s) : C. Huitema, B. Carpenter Filename : draft-ietf-ipv6-deprecate-site-local-02.txt Pages : 11 Date : 2003-11-19 as a Proposed Standard. This version of the document contains the working group consensus on deprecating site-local addresses. 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 Feb 9 22:13: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 WAA12909 for ; Mon, 9 Feb 2004 22:13:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqOL4-0006Ae-RF for ipv6-archive@odin.ietf.org; Mon, 09 Feb 2004 22:13:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A3DUQf023720 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 22:13:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqOL4-0006AV-KG for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 22:13:30 -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 WAA12888 for ; Mon, 9 Feb 2004 22:13:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqOL1-0001xC-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 22:13:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqOK3-0001rr-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 22:12:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqOJ9-0001mi-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 22:11:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqOIh-0005wz-Ai; Mon, 09 Feb 2004 22:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqOIG-0005w0-Ka for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 22:10:36 -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 WAA12825 for ; Mon, 9 Feb 2004 22:10:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqOID-0001hT-00 for ipv6@ietf.org; Mon, 09 Feb 2004 22:10:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqOHP-0001ch-00 for ipv6@ietf.org; Mon, 09 Feb 2004 22:09:44 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AqOGi-0001Wo-00 for ipv6@ietf.org; Mon, 09 Feb 2004 22:09:01 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 592C615210 for ; Tue, 10 Feb 2004 12:08:59 +0900 (JST) Date: Tue, 10 Feb 2004 12:09:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Subject: Re: [rfc2462bis issue 280] interface failure upon DAD failure 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, 9 Feb 2004 16:13:16 +0200, >>>>> john.loughney@nokia.com said: >> - Thomas made a good point about the rationale of the SHOULD (DAD >> failure for an EUI-64 based address likely indicates MAC address >> duplication). We should also note that John (Loughney) pointed out >> the assumption in 2462 is not necessarily met for the 3GPP case (I >> don't know what exactly he wanted to say, though) > I discussed this with Thomas at the last IETF, and as long as the SHOULD > covers only DAD failures for EUI-64 based addresses, than it covers > my concerns. The new revision revised this section as follows: 5.4.5 When Duplicate Address Detection Fails A tentative address that is determined to be a duplicate as described above MUST NOT be assigned to an interface and the node SHOULD log a system management error. If the address is a link-local address formed from an interface identifier based on the hardware address (e.g., EUI-64), the interface SHOULD be disabled. In this case, the IP address duplication probably means duplicate hardware addresses are in use, and trying to recover from it by configuring another IP address will not result in a usable network. In fact, it probably makes things worse by creating problems that are harder to diagnose than just shutting down the interface; the user will see a partially working network where some things work, and other things will not. On the other hand, if the duplicated link-local address is not formed from an interface identifier based on the hardware address, the interface MAY continue to be used. Would you live with 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 Tue Feb 10 04:35: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 EAA07428 for ; Tue, 10 Feb 2004 04:35:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUI0-0002QU-4U for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 04:34:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A9Yi10009320 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 04:34:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUHz-0002QF-S9 for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 04:34:43 -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 EAA07424 for ; Tue, 10 Feb 2004 04:34:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqUHx-0006U1-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 04:34:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqUH2-0006PJ-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 04:33:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqUGk-0006KV-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 04:33:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUGL-00027E-Fq; Tue, 10 Feb 2004 04:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUG1-00026g-OT for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 04:32:41 -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 EAA07383 for ; Tue, 10 Feb 2004 04:32:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqUFy-0006Iz-00 for ipv6@ietf.org; Tue, 10 Feb 2004 04:32:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqUF0-0006EO-00 for ipv6@ietf.org; Tue, 10 Feb 2004 04:31:38 -0500 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1AqUE2-00069I-00 for ipv6@ietf.org; Tue, 10 Feb 2004 04:30:39 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1AqUE2-00020h-00 for ; Tue, 10 Feb 2004 09:30:38 +0000 Date: Tue, 10 Feb 2004 09:30:38 +0000 To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Message-ID: <20040210093038.GA5386@fysh.org> References: <200402082302.SAA19157@ss10.danlan.com> <20040209172203.GM16789@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040209172203.GM16789@login.ecs.soton.ac.uk> User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 Tim Chown wrote: >With 1,000 billion entries, it might also become a large database... The allocation bitmap would be 128GiB. That fits onto one current commodity hard disk. Are we really quibbling over who's going to have to pay for eternal reliable storage of such a trifling dataset? When this issue was raised on one of the previous occasions, some months ago, I considered setting up a proof-of-concept automated registry for 36-bit random numbers (thus scaled down by a mere factor of 16) on my home equipment. Regrettably I never got round to doing that, but it seems it might still be of use. Operating such a thing might also have useful lessons for the operation of the eventual prefix registry. Thoughts, anyone? -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 10 05:30: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 FAA10549 for ; Tue, 10 Feb 2004 05:30:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqV9W-0007XZ-HF for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 05:30:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AAU2X7028958 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 05:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqV9T-0007Wz-Nw for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 05:29:59 -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 FAA10532 for ; Tue, 10 Feb 2004 05:29:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqV9Q-0005k2-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 05:29:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqV8R-0005cw-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 05:28:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqV7o-0005WY-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 05:28:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqV7a-0007D5-Os; Tue, 10 Feb 2004 05:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqV7K-0007CH-UK for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 05:27:46 -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 FAA10425 for ; Tue, 10 Feb 2004 05:27:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqV7H-0005Vk-00 for ipv6@ietf.org; Tue, 10 Feb 2004 05:27:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqV6K-0005R8-00 for ipv6@ietf.org; Tue, 10 Feb 2004 05:26:45 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AqV5W-0005Me-00 for ipv6@ietf.org; Tue, 10 Feb 2004 05:25:54 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 918D16A902; Tue, 10 Feb 2004 12:25:54 +0200 (EET) Message-ID: <4028B14B.9090009@kolumbus.fi> Date: Tue, 10 Feb 2004 12:24:11 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JINMEI Tatuya Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 280] interface failure upon DAD failure References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jinmei, > 5.4.5 When Duplicate Address Detection Fails > > A tentative address that is determined to be a duplicate as described > above MUST NOT be assigned to an interface and the node SHOULD log a > system management error. If the address is a link-local address > formed from an interface identifier based on the hardware address > (e.g., EUI-64), the interface SHOULD be disabled. In this case, the > IP address duplication probably means duplicate hardware addresses > are in use, and trying to recover from it by configuring another IP > address will not result in a usable network. In fact, it probably > makes things worse by creating problems that are harder to diagnose > than just shutting down the interface; the user will see a partially > working network where some things work, and other things will not. On > the other hand, if the duplicated link-local address is not formed > from an interface identifier based on the hardware address, the > interface MAY continue to be used. Ok. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 10 06:25:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12077 for ; Tue, 10 Feb 2004 06:25:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqW0Z-0002Sj-16 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 06:24:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ABOokq009459 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 06:24:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqW0Y-0002SU-Ne for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 06:24:50 -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 GAA12047 for ; Tue, 10 Feb 2004 06:24:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqW0U-0002nm-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 06:24:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqVza-0002hX-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 06:23:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqVyl-0002cQ-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 06:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVxp-0001oT-D9; Tue, 10 Feb 2004 06:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVxb-0001o8-MD for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 06:21:47 -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 GAA11976 for ; Tue, 10 Feb 2004 06:21:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqVxX-0002Vi-00 for ipv6@ietf.org; Tue, 10 Feb 2004 06:21:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqVwb-0002RA-00 for ipv6@ietf.org; Tue, 10 Feb 2004 06:20:46 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AqVvx-0002IH-00 for ipv6@ietf.org; Tue, 10 Feb 2004 06:20:05 -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 i1ABJaV10706 for ; Tue, 10 Feb 2004 03:19:36 -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 i1ABUDlN024067 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 10 Feb 2004 03:30:17 -0800 Message-ID: <4028BE34.6030806@innovationslab.net> Date: Tue, 10 Feb 2004 06:19:16 -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: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40268EED.1080005@innovationslab.net> <4026D67A.2090007@eng.monash.edu.au> <40276DEA.40305@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, 09 Feb 2004 06:24:26 -0500, >>>>>>Brian Haberman said: > > >>>I think what Jari asked was not a modification to the semantics >>>of reporting group joins. >>> >>>I think that what Jari proposed was actually that we delay DAD >>>(which entails both the operation of beginning listening to >>>a group and the NS transmission). > > >>So, in logic-wise it would look like: > > >> 1. Generate the solicited-node multicast address >> 2. Wait for random timer expiry >> 3. Perform ADD_MEMBERSHIP call on the socket >> 4. Send DAD > > >>I think I can live with that for the time being. > > > In my latest proposal, the behavior is a bit different: > > 1. Generate the solicited-node multicast address > 2. Perform ADD_MEMBERSHIP call on the socket (or equivalent) but > not send MLD, i.e., start listening to the multicast address > 3. Wait for random timer expiry > 4. send MLD > 5. Send DAD > > The reason for doing 2 before the random delay is because we need to > listen to the multicast address to improve the reliability of DAD. > > The reason for doing 3 (random delay) before sending MLD is for > avoiding collisions. > > Would you still live with this? In the stacks I am familiar with, once you perform ADD_MEMBERSHIP, the sending of the Report message is out of your control. 1. Would you standardize a mechanism for joining but not reporting? 2. Does the implementation of NDP "control" the MLD state machine? 3. What happens if someone builds a stack from multiple vendors (e.g. MLD from vendor X and NDP from vendor Y)? 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 Feb 10 06:35: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 GAA12423 for ; Tue, 10 Feb 2004 06:35:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqWAK-0003DY-5j for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 06:34:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ABYuC6012362 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 06:34:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqWAK-0003DJ-0Z for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 06:34:56 -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 GAA12353 for ; Tue, 10 Feb 2004 06:34:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqWAG-0003j1-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 06:34:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqW9F-0003e4-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 06:33:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqW8b-0003ZB-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 06:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqW8T-0002tJ-Nu; Tue, 10 Feb 2004 06:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqW8H-0002sw-UX for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 06:32:49 -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 GAA12291 for ; Tue, 10 Feb 2004 06:32:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqW8D-0003Y1-00 for ipv6@ietf.org; Tue, 10 Feb 2004 06:32:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqW7H-0003TR-00 for ipv6@ietf.org; Tue, 10 Feb 2004 06:31:48 -0500 Received: from usen-221x249x121x227.ap-us01.usen.ad.jp ([221.249.121.227] helo=coconut.itojun.org) by ietf-mx with esmtp (Exim 4.12) id 1AqW6p-0003OU-00 for ipv6@ietf.org; Tue, 10 Feb 2004 06:31:20 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 7A585BF; Tue, 10 Feb 2004 20:31:19 +0900 (JST) To: brian@innovationslab.net Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay In-Reply-To: Your message of "Tue, 10 Feb 2004 06:19:16 -0500" <4028BE34.6030806@innovationslab.net> References: <4028BE34.6030806@innovationslab.net> X-Mailer: Cue version 0.6 (040210-0635/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040210113119.7A585BF@coconut.itojun.org> Date: Tue, 10 Feb 2004 20:31:19 +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 > 3. What happens if someone builds a stack from multiple vendors > (e.g. MLD from vendor X and NDP from vendor Y)? this is "someone"'s responsibility to ensure the documented behavior, IMHO. it is not a concern for standard document (no need to document). itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 10 07:29: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 HAA13729 for ; Tue, 10 Feb 2004 07:29:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX0U-0006Zd-QP for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 07:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ACSopG025268 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 07:28:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX0U-0006ZT-Cv for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 07:28:50 -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 HAA13723 for ; Tue, 10 Feb 2004 07:28:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqX0T-0000RS-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:28:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqWza-0000MY-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:27:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqWzC-0000HF-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:27:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqWyk-0005y4-0Y; Tue, 10 Feb 2004 07:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqWyV-0005wX-LA for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 07:26:47 -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 HAA13628 for ; Tue, 10 Feb 2004 07:26:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqWyV-0000Fi-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:26:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqWxX-0000At-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:25:47 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AqWwa-00001W-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:24:48 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4E7EF15210; Tue, 10 Feb 2004 21:24:41 +0900 (JST) Date: Tue, 10 Feb 2004 21:24:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: itojun@itojun.org (Jun-ichiro itojun Hagino) Cc: brian@innovationslab.net, ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay In-Reply-To: <20040210113119.7A585BF@coconut.itojun.org> References: <4028BE34.6030806@innovationslab.net> <20040210113119.7A585BF@coconut.itojun.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=AWL autolearn=no version=2.60 >>>>> On Tue, 10 Feb 2004 20:31:19 +0900 (JST), >>>>> itojun@itojun.org (Jun-ichiro itojun Hagino) said: >> 3. What happens if someone builds a stack from multiple vendors >> (e.g. MLD from vendor X and NDP from vendor Y)? > this is "someone"'s responsibility to ensure the documented behavior, > IMHO. it is not a concern for standard document (no need to document). I basically agree. IMO, this kind of thing is implementation dependent, and can be out of scope of a specification document. Regarding our own implementation (KAME/BSD), it joins the solicited-node multicast group corresponding to a link-local unicast address within the kernel; it doesn't need a separate system call (IPV6_JOIN_GROUP) to join the group in this particular case. So, I believe it's not so difficult to implement the procedure I showed in my previous message at least on one OS that I know of. We could add a note in rfc2462bis that in some OSes it may not be effective to separate the join process and the listen process, though I personally think it's overkilling in this document. 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 Feb 10 07:30: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 HAA13786 for ; Tue, 10 Feb 2004 07:30:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX1R-0006fC-LW for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 07:29:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ACTnwp025608 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 07:29:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX1R-0006ex-I7 for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 07:29:49 -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 HAA13755 for ; Tue, 10 Feb 2004 07:29:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqX1Q-0000Xc-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:29:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqX0W-0000Rt-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:28:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqWzi-0000Mp-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqWzh-0006Ci-MV; Tue, 10 Feb 2004 07:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqWzX-0006C4-Fd for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 07:27: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 HAA13671 for ; Tue, 10 Feb 2004 07:27:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqWzW-0000Lh-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:27:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqWyb-0000Gv-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:26:54 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AqWyO-0000Bq-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:26:41 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGWJYH>; Tue, 10 Feb 2004 07:26:16 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042123@ftmail.lab.flarion.com> From: Soliman Hesham To: IETF Mailing List Subject: [2461bis issue 250] Reception of prefix option with prefix length > 64 Date: Tue, 10 Feb 2004 07:26:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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 What should a node do upon reception of a prefix option with the prefix length set to a value >64? The issue can be stated more accurately to say: What should a host do upon reception of a prefix option with the prefix length set to a value != 64? So far I haven't received any comments on this issue. It seems that there are few options to consider: 1. A host should ignore this field if it's not set to 64 and form an address based on the leading 64 bits. 2. A host should ignore the field if not set to 64 and log an error. The host MUST NOT form an address based on this prefix. 3. This field should be removed and a 64-bit prefix always assumed by hosts. 4. Leave this field as is and design a mechanism that allows the host to form an address based on the length of the interface identifier (i.e. 128 - prefixlen). Realistically I don't think we should go with option 1. Option 4 requires more work and I don't know how we can proceed with this dependency on another spec. In any case, options 2,3,and 4 are the most realistic. Note that none of the options above are backward compatible. In a sense, we can't be backward compatible because this seems like a bug given the current address architecture RFC. Which option should we pick to solve this problem? Other options are certainly welcome. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 10 07:43: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 HAA14231 for ; Tue, 10 Feb 2004 07:43:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXE4-0008SX-HE for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 07:42:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ACgq8D032511 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 07:42:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXE4-0008SI-8B for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 07:42: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 HAA14221 for ; Tue, 10 Feb 2004 07:42:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqXE3-0001md-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:42:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqXD7-0001hA-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:41:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqXCW-0001bv-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:41:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXCI-0007mD-TU; Tue, 10 Feb 2004 07:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXC3-0007lH-50 for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 07:40:47 -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 HAA14113 for ; Tue, 10 Feb 2004 07:40:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqXC2-0001a7-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:40:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqXB3-0001U8-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:39:46 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AqXA6-0001KN-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:38:46 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1ACcS6A000568; Tue, 10 Feb 2004 14:38:28 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1ACcS5S000565; Tue, 10 Feb 2004 14:38:28 +0200 Date: Tue, 10 Feb 2004 14:38:28 +0200 Message-Id: <200402101238.i1ACcS5S000565@burp.tkv.asdf.org> From: Markku Savela To: H.Soliman@flarion.com CC: ipv6@ietf.org In-reply-to: <9E3BA3946476AD4EB94672712B12A85F042123@ftmail.lab.flarion.com> (message from Soliman Hesham on Tue, 10 Feb 2004 07:26:05 -0500) Subject: Re: [2461bis issue 250] Reception of prefix option with prefix length > 64 References: <9E3BA3946476AD4EB94672712B12A85F042123@ftmail.lab.flarion.com> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > From: Soliman Hesham > What should a node do upon reception of a prefix option with the prefix > length set to a value >64? ... > 4. Leave this field as is and design a mechanism that > allows the host to form an address based on the > length of the interface identifier (i.e. 128 - prefixlen). Well, just a datapoint: I do basicly 4. I have 128 bits or less of interface id. (128 - prefixlen) bits from the least significant part of the interface id is copied into real address (and rest is ignored). I could as well have prefixlen < 64. Makes no difference. However, I would really prefer that all prefixes on the link do use the same prefixlen :-) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 10 08:33: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 HAA14232 for ; Tue, 10 Feb 2004 07:43:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXE4-0008SY-HQ for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 07:42:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ACgqJm032496 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 07:42:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXE3-0008S3-HV for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 07:42: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 HAA14218 for ; Tue, 10 Feb 2004 07:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqXE2-0001mY-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:42:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqXD6-0001h1-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:41:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqXCW-0001bu-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:41:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXCK-0007mP-BN; Tue, 10 Feb 2004 07:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXC3-0007lM-QK for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 07:40:47 -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 HAA14116 for ; Tue, 10 Feb 2004 07:40:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqXC3-0001aC-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:40:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqXB5-0001UP-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:39:48 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AqXA9-0001OZ-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:38:49 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AF90115210 for ; Tue, 10 Feb 2004 21:38:48 +0900 (JST) Date: Tue, 10 Feb 2004 21:38:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: new revision of rfc2462bis is available 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 I've submitted a new revision of the rfc2462bis draft: draft-ietf-ipv6-rfc2462bis-00.txt I expect a certain amount of delay before the draft is ready at the official I-D archive, so I put a copy of the draft at the following URL: http://www.jinmei.org/draft-ietf-ipv6-rfc2462bis-00.txt Any comments/questions/corrections 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 Feb 10 08:41: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 IAA18091 for ; Tue, 10 Feb 2004 08:41:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqY8P-0003pV-Kf for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 08:41:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ADf5kZ014720 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 08:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqY8O-0003pI-VV for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 08:41:05 -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 IAA17998 for ; Tue, 10 Feb 2004 08:41:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqY8N-00010T-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 08:41:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqY7R-0000oW-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 08:40:06 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqY6k-0000im-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 08:39:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqY1y-0001nb-RF for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 08:34:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqY1a-0002tG-2K; Tue, 10 Feb 2004 08:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqY1X-0002st-9v for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 08:33:59 -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 IAA17689 for ; Tue, 10 Feb 2004 08:33:57 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqY1W-0000Fo-00 for ipv6@ietf.org; Tue, 10 Feb 2004 08:33:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqY0h-0000A5-00 for ipv6@ietf.org; Tue, 10 Feb 2004 08:33:08 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqY0J-00002O-00 for ipv6@ietf.org; Tue, 10 Feb 2004 08:32:43 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1ADWfv02542 for ; Tue, 10 Feb 2004 15:32:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Feb 2004 15:32:39 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 15:32:39 +0200 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 issue 280] interface failure upon DAD failure Date: Tue, 10 Feb 2004 15:32:14 +0200 Message-ID: Thread-Topic: [rfc2462bis issue 280] interface failure upon DAD failure Thread-Index: AcPvg6Y7roma1sr8TyqFp8QiH9xbSAAVpVQg To: , X-OriginalArrivalTime: 10 Feb 2004 13:32:39.0967 (UTC) FILETIME=[5AAC82F0:01C3EFDA] 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, > The new revision revised this section as follows: > > 5.4.5 When Duplicate Address Detection Fails > > A tentative address that is determined to be a duplicate as described > above MUST NOT be assigned to an interface and the node SHOULD log a > system management error. If the address is a link-local address > formed from an interface identifier based on the hardware address > (e.g., EUI-64), the interface SHOULD be disabled. In this case, the > IP address duplication probably means duplicate hardware addresses > are in use, and trying to recover from it by configuring another IP > address will not result in a usable network. In fact, it probably > makes things worse by creating problems that are harder to diagnose > than just shutting down the interface; the user will see a partially > working network where some things work, and other things will not. On > the other hand, if the duplicated link-local address is not formed > from an interface identifier based on the hardware address, the > interface MAY continue to be used. > > Would you live with this? Yes, this is OK. thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 10 15:02: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 PAA06212 for ; Tue, 10 Feb 2004 15:02:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqe56-0007en-P7 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 15:02:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AK24Yw029431 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 15:02:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqe56-0007eT-Kt for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 15:02: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 PAA06130 for ; Tue, 10 Feb 2004 15:02:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqe53-0001Vg-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 15:02:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqe43-0001MU-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 15:01:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqe34-00019n-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 14:59:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqe29-00057T-ST; Tue, 10 Feb 2004 14:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqe1i-000546-TM for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 14:58:34 -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 OAA05786 for ; Tue, 10 Feb 2004 14:58:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqe1g-0000vt-00 for ipv6@ietf.org; Tue, 10 Feb 2004 14:58:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqe0m-0000m5-00 for ipv6@ietf.org; Tue, 10 Feb 2004 14:57:37 -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 1Aqe00-0000bW-00 for ipv6@ietf.org; Tue, 10 Feb 2004 14:56:49 -0500 Received: from [192.168.0.100] (teapot.felipe-alfaro.com [192.168.0.100]) by kerberos.felipe-alfaro.com (Postfix) with ESMTP id 6CD5142E4B for ; Tue, 10 Feb 2004 20:56:11 +0100 (CET) Subject: Re: new revision of rfc2462bis is available From: Felipe Alfaro Solana To: ipv6@ietf.org In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Message-Id: <1076442972.2358.11.camel@teapot.felipe-alfaro.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-8) Date: Tue, 10 Feb 2004 20:56:12 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Tue, 2004-02-10 at 13:38, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 wrote: > I've submitted a new revision of the rfc2462bis draft: > draft-ietf-ipv6-rfc2462bis-00.txt >=20 > I expect a certain amount of delay before the draft is ready at the > official I-D archive, so I put a copy of the draft at the following URL= : >=20 > http://www.jinmei.org/draft-ietf-ipv6-rfc2462bis-00.txt >=20 > Any comments/questions/corrections are welcome. May I ask a question about the following paragraph? o Small sites consisting of a set of machines attached to a single link should not require the presence of a stateful server or router as a prerequisite for communicating. Plug-and-play communication is achieved through the use of link-local addresses. Link-local addresses have a well-known prefix that identifies the (single) shared link to which a set of nodes attach. A host forms a link-local address by appending its interface identifier to the link-local prefix. I don't understand how is it possible for two hosts to communicate when no stateful server or router advertising a prefix is attached to the link. In this case, both hosts are configured exclusively with link-local addresses, but since those addresses have a fe80::/10 prefix, how can the IPv6 stack know what interface should the packets be sent on? For instance, on Linux 2.6 kernels, when trying to ping another host using its link-local IPv6, an invalid argument error is generated since the kernel is not able to guess which interface the packet should be sent to, since any local interface has exactly the same prefix and length. This gets complicated even more if the machine has multiple interfaces, for example, two Ethernet interfaces. I thought that two IPv6-enabled hosts could only communicate if both have a site-local or global IPv6 address configured. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 10 15:22: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 PAA09320 for ; Tue, 10 Feb 2004 15:22:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeOi-0000zK-GQ for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 15:22:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AKMKld003795 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 15:22:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeOi-0000z4-C6 for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 15:22:20 -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 PAA08943 for ; Tue, 10 Feb 2004 15:22:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqeOf-0004BU-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 15:22:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqeNn-00044W-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 15:21:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqeN2-0003xL-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 15:20:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeMW-0008Iz-Sc; Tue, 10 Feb 2004 15:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeLl-00087H-Vs for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 15:19:17 -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 PAA08275 for ; Tue, 10 Feb 2004 15:19:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqeLk-0003mZ-00 for ipv6@ietf.org; Tue, 10 Feb 2004 15:19:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqeKe-0003dG-00 for ipv6@ietf.org; Tue, 10 Feb 2004 15:18:09 -0500 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1AqeJg-0003Sf-00 for ipv6@ietf.org; Tue, 10 Feb 2004 15:17:09 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA23224; Tue, 10 Feb 2004 15:17:05 -0500 (EST) Date: Tue, 10 Feb 2004 15:17:05 -0500 (EST) From: Dan Lanciani Message-Id: <200402102017.PAA23224@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.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=2.2 required=5.0 tests=AWL,MLM autolearn=no version=2.60 Alain Durand wrote: |On Feb 8, 2004, at 3:02 PM, Dan Lanciani wrote: |> |> In the past we were unable to come up with a value for ``long enough'' |> which |> is in any meaningful way different from ``forever.'' | |There is a simple business model to solve this problem: |long enough == as long as you pay for it. There is a much simpler model that does not create an artificial profit stream: long enough = forever. |This is the same as any other utility. You get gaz, water & electricity |as long as you pay for it. And if the address allocation entity were to send me fresh new addresses to add to my collection each month I might want to pay them on that basis. But they aren't sending me anything. You are trying desperately to create an ongoing revenue stream out of the ether. Certainly this has been done before, but at least there were technical excuses to make it seem more legitimate. This time it's purely economic. |> You are making the standard fallacious assumption that the allocation |> service/ |> ISP/whatever is infallible and philanthropic. What happens when the |> service |> goes bankrupt? Don't imagine that the bankruptcy court is going to |> ignore that |> subscription income and just let the customers keep their addresses. |> What |> happens when the service gets greedy and (after enough people are |> dependent) |> raises the rates? You think that can be avoided by contract? That |> brings us |> back to the question of how long a contract is ''long enough?'' | |This is the exact reason why we should not create a monopoly but foster |healthy |competition. Previously you argued that a registry might need recurring fees in order to recover its costs of operation. Now you are talking about competition. Cost-recovery operation and competition are not particularly compatible. Competition typically requires profit since there is little incentive in competing if you don't get anything by being better. I'll assume that when you said, ``recover the costs of operation'' you really meant to say, ``make a profit''. Now, let's assume that we have created this environment of healthy competition that you espouse. Who gets to decide who is allowed to compete by being a registry? It can't be a free-for-all because then anyone could bypass the fees of existing registries by declaring herself a registry and allocating addresses for free. I'll bet your answer is that the registries should themselves pay recurring fees to a higher authority for the privilege of being in this profitable business that we have created. That also conveniently locks out anyone who might want to offer addresses for a small one-time fee (or perhaps for no fee at all) and maintains the MLM status quo. |If you're not happy with network solution for your DNS name |danlan.com, you can switch to another one. We can have the same model |here. And how exactly do you know to switch right before the bankruptcy? What's the cost of your time tracking such events? For DNS names there is a technical excuse for ongoing maintenance because the owner has to interact with the registry and the registry has to interact with the root name servers. (These interactions--"updates"--were exactly what the initial domain name fees were alleged to cover. That was before folks had been acclimated to the idea that there should be recurring fees for all manner of things and that they were not owners but renters.) Those excuses do not apply in the case of the addresses under discussion. Your analogy, while not quite as bad as your previous comparison to a pyramid scheme, is still flawed. |> In any case, the actual cost of |> maintaining an individual address would be swamped by the costs of |> billing the |> renter for that address. | |Billing & recurrent fees is a way to guaranty that the database will be |maintainable. Nonsense. Recurring fees are a way to guarantee that someone can make (more) money. They guarantee nothing about the database. The maintainers can squander the recurring fees just as well as they can squander the one-time fee. The way to guarantee the maintainability of the database is to make it largely independent of the allocator. Allocations could be self-proving and held by the owners. This could be achieved with public key crypto, for example. |With permanent allocation, the day you get close to exhausting the pool |of new subscribers, the rate of new subscription may not be enough to |recover the |cost of maintaining the database. This is just your broken pyramid scheme analogy again, based on the assumption that only ongoing user fees can pay for ongoing costs. Did it ever occur to you that the allocator could invest most of the one-time fee and use the return on that investment to pay ongoing costs? Now, you may say, with the example of Enron and friends we can assume that they won't do that but will instead take the fee out in executive compensation and such. This may well be true, but the solution is not to throw even more money (in the form of recurring fees) at them. If they appropriate the one-time fee they will appropriate the recurring fees as well. All the recurring fee model does is give them the opportunity to go back to the well over and over again, increasing fees as they squander more and more money. |> But even the premise behind your analogy is wrong. A one-time payment |> does |> not in any way imply that ``new comers'' are paying to support previous |> customers. The future value of money is well understood. If the cost |> of |> maintaining an address in the database can be expressed as a recurring |> fee |> then it can also be expressed as a one-time fee. A recurring fee is |> just a |> way to hide the true cost from the customer. It also decouples the fee |> from the cost of maintaining the database (because the billing and |> other |> administrative overhead will dominate the computation), allowing lots |> of |> wiggle room for little extra expenses. And most people won't even do |> the |> annuity calculation to determine their equivalent up-front cost. | |I'm not sure the future value of money is that well understood for |infinite length of time... |Actually, I'm sure of the opposite. A little while ago you seemed sure that the one-time fee model was equivalent to a chain letter scheme even though the math is totally different. Your economic analysis is, at best, questionable. 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 Tue Feb 10 15:51: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 PAA13226 for ; Tue, 10 Feb 2004 15:51:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqeqk-000462-4V for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 15:51:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AKpH28015739 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 15:51:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqeqj-00045m-O6 for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 15:51:17 -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 PAA13188 for ; Tue, 10 Feb 2004 15:51:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqeqi-0006we-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 15:51:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqepp-0006qe-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 15:50:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqep6-0006jl-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 15:49:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeZ3-00027o-Fx; Tue, 10 Feb 2004 15:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeY8-00024w-TS for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 15:32: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 PAA12305 for ; Tue, 10 Feb 2004 15:32:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqeY7-0004wO-00 for ipv6@ietf.org; Tue, 10 Feb 2004 15:32:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqeX7-0004qZ-00 for ipv6@ietf.org; Tue, 10 Feb 2004 15:31:02 -0500 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1AqeW9-0004kv-00 for ipv6@ietf.org; Tue, 10 Feb 2004 15:30:02 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA23656; Tue, 10 Feb 2004 15:29:58 -0500 (EST) Date: Tue, 10 Feb 2004 15:29:58 -0500 (EST) From: Dan Lanciani Message-Id: <200402102029.PAA23656@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.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.9 required=5.0 tests=AWL autolearn=no version=2.60 Zefram wrote: |The allocation bitmap would be 128GiB. That fits onto one current |commodity hard disk. Are we really quibbling over who's going to have |to pay for eternal reliable storage of such a trifling dataset? Not really. It's just folks grasping at straws in a desperate effort to turn something simple into something complicated and expensive. It will be interesting to see if they are allowed to succeed. |When this issue was raised on one of the previous occasions, some months |ago, I considered setting up a proof-of-concept automated registry |for 36-bit random numbers (thus scaled down by a mere factor of 16) |on my home equipment. Regrettably I never got round to doing that, but |it seems it might still be of use. Operating such a thing might also |have useful lessons for the operation of the eventual prefix registry. |Thoughts, anyone? As I recall, at one point someone set up a proof-of-concept auto-allocator just to show how easy it was to hand out prefixes. It was shut down very quickly. :( I'd like to know who ``requested'' this... 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 Tue Feb 10 16:11: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 QAA16282 for ; Tue, 10 Feb 2004 16:11:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf9u-00077C-OB for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 16:11:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALB6uj027344 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 16:11:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf9u-00076u-EB for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:11: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 QAA16123 for ; Tue, 10 Feb 2004 16:11:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf9s-0001tc-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 16:11:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf8e-0001dZ-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 16:09:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf7d-0001S1-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 16:08:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf5x-0005Tp-JR; Tue, 10 Feb 2004 16:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf51-0005F9-GZ for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 16:06:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15042; Tue, 10 Feb 2004 16:06:00 -0500 (EST) Message-Id: <200402102106.QAA15042@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2462bis-00.txt Date: Tue, 10 Feb 2004 16:06:00 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Stateless Address Autoconfiguration Author(s) : S. Thomson Filename : draft-ietf-ipv6-rfc2462bis-00.txt Pages : 29 Date : 2004-2-10 This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2462bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2462bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2462bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10154707.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2462bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2462bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10154707.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 Feb 10 20:00: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 UAA07492 for ; Tue, 10 Feb 2004 20:00:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqij8-0001jJ-Es for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 19:59:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B0xgcH006643 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 19:59:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqij8-0001j4-9Z for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 19:59:42 -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 TAA07404 for ; Tue, 10 Feb 2004 19:59:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqij6-0004ga-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 19:59:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqihQ-0004Ey-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 19:57:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqiev-0003aw-02 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 19:55:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqiD3-0004uJ-JF for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 19:26:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqiCZ-0007IY-IX; Tue, 10 Feb 2004 19:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqiBn-0007Fj-72 for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 19:25:15 -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 TAA03145 for ; Tue, 10 Feb 2004 19:25:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqiBl-0006JZ-00 for ipv6@ietf.org; Tue, 10 Feb 2004 19:25:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqiAq-0006E9-00 for ipv6@ietf.org; Tue, 10 Feb 2004 19:24:16 -0500 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1AqiAG-00069B-00 for ipv6@ietf.org; Tue, 10 Feb 2004 19:23:40 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id TAA26410; Tue, 10 Feb 2004 19:23:32 -0500 (EST) Date: Tue, 10 Feb 2004 19:23:32 -0500 (EST) From: Dan Lanciani Message-Id: <200402110023.TAA26410@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.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.6 required=5.0 tests=AWL autolearn=no version=2.60 Zefram wrote: |Dan Lanciani wrote: |>As I recall, at one point someone set up a proof-of-concept auto-allocator |>just to show how easy it was to hand out prefixes. It was shut down very |>quickly. :( I'd like to know who ``requested'' this... | |As I recall, it was claiming to actually allocate prefixes. Interesting. That was not the impression I got when I tested it, but obviously I knew in advance what to expect. |I don't |intend to make any such unfounded claim. I'm sure you will get all the disclaimers just right so there will be no possible reason to object to the demonstration. 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 Wed Feb 11 00:55: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 AAA20938 for ; Wed, 11 Feb 2004 00:55:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqnKd-0006sP-5s for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 00:54:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B5shgf026432 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 00:54:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqnKc-0006nN-1V for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 00:54:42 -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 AAA20904 for ; Wed, 11 Feb 2004 00:54:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqnKZ-0000Ao-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 00:54:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqnJv-00001U-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 00:54:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqnIc-0007Zb-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 00:52:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqnI7-0006Mo-TA; Wed, 11 Feb 2004 00:52:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqnHo-0006JV-6y for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 00:51:48 -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 AAA20519 for ; Wed, 11 Feb 2004 00:51:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqnHl-0007OU-00 for ipv6@ietf.org; Wed, 11 Feb 2004 00:51:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqnGK-00071X-00 for ipv6@ietf.org; Wed, 11 Feb 2004 00:50:17 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AqnEG-0006XD-00 for ipv6@ietf.org; Wed, 11 Feb 2004 00:48:08 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGW3XQ>; Wed, 11 Feb 2004 00:47:40 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042127@ftmail.lab.flarion.com> From: Soliman Hesham To: ipv6@ietf.org Subject: [rfc2461bis issue 252] Security considerations issues Date: Wed, 11 Feb 2004 00:47:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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 This issue addresses RFC 2461's assumptions about securing ND messages. The following is needed: - explain context in which IPSec can be used to secure NDP messages. This should include a reference to the SEND work. - Expand Security Considerations section to discuss more security threats defined in draft-ietf-send-psreq-xx.txt. - Need more elaborate discussion on manual vs. dynamic keying. I'm currently doing the following: 1. Adding a new section (3.2) before the message formats to briefly explain that security is outside the scope of this doc and refer to SEND work. It also explains when IPsec can be used. 2. Remove the "AH" sections included under the message formats. They're not wrong per se, but they give the impression that IPsec is always possible. Any objections to this step? 3. Remove the IPsec checks in the sections describing the validation of various ND messages. 4. Rewrite most of section 11. Here is section 3.2 so far: 3.2 Securing Neighbor Discovery messages "Neighbor Discovery messages are needed for various functions. Several functions are designed to allow hosts to ascertain the ownership of an address or the mapping between link layer and IP layer addresses. Having Neighbor Discovery functions on the ICMP layer allows for the use of IP layer security mechanisms, which are available independently of the availability of security on the link layer. In order to allow for IP layer security, a mechanism is required to allow for dynamic keying between neighbors. The use of the Internet Key Exchange [IKE] is not suited for creating dynamic security associations that can be used to secure address resolution or neighbor solicitation messages as documented in [ICMPIKE]. The security of Neighbor Discovery messages through dynamic keying is outside the scope of this document and is addressed in [SEND]. In some cases, it may be acceptable to use statically configured security associations with either [IPv6-AH] or [IPv6-ESP] to secure Neighbor Discovery messages. However, it is important to note that statically configured security associations are not scalable (especially when considering multicast links) and are therefore limited to small networks with known hosts." Informative references: [ICMPIKE]Arkko, J., "Effects of ICMPv6 on IKE", draft-arkko-icmpv6-ike-effects-02 (work in progress), March 2003. Arkko, J., "Manual Configuration of Security Associations for IPv6 Neighbor Discovery", draft-arkko-manual-icmpv6-sas-02 (work in progress), March 2003. Section 11 is too long to send. I'm interested to know if the above steps are ok with everyone. Comments? Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 04:05: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 EAA23252 for ; Wed, 11 Feb 2004 04:05:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqqJF-0001uv-QT for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 04:05:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B95T9t007364 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 04:05:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqqJF-0001uf-45 for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 04:05: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 EAA23227 for ; Wed, 11 Feb 2004 04:05:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqqJC-0002C5-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 04:05:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqqIH-00026p-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 04:04:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqqHN-000223-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 04:03:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqqGt-0001ZE-Bf; Wed, 11 Feb 2004 04:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqqGM-0001Rj-Oz for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 04:02:30 -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 EAA23174 for ; Wed, 11 Feb 2004 04:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqqGK-0001wQ-00 for ipv6@ietf.org; Wed, 11 Feb 2004 04:02:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqqFT-0001rp-00 for ipv6@ietf.org; Wed, 11 Feb 2004 04:01:36 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AqqEf-0001mM-00 for ipv6@ietf.org; Wed, 11 Feb 2004 04:00:45 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 6C8C86A902; Wed, 11 Feb 2004 11:00:40 +0200 (EET) Message-ID: <4029EECF.9050704@kolumbus.fi> Date: Wed, 11 Feb 2004 10:58:55 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: ipv6@ietf.org Subject: Re: [rfc2461bis issue 252] Security considerations issues References: <9E3BA3946476AD4EB94672712B12A85F042127@ftmail.lab.flarion.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F042127@ftmail.lab.flarion.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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > This issue addresses RFC 2461's assumptions about > securing ND messages. Thanks for taking this up. > The following is needed: > > - explain context in which IPSec can be used to secure NDP messages. > This should include a reference to the SEND work. > > - Expand Security Considerations section to discuss more security > threats defined in draft-ietf-send-psreq-xx.txt. > > - Need more elaborate discussion on manual vs. dynamic keying. I think the general approach is correct. You may wish to avoid an extensive discussion of the threats and just list the main ones, then refere to the details through psreq (which I believe has been approved by IESG). Also, I think what you are trying to achieve is (a) make it still possible to use the old AH-based approach but explain its limitations better, (b) inform the reader about the availability of another approach, SEND, and (c) inform the reader about the various vulnerabilities associated with running ND without security. This is a good approach. But there's the additional issue of what you actually are mandating in this document, and with what keywords. Do you have a suggestion on what it should be? > I'm currently doing the following: > > 1. Adding a new section (3.2) before the message formats > to briefly explain that security is outside the scope of > this doc and refer to SEND work. It also explains when IPsec > can be used. Perhaps the latter explanation could go into the security considerations section. > 2. Remove the "AH" sections included under the message formats. > They're not wrong per se, but they give the impression that > IPsec is always possible. Any objections to this step? > > 3. Remove the IPsec checks in the sections describing the > validation of various ND messages. > > 4. Rewrite most of section 11. Ok. > Here is section 3.2 so far: > > 3.2 Securing Neighbor Discovery messages > > "Neighbor Discovery messages are needed for various functions. Several > functions are designed to allow hosts to ascertain the ownership of an > address or the mapping between link layer and IP layer addresses. Having > Neighbor Discovery functions on the ICMP layer allows for the use of IP > layer security mechanisms, which are available independently of the > availability of security on the link layer. > > In order to allow for IP layer security, a mechanism is required to allow > for dynamic keying between neighbors. The use of the Internet Key Exchange > [IKE] is not suited for creating dynamic security associations that can be > used to secure address resolution or neighbor solicitation messages as > documented in [ICMPIKE]. The security of Neighbor Discovery messages through > dynamic keying is outside the scope of this document and is addressed in > [SEND]. > > In some cases, it may be acceptable to use statically configured security > associations with either [IPv6-AH] or [IPv6-ESP] to secure Neighbor > Discovery messages. However, it is important to note that statically > configured security associations are not scalable (especially when > considering multicast links) and are therefore limited to small networks > with known hosts." How about this for 3.2: Vulnerabilities related to Neighbor Discovery are discussed in Section 11.1. A general solution for securing Neighbor Discovery is outside the scope of this specification and is discussed in [SEND]. However, Section 11.2 explains how and under which constraints IPsec AH or ESP can be used to secure Neighbor Discovery. And then in 11.1 and 11.2 you would include text from the above. > Informative references: > > [ICMPIKE]Arkko, J., "Effects of ICMPv6 on IKE", > draft-arkko-icmpv6-ike-effects-02 (work in progress), March > 2003. > > Arkko, J., "Manual Configuration of Security Associations for > IPv6 Neighbor Discovery", draft-arkko-manual-icmpv6-sas-02 > (work in progress), March 2003. And [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-04 (work in progress), February 2004. > Section 11 is too long to send. I'm interested to know if the > above steps are ok with everyone. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 04:31: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 EAA24303 for ; Wed, 11 Feb 2004 04:31:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqqi9-00047Y-IB for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 04:31:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B9VDxL015834 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 04:31:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqqi8-00047J-TL for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 04:31:12 -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 EAA24254 for ; Wed, 11 Feb 2004 04:31:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqqi6-0004pG-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 04:31:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqqhI-0004fP-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 04:30:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqqgG-0004TD-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 04:29:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqqg4-0003d4-CB; Wed, 11 Feb 2004 04:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqqfW-0003Xg-2I for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 04:28:30 -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 EAA23883 for ; Wed, 11 Feb 2004 04:28:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqqfT-0004NL-00 for ipv6@ietf.org; Wed, 11 Feb 2004 04:28:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqqeU-0004Gy-00 for ipv6@ietf.org; Wed, 11 Feb 2004 04:27:27 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AqqdW-000471-00 for ipv6@ietf.org; Wed, 11 Feb 2004 04:26:26 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGWP2R>; Wed, 11 Feb 2004 04:26:03 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042129@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Jari Arkko'" Cc: ipv6@ietf.org Subject: RE: [rfc2461bis issue 252] Security considerations issues Date: Wed, 11 Feb 2004 04:25:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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 Thanks Jari, a couple of answers below. > > - explain context in which IPSec can be used to secure NDP > messages. > > This should include a reference to the SEND work. > > > > - Expand Security Considerations section to discuss more security > > threats defined in draft-ietf-send-psreq-xx.txt. > > > > - Need more elaborate discussion on manual vs. dynamic keying. > > I think the general approach is correct. You may wish to > avoid an extensive discussion of the threats and just list > the main ones, then refere to the details through psreq > (which I believe has been approved by IESG). => Defeinitely. That's my intention. > > Also, I think what you are trying to achieve is (a) make > it still possible to use the old AH-based approach but > explain its limitations better, (b) inform the reader about > the availability of another approach, SEND, and (c) inform the > reader about the various vulnerabilities associated with > running ND without security. This is a good approach. But > there's the additional issue of what you actually are mandating > in this document, and with what keywords. Do you have a suggestion > on what it should be? => There are two issues here: a) The current Keywords used for IPsec. They should definitely be lighter (no SHOULDs, MAY at best) or removed totally. b) What to use for SEND. I have no idea about b). As for a) I think we should remove any keywords on IPsec. I tend to think MAY is appropriate for SEND. Any ideas? > > 1. Adding a new section (3.2) before the message formats > > to briefly explain that security is outside the scope of > > this doc and refer to SEND work. It also explains when IPsec > > can be used. > > Perhaps the latter explanation could go into the security > considerations section. => ok. > How about this for 3.2: => BTW, this is section 3.3 ( a new one) sorry for the confusion. > > Vulnerabilities related to Neighbor Discovery are discussed in > Section 11.1. A general solution for securing Neighbor Discovery > is outside the scope of this specification and is discussed in > [SEND]. However, Section 11.2 explains how and under > which constraints > IPsec AH or ESP can be used to secure Neighbor Discovery. > > And then in 11.1 and 11.2 you would include text from the above. > Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 11:50: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 LAA09037 for ; Wed, 11 Feb 2004 11:50:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxYX-0007AZ-Hu for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 11:49:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BGnjHg027555 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 11:49:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxYX-0007AM-Bx for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 11:49: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 LAA09015 for ; Wed, 11 Feb 2004 11:49:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxYW-0001L6-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 11:49:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxXc-0001G2-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 11:48:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqxXP-0001Au-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 11:48:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxWs-0006s3-3I; Wed, 11 Feb 2004 11:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxWf-0006qb-Ji for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 11:47:49 -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 LAA08929 for ; Wed, 11 Feb 2004 11:47:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxWe-00019d-00 for ipv6@ietf.org; Wed, 11 Feb 2004 11:47:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxVk-00013p-00 for ipv6@ietf.org; Wed, 11 Feb 2004 11:46:53 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AqxUx-0000xt-00 for ipv6@ietf.org; Wed, 11 Feb 2004 11:46:03 -0500 Message-ID: <009801c3f0be$9953e310$936015ac@dclkempt40> From: "James Kempf" To: "Soliman Hesham" , References: <9E3BA3946476AD4EB94672712B12A85F042127@ftmail.lab.flarion.com> Subject: Re: [rfc2461bis issue 252] Security considerations issues Date: Wed, 11 Feb 2004 08:46:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hesham, Comments embedded. > - explain context in which IPSec can be used to secure NDP messages. > This should include a reference to the SEND work. > > - Expand Security Considerations section to discuss more security > threats defined in draft-ietf-send-psreq-xx.txt. > > - Need more elaborate discussion on manual vs. dynamic keying. > > I'm currently doing the following: > > 1. Adding a new section (3.2) before the message formats > to briefly explain that security is outside the scope of > this doc and refer to SEND work. It also explains when IPsec > can be used. > I think it might be wise to discuss whether the document should continue to recommend IPsec with the Security ADs and get some input from the community and the security directorate. draft-arkko-manual-icmpv6-sas-01.txt outlines some scalability problems with IPsec, even if manual keying is used, as you mention below. There is a potential deployment issue as to what constitutes a "small" network and at what point the network hits the scalability barrier when the network provider will have to completely reconfigure their network and turn SEND on. I'm not sure whether it makes sense to recommend manual keying for small networks when SEND would work as well and wouldn't require a flag day reconfigure if the network grew too large. Also, manual keying doesn't make sense for zeroconf networks, because it isn't zeroconf. The ND part of SEND could be used for disconnected zeroconf networks, and the router part could too if the host came preconfigured with a collection of cert trust anchors. > 2. Remove the "AH" sections included under the message formats. > They're not wrong per se, but they give the impression that > IPsec is always possible. Any objections to this step? > > 3. Remove the IPsec checks in the sections describing the > validation of various ND messages. > > 4. Rewrite most of section 11. > These look OK. > Here is section 3.2 so far: > > 3.2 Securing Neighbor Discovery messages > > "Neighbor Discovery messages are needed for various functions. Several > functions are designed to allow hosts to ascertain the ownership of an > address or the mapping between link layer and IP layer addresses. Having > Neighbor Discovery functions on the ICMP layer allows for the use of IP > layer security mechanisms, which are available independently of the > availability of security on the link layer. > I would say "requires the use of IP layer", since if the user chooses to use security in ND, they must use IP layer security. > In order to allow for IP layer security, a mechanism is required to allow > for dynamic keying between neighbors. The use of the Internet Key Exchange > [IKE] is not suited for creating dynamic security associations that can be > used to secure address resolution or neighbor solicitation messages as > documented in [ICMPIKE]. The security of Neighbor Discovery messages through > dynamic keying is outside the scope of this document and is addressed in > [SEND]. > > In some cases, it may be acceptable to use statically configured security > associations with either [IPv6-AH] or [IPv6-ESP] to secure Neighbor > Discovery messages. However, it is important to note that statically > configured security associations are not scalable (especially when > considering multicast links) and are therefore limited to small networks > with known hosts." > Reads well. If there is support for completely deprecating IPsec for ND, I'd suggest adding that instead. > Informative references: > > [ICMPIKE]Arkko, J., "Effects of ICMPv6 on IKE", > draft-arkko-icmpv6-ike-effects-02 (work in progress), March > 2003. > > Arkko, J., "Manual Configuration of Security Associations for > IPv6 Neighbor Discovery", draft-arkko-manual-icmpv6-sas-02 > (work in progress), March 2003. > > Section 11 is too long to send. I'm interested to know if the > above steps are ok with everyone. > I assume you will also put a reference to draft-send-ndopts (to be changed into the RFC when it passes IESG review) in the normative references section? jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 12:01: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 MAA09504 for ; Wed, 11 Feb 2004 12:01:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxjK-0008Ma-VO for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 12:00:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BH0s5e032142 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 12:00:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxjK-0008ML-Pr for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 12:00:54 -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 MAA09476 for ; Wed, 11 Feb 2004 12:00:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxjJ-0002S4-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 12:00:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxiN-0002Ln-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 11:59:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqxi5-0002FZ-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 11:59:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxhU-0007mO-W7; Wed, 11 Feb 2004 11:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxhG-0007lp-0w for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 11:58:46 -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 LAA09368 for ; Wed, 11 Feb 2004 11:58:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxhE-0002Dl-00 for ipv6@ietf.org; Wed, 11 Feb 2004 11:58:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxgH-00028D-00 for ipv6@ietf.org; Wed, 11 Feb 2004 11:57:46 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AqxfR-00022W-00 for ipv6@ietf.org; Wed, 11 Feb 2004 11:56:53 -0500 Message-ID: <00e601c3f0c0$1bc1f930$936015ac@dclkempt40> From: "James Kempf" To: "Soliman Hesham" , "'Jari Arkko'" Cc: References: <9E3BA3946476AD4EB94672712B12A85F042129@ftmail.lab.flarion.com> Subject: Re: [rfc2461bis issue 252] Security considerations issues Date: Wed, 11 Feb 2004 08:57:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > => There are two issues here: a) The current Keywords used > for IPsec. They should definitely be lighter (no SHOULDs, > MAY at best) or removed totally. b) What to use for SEND. > I have no idea about b). As for a) I think we should remove > any keywords on IPsec. I tend to think MAY is appropriate > for SEND. Any ideas? > I think we need to ask the Security ADs about this. Of the drafts I've seen, security is a MUST in standards track drafts, otherwise, there's a risk that the standard is recommending something lax and subject to attack. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 13:59: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 NAA13963 for ; Wed, 11 Feb 2004 13:59:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzZb-0001Jg-IF for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 13:58:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BIwxbA005054 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 13:58:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzZb-0001JR-CA for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 13:58:59 -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 NAA13955 for ; Wed, 11 Feb 2004 13:58:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzZZ-0006Xn-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 13:58:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzYf-0006Qu-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 13:58:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqzY3-0006KA-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 13:57:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzXi-0000jb-OL; Wed, 11 Feb 2004 13:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzXa-0000j0-A5 for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 13:56:54 -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 NAA13824 for ; Wed, 11 Feb 2004 13:56:52 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzXY-0006J6-00 for ipv6@ietf.org; Wed, 11 Feb 2004 13:56:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzWs-0006Dc-00 for ipv6@ietf.org; Wed, 11 Feb 2004 13:56:11 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqzW9-00067n-00 for ipv6@ietf.org; Wed, 11 Feb 2004 13:55:25 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BItOq17488 for ; Wed, 11 Feb 2004 20:55:24 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 11 Feb 2004 20:55:23 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 11 Feb 2004 20:55:22 +0200 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: ed nits:draft-ietf-ipv6-node-requirements-07.txt Date: Wed, 11 Feb 2004 20:55:23 +0200 Message-ID: Thread-Topic: I-D ACTION:draft-ietf-ipv6-node-requirements-07.txt Thread-Index: AcPEpuja82B7LW5pRDq/fwaKZ/OgvgsKZjhQ To: X-OriginalArrivalTime: 11 Feb 2004 18:55:22.0842 (UTC) FILETIME=[9A4283A0:01C3F0D0] 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 Assigned issue 32. > Just a couple of editorial nits: >=20 > For nodes which do not support Stateful Address Autoconfiguration, > the node may be unable to obtain any IPv6 addresses aside=20 > from link- > local addresses >=20 > =3D=3D> rewrite: >=20 > Nodes which do not support Stateful Address Autoconfiguration > may be unable to obtain any IPv6 addresses aside from link- > local addresses >=20 > [same style as the rest of the similar paragraphs..] > ... >=20 > DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] > and [RFC-1886] MAY be supported. >=20 > =3D=3D> s/1886/3596/ (already OK in the rest of the document, forgot = to=20 > update this one :-) >=20 > portions of this MIB be supported. > 11. Security Considerations >=20 > =3D=3D> add an empty line. >=20 > [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling > in IPv6 Specification", RFC 2473, December=20 > 1998. Xxx > add > =20 > =20 > =20 > [RFC-2671] > =20 > =20 > =20 > [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast > Listener Discovery (MLD) for IPv6", RFC=20 > 2710, October > 1999. > =20 > =20 > =20 > =3D=3D> add the reference info to 2671 :-) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 14:04: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 OAA14354 for ; Wed, 11 Feb 2004 14:04:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzeR-0002B3-Gh for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:04:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJ3xju008363 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:03:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzeR-0002Ao-C4 for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 14:03:59 -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 OAA14326 for ; Wed, 11 Feb 2004 14:03:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzeP-0007Aj-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:03:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzdR-00073p-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:02:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzck-0006xR-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:02:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzcX-0001TM-KK; Wed, 11 Feb 2004 14:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzbf-0001Rq-I7 for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 14:01:07 -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 OAA14084 for ; Wed, 11 Feb 2004 14:01:05 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzbd-0006pV-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:01:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqzaa-0006go-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:00:01 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqzZj-0006ZK-00 for ipv6@ietf.org; Wed, 11 Feb 2004 13:59:07 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BIx6q21252 for ; Wed, 11 Feb 2004 20:59:07 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 11 Feb 2004 20:59:06 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 11 Feb 2004 20:59:06 +0200 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: Issue 33: Evaluation of: draft-ietf-ipv6-node-requirements-07.txt Date: Wed, 11 Feb 2004 20:59:06 +0200 Message-ID: Thread-Topic: FW: Evaluation of: draft-ietf-ipv6-node-requirements-07.txt Thread-Index: AcPJUuZdq/Dzns8DTTydWfqRk2m0pwnfiAGQ To: Cc: X-OriginalArrivalTime: 11 Feb 2004 18:59:06.0376 (UTC) FILETIME=[1F7F1880:01C3F0D1] 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 Assigned issue 33. > >>I'm astonished that Path MTU is a MAY -- I had thought it was=20 > >>a MUST. I'd really like some more text explaining what some=20 > >>of the many exceptions are that are alluded to here. >=20 > It follows RFC 2460, which states: >=20 > It is strongly recommended that IPv6 nodes implement Path MTU > Discovery [RFC-1981], in order to discover and take advantage of = path > MTUs greater than 1280 octets. However, a minimal IPv6 > implementation (e.g., in a boot ROM) may simply restrict itself to > sending packets no larger than 1280 octets, and omit = implementation > of Path MTU Discovery. >=20 > Given this, I'm not sure we can convert it to a MUST. But > did you have some specific text issues about the Path MTU > text as well? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 14:05: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 OAA14437 for ; Wed, 11 Feb 2004 14:05:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzfO-0002UX-8y for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:04:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJ4wHt009571 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:04:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzfO-0002UH-3y for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 14:04:58 -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 OAA14390 for ; Wed, 11 Feb 2004 14:04:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzfL-0007IC-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:04:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzeR-0007BI-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:04:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqzdU-00074L-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14: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 1AqzdV-0001ll-NN; Wed, 11 Feb 2004 14:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzcb-0001XU-E5 for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 14:02:05 -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 OAA14180 for ; Wed, 11 Feb 2004 14:02:02 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzcZ-0006wr-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:02:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzbZ-0006p5-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:01:02 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqzaT-0006fc-00 for ipv6@ietf.org; Wed, 11 Feb 2004 13:59:54 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BIxrq22184 for ; Wed, 11 Feb 2004 20:59:53 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 11 Feb 2004 20:59:53 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 11 Feb 2004 20:59:51 +0200 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: [node req] Issue 34: security issues Date: Wed, 11 Feb 2004 20:59:52 +0200 Message-ID: Thread-Topic: FW: Evaluation of: draft-ietf-ipv6-node-requirements-07.txt Thread-Index: AcPJUuZdq/Dzns8DTTydWfqRk2m0pwnfjrOQ To: Cc: X-OriginalArrivalTime: 11 Feb 2004 18:59:51.0796 (UTC) FILETIME=[3A91A340:01C3F0D1] 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 Assigned issue 34. > >>For Section 8, RFCs 2401, 2402, and 2406 are currently being=20 > >>revised by the IPsec group; that should be mentioned. >=20 > Ok. I agree that it is good to alert the reader to the > fact that some of the documents may have updated RFCs > available. Thanks. >=20 > >>The crypto algorithm requirements should be better aligned=20 > >>with recommendations from the IPsec wg. There's a draft that=20 > >>lists 3DES as SHOULD, not MAY. >=20 > The problem is that the requirements have been aligned with > the recommendations of the IPsec, as they exist in *RFCs*. > Not drafts. >=20 > I personally think that we need to recommend and inform > about better alternatives, even if such alternatives do not > yet exist as RFCs or if they are not mandated by keywords. > This is what we have done -- the document talks about 3DES, > AES, etc. >=20 > However, there has been general resistance in the WG (maybe even the > ADs) for us to mandate anything beyond the current normative RFCs. It > was felt that the original RFCs should rather be updated than the > node requirements document made to impose additional requirements. > If the IESG thinks its okay for us to mandate stronger algorithms > than what the current IPsec RFCs say, then I'm going to be > *very* happy. >=20 > But if, not then I think its up to the IPsec WG to advance their > documents and mandate the algorithms that they think are > appropriate. >=20 > >>I think that IKEv? should be a SHOULD, not a MAY. While the=20 > >>IESG hasn't yet seen draft-bellovin-mandate-keymgmt, it will=20 > >>soon and it describes automated key management as a "strong=20 > >>SHOULD". That's certainly the consensus in the security area. >=20 > This is also related to the question of what the current > RFCs say. In the case of IKE, I'm actually uncertain what > the keyword is -- it is not immediately clear to me from the > document. Perhaps it is to others, I would appreciate comments > on this! I think we should use a keyword that the current > RFCs have, whatever that is. >=20 > Anyway, I think the node requirements document is somewhat > different than a usual IETF protocol document. In the RFC for > for protocol FOO, there are some security issues and those > are solved with the support of some security mechanisms. >=20 > But here, the specific security issues appear within the > RFCs that we refer to, and the necessary security mechanisms > are introduced there as well. So when talking about FOO > and IKE, we know that IKE addresses FOO's issues. But in > the case of the node requirements document, the security > issues either have been addressed in the relevant RFCs, or > those RFCs should be reissued and corrected. >=20 > Additional stuff can be extremely useful for the nodes, but it > may not address any IPv6-specific issue. For instance, if we > required IKE, TLS, and S/MIME, this would make sure that > those are available to the IPv6 nodes, but none of them would > help addressing the security issues in, say, IPv6 ND. >=20 > So I guess what I am looking for is some guidance on whether > this document should focus on the IPv6 specific part, or give > a more general requirements. I think we need to choose between >=20 > (1) "We, the IETF, think that in order to do IPv6, you > need .", and > (2) "We, the IETF, think that in order to do IPv6, you > need and the user on a node surely needs > also ." >=20 > I'm fine doing it either way, but we need to agree what > the scope is. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 14:06: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 OAA14524 for ; Wed, 11 Feb 2004 14:06:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzgW-0002XZ-3g for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:06:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJ68pD009759 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:06:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzgV-0002XK-Vc for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 14:06:08 -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 OAA14507 for ; Wed, 11 Feb 2004 14:06:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzgT-0007S0-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:06:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzfY-0007KC-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:05:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzet-0007Ce-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:04:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzeU-0002BR-GJ; Wed, 11 Feb 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 1AqzeJ-00028U-4r for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 14:03: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 OAA14302 for ; Wed, 11 Feb 2004 14:03:48 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzeG-00079U-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:03:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzdH-00072E-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:02:48 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqzcM-0006uv-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:01:50 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BJ1nq24771 for ; Wed, 11 Feb 2004 21:01:50 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 11 Feb 2004 21:01:49 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 11 Feb 2004 21:01:49 +0200 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: [node req] issue 35 - toc Date: Wed, 11 Feb 2004 21:01:49 +0200 Message-ID: Thread-Topic: [Fwd: I-D ACTION:draft-ietf-ipv6-node-requirements-07.txt] Thread-Index: AcO/c7Ymh31Yf9E5TOuFVRCo5ZLSawxXbL7g To: , X-OriginalArrivalTime: 11 Feb 2004 19:01:49.0499 (UTC) FILETIME=[80B9B0B0:01C3F0D1] 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 Assigned issue 35. > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > hi John, >=20 > the table of contents is not consistent with the text. > there are section 7, 7.1 and 7.2. the text only has > section 7. >=20 > Vijay -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 14:13: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 OAA15103 for ; Wed, 11 Feb 2004 14:13:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqznI-0003Sl-1H for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:13:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJD7SV013305 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqznH-0003SW-Qv for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 14:13:07 -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 OAA15084 for ; Wed, 11 Feb 2004 14:13:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqznF-0000ge-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:13:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzmO-0000YG-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:12:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqzlW-0000PR-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:11:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzlH-00038A-D3; Wed, 11 Feb 2004 14:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzkb-000376-Hm for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 14:10:21 -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 OAA14815 for ; Wed, 11 Feb 2004 14:10:19 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzkZ-0000FT-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:10:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqzjh-00006D-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:09:25 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzit-0007jV-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:08:35 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BJ8Yv19611 for ; Wed, 11 Feb 2004 21:08:34 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 11 Feb 2004 21:08:34 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 11 Feb 2004 21:08:07 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 11 Feb 2004 21:08:07 +0200 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: [node req] issue 36 - mib issues Date: Wed, 11 Feb 2004 21:08:07 +0200 Message-ID: Thread-Topic: FW: Evaluation of: draft-ietf-ipv6-node-requirements-07.txt Thread-Index: AcPJUuZdq/Dzns8DTTydWfqRk2m0pwnf2EuA To: Cc: X-OriginalArrivalTime: 11 Feb 2004 19:08:07.0164 (UTC) FILETIME=[61D4CBC0:01C3F0D2] 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 assigned issue 36. > > Set 2: > > =20 > >=20 > >>1. Section 10.1.1 talks about "IP Forwarding Table MIB" > >> The revision of this MIB document (that you refer to) has a number > >> of deprecated and obsoleted objects. I think what you=20 > want (intend) > >> to say is that an agent must implement those objects that are > >> required as per ipForwardFullCompliance or=20 > ipForwardReadOnlyCompliance. > >> > >> I am also not sure that this is correct: > >> Support for this MIB does not imply that IPv4 or IPv4 specific > >> portions of this MIB be supported. > >> Did you mean "IPv4 or IPv6 specific portions" ? >=20 > I think the intent was to say that if you implement IPv6 and as a > result also the forwarding table MIB, it does not follow that you also > have to implement all of IPv4. >=20 > >> But maybe the sentence is not needed at all. The two = MODULE-COMPLIANCEs > >> that I point you to above specify IP version neurtral objects! >=20 > I'm glad to hear that its IP version neutral. >=20 > So what happens if I create a new InetCidrRouteEntry and > set inetCidrRouteDestType to "ipv4" on a box that supports > only IPv6? >=20 > What I would like to happen is that this would fail, and > doing so would not mean that the box violates 2096bis... >=20 > >>2. Similar comments/issue with Sect 10.1.2 > >> I think you want to refer to CURRENT MODULE-COMPLIANCE, namely=20 > >> ipMIBCompliance2. Pls check and make sure you be specific as to = what > >> needs to be supported. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 14:24: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 OAA15900 for ; Wed, 11 Feb 2004 14:24:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzxl-0004Se-Mf for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:23:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJNvLN017142 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:23:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzxl-0004SP-Ij for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 14:23: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 OAA15877 for ; Wed, 11 Feb 2004 14:23:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzxj-00024F-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:23:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqzws-0001xi-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:23:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzw7-0001qv-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 14:22:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzvu-00046T-8l; Wed, 11 Feb 2004 14:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzvk-00045l-9d for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 14:21: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 OAA15750 for ; Wed, 11 Feb 2004 14:21:49 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzvh-0001oP-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:21:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqzuk-0001hX-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:20:50 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aqztk-0001Z4-00 for ipv6@ietf.org; Wed, 11 Feb 2004 14:19:48 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BJJmq14210 for ; Wed, 11 Feb 2004 21:19:48 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 11 Feb 2004 21:19:44 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 11 Feb 2004 21:18:49 +0200 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: [node req] Issue37: EDNS0 support Date: Wed, 11 Feb 2004 21:14:40 +0200 Message-ID: Thread-Topic: Evaluation of: draft-ietf-ipv6-node-requirements-07.txt Thread-Index: AcPIFsgHRsoednRPRbGbhM7mCEW/ygADw9xQCitVelA= To: X-OriginalArrivalTime: 11 Feb 2004 19:18:49.0982 (UTC) FILETIME=[E0FB09E0:01C3F0D3] 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 assigned issue 37 > From OPS Directorate (Pekka): >=20 > I've reviewed this along the line, and it's pretty good stuff. >=20 > I've sent 3 editorial typos to the author directly. >=20 > One bigger issue, which may not be worth a Discuss, but=20 > something that=20 > IMHO should be discussed in some forum: >=20 > All nodes that need to resolve names SHOULD implement stub- > resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with > support for: > =20 > =20 > =20 > - AAAA type Resource Records [RFC-3596]; > - reverse addressing in ip6.arpa using PTR records [RFC-3152]; > - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 > octets. >=20 > .. I'm operationally concerned about the last SHOULD. As far as I=20 > know, EDNS0 is not really implemented. It does not seem to include a=20 > SHOULD to something that hasn't seen practical, wide-spread=20 > deployment=20 > already. I'd recommend removing this or rewording it to a MAY. >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 16:07: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 QAA23972 for ; Wed, 11 Feb 2004 16:07:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Zh-0006EY-Px for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 16:07:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BL7D1j023956 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 16:07:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Zg-0006EJ-IZ for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 16:07:12 -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 QAA23903 for ; Wed, 11 Feb 2004 16:07:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Ze-0005ac-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:07:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1YX-0005RA-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:06:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Y1-0005Kd-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:05:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Wc-0005km-In; Wed, 11 Feb 2004 16: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 1Ar1Vk-0005hC-N3 for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 16:03:08 -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 QAA23493 for ; Wed, 11 Feb 2004 16:03:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Vj-00056G-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:03:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1Uj-0004yY-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:02:05 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1UB-0004pP-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:01:32 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1BL0sg11628; Wed, 11 Feb 2004 13:00:54 -0800 X-mProtect: <200402112100> 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 smtpdvTYdui; Wed, 11 Feb 2004 13:00:52 PST Message-Id: <4.3.2.7.2.20040211125234.0436fda8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Feb 2004 12:57:24 -0800 To: ipv6@ietf.org From: Bob Hinden Subject: Re: [node req] Issue37: EDNS0 support Cc: john.loughney@nokia.com 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.0 required=5.0 tests=AWL autolearn=no version=2.60 > > > - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 > > octets. > > > > .. I'm operationally concerned about the last SHOULD. As far as I > > know, EDNS0 is not really implemented. It does not seem to include a > > SHOULD to something that hasn't seen practical, wide-spread > > deployment > > already. I'd recommend removing this or rewording it to a MAY. > > Is there a technical problem with EDSNO (e.g., broken, doesn't scale, too complex, etc.)? Or has it not been deployed because it hasn't been implemented. If it's the latter than making it a SHOULD be implemented would appear to be the right message. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 16: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 QAA26627 for ; Wed, 11 Feb 2004 16:24:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1qF-0008BK-SQ for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 16:24:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLOJCw031444 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 16:24:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1qF-0008B5-NQ for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 16:24: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 QAA26459 for ; Wed, 11 Feb 2004 16:24:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1qD-0001PW-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:24:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1oc-00012V-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:22:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1nX-0000mv-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:21:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar1nW-0006Pq-Qa for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:21:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1n6-0007Yc-DA; Wed, 11 Feb 2004 16:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1m7-0007Ws-DV for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 16:20: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 QAA25941 for ; Wed, 11 Feb 2004 16:20:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1m5-0000aJ-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:20:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1lE-0000OI-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:19:09 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1kD-00001w-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:18:05 -0500 Received: from txc.com ([172.17.0.173]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i1BLHR024213; Wed, 11 Feb 2004 16:17:28 -0500 Message-ID: <402A9BE7.4040406@txc.com> Date: Wed, 11 Feb 2004 16:17:27 -0500 From: srihari varada 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 CC: Brian Haberman , Bob Hinden , Alex Conta , ietf_ppp@merit.edu Subject: Re: updates to IPv6 over PPP spec. References: <3FE0975E.A673612A@txc.com> <4005CA68.E37E0B56@txc.com> <400ED755.9ACA09F6@txc.com> <40200B6D.86332A04@txc.com> <4020F0F6.6000504@innovationslab.net> In-Reply-To: <4020F0F6.6000504@innovationslab.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by pguin2.txc.com id i1BLHR024213 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 Dear All: As broadcasted on the IPv6 and PPPext mailing lists some time back, we=20 are soliciting input to update the RFC 2472. Provided below is the input=20 received so far from the IPv6 community on the IPv6 over PPP spec.=20 Please review and make any additions to the list at your earliest=20 convenience. If no further input is received in the next few days or so,=20 consensus is assumed and edits to the spec. would be initiated. (1) The Duplicate address detection shouldn=92t be recommended to be=20 disabled, if the IPv6CP negotiates interface identifier with the peer. * * *Rationale:* (a) In the mobile (3GPP) networks the host isn't stationary. As such, the interface identifier uniqueness may not be ensured at different space points in the provider network (for instance, in the case of randomly generated Interface Identifier). This would then warrant the mobile host to trigger duplicate address detection as and when it changes it's position. (b) RFC 2462, section 5.4 states that if there is a group of addresses that are generated from a given interface identifier, the Link-Local address MUST at least be tested for uniqueness. It is likely that an interface would have multiple addresses (Link Local, site-local and global scope addresses, for instance). This would then necessitates the Link-Local address to be tested for uniqueness. Thus, the text needs to be changed for consistency reasons." 2. Update the reference section with corrected URL to guidelines for=20 EUI-64 assignment. Alternatively, remove the URL altogether, but keep=20 the reference identifying IEEE.org as the source. 3. Review and clarify the IPv6 over PPP specification to match the=20 current IPv6 addressing architecture. (as stated in RFC 3314) 4. RA (Route Advertisement) should be mentioned somewhere in the Document for global unicast address configuration and other=20 configuration parameters. In IPCP, the IP address is part of the IPCP.=20 But in IPv6CP, only the interface ID is negotiated and link local is=20 auto-configured. For a new comer, it took us a while to figure out that=20 RA is used to configure the rest of stuff. 5. Default ordering of IPv6CP and IPCP negotiation in a dual stack mode=20 should be explained -- RFC 1661 says that there could be one or more=20 NCPs in one PPP link. During inter-operability testing, we found some=20 vendors started NCP with IPv6CP and others with IPCP. It will evetually=20 work. But some extra messages will be dropped because of miss match. It=20 will be good to document the relationship between IPv6CP and IPCP in a=20 dual stack mode. Of course, the order should be configurable by the user=20 and one of them may be disabled in a single stack mode (either IPv4 only=20 or IPv6 only). 6. The Interface Identifier section should mention an exception (due to=20 the need for privary addresses) to the suggestion of consistent=20 reproduction of the interface identifier -- RFC 2472 states that the=20 interface identifier is suggested to be consistently reproducable across=20 initializations of the IPv6CP finite state machine (see section 4.1).=20 The text should be elaborated to include an exception as identified by=20 the Privacy Extensions for Stateless Address Autoconfiguration in IPv6=20 (RFC 3041). Regards, Srihari Varada -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 16:47: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 QAA29199 for ; Wed, 11 Feb 2004 16:47: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 1Ar2C2-0002GU-CZ for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 16:46:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLkoCo008700 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 16:46:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2C2-0002GF-2x for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 16:46:50 -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 QAA29146 for ; Wed, 11 Feb 2004 16:46:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2C0-0004qT-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:46:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2B6-0004hL-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:45:52 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar29v-0004Yl-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:44:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar29u-0006kM-FA for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:44:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar29J-0001jr-KE; Wed, 11 Feb 2004 16:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar299-0001jb-9c for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 16:43: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 QAA28990 for ; Wed, 11 Feb 2004 16:43:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar297-0004Rr-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:43:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar28A-0004KC-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:42:50 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Ar27Z-0004DL-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:42:14 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1BLg8qY002738 for ; Wed, 11 Feb 2004 22:42:12 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Feb 2004 22:42:08 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1LJQZJ18>; Wed, 11 Feb 2004 22:42:08 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639A0D@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'srihari varada'" , ipv6@ietf.org Cc: Brian Haberman , Bob Hinden , Alex Conta , ietf_ppp@merit.edu Subject: RE: updates to IPv6 over PPP spec. Date: Wed, 11 Feb 2004 22:41:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 11 Feb 2004 21:42:08.0412 (UTC) FILETIME=[E60B55C0:01C3F0E7] 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 > (1) The Duplicate address detection shouldn=92t be recommended to be=20= > disabled, if the IPv6CP negotiates interface identifier with=20 > the peer. > * > * >=20 > *Rationale:* >=20 > (a) In the mobile (3GPP) networks the host isn't stationary. As > such, the interface identifier uniqueness may not be ensured at > different space points in the provider network (for=20 > instance, in the > case of randomly generated Interface Identifier). This would then > warrant the mobile host to trigger duplicate address detection as > and when it changes it's position. (a) doesn't seem correct to me. In terms of 3GPP nets the host is stationary with respect to its default router. Also as recommended in RFC 3314 an entire /64 is assigned to a mobile's connection so DAD is not useful. Looks to me like the 3GPP case would actually be in favour of disabling DAD. /Karim This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 16:50: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 QAA29626 for ; Wed, 11 Feb 2004 16:50:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2Ek-0002oT-Bn for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 16:49:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLnckq010807 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 16:49:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2Ek-0002oE-6v for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 16:49: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 QAA29455 for ; Wed, 11 Feb 2004 16:49:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2Ei-0005Hs-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:49:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2Dj-00057t-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:48:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar2Cj-0004tw-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:47:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar2Ci-0006s4-Kq for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:47:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2CD-0002IP-UR; Wed, 11 Feb 2004 16:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2BG-00028S-AK for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 16:46: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 QAA29128 for ; Wed, 11 Feb 2004 16:45:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2BE-0004iX-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:46:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2AA-0004b3-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:44:55 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Ar29Z-0004RQ-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:44:17 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1BLhdf00713; Wed, 11 Feb 2004 22:43:39 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1BLhdSj076218; Wed, 11 Feb 2004 22:43:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402112143.i1BLhdSj076218@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipv6@ietf.org, john.loughney@nokia.com Subject: Re: [node req] Issue37: EDNS0 support In-reply-to: Your message of Wed, 11 Feb 2004 12:57:24 PST. <4.3.2.7.2.20040211125234.0436fda8@mailhost.iprg.nokia.com> Date: Wed, 11 Feb 2004 22:43:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 In your previous mail you wrote: > > - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 > > octets. > > > > .. I'm operationally concerned about the last SHOULD. As far as I > > know, EDNS0 is not really implemented. It does not seem to include a > > SHOULD to something that hasn't seen practical, wide-spread > > deployment > > already. I'd recommend removing this or rewording it to a MAY. > > Is there a technical problem with EDSNO (e.g., broken, doesn't scale, too complex, etc.)? Or has it not been deployed because it hasn't been implemented. If it's the latter than making it a SHOULD be implemented would appear to be the right message. => I simply disagree with the "as far as I know, EDNS0 is not really implemented". IMHO this is not true and not only in DNSSEC testbeds where EDNS0 is really needed. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 17:12: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 RAA02415 for ; Wed, 11 Feb 2004 17:12: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 1Ar2aT-0005pD-Rn for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 17:12:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BMC5GP022385 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 17:12:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2aT-0005oy-NZ for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 17:12:05 -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 RAA02300 for ; Wed, 11 Feb 2004 17:12:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2aR-0001KM-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:12:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2Z8-000143-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:10:43 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar2Y3-0000kY-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:09:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar2S8-000796-Cv for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:03:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2Ri-0004jW-N7; Wed, 11 Feb 2004 17: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 1Ar2RT-0004hv-TU for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 17:02:47 -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 RAA01160 for ; Wed, 11 Feb 2004 17:02:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2RR-0007U8-00 for ipv6@ietf.org; Wed, 11 Feb 2004 17:02:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2QZ-0007MQ-00 for ipv6@ietf.org; Wed, 11 Feb 2004 17:01:52 -0500 Received: from thrintun.hactrn.net ([66.92.66.67]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2Pd-00078C-00 for ipv6@ietf.org; Wed, 11 Feb 2004 17:00:54 -0500 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4C01E18DE for ; Wed, 11 Feb 2004 17:00:19 -0500 (EST) Date: Wed, 11 Feb 2004 17:00:19 -0500 From: Rob Austein To: ipv6@ietf.org Subject: Re: [node req] Issue37: EDNS0 support In-Reply-To: <4.3.2.7.2.20040211125234.0436fda8@mailhost.iprg.nokia.com> 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: <20040211220019.4C01E18DE@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.2 required=5.0 tests=AWL autolearn=no version=2.60 At Wed, 11 Feb 2004 12:57:24 -0800, Bob Hinden wrote: > > > > - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 > > > octets. > > > > > > .. I'm operationally concerned about the last SHOULD. As far as I > > > know, EDNS0 is not really implemented. It does not seem to include a > > > SHOULD to something that hasn't seen practical, wide-spread > > > deployment > > > already. I'd recommend removing this or rewording it to a MAY. > > Is there a technical problem with EDSNO (e.g., broken, doesn't scale, too > complex, etc.)? No. It's somewhat baroque due to the need for retrofitting it into an old protocol, but there's nothing complex about it. There simply hasn't been a pressing need to deploy it in stub resolvers that only deal with IPv4. > Or has it not been deployed because it hasn't been implemented. If > it's the latter than making it a SHOULD be implemented would appear > to be the right message. Server-side support for EDNS0 has been deployed for a long time, as has client-side support in recursive name servers. Certainly there are server implementations that don't support ENDS0, but then there are server implementations that don't support AAAA RRs or IPv6 either. Client side support for EDNS0 in stub resolvers has not been critical with IPv4 because the addresses are smaller than in IPv6. We have known for a long time that adding AAAA RRs to the mix is likely to push us over the packet size limits. See RFC 3226: it needs updating (A6 RRs rather than AAAA RRs) but it is a proposed standard. So, in summary, I do not agree with Pekka about changing this SHOULD to a MAY. Changing it to a MUST, perhaps. :) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 17:13: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 RAA02595 for ; Wed, 11 Feb 2004 17:13: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 1Ar2bf-00061w-Er for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 17:13:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BMDJGg023174 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 17:13:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2bf-00061h-9a for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 17:13: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 RAA02564 for ; Wed, 11 Feb 2004 17:13:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2bd-0001Yr-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:13:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2a2-0001EP-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:11:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2Yl-0000xS-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:10:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2Os-0004Ca-0Y; Wed, 11 Feb 2004 17:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2OV-000478-0C for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 16:59:43 -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 QAA00920 for ; Wed, 11 Feb 2004 16:59:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2OS-00075r-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:59:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2NZ-0006zm-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:58:46 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2Mp-0006mU-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:57:59 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1BLv2f01882; Wed, 11 Feb 2004 22:57:02 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1BLv3Sj076342; Wed, 11 Feb 2004 22:57:03 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402112157.i1BLv3Sj076342@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: srihari varada cc: ipv6@ietf.org, Brian Haberman , Bob Hinden , Alex Conta , ietf_ppp@merit.edu Subject: Re: updates to IPv6 over PPP spec. In-reply-to: Your message of Wed, 11 Feb 2004 16:17:27 EST. <402A9BE7.4040406@txc.com> Date: Wed, 11 Feb 2004 22:57:03 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 In your previous mail you wrote: (1) The Duplicate address detection shouldn’t be recommended to be disabled, if the IPv6CP negotiates interface identifier with the peer. => as I have no concern about (1) I disagree with the rationale. *Rationale:* (a) In the mobile (3GPP) networks the host isn't stationary. As such, the interface identifier uniqueness may not be ensured at different space points in the provider network (for instance, in the case of randomly generated Interface Identifier). This would then warrant the mobile host to trigger duplicate address detection as and when it changes it's position. => this makes sense if and only if you suggest that a 3GPP terminal can change its PPP peer without shutting down PPP??? (b) RFC 2462, section 5.4 states that if there is a group of addresses that are generated from a given interface identifier, the Link-Local address MUST at least be tested for uniqueness. It is likely that an interface would have multiple addresses (Link Local, site-local and global scope addresses, for instance). This would then necessitates the Link-Local address to be tested for uniqueness. Thus, the text needs to be changed for consistency reasons." => we agreed in the WG that DAD is really per address and not per interface ID so MUST be done for every addresses (perhaps at the exception of the link-local using the negociated IID). 4. RA (Route Advertisement) should be mentioned somewhere in the Document for global unicast address configuration and other configuration parameters. In IPCP, the IP address is part of the IPCP. But in IPv6CP, only the interface ID is negotiated and link local is auto-configured. For a new comer, it took us a while to figure out that RA is used to configure the rest of stuff. => I disagree, this implies the PPP link is between an host and a router when two other cases are possible. 5. Default ordering of IPv6CP and IPCP negotiation in a dual stack mode should be explained -- RFC 1661 says that there could be one or more NCPs in one PPP link. During inter-operability testing, we found some vendors started NCP with IPv6CP and others with IPCP. It will evetually work. But some extra messages will be dropped because of miss match. It will be good to document the relationship between IPv6CP and IPCP in a dual stack mode. Of course, the order should be configurable by the user and one of them may be disabled in a single stack mode (either IPv4 only or IPv6 only). => this is not in the scope of the WG: if some implementations don't support parallel NCPs either they need to be fixed or the PPP specifications should forbid this. 6. The Interface Identifier section should mention an exception (due to the need for privary addresses) to the suggestion of consistent reproduction of the interface identifier -- RFC 2472 states that the interface identifier is suggested to be consistently reproducable across initializations of the IPv6CP finite state machine (see section 4.1). The text should be elaborated to include an exception as identified by the Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (RFC 3041). => I am not convinced this is really useful because the IID can be used only for the link-local address which is not supposed to leak outside the link... Regards Francis.Dupont@enst-bretagne.fr PS: BTW I haven't seen a call for the agenda? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 17:15: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 RAA02952 for ; Wed, 11 Feb 2004 17:15:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2dX-0006N9-4e for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 17:15:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BMFFpI024489 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 17:15:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2dW-0006Mu-WF for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 17:15:15 -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 RAA02847 for ; Wed, 11 Feb 2004 17:15:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2dU-0001xd-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:15:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2c2-0001eR-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:13:43 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar2aB-0000kY-01 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:11:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar2OF-0006zp-HL for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 16:59:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2Np-0003mv-QF; Wed, 11 Feb 2004 16:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2Nd-0003lm-F7 for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 16:58:49 -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 QAA00877 for ; Wed, 11 Feb 2004 16:58:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2Nb-0006zz-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:58:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2Mq-0006tl-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:58:01 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2M8-0006jJ-00 for ipv6@ietf.org; Wed, 11 Feb 2004 16:57:17 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1BLuZ220280; Wed, 11 Feb 2004 23:56:35 +0200 Date: Wed, 11 Feb 2004 23:56:35 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Bob Hinden , , Subject: Re: [node req] Issue37: EDNS0 support In-Reply-To: <200402112143.i1BLhdSj076218@givry.rennes.enst-bretagne.fr> 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 Wed, 11 Feb 2004, Francis Dupont wrote: > > > - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 > > > octets. > > > > > > .. I'm operationally concerned about the last SHOULD. As far as I > > > know, EDNS0 is not really implemented. It does not seem to include a > > > SHOULD to something that hasn't seen practical, wide-spread > > > deployment > > > already. I'd recommend removing this or rewording it to a MAY. > > > > > Is there a technical problem with EDSNO (e.g., broken, doesn't scale, too > complex, etc.)? Or has it not been deployed because it hasn't been > implemented. If it's the latter than making it a SHOULD be implemented > would appear to be the right message. > > => I simply disagree with the "as far as I know, EDNS0 is not really > implemented". IMHO this is not true and not only in DNSSEC testbeds > where EDNS0 is really needed. I'm not really sure what you're saying -- do you mean "EDNS0 is really needed in DNSSEC testbeds" and a) "thus EDNS0 is needed" , b) "and EDNS0 has been implemented otherwise as well", or c) something else? AFAIK, most BSDs implment EDNS0 but none of them enable it by default. Linux glibc doesn't implement it. Microsoft does not implement it (not sure). BIND does implement it, but the *point* here is stub resolver support ("node requirements"), not the support in DNS servers. AFAIK, we don't have real deployment experience of this. I don't think we know the full consequences resulting from EDNS0 use because it hasn't been widely used yet. Thus, I'm a bit hesitant to put wording as strong as SHOULD here. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 17:20: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 RAA03575 for ; Wed, 11 Feb 2004 17:20:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2i2-0006sw-Ih for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 17:19:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BMJs02026460 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 17:19:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2i2-0006sh-Dl for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 17:19:54 -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 RAA03520 for ; Wed, 11 Feb 2004 17:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2i0-0002ls-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:19:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2hC-0002f1-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:19:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2gW-0002Wo-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:18:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2gD-0006Wp-K2; Wed, 11 Feb 2004 17:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2g8-0006WY-Hy for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 17:17:56 -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 RAA03288 for ; Wed, 11 Feb 2004 17:17:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2g6-0002Uf-00 for ipv6@ietf.org; Wed, 11 Feb 2004 17:17:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2fG-0002Lk-00 for ipv6@ietf.org; Wed, 11 Feb 2004 17:17:03 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2eS-00024w-00 for ipv6@ietf.org; Wed, 11 Feb 2004 17:16:12 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1BMFaf03374; Wed, 11 Feb 2004 23:15:36 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1BMFbSj076526; Wed, 11 Feb 2004 23:15:37 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402112215.i1BMFbSj076526@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Bob Hinden , ipv6@ietf.org, john.loughney@nokia.com Subject: Re: [node req] Issue37: EDNS0 support In-reply-to: Your message of Wed, 11 Feb 2004 23:56:35 +0200. Date: Wed, 11 Feb 2004 23:15:37 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 In your previous mail you wrote: > => I simply disagree with the "as far as I know, EDNS0 is not really > implemented". IMHO this is not true and not only in DNSSEC testbeds > where EDNS0 is really needed. I'm not really sure what you're saying -- do you mean "EDNS0 is really needed in DNSSEC testbeds" and a) "thus EDNS0 is needed" , b) "and EDNS0 has been implemented otherwise as well", or c) something else? => b) AFAIK, most BSDs implment EDNS0 but none of them enable it by default. => I believe the problem is that some buggy DNS codes don't like at all EDNS0 queries. Linux glibc doesn't implement it. => please fix this! Microsoft does not implement it (not sure). => same (if true). BIND does implement it, but the *point* here is stub resolver support ("node requirements"), not the support in DNS servers. => but the deployment issue is more in servers. AFAIK, we don't have real deployment experience of this. I don't think we know the full consequences resulting from EDNS0 use because it hasn't been widely used yet. Thus, I'm a bit hesitant to put wording as strong as SHOULD here. => please ask the dnsop WG if you have a doubt. And look at RFC 3226 even it should be updated. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 17:34: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 RAA04505 for ; Wed, 11 Feb 2004 17:34:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2vZ-0008Pt-Rx for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 17:33:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BMXrrG032347 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 17:33:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2vZ-0008Pe-NR for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 17:33:53 -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 RAA04472 for ; Wed, 11 Feb 2004 17:33:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2vX-0004as-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:33:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2ud-0004TX-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:32:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2u3-0004MJ-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 17:32:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2tn-0007vZ-48; Wed, 11 Feb 2004 17:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2tb-0007uq-4L for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 17:31: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 RAA04360 for ; Wed, 11 Feb 2004 17:31:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2tY-0004L0-00 for ipv6@ietf.org; Wed, 11 Feb 2004 17:31:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2sg-0004Ek-00 for ipv6@ietf.org; Wed, 11 Feb 2004 17:30:54 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar2sF-00047P-00 for ipv6@ietf.org; Wed, 11 Feb 2004 17:30:27 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGWTVB>; Wed, 11 Feb 2004 17:29:54 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04212E@ftmail.lab.flarion.com> From: Soliman Hesham To: "'James Kempf'" , ipv6@ietf.org Subject: RE: [rfc2461bis issue 252] Security considerations issues Date: Wed, 11 Feb 2004 17:29:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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 Thanks James, a couple of answers below. > > 1. Adding a new section (3.2) before the message formats > > to briefly explain that security is outside the scope of > > this doc and refer to SEND work. It also explains when IPsec > > can be used. > > > > I think it might be wise to discuss whether the document > should continue to > recommend IPsec with the Security ADs and get some input > from the community > and the security directorate. > draft-arkko-manual-icmpv6-sas-01.txt outlines > some scalability problems with IPsec, even if manual keying > is used, as you > mention below. There is a potential deployment issue as to > what constitutes > a "small" network and at what point the network hits the > scalability barrier > when the network provider will have to completely > reconfigure their network > and turn SEND on. I'm not sure whether it makes sense to > recommend manual > keying for small networks when SEND would work as well and > wouldn't require > a flag day reconfigure if the network grew too large. Also, > manual keying > doesn't make sense for zeroconf networks, because it isn't > zeroconf. The ND > part of SEND could be used for disconnected zeroconf > networks, and the > router part could too if the host came preconfigured with a > collection of > cert trust anchors. => I just want to clarify one thing: it is not my intention to recommend IPsec in any way. I just wanted to mention when it can be used and its limitation. I can add something to say that SEND is the preferred option in general. If the WG wants to remove any reference to IPsec I'm happy to do that too. > > "Neighbor Discovery messages are needed for various > functions. Several > > functions are designed to allow hosts to ascertain the > ownership of an > > address or the mapping between link layer and IP layer > addresses. Having > > Neighbor Discovery functions on the ICMP layer allows for > the use of IP > > layer security mechanisms, which are available independently of the > > availability of security on the link layer. > > > > I would say "requires the use of IP layer", since if the > user chooses to use > security in ND, they must use IP layer security. => ok, I actually changed this as per Jari's comment. > If there is support for completely deprecating IPsec for ND, > I'd suggest > adding that instead. => I'll go with whatever the WG wants of course. So far only you and Jari have commented. > > I assume you will also put a reference to draft-send-ndopts > (to be changed > into the RFC when it passes IESG review) in the normative references > section? => Sure. Hesham > > jak > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 18:15:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08473 for ; Wed, 11 Feb 2004 18:15:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3ZC-0007iI-S6 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 18:14:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BNEoBV029641 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 18:14:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3ZC-0007hz-LM for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 18:14:50 -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 SAA08428 for ; Wed, 11 Feb 2004 18:14:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3Z9-0002aF-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 18:14:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3YD-0002UN-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 18:13:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3Xl-0002OO-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 18:13:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3XS-0006zu-2F; Wed, 11 Feb 2004 18:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3XG-0006xa-BF for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 18:12:50 -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 SAA08136 for ; Wed, 11 Feb 2004 18:12:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3XD-0002LR-00 for ipv6@ietf.org; Wed, 11 Feb 2004 18:12:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3WC-00027i-00 for ipv6@ietf.org; Wed, 11 Feb 2004 18:11:45 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Ar3V3-0001rE-00 for ipv6@ietf.org; Wed, 11 Feb 2004 18:10:33 -0500 Message-ID: <03d501c3f0f4$5089f210$936015ac@dclkempt40> From: "James Kempf" To: "Soliman Hesham" , Cc: "Russ Housley" , "Steve Bellovin" , "Thomas Narten" References: <9E3BA3946476AD4EB94672712B12A85F04212E@ftmail.lab.flarion.com> Subject: Re: [rfc2461bis issue 252] Security considerations issues Date: Wed, 11 Feb 2004 15:11:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> I think it might be wise to discuss whether the document > > should continue to >> recommend IPsec with the Security ADs and get some input >> from the community >> and the security directorate. >> draft-arkko-manual-icmpv6-sas-01.txt outlines >> some scalability problems with IPsec, even if manual keying >> is used, as you >> mention below. There is a potential deployment issue as to >> what constitutes >> a "small" network and at what point the network hits the >> scalability barrier >> when the network provider will have to completely >> reconfigure their network >> and turn SEND on. I'm not sure whether it makes sense to >> recommend manual >> keying for small networks when SEND would work as well and >> wouldn't require >> a flag day reconfigure if the network grew too large. Also, >> manual keying >> doesn't make sense for zeroconf networks, because it isn't >> zeroconf. The ND >> part of SEND could be used for disconnected zeroconf >> networks, and the >> router part could too if the host came preconfigured with a >> collection of >> cert trust anchors. > > > => I just want to clarify one thing: it is not my intention > to recommend IPsec in any way. I just wanted to mention > when it can be used and its limitation. I can add something > to say that SEND is the preferred option in general. If the WG > wants to remove any reference to IPsec I'm happy to do that > too. > Sure, I understand. My preference would be to say that use of IPsec is deprecated, since, as outlined above, there may be significant deployment consequences if it is used, and having one way to do something is generally simpler than having many. What do other WG members think? Also, what do the Security ADs (cc'ed) think? jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 18:21: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 SAA09077 for ; Wed, 11 Feb 2004 18:21:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3ew-00013k-7y for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 18:20:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BNKkKc004060 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 18:20:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3et-00012n-K2 for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 18:20:43 -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 SAA09043 for ; Wed, 11 Feb 2004 18:20:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3eq-0003El-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 18:20:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3dt-00037o-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 18:19:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3cu-00030e-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 18:18:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3cI-0000BI-J3; Wed, 11 Feb 2004 18:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3by-0008U0-Ao for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 18:17:42 -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 SAA08746 for ; Wed, 11 Feb 2004 18:17:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3bv-0002t3-00 for ipv6@ietf.org; Wed, 11 Feb 2004 18:17:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3ay-0002mZ-00 for ipv6@ietf.org; Wed, 11 Feb 2004 18:16:41 -0500 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar3a4-0002by-00 for ipv6@ietf.org; Wed, 11 Feb 2004 18:15:44 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by mail-white.research.att.com (Postfix) with ESMTP id AABB266410B; Wed, 11 Feb 2004 18:14:04 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-green.research.att.com (Postfix) with ESMTP id 85695F3B5D; Wed, 11 Feb 2004 18:11:47 -0500 (EST) Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i1BNFEZ02087; Wed, 11 Feb 2004 18:15:14 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 129827B43; Wed, 11 Feb 2004 18:15:14 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "James Kempf" Cc: "Soliman Hesham" , ipv6@ietf.org, "Russ Housley" , "Thomas Narten" Subject: Re: [rfc2461bis issue 252] Security considerations issues In-Reply-To: Your message of "Wed, 11 Feb 2004 15:11:00 PST." <03d501c3f0f4$5089f210$936015ac@dclkempt40> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Feb 2004 18:15:13 -0500 Message-Id: <20040211231514.129827B43@berkshire.research.att.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=AWL autolearn=no version=2.60 In message <03d501c3f0f4$5089f210$936015ac@dclkempt40>, "James Kempf" writes: >>> I think it might be wise to discuss whether the document >> > should continue to > >> recommend IPsec with the Security ADs and get some input > >> from the community > >> and the security directorate. > >> draft-arkko-manual-icmpv6-sas-01.txt outlines > >> some scalability problems with IPsec, even if manual keying > >> is used, as you > >> mention below. There is a potential deployment issue as to > >> what constitutes > >> a "small" network and at what point the network hits the > >> scalability barrier > >> when the network provider will have to completely > >> reconfigure their network > >> and turn SEND on. I'm not sure whether it makes sense to > >> recommend manual > >> keying for small networks when SEND would work as well and > >> wouldn't require > >> a flag day reconfigure if the network grew too large. Also, > >> manual keying > >> doesn't make sense for zeroconf networks, because it isn't > >> zeroconf. The ND > >> part of SEND could be used for disconnected zeroconf > >> networks, and the > >> router part could too if the host came preconfigured with a > >> collection of > >> cert trust anchors. >> >> >> => I just want to clarify one thing: it is not my intention >> to recommend IPsec in any way. I just wanted to mention >> when it can be used and its limitation. I can add something >> to say that SEND is the preferred option in general. If the WG >> wants to remove any reference to IPsec I'm happy to do that >> too. >> > >Sure, I understand. > >My preference would be to say that use of IPsec is deprecated, since, as >outlined above, there may be significant deployment consequences if it is >used, and having one way to do something is generally simpler than having >many. > >What do other WG members think? > >Also, what do the Security ADs (cc'ed) think? > One of the major conclusions of SEND was that IPsec for neighbor discovery didn't work very well. Given that, and given that we have a replacement coming, I have no objection. However... 2461 is at Draft. I'll have to figure out the procedural consequences of such a change at this point. Of course, I also have to figure out the consequences of not making the change.... --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 18:34: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 SAA10492 for ; Wed, 11 Feb 2004 18:34:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3rl-0002Kk-QJ for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 18:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BNY15g008969 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 18:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3rl-0002Ka-Lq for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 18:34: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 SAA10480 for ; Wed, 11 Feb 2004 18:33:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3ri-0005fm-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 18:33:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3qo-0005Wd-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 18:33:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3q4-0005NB-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 18:32:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3pq-0001xO-Iv; Wed, 11 Feb 2004 18:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3pi-0001wd-RT for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 18:31:55 -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 SAA10261 for ; Wed, 11 Feb 2004 18:31:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3pf-0005Jk-00 for ipv6@ietf.org; Wed, 11 Feb 2004 18:31:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3od-00055J-00 for ipv6@ietf.org; Wed, 11 Feb 2004 18:30:48 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3nP-0004fd-00 for ipv6@ietf.org; Wed, 11 Feb 2004 18:29:31 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1BNSri32445; Wed, 11 Feb 2004 15:28:53 -0800 X-mProtect: <200402112328> 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 smtpdX80yoX; Wed, 11 Feb 2004 15:28:50 PST Message-Id: <4.3.2.7.2.20040211152114.039aca30@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Feb 2004 15:25:26 -0800 To: Rob Austein From: Bob Hinden Subject: Re: [node req] Issue37: EDNS0 support Cc: ipv6@ietf.org In-Reply-To: <20040211220019.4C01E18DE@thrintun.hactrn.net> References: <4.3.2.7.2.20040211125234.0436fda8@mailhost.iprg.nokia.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 Rob, >Client side support for EDNS0 in stub resolvers has not been critical >with IPv4 because the addresses are smaller than in IPv6. We have >known for a long time that adding AAAA RRs to the mix is likely to >push us over the packet size limits. See RFC 3226: it needs updating >(A6 RRs rather than AAAA RRs) but it is a proposed standard. > >So, in summary, I do not agree with Pekka about changing this SHOULD >to a MAY. Changing it to a MUST, perhaps. :) So we should be encouraging people to include it in their IPv6 implementations. Hence a SHOULD for EDNSO in IPv6 node requirements as currently written. Or as you suggest a SHOULD++. :-) Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 19:12: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 TAA12700 for ; Wed, 11 Feb 2004 19:12:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4Sx-0006KH-3t for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 19:12:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C0CRvB024311 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 19:12:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4Sw-0006K2-Uf for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 19:12: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 TAA12632 for ; Wed, 11 Feb 2004 19:12:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4Sv-0002JE-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 19:12:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar4Rm-00028N-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 19:11:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4Ql-0001yk-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 19:10:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4Qc-0005wv-Vn; Wed, 11 Feb 2004 19:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4QO-0005vm-Os for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 19:09:48 -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 TAA12466 for ; Wed, 11 Feb 2004 19:09:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4QL-0001wS-00 for ipv6@ietf.org; Wed, 11 Feb 2004 19:09:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar4PO-0001qa-00 for ipv6@ietf.org; Wed, 11 Feb 2004 19:08:47 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4Op-0001jO-00 for ipv6@ietf.org; Wed, 11 Feb 2004 19:08:11 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 12 Feb 2004 01:08:18 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1C07GL1024076; Thu, 12 Feb 2004 01:07:16 +0100 (MET) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA12582; Thu, 12 Feb 2004 00:07:40 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?euc-jp?b?v8DMwMOj?= =?euc-jp?b?usg=?= Cc: ipv6@ietf.org Subject: rfc2462bis -- loopback suppression From: Ole Troan Date: Thu, 12 Feb 2004 00:07:39 +0000 In-Reply-To: (JINMEI Tatuya's message of "Tue, 10 Feb 2004 21:38:51 +0900") Message-ID: <7t5d68lkvn8.fsf@mrwint.cisco.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2.95 (usg-unix-v) References: 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 > I've submitted a new revision of the rfc2462bis draft: > draft-ietf-ipv6-rfc2462bis-00.txt on the issue of DAD and loopback suppression outlined in appendix A. I've seen a couple of cases in the past where DAD packets could be looped back by the network. this could happen if there is a temporary loop in a bridged network. I've also seen it where parallel links are used between two boxes, e.g Etherchannel. this is something which is very difficult to solve with the current spec. the only alternative is to filter out DAD packets with the same link-layer address as the receiving interface. stopping duplicate MAC address checking from working. one solution could be to add a optional identifier option to DAD NS packets, so that the sender can recognise the case when its own packets are looped around. too big a change for 2462bis? /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 11 19:19: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 TAA13313 for ; Wed, 11 Feb 2004 19:19:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4ZU-0007Ez-QF for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 19:19:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C0JCkI027827 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 19:19:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4ZU-0007Ek-Kp for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 19:19:12 -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 TAA13291 for ; Wed, 11 Feb 2004 19:19:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4ZT-0003NX-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 19:19:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar4Yd-0003EM-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 19:18:19 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar4Xm-000340-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 19:17:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar4Xm-0000p0-RT for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 19:17:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4XN-0006mW-Sh; Wed, 11 Feb 2004 19:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4WS-0006Vq-14 for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 19:16: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 TAA13012 for ; Wed, 11 Feb 2004 19:16:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4WQ-0002sV-00 for ipv6@ietf.org; Wed, 11 Feb 2004 19:16:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar4VO-0002mC-00 for ipv6@ietf.org; Wed, 11 Feb 2004 19:14:59 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4Uw-0002fB-00 for ipv6@ietf.org; Wed, 11 Feb 2004 19:14:31 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1C0EJvf014644; Wed, 11 Feb 2004 16:14:20 -0800 (PST) Received: from naexfe02.na.qualcomm.com (naexfe02.qualcomm.com [129.46.51.214]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1C0EGVJ002767; Wed, 11 Feb 2004 16:14:16 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by naexfe02.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Feb 2004 16:14:16 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: updates to IPv6 over PPP spec. Date: Wed, 11 Feb 2004 16:14:15 -0800 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327D2E@NAEX01.na.qualcomm.com> Thread-Topic: updates to IPv6 over PPP spec. Thread-Index: AcPw6qVJcvPN3XXhRROYIhTJgeuCvgAEd8mg From: "Barany, Pete" To: "Karim El-Malki \(HF/EAB\)" , "srihari varada" , Cc: "Brian Haberman" , "Bob Hinden" , "Alex Conta" , X-OriginalArrivalTime: 12 Feb 2004 00:14:16.0524 (UTC) FILETIME=[26D2B0C0:01C3F0FD] 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 The rationale also fails to account for 3GPP2 networks (cdma2000). Here, PPP (IPV6CP) is used to obtain an IPv6 address for the mobile (or the MIPv6 CoA for the mobile). UMTS uses a PDP context instead. Since 3GPP2 has mandated a restriction that the /64 prefix advertised to a mobile by a PDSN (similar to 'GGSN' if you are a UMTS-only person) be unique/exclusive to that PPP link, then there is no need for the suggested update #1 below. In fact, quite the contrary. - Pete -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Karim El-Malki (HF/EAB) Sent: Wednesday, February 11, 2004 1:42 PM To: 'srihari varada'; ipv6@ietf.org Cc: Brian Haberman; Bob Hinden; Alex Conta; ietf_ppp@merit.edu Subject: RE: updates to IPv6 over PPP spec. > (1) The Duplicate address detection shouldn't be recommended to be=20 > disabled, if the IPv6CP negotiates interface identifier with=20 > the peer. > * > * >=20 > *Rationale:* >=20 > (a) In the mobile (3GPP) networks the host isn't stationary. As > such, the interface identifier uniqueness may not be ensured at > different space points in the provider network (for=20 > instance, in the > case of randomly generated Interface Identifier). This would then > warrant the mobile host to trigger duplicate address detection as > and when it changes it's position. (a) doesn't seem correct to me. In terms of 3GPP nets the host is stationary with respect to its default router. Also as recommended in RFC 3314 an entire /64 is assigned to a mobile's connection so DAD is not useful. Looks to me like the 3GPP case would actually be in favour of disabling DAD. /Karim This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- 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 Feb 11 23:04: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 XAA22714 for ; Wed, 11 Feb 2004 23:04: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 1Ar85K-0007UB-Ut for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 23:04:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C44ICT028765 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 23:04:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar85J-0007Tr-Vk for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 23:04:18 -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 XAA22702 for ; Wed, 11 Feb 2004 23:04:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar85F-0004Ms-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 23:04:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar841-0004HB-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 23:02:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar83U-0004Bl-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 23:02:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar837-0006zh-Rs; Wed, 11 Feb 2004 23:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar830-0006z2-L2 for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 23:01:54 -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 XAA22608 for ; Wed, 11 Feb 2004 23:01:50 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar82w-00049b-00 for ipv6@ietf.org; Wed, 11 Feb 2004 23:01:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar81z-00042a-00 for ipv6@ietf.org; Wed, 11 Feb 2004 23:00:52 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ar813-0003w3-00 for ipv6@ietf.org; Wed, 11 Feb 2004 22:59:53 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1C3xrq18514 for ; Thu, 12 Feb 2004 05:59:53 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 12 Feb 2004 05:59:53 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 11 Feb 2004 21:59:51 -0600 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: ICMPv3: Security Consideration Section. Date: Wed, 11 Feb 2004 21:59:51 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE94@daebe009.americas.nokia.com> Thread-Topic: ICMPv3: Security Consideration Section. Thread-Index: AcPxHKoTYO3zEIfrRB6TeAGTZVaGhg== To: X-OriginalArrivalTime: 12 Feb 2004 03:59:51.0936 (UTC) FILETIME=[AA8EA800:01C3F11C] 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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All, I am trying to address Thomas Narten's comment on the security=20 consideration section of draft-ietf-ipngwg-icmp-v3-02.txt. (See comments at the end of this mail) Here is the proposed updated text. Please review it. I am trying to submit the updated draft before Monday. Regards Mukesh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposed = updated text =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5. Security Considerations 5.1 Authentication and Confidentiality of ICMP messages ICMP protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH] or IP Encapsulating Security Payload Header [IPv6-ESP]. Confidentiality for the ICMP protocol packet exchanges can be achieved using IP Encapsulating Security Payload Header [IPv6-ESP]. A node SHOULD include an Authentication Header or Encapsulating Security Payload Header when sending ICMP messages if a security association for use with the IP Authentication Header or IP Encapsulating Security Payload Header exists for the destination address. The security associations may have been created through manual configuration or through the operation of some key management protocol. Received ICMP packets that have Authentication Header or Encapsulating Security Payload Header must be processed as specified in [IPv6-AUTH] and [IPv6-ESP]. The ICMP packets that fail the security processing MUST be ignored and discarded. It SHOULD be possible for the system administrator to configure a node to ignore any ICMP messages that are not authenticated using either the Authentication Header or Encapsulating Security Payload. Such a switch SHOULD default to allowing unauthenticated messages. 5.2 ICMP Attacks ICMP messages may be subject to various attacks. A complete discussion can be found in the IP Security Architecture [IPv6-SA]. A brief discussion of such attacks and their prevention is as follows: 1. ICMP messages may be subject to actions intended to cause the receiver to believe the message came from a different source than the message originator. In some cases, the protection against this attack can be achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH] to the ICMP message. 2. ICMP messages may be subject to actions intended to cause the message or the reply to it go to a destination different than the message originator's intention. In some cases, the protection against this attack can be achieved using the Authentication Header or the Encapsulating Security Payload Header as the source and the destination addresses are protected against change when the Authentication Header or the Encapsulating Security Payload Header is used. 3. ICMP messages may be subject to changes in the message fields, or payload. The authentication [IPv6-AUTH] or encryption [IPv6-ESP] of the ICMP message is a protection against such actions. 4. ICMP messages may be used as attempts to perform denial of service attacks by sending back to back erroneous IP packets. An implementation that correctly followed section 2.4, paragraph (f) of this specifications, would be protected by the ICMP error rate limiting mechanism. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thomas's = comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D security considerations could perhaps use some updating. It seems = largely unchanged relative to RFC 2463. Has nothing really changed in our thinking here since 2463 came out?=20 It doesn't seem to note that ESP can do authentication only now. Should ESP (w/o encryption) also be used if an SA exists? 1. ICMP messages may be subject to actions intended to cause the receiver to believe the message came from a different source than the message originator. The protection against this attack can be achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH] to the ICMP message. add "in some cases"? There is an authorization questioned buried here. How does one know that a particular SA is authorized to speak on behalf of a particular IP address (or actually came from the message originator)? Note, this issue is one of the reasons why IPsec doesn't automatically solve the problem of authenticating MIPv6 BUs. 2. ICMP messages may be subject to actions intended to cause the message or the reply to it go to a destination different than the message originator's intention. The ICMP checksum calculation provides a protection mechanism against changes by a malicious interceptor in the destination and source address of the IP packet carrying that message, provided the ICMP checksum field is protected against change by authentication [IPv6-AUTH] or encryption [IPv6-ESP] of the ICMP message. seems like if you have AH/ESP, that check alone provides you the additional protection. That it also covers the ICMP checksum is not really relevant... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Feb 12 00:42: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 AAA25793 for ; Thu, 12 Feb 2004 00:42:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9c5-0006DM-TK for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C5gDSc023882 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9c5-0006D7-OR for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 00:42:13 -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 AAA25693 for ; Thu, 12 Feb 2004 00:42:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9c3-0005rp-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:42:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9bD-0005hL-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:41:19 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar9Zz-0005YX-05 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:40:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar9RX-0005ou-05 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:31:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9RF-00056K-1d; Thu, 12 Feb 2004 00:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9R8-00055W-F5 for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 00:30:54 -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 AAA25319 for ; Thu, 12 Feb 2004 00:30:51 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9R5-0004ly-00 for ipv6@ietf.org; Thu, 12 Feb 2004 00:30:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9Q7-0004gm-00 for ipv6@ietf.org; Thu, 12 Feb 2004 00:29:52 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9PA-0004bq-00 for ipv6@ietf.org; Thu, 12 Feb 2004 00:28:52 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1C5Sqv06421 for ; Thu, 12 Feb 2004 07:28:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Feb 2004 07:28:50 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 07:28:51 +0200 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: [node req] Issue37: EDNS0 support Date: Thu, 12 Feb 2004 07:28:51 +0200 Message-ID: Thread-Topic: [node req] Issue37: EDNS0 support Thread-Index: AcPxKMiIu3r50PdFQ0S2zeXVC76wrQAACNWw To: , Cc: X-OriginalArrivalTime: 12 Feb 2004 05:28:51.0622 (UTC) FILETIME=[19421460:01C3F129] 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, I'm comfortable with the SHOULD, following the many comments sent already. I haven't seen any information on how including SHOULD would break anything. John > >>>>> On Wed, 11 Feb 2004 23:56:35 +0200 (EET), > >>>>> Pekka Savola said: > > > AFAIK, we don't have real deployment experience of this. I don't > > think we know the full consequences resulting from EDNS0 use because > > it hasn't been widely used yet. Thus, I'm a bit hesitant to put > > wording as strong as SHOULD here. > > If this is your main reason, I disagree. > > First, as Rob pointed out, we have enough experience about the client > side of EDNS0 in DNS recursive servers, which I believe can be applied > to the deployment at stub resolvers. > > Secondly, the node requirement document contains other SHOULDs of > which we have little real deployment experience: > > Nodes that need to join multicast groups SHOULD implement MLDv2 > [MLDv2]. > (Section 4.6) > > Hosts SHOULD support route optimization requirements for > correspondent nodes described in Section 8.2 of [MIPv6]. > (Section 7) > > With your logic, we'd also have to change these SHOULDs to MAYs > (perhaps you've already insisted this?). IMO, the deployment status > and experience about EDNS0 (the client side or even at stub resolvers) > is much more mature than that for these SHOULDs. > > I personally do not think supporting EDNS0 at stub resolver is crucial > even with AAAA RRs (at least *without* DNSSEC RRs), BTW, because such > resolvers usually only need short sizes of packets; short enough to > meet the 512-byte requirement. In this sense, I would not oppose to > the SHOULD, but I'm not insisting a SHOULD. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 12 00:42: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 AAA25810 for ; Thu, 12 Feb 2004 00:42: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 1Ar9cC-0006EK-9n for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C5gKUK023942 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9cC-0006E5-5M for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 00:42:20 -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 AAA25711 for ; Thu, 12 Feb 2004 00:42:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9c9-0005sm-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:42:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9bI-0005iP-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:41:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar9a0-0005YX-05 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:40:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar9LF-0005hZ-1a for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:24:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9KW-0003JL-Hi; Thu, 12 Feb 2004 00:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar8Hf-0008Nw-Vz for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 23:17: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 XAA23133 for ; Wed, 11 Feb 2004 23:17:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar8He-0005ey-00 for ipv6@ietf.org; Wed, 11 Feb 2004 23:17:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar8Gc-0005Z3-00 for ipv6@ietf.org; Wed, 11 Feb 2004 23:15:58 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar8Fy-0005Nt-00 for ipv6@ietf.org; Wed, 11 Feb 2004 23:15:18 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1C4EeY27327; Thu, 12 Feb 2004 06:14:40 +0200 Date: Thu, 12 Feb 2004 06:14:40 +0200 (EET) From: Pekka Savola To: "Barany, Pete" cc: "Karim El-Malki (HF/EAB)" , Subject: RE: updates to IPv6 over PPP spec. In-Reply-To: <17D8F6DF3ED94D40BD607380866D9B7F327D2E@NAEX01.na.qualcomm.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 Wed, 11 Feb 2004, Barany, Pete wrote: > The rationale also fails to account for 3GPP2 networks (cdma2000). Here, > PPP (IPV6CP) is used to obtain an IPv6 address for the mobile (or the > MIPv6 CoA for the mobile). UMTS uses a PDP context instead. > > Since 3GPP2 has mandated a restriction that the /64 prefix advertised to > a mobile by a PDSN (similar to 'GGSN' if you are a UMTS-only person) be > unique/exclusive to that PPP link, then there is no need for the > suggested update #1 below. In fact, quite the contrary. Umm.. but doesn't the access router which terminates the PPP link also have an address from that /64 prefix (e.g., ::1) -- or does it have a link-local address only? In case such an assumption is made, it should be spelled out clearly enough. -- 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 Feb 12 00:42: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 AAA25893 for ; Thu, 12 Feb 2004 00:42:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9cN-0006GX-Of for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C5gVhi024079 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9cN-0006GI-KV for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 00:42:31 -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 AAA25757 for ; Thu, 12 Feb 2004 00:42:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9cL-0005uF-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:42:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9bU-0005kX-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:41:37 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar9a1-0005Yo-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:40:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar9LF-0005hY-NM for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:24:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9Kn-0003Vn-J6; Thu, 12 Feb 2004 00:24:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar95q-0002s8-FV for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 00:08:54 -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 AAA24543 for ; Thu, 12 Feb 2004 00:08:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar95o-0002dO-00 for ipv6@ietf.org; Thu, 12 Feb 2004 00:08:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar94s-0002Yz-00 for ipv6@ietf.org; Thu, 12 Feb 2004 00:07:55 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Ar94V-0002UH-00 for ipv6@ietf.org; Thu, 12 Feb 2004 00:07:31 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 04A7F15214; Thu, 12 Feb 2004 14:07:30 +0900 (JST) Date: Thu, 12 Feb 2004 14:07:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Subject: Re: [node req] Issue37: EDNS0 support In-Reply-To: References: <200402112143.i1BLhdSj076218@givry.rennes.enst-bretagne.fr> 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, 11 Feb 2004 23:56:35 +0200 (EET), >>>>> Pekka Savola said: > AFAIK, we don't have real deployment experience of this. I don't > think we know the full consequences resulting from EDNS0 use because > it hasn't been widely used yet. Thus, I'm a bit hesitant to put > wording as strong as SHOULD here. If this is your main reason, I disagree. First, as Rob pointed out, we have enough experience about the client side of EDNS0 in DNS recursive servers, which I believe can be applied to the deployment at stub resolvers. Secondly, the node requirement document contains other SHOULDs of which we have little real deployment experience: Nodes that need to join multicast groups SHOULD implement MLDv2 [MLDv2]. (Section 4.6) Hosts SHOULD support route optimization requirements for correspondent nodes described in Section 8.2 of [MIPv6]. (Section 7) With your logic, we'd also have to change these SHOULDs to MAYs (perhaps you've already insisted this?). IMO, the deployment status and experience about EDNS0 (the client side or even at stub resolvers) is much more mature than that for these SHOULDs. I personally do not think supporting EDNS0 at stub resolver is crucial even with AAAA RRs (at least *without* DNSSEC RRs), BTW, because such resolvers usually only need short sizes of packets; short enough to meet the 512-byte requirement. In this sense, I would not oppose to the SHOULD, but I'm not insisting a SHOULD. 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 Feb 12 00:45: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 AAA26003 for ; Thu, 12 Feb 2004 00:45:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9el-0006bn-Ox for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 00:44:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C5ix0G025397 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 00:44:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9el-0006bY-L3 for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 00:44:59 -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 AAA25978 for ; Thu, 12 Feb 2004 00:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9ej-0006Cf-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:44:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9dn-00066g-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:44:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar9d5-000613-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:43:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar9d6-00065b-Lu for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 00:43:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9ct-0006Ix-Kv; Thu, 12 Feb 2004 00:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9cn-0006Hi-5u for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 00:42: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 AAA25868 for ; Thu, 12 Feb 2004 00:42:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9ck-0005zZ-00 for ipv6@ietf.org; Thu, 12 Feb 2004 00:42:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9bs-0005qX-00 for ipv6@ietf.org; Thu, 12 Feb 2004 00:42:01 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9az-0005fA-00 for ipv6@ietf.org; Thu, 12 Feb 2004 00:41:05 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 07A5215214; Thu, 12 Feb 2004 14:41:05 +0900 (JST) Date: Thu, 12 Feb 2004 14:41:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: ipv6@ietf.org Subject: Re: rfc2462bis -- loopback suppression In-Reply-To: <7t5d68lkvn8.fsf@mrwint.cisco.com> References: <7t5d68lkvn8.fsf@mrwint.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, 12 Feb 2004 00:07:39 +0000, >>>>> Ole Troan said: > one solution could be to add a optional identifier option to DAD NS > packets, so that the sender can recognise the case when its own > packets are looped around. > too big a change for 2462bis? I think this is too big to merge into 2462bis (sorry), but I agree this is worth considering as an extension in a separate document (depending on how this is popular and severe). 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 Feb 12 01:24: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 BAA26952 for ; Thu, 12 Feb 2004 01:24:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAGd-0000Mt-U7 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 01:24:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C6O78s001409 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 01:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAGd-0000Mc-PB for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 01:24:07 -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 BAA26945 for ; Thu, 12 Feb 2004 01:24:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArAGa-00022v-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 01:24:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArAFf-0001wv-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 01:23:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArAF0-0001q4-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 01:22:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAEb-0008SB-WE; Thu, 12 Feb 2004 01:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArADm-0008OU-3T for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 01:21:10 -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 BAA26843 for ; Thu, 12 Feb 2004 01:21:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArADj-0001i0-00 for ipv6@ietf.org; Thu, 12 Feb 2004 01:21:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArACn-0001bU-00 for ipv6@ietf.org; Thu, 12 Feb 2004 01:20:11 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ArAC1-0001Uh-00 for ipv6@ietf.org; Thu, 12 Feb 2004 01:19:22 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 370046A908; Thu, 12 Feb 2004 08:19:22 +0200 (EET) Message-ID: <402B1A7F.9010206@kolumbus.fi> Date: Thu, 12 Feb 2004 08:17:35 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mukesh.Gupta@nokia.com Cc: ipv6@ietf.org Subject: Re: ICMPv3: Security Consideration Section. References: <8D260779A766FB4A9C1739A476F84FA42ABE94@daebe009.americas.nokia.com> In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABE94@daebe009.americas.nokia.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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I mostly agree with Thomas' comments. A couple of additional points inline: > ==================== Proposed updated text =============== > 5. Security Considerations > > 5.1 Authentication and Confidentiality of ICMP messages > > ICMP protocol packet exchanges can be authenticated using the IP > Authentication Header [IPv6-AUTH] or IP Encapsulating Security > Payload Header [IPv6-ESP]. Confidentiality for the ICMP protocol > packet exchanges can be achieved using IP Encapsulating Security > Payload Header [IPv6-ESP]. A node SHOULD include an Authentication > Header or Encapsulating Security Payload Header when sending ICMP > messages if a security association for use with the IP Authentication > Header or IP Encapsulating Security Payload Header exists for the > destination address. The security associations may have been created > through manual configuration or through the operation of some key > management protocol. The primary problem with this is that while you may know well your peer and even be able to set up a security association with him, it may not be easy to set up security associations with all the routers (and their operators) in between. Perhaps you should mention something about this. > Received ICMP packets that have Authentication Header or > Encapsulating Security Payload Header must be processed as specified > in [IPv6-AUTH] and [IPv6-ESP]. The ICMP packets that fail the > security processing MUST be ignored and discarded. > > It SHOULD be possible for the system administrator to configure a > node to ignore any ICMP messages that are not authenticated using > either the Authentication Header or Encapsulating Security Payload. > Such a switch SHOULD default to allowing unauthenticated messages. > > 5.2 ICMP Attacks > > ICMP messages may be subject to various attacks. A complete > discussion can be found in the IP Security Architecture [IPv6-SA]. A > brief discussion of such attacks and their prevention is as follows: > > 1. ICMP messages may be subject to actions intended to cause the > receiver to believe the message came from a different source than > the message originator. In some cases, the protection against this > attack can be achieved by applying the IPv6 Authentication > mechanism [IPv6-AUTH] to the ICMP message. > > 2. ICMP messages may be subject to actions intended to cause the > message or the reply to it go to a destination different than the > message originator's intention. In some cases, the protection > against this attack can be achieved using the Authentication > Header or the Encapsulating Security Payload Header as the source > and the destination addresses are protected against change when > the Authentication Header or the Encapsulating Security Payload > Header is used. Actually, the point about the checksum may have been relevant. I think the attack you are describing here is that someone in the middle change the destination address of an ICMP message, right? ESP does not protect the IP header, but the fact that the addresses from the header are included in the pseudo-header that is calculated into the checksum helps. The checksum is covered by ESP, so that can not be changed. Anyway, that protection may not be quite as strong as AH/ESP gives you otherwise. Presumably you would have to test for 2^15 different fake addresses before you found one that would give the same checksum value, no? > 3. ICMP messages may be subject to changes in the message fields, or > payload. The authentication [IPv6-AUTH] or encryption [IPv6-ESP] > of the ICMP message is a protection against such actions. > > 4. ICMP messages may be used as attempts to perform denial of service > attacks by sending back to back erroneous IP packets. An > implementation that correctly followed section 2.4, paragraph (f) > of this specifications, would be protected by the ICMP error rate > limiting mechanism. There may be some additional ICMP issues related to DoS that you should mention. There are two exceptions in the multicast rule e.2 in Section 2.4. In theory, you could cause a very large number of nodes to send you Packet Too Bigs or Parameter Problems. For instance, just send a multicast packet with an unknown option marked as mandatory. Fortunately, it turns out that its relatively hard to get the multicast routers to carry your fake multicast packet unless you are on the correct multicast path, i.e. very near the legitimate sender. But perhaps you should say something about this too. > ========================================================== > > =================== Thomas's comments ==================== > security considerations could perhaps use some updating. It seems largely > unchanged relative to RFC 2463. Has nothing really changed in our > thinking here since 2463 came out? > > It doesn't seem to note that ESP can do authentication only > now. Should ESP (w/o encryption) also be used if an SA exists? > > 1. ICMP messages may be subject to actions intended to cause the > receiver to believe the message came from a different source than > the message originator. The protection against this attack can be > achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH] > to the ICMP message. > > add "in some cases"? There is an authorization questioned buried > here. How does one know that a particular SA is authorized to speak on > behalf of a particular IP address (or actually came from the message > originator)? Note, this issue is one of the reasons why IPsec doesn't > automatically solve the problem of authenticating MIPv6 BUs. > > 2. ICMP messages may be subject to actions intended to cause the > message or the reply to it go to a destination different than the > message originator's intention. The ICMP checksum calculation > provides a protection mechanism against changes by a malicious > interceptor in the destination and source address of the IP packet > carrying that message, provided the ICMP checksum field is > protected against change by authentication [IPv6-AUTH] or > encryption [IPv6-ESP] of the ICMP message. > > seems like if you have AH/ESP, that check alone provides you the > additional protection. That it also covers the ICMP checksum is not > really relevant... > ========================================================== > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 12 03:45: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 DAA14732 for ; Thu, 12 Feb 2004 03:45:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArCT8-0002I7-Ss for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 03:45:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C8jAND008807 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 03:45:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArCT6-0002Hy-B5 for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 03:45:08 -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 DAA14721 for ; Thu, 12 Feb 2004 03:45:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArCT3-0000Ax-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 03:45:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArCS8-00005H-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 03:44:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArCRi-0007n7-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 03:43:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArCR4-0001x2-BF; Thu, 12 Feb 2004 03:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArCQG-0001vR-UG for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 03:42:13 -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 DAA14546 for ; Thu, 12 Feb 2004 03:42:11 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArCQE-0007dn-00 for ipv6@ietf.org; Thu, 12 Feb 2004 03:42:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArCPJ-0007TM-00 for ipv6@ietf.org; Thu, 12 Feb 2004 03:41:14 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArCOP-0007Im-00 for ipv6@ietf.org; Thu, 12 Feb 2004 03:40:17 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1C8eIv15802 for ; Thu, 12 Feb 2004 10:40:18 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 12 Feb 2004 10:40:16 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 02:40:14 -0600 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: ICMPv3: Security Consideration Section. Date: Thu, 12 Feb 2004 02:40:14 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE96@daebe009.americas.nokia.com> Thread-Topic: ICMPv3: Security Consideration Section. Thread-Index: AcPxMCm0/5jYqdF6Tb6xNmK4rKW7UwACpoZg To: Cc: X-OriginalArrivalTime: 12 Feb 2004 08:40:14.0756 (UTC) FILETIME=[D5BD4640:01C3F143] 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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jari, Your points are valid. See my comments inline.. > The primary problem with this is that while you may know well your > peer and even be able to set up a security association with him, it > may not be easy to set up security associations with all the routers > (and their operators) in between. Perhaps you should mention something > about this. You are right but there is no solution to that problem. What is the purpose of mentioning that ? How exactly do you want this to be=20 mentioned ? Some proposed text would be helpful. > Actually, the point about the checksum may have been relevant. > I think the attack you are describing here is that someone in > the middle change the destination address of an ICMP message, > right? ESP does not protect the IP header, but the fact that the > addresses from the header are included in the pseudo-header that > is calculated into the checksum helps. The checksum is covered > by ESP, so that can not be changed. Anyway, that protection may > not be quite as strong as AH/ESP gives you otherwise. Presumably > you would have to test for 2^15 different fake addresses before > you found one that would give the same checksum value, no? You are right. What about changing the text to the following ? =3D=3D=3D=3D=3D 2. ICMP messages may be subject to actions intended to cause the message or the reply to it go to a destination different than the message originator's intention. The protection against this attack can be achieved by using the Authentication Header [IPv6-AUTH] or the Encapsulating Security Payload Header [IPv6-ESP]. Authentication Header provides the protection against change for the source and the destination address of the IP packet. Encapsulating Security Payload Header does not provide this protection but the ICMP checksum calculation includes the source and the destination addresses and the Encapsulating Security Payload Header protects the checksum. Therefore, the combination of ICMP checksum and the Encapsulating Security Payload Header provides the protection against this attack. The protection provided by the Encapsulating Security Payload Header will not be as strong as the protection provided by the Authentication Header. =3D=3D=3D=3D=3D > There may be some additional ICMP issues related to DoS that you > should mention. There are two exceptions in the multicast rule > e.2 in Section 2.4. In theory, you could cause a very large number > of nodes to send you Packet Too Bigs or Parameter Problems. For > instance, just send a multicast packet with an unknown option marked > as mandatory. Fortunately, it turns out that its relatively hard to > get the multicast routers to carry your fake multicast packet unless > you are on the correct multicast path, i.e. very near the legitimate > sender. But perhaps you should say something about this too. If a malicious router sends this multicast packet with its own address as the source address then it is causing a DoS for itself. That is=20 certainly NOT what the malicious router would like to do. If this malicious router sends this multicast packet with the source address of a legitimate multicast source then it might cause a DoS attack to the multicast sender. This is harmful. Can ESP/AH protect the sender against this attack ? Yes if the sender=20 is not accepting un-authenticated ICMP packets.=20 Did I get this right ? If yes, I will try to add some text about this in the draft. If no, would you please send me some text for this ? Thanks ! - Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 12 05: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 FAA17690 for ; Thu, 12 Feb 2004 05:18: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 1ArDv2-0008MN-PE for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 05:18:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CAI47H032134 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 05:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArDv2-0008MD-8H for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 05:18: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 FAA17678 for ; Thu, 12 Feb 2004 05:18:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArDuy-0001Q1-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 05:18:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArDu5-0001LM-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 05:17:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArDtQ-0001Gj-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 05:16:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArDt5-00083i-U1; Thu, 12 Feb 2004 05:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArDsC-000839-18 for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 05:15:08 -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 FAA17602 for ; Thu, 12 Feb 2004 05:15:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArDs8-0001Ae-00 for ipv6@ietf.org; Thu, 12 Feb 2004 05:15:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArDrB-00014z-00 for ipv6@ietf.org; Thu, 12 Feb 2004 05:14:05 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1ArDqQ-0000uy-00 for ipv6@ietf.org; Thu, 12 Feb 2004 05:13:18 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HSY00J07UYEPB@mailout1.samsung.com> for ipv6@ietf.org; Thu, 12 Feb 2004 19:11:02 +0900 (KST) Received: from ep_ms13_bk (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 <0HSY000T7UYDGY@mailout1.samsung.com> for ipv6@ietf.org; Thu, 12 Feb 2004 19:11:02 +0900 (KST) Received: from ep_spt01 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HSY00D3DUYDGL@ms13.samsung.com> for ipv6@ietf.org; Thu, 12 Feb 2004 19:11:01 +0900 (KST) Content-return: prohibited Date: Thu, 12 Feb 2004 10:11:07 +0000 (GMT) From: Syam Madanpalli Subject: Re :rfc2462bis -- loopback suppression X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9TSVNPKENUTyk/TWFuYWdlcg==?= To: Ole Troan Cc: JINMEI Tatuya / ???? , "ipv6@ietf.org " Reply-to: syam@samsung.com Message-id: <1590617.1076580664920.JavaMail.weblogic@ep_app12> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040212101104911@syam X-MTR: 20040212101104911@syam X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 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.8 required=5.0 tests=PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, > one solution could be to add a optional identifier option to DAD NS > packets, so that the sender can recognise the case when its own > packets are looped around. We were thinking of this solution while writing the draft http://www.ietf.org/internet-drafts/draft-syam-ipv6-over-wifi-00.txt but again how can we guarantee the uniqueness of this optional identifier. Of course the probability of two nodes choosing same IID and the optional dentifier is very less. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 12 10:50: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 KAA29308 for ; Thu, 12 Feb 2004 10:50:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJ6b-0003ks-Pq for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 10:50:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CFoLJG014430 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 10:50:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJ6b-0003kf-JY for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 10:50:21 -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 KAA29278 for ; Thu, 12 Feb 2004 10:50:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJ6V-0001vJ-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 10:50:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJ5b-0001pc-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 10:49:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArJ4g-0001kR-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 10:48:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJ4M-0003Nl-TW; Thu, 12 Feb 2004 10:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJ3f-0003N4-Id for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 10:47: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 KAA29141 for ; Thu, 12 Feb 2004 10:47:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJ3Z-0001dZ-00 for ipv6@ietf.org; Thu, 12 Feb 2004 10:47:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJ2e-0001Yu-00 for ipv6@ietf.org; Thu, 12 Feb 2004 10:46:16 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1ArJ25-0001UM-00 for ipv6@ietf.org; Thu, 12 Feb 2004 10:45:41 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1CFjbnp006523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2004 07:45:38 -0800 (PST) Received: from NAEXFE03.na.qualcomm.com (naexfe03.qualcomm.com [172.30.32.23]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1CFjWtS003108; Thu, 12 Feb 2004 07:45:35 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXFE03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Feb 2004 07:45:33 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: updates to IPv6 over PPP spec. Date: Thu, 12 Feb 2004 07:45:52 -0800 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327D30@NAEX01.na.qualcomm.com> Thread-Topic: updates to IPv6 over PPP spec. Thread-Index: AcPxLolkSCqB9+TAS2WG8NU63c2MUAAUJhqw From: "Barany, Pete" To: "Pekka Savola" Cc: "Karim El-Malki \(HF/EAB\)" , X-OriginalArrivalTime: 12 Feb 2004 15:45:33.0212 (UTC) FILETIME=[3FECA5C0:01C3F17F] 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 The PDSN in cdma2000 does not have a global unicast address for the PPP connection between itself and the mobile. It only has a link-local address. The mobile has both a link-local and global unicast address. Pete -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Pekka Savola Sent: Wednesday, February 11, 2004 8:15 PM To: Barany, Pete Cc: Karim El-Malki (HF/EAB); ipv6@ietf.org Subject: RE: updates to IPv6 over PPP spec. On Wed, 11 Feb 2004, Barany, Pete wrote: > The rationale also fails to account for 3GPP2 networks (cdma2000). Here, > PPP (IPV6CP) is used to obtain an IPv6 address for the mobile (or the > MIPv6 CoA for the mobile). UMTS uses a PDP context instead. >=20 > Since 3GPP2 has mandated a restriction that the /64 prefix advertised to > a mobile by a PDSN (similar to 'GGSN' if you are a UMTS-only person) be > unique/exclusive to that PPP link, then there is no need for the > suggested update #1 below. In fact, quite the contrary. Umm.. but doesn't the access router which terminates the PPP link also have an address from that /64 prefix (e.g., ::1) -- or does it have a link-local address only? In case such an assumption is made, it should be spelled out clearly=20 enough. --=20 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 Thu Feb 12 11:07: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 LAA00118 for ; Thu, 12 Feb 2004 11:07:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJNA-00063S-60 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 11:07:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CG7SCC023268 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 11:07:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJN9-00063D-A8 for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 11:07: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 LAA00061 for ; Thu, 12 Feb 2004 11:07:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJN2-0003tC-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 11:07:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJM2-0003m9-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 11:06:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArJLG-0003gg-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 11:05:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJKp-0005YD-5X; Thu, 12 Feb 2004 11:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJKE-0005Wg-I1 for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 11:04: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 LAA29882 for ; Thu, 12 Feb 2004 11:04:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJK8-0003YK-00 for ipv6@ietf.org; Thu, 12 Feb 2004 11:04:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJJI-0003S8-00 for ipv6@ietf.org; Thu, 12 Feb 2004 11:03:28 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1ArJIa-0003Lk-00 for ipv6@ietf.org; Thu, 12 Feb 2004 11:02:44 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1CG2hvf015041; Thu, 12 Feb 2004 08:02:43 -0800 (PST) Received: from NAEXFE01.na.qualcomm.com (naexfe01.qualcomm.com [172.30.32.17]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1CG2dVJ009418; Thu, 12 Feb 2004 08:02:40 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXFE01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Feb 2004 08:02:39 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: FW: updates to IPv6 over PPP spec. Date: Thu, 12 Feb 2004 08:02:59 -0800 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327D32@NAEX01.na.qualcomm.com> Thread-Topic: updates to IPv6 over PPP spec. Thread-Index: AcPxLolkSCqB9+TAS2WG8NU63c2MUAAUJhqwAACDo1A= From: "Barany, Pete" To: Cc: X-OriginalArrivalTime: 12 Feb 2004 16:02:39.0806 (UTC) FILETIME=[A3D275E0:01C3F181] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I forgot to mention where this is explicitly stated. In TIA-835-C, Section 3.2.1.4.2 "IPv6 Addressing": --->BEGIN For an IPv6 MS, the PDSN shall be the default router and the PPP termination point. The PDSN shall allocate one globally unique /64 prefix to each PPP link. The PDSN shall not construct any global address from this prefix. --->END - Pete -----Original Message----- From: Barany, Pete=20 Sent: Thursday, February 12, 2004 7:46 AM To: 'Pekka Savola' Cc: Karim El-Malki (HF/EAB); ipv6@ietf.org Subject: RE: updates to IPv6 over PPP spec. The PDSN in cdma2000 does not have a global unicast address for the PPP connection between itself and the mobile. It only has a link-local address. The mobile has both a link-local and global unicast address. Pete -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Pekka Savola Sent: Wednesday, February 11, 2004 8:15 PM To: Barany, Pete Cc: Karim El-Malki (HF/EAB); ipv6@ietf.org Subject: RE: updates to IPv6 over PPP spec. On Wed, 11 Feb 2004, Barany, Pete wrote: > The rationale also fails to account for 3GPP2 networks (cdma2000). Here, > PPP (IPV6CP) is used to obtain an IPv6 address for the mobile (or the > MIPv6 CoA for the mobile). UMTS uses a PDP context instead. >=20 > Since 3GPP2 has mandated a restriction that the /64 prefix advertised to > a mobile by a PDSN (similar to 'GGSN' if you are a UMTS-only person) be > unique/exclusive to that PPP link, then there is no need for the > suggested update #1 below. In fact, quite the contrary. Umm.. but doesn't the access router which terminates the PPP link also have an address from that /64 prefix (e.g., ::1) -- or does it have a link-local address only? In case such an assumption is made, it should be spelled out clearly=20 enough. --=20 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 Thu Feb 12 15:25: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 PAA12788 for ; Thu, 12 Feb 2004 15:25:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNOV-0005WC-IG for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 15:25:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKP7Ew021212 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 15:25:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNOU-0005W3-RJ for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:25: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 PAA12729 for ; Thu, 12 Feb 2004 15:25:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNOR-0007JF-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 15:25:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNMw-00079x-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 15:23:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArNM2-00074K-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 15:22:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNLW-0004c4-AX; Thu, 12 Feb 2004 15:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNKu-0004AA-Td for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 15:21:25 -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 PAA12602 for ; Thu, 12 Feb 2004 15:21:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNKr-0006z8-00 for ipv6@ietf.org; Thu, 12 Feb 2004 15:21:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNJu-0006vA-00 for ipv6@ietf.org; Thu, 12 Feb 2004 15:20:23 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ArNJo-0006qy-00 for ipv6@ietf.org; Thu, 12 Feb 2004 15:20:16 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 12 Feb 2004 21:20:23 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1CKJML1024252; Thu, 12 Feb 2004 21:19:23 +0100 (MET) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id UAA22901; Thu, 12 Feb 2004 20:19:45 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Michael Hunter Cc: =?iso-8859-1?q?JINMEI_Tatuya_=2F_=BF=C0=CC=C0=C3=A3=BA=C8?= , ipv6@ietf.org Subject: Re: rfc2462bis -- loopback suppression References: <7t5d68lkvn8.fsf@mrwint.cisco.com> <20040212120940.0a67e23b.michael.hunter@eng.sun.com> From: Ole Troan Date: Thu, 12 Feb 2004 20:19:45 +0000 In-Reply-To: <20040212120940.0a67e23b.michael.hunter@eng.sun.com> (Michael Hunter's message of "Thu, 12 Feb 2004 12:09:40 -0800") Message-ID: <7t5hdxwhwym.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 >> >>>>> On Thu, 12 Feb 2004 00:07:39 +0000, >> >>>>> Ole Troan said: >> >> > one solution could be to add a optional identifier option to DAD NS >> > packets, so that the sender can recognise the case when its own >> > packets are looped around. >> >> > too big a change for 2462bis? >> >> I think this is too big to merge into 2462bis (sorry), but I agree >> this is worth considering as an extension in a separate document >> (depending on how this is popular and severe). > > This essentially the problem with DAD on wifi, right? That should > make a general solution more interesting then just a corner case. no, this is a general problem. I've seen this on Ethernet. I've spoken to the DAD/WIFI draft owners and we've agreed to add the id option to that draft and rename it to something less wifi specific. /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 Feb 12 15:28: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 PAA12944 for ; Thu, 12 Feb 2004 15:28:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNRj-0006Ty-B9 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 15:28:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKSRjH024912 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 15:28:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNRj-0006Tj-6E for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:28: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 PAA12938 for ; Thu, 12 Feb 2004 15:28:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNRg-0007l2-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 15:28:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNQp-0007gI-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 15:27:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArNQO-0007b2-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 15:27:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNQL-0005qJ-Pw; Thu, 12 Feb 2004 15:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNCL-00019n-Uc for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 15:12:33 -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 PAA11443 for ; Thu, 12 Feb 2004 15:12:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNCI-00061H-00 for ipv6@ietf.org; Thu, 12 Feb 2004 15:12:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNBO-0005vu-00 for ipv6@ietf.org; Thu, 12 Feb 2004 15:11:35 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1ArNB1-0005q5-00 for ipv6@ietf.org; Thu, 12 Feb 2004 15:11:12 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1CKBCVo013493 for ; Thu, 12 Feb 2004 13:11:12 -0700 (MST) 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 <0HSZ0006OMQNJ9@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Thu, 12 Feb 2004 13:11:12 -0700 (MST) Received: from laphroig ([129.146.85.171]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with SMTP id <0HSZ00EB3MQMDR@mail.sun.net> for ipv6@ietf.org; Thu, 12 Feb 2004 13:11:11 -0700 (MST) Date: Thu, 12 Feb 2004 12:09:40 -0800 From: Michael Hunter Subject: Re: rfc2462bis -- loopback suppression In-reply-to: To: JINMEI Tatuya / =?ISO-8859-1?Q?=BF=C0=CC=C0=C3=A3=BA=C8?= Cc: ot@cisco.com, ipv6@ietf.org Message-id: <20040212120940.0a67e23b.michael.hunter@eng.sun.com> MIME-version: 1.0 X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; sparc-sun-solaris2.10) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable References: <7t5d68lkvn8.fsf@mrwint.cisco.com> 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 Thu, 12 Feb 2004 14:41:09 +0900 JINMEI Tatuya / =BF=C0=CC=C0=C3=A3=BA=C8 wro= te: > >>>>> On Thu, 12 Feb 2004 00:07:39 +0000,=20 > >>>>> Ole Troan said: >=20 > > one solution could be to add a optional identifier option to DAD NS > > packets, so that the sender can recognise the case when its own > > packets are looped around. >=20 > > too big a change for 2462bis? >=20 > I think this is too big to merge into 2462bis (sorry), but I agree > this is worth considering as an extension in a separate document > (depending on how this is popular and severe). This essentially the problem with DAD on wifi, right? That should make a general solution more interesting then just a corner case. mph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 12 18:33: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 SAA23902 for ; Thu, 12 Feb 2004 18:32:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQJs-0000Ao-T5 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 18:32:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CNWWLq000662 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 18:32:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQJs-0000Ab-OX for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 18:32: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 SAA23868 for ; Thu, 12 Feb 2004 18:32:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQJn-0002wc-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 18:32:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQIp-0002qa-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 18:31:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArQHw-0002ki-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 18:30:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQHV-0008EE-8z; Thu, 12 Feb 2004 18:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQGz-00089l-3G for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 18:29:33 -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 SAA23694 for ; Thu, 12 Feb 2004 18:29:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQGu-0002eI-00 for ipv6@ietf.org; Thu, 12 Feb 2004 18:29:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQG2-0002ZF-00 for ipv6@ietf.org; Thu, 12 Feb 2004 18:28:35 -0500 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1ArQFM-0002Tx-00 for ipv6@ietf.org; Thu, 12 Feb 2004 18:27:52 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1ArQFD-0003ur-00 for ; Thu, 12 Feb 2004 23:27:43 +0000 Date: Thu, 12 Feb 2004 23:27:43 +0000 To: ipv6@ietf.org Subject: experimental registry Message-ID: <20040212232742.GA8528@fysh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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've set up an experimental registry, as I suggested earlier, as a prototype for an address prefix registry. I call it LUNREX: the Lightweight Unique Number Registry Experiment. It's allocating 36-bit numbers (4 bits short of what an fc00::/8 registry would have to do). The numbers allocated have no significance outside this experiment. To get your own number: mail allocate@lunrex.nume.rous.org < /dev/null The project website: http://lunrex.nume.rous.org Allocation certificates are signed with this PGP key: pub 1024D/D1B93576 2004-02-12 LUNREX allocations -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQGiBEAr1+cRBADB9MYYfGyp8iAGtHdbQxSxQmAlR6rXMQexfTfE+mmzGTqKUNvK HfFr3XI/FRdzIRvMdAMUjOoz+KoMxvfrGRxRK5D6vh6gzm6WesvIIL8SgW45ELc7 AJblRB5fqwoXk6Nf7I3eN8JEcFH5b8k5716nq1KgCA1VLCj+4Ph+HfjJJwCg1MPc 64WjkF/Bx0zOI1kLDxtJlH0D/3Ss8ALF5Pic5R5AbvYkXDNcOcpjDYgdabdn9+II oW01wKE4MYvsHprB+oqpLqFQ3hSE9qslZiwG7KPsSeEBd2VgpeVwy0KYmQxvrBja WjVfURU7egK46v/RleRAbuTPqnvj/zAz4KqwJh+AqO2tLbpGM+drebFOb+dSPzYu 1+CZA/wIUANTDcgUQN0RY/cbvjbSVfwtVPlg/XO0jkRhucKVALtHPYUEIE83eq9A o/DGYUhdc3MwAtI/PhiMamQ87NdkzvBDbV3PDUu7S2i/QNpiEhhUm8onZqPWaFER zmyIhP5xK7TDas31gUSbH0zkJCeJkCrkwEv8tsrcolBZQsjsYbQSTFVOUkVYIGFs bG9jYXRpb25ziF4EExECAB4FAkAr1+cCGwMGCwkIBwMCAxUCAwMWAgECHgECF4AA CgkQpV047tG5NXa9oACffaWEqUvhhlmWu0n2jdUHr99ekUYAoLjwtw2GmCSIE8o+ 6jRBxr+op6cy =8fza -----END PGP PUBLIC KEY BLOCK----- Multiple allocations are welcome, but please don't flood me. This is sitting behind an ADSL line. Comments welcome. -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 12 18:43: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 SAA24858 for ; Thu, 12 Feb 2004 18:43:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQTk-0002ow-1j for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 18:42:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CNgh07010833 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 18:42:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQTj-0002oc-Qs for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 18:42:43 -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 SAA24829 for ; Thu, 12 Feb 2004 18:42:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQTe-0004OJ-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 18:42:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQSq-0004Hz-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 18:41:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArQS9-0004Ab-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 18:41:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQS7-0002RQ-Fv; Thu, 12 Feb 2004 18:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQRd-0002Ja-FZ for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 18:40:33 -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 SAA24540 for ; Thu, 12 Feb 2004 18:40:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQRY-00045o-00 for ipv6@ietf.org; Thu, 12 Feb 2004 18:40:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQQg-0003wq-00 for ipv6@ietf.org; Thu, 12 Feb 2004 18:39:34 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQPm-0003mj-00 for ipv6@ietf.org; Thu, 12 Feb 2004 18:38:38 -0500 Received: from localhost ([130.194.13.81]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L6JTGFFIK8935MST@vaxc.its.monash.edu.au> for ipv6@ietf.org; Fri, 13 Feb 2004 10:37:57 +1100 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id DECB61B000E; Fri, 13 Feb 2004 10:37:55 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id C7ED212400A; Fri, 13 Feb 2004 10:37:55 +1100 (EST) Date: Fri, 13 Feb 2004 10:37:55 +1100 From: Greg Daley Subject: Re: rfc2462bis -- loopback suppression To: Ole Troan Cc: Michael Hunter , =?ISO-8859-1?Q?JINMEI_Tatu?= =?ISO-8859-1?Q?ya_/_=BF=C0=CC=C0=C3=A3=BA=C8?= , ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <402C0E53.2020008@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <7t5d68lkvn8.fsf@mrwint.cisco.com> <20040212120940.0a67e23b.michael.hunter@eng.sun.com> <7t5hdxwhwym.fsf@mrwint.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 Hi Ole, I think the problem is half solved with securing-neighbour discovery. Ole Troan wrote: >>>>>>>>On Thu, 12 Feb 2004 00:07:39 +0000, >>>>>>>>Ole Troan said: >>>>>>> >>>>one solution could be to add a optional identifier option to DAD NS >>>>packets, so that the sender can recognise the case when its own >>>>packets are looped around. >>> >>>>too big a change for 2462bis? >>> >>>I think this is too big to merge into 2462bis (sorry), but I agree >>>this is worth considering as an extension in a separate document >>>(depending on how this is popular and severe). >> >>This essentially the problem with DAD on wifi, right? That should >>make a general solution more interesting then just a corner case. > > > no, this is a general problem. I've seen this on Ethernet. > > I've spoken to the DAD/WIFI draft owners and we've agreed to add the > id option to that draft and rename it to something less wifi specific. > > /ot SEND has already defined a random Nonce option for Neighbour Solicitation messages. Also defined are Timestamp options for these messages. Send requires both of these to be present in a DAD-NS. In this case, a node can keep track of (only) its fresh Nonces, and it will be able to check if received DAD NS's are its own. These options would even be able to be used in non-SEND solicitations under the constraint that there's no trust associated with them (since they're not signed messages). There's no further identifier definition required (although it would be valuable to write a short draft on it). Greg Daley -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 13 01:39: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 BAA11015 for ; Fri, 13 Feb 2004 01:39:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWyM-0005OQ-Gm for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 01:38:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D6ckjF020699 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 01:38:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWyM-0005Nm-4b for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 01:38:46 -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 BAA10986 for ; Fri, 13 Feb 2004 01:38:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWyF-0005CO-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 01:38:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArWxG-00056A-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 01:37:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArWwJ-000507-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 01:36:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWvj-0004hj-5G; Fri, 13 Feb 2004 01:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWvS-0004g6-9I for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 01:35:46 -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 BAA10903 for ; Fri, 13 Feb 2004 01:35:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWvL-0004ul-00 for ipv6@ietf.org; Fri, 13 Feb 2004 01:35:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArWuN-0004pK-00 for ipv6@ietf.org; Fri, 13 Feb 2004 01:34:39 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWtT-0004hL-00 for ipv6@ietf.org; Fri, 13 Feb 2004 01:33:43 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1D6XBH14925; Fri, 13 Feb 2004 08:33:11 +0200 Date: Fri, 13 Feb 2004 08:33:11 +0200 (EET) From: Pekka Savola To: "Barany, Pete" cc: ipv6@ietf.org Subject: Re: FW: updates to IPv6 over PPP spec. In-Reply-To: <17D8F6DF3ED94D40BD607380866D9B7F327D32@NAEX01.na.qualcomm.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 Thu, 12 Feb 2004, Barany, Pete wrote: > I forgot to mention where this is explicitly stated. In TIA-835-C, > Section 3.2.1.4.2 "IPv6 Addressing": > > --->BEGIN > For an IPv6 MS, the PDSN shall be the default router and the PPP > termination point. The PDSN shall allocate one globally unique /64 > prefix to each PPP link. The PDSN shall not construct any global address > from this prefix. > --->END Right -- but as PPPv6 is used in other scopes than 3GPP and 3GPP2 as well, PPP specification should probably include some discussion of the assumptions required for disabling DAD. > -----Original Message----- > From: Barany, Pete > Sent: Thursday, February 12, 2004 7:46 AM > To: 'Pekka Savola' > Cc: Karim El-Malki (HF/EAB); ipv6@ietf.org > Subject: RE: updates to IPv6 over PPP spec. > > The PDSN in cdma2000 does not have a global unicast address for the PPP > connection between itself and the mobile. It only has a link-local > address. The mobile has both a link-local and global unicast address. > > Pete > > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of > Pekka Savola > Sent: Wednesday, February 11, 2004 8:15 PM > To: Barany, Pete > Cc: Karim El-Malki (HF/EAB); ipv6@ietf.org > Subject: RE: updates to IPv6 over PPP spec. > > On Wed, 11 Feb 2004, Barany, Pete wrote: > > The rationale also fails to account for 3GPP2 networks (cdma2000). > Here, > > PPP (IPV6CP) is used to obtain an IPv6 address for the mobile (or the > > MIPv6 CoA for the mobile). UMTS uses a PDP context instead. > > > > Since 3GPP2 has mandated a restriction that the /64 prefix advertised > to > > a mobile by a PDSN (similar to 'GGSN' if you are a UMTS-only person) > be > > unique/exclusive to that PPP link, then there is no need for the > > suggested update #1 below. In fact, quite the contrary. > > Umm.. but doesn't the access router which terminates the PPP link also > have an address from that /64 prefix (e.g., ::1) -- or does it have a > link-local address only? > > In case such an assumption is made, it should be spelled out clearly > enough. > > -- 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 Feb 13 03:48: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 DAA28923 for ; Fri, 13 Feb 2004 03:48: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 1ArYzI-0006Y0-RM for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 03:47:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D8lqWF025158 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 03:47:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYzH-0006Xh-An for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 03:47: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 DAA28892 for ; Fri, 13 Feb 2004 03:47:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYz9-0000vY-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 03:47:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYyA-0000qE-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 03:46:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArYxD-0000lC-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 03:45:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYwZ-0006AG-H1; Fri, 13 Feb 2004 03:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYva-00065w-Hq for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 03:44: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 DAA28760 for ; Fri, 13 Feb 2004 03:43:56 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYvS-0000ah-00 for ipv6@ietf.org; Fri, 13 Feb 2004 03:43:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYuU-0000VA-00 for ipv6@ietf.org; Fri, 13 Feb 2004 03:42:55 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ArYtp-0000QK-00 for ipv6@ietf.org; Fri, 13 Feb 2004 03:42:13 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1D8gF323574 for ; Fri, 13 Feb 2004 10:42:15 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Feb 2004 10:37:50 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 00:36:18 -0800 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: ICMPv3: Security Consideration Section. Date: Fri, 13 Feb 2004 02:36:19 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE9B@daebe009.americas.nokia.com> Thread-Topic: ICMPv3: Security Consideration Section. Thread-Index: AcPxMCm0/5jYqdF6Tb6xNmK4rKW7UwA24f8A To: Cc: X-OriginalArrivalTime: 13 Feb 2004 08:36:18.0634 (UTC) FILETIME=[7369AAA0:01C3F20C] 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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jari, > There may be some additional ICMP issues related to DoS that you > should mention. There are two exceptions in the multicast rule > e.2 in Section 2.4. In theory, you could cause a very large number > of nodes to send you Packet Too Bigs or Parameter Problems. For > instance, just send a multicast packet with an unknown option marked > as mandatory. Fortunately, it turns out that its relatively hard to > get the multicast routers to carry your fake multicast packet unless > you are on the correct multicast path, i.e. very near the legitimate > sender. But perhaps you should say something about this too. Even when you are on the correct path, won't this fake multicast packet with an unknown option marked as mandatory be dropped by the next hop multicast router ? If the next hop router (or a bunch of them) itself is gonna drop this packet and send you ICMP error=20 message, why would you receive ICMP error messages from a large=20 number of nodes ?? Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 13 06:34: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 GAA05259 for ; Fri, 13 Feb 2004 06:34:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arba5-0003NF-2i for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 06:34:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DBY1dJ012968 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 06:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arba4-0003N5-S3 for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 06:34:00 -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 GAA05238 for ; Fri, 13 Feb 2004 06:33:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArbZv-0007Gh-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 06:33:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArbYw-0007C5-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 06:32:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArbYL-00078N-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 06:32:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArbYB-00030X-4M; Fri, 13 Feb 2004 06:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArbXE-0002xl-JW for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 06:31: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 GAA05181 for ; Fri, 13 Feb 2004 06:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArbX4-00074g-00 for ipv6@ietf.org; Fri, 13 Feb 2004 06:30:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArbW6-00070g-00 for ipv6@ietf.org; Fri, 13 Feb 2004 06:29:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ArbVb-0006wU-00 for ipv6@ietf.org; Fri, 13 Feb 2004 06:29:24 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2004 12:29:31 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1DBSUL1021342; Fri, 13 Feb 2004 12:28:31 +0100 (MET) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA19513; Fri, 13 Feb 2004 11:28:54 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: greg.daley@eng.monash.edu.au Cc: Michael Hunter , =?iso-8859-1?q?JINMEI_Tatuya_=2F_=BF=C0=CC=C0=C3=A3=BA=C8?= , ipv6@ietf.org Subject: Re: rfc2462bis -- loopback suppression References: <7t5d68lkvn8.fsf@mrwint.cisco.com> <20040212120940.0a67e23b.michael.hunter@eng.sun.com> <7t5hdxwhwym.fsf@mrwint.cisco.com> <402C0E53.2020008@eng.monash.edu.au> From: Ole Troan Date: Fri, 13 Feb 2004 11:28:54 +0000 In-Reply-To: <402C0E53.2020008@eng.monash.edu.au> (Greg Daley's message of "Fri, 13 Feb 2004 10:37:55 +1100") Message-ID: <7t5y8r7fcax.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 Greg, >>>This essentially the problem with DAD on wifi, right? That should >>>make a general solution more interesting then just a corner case. >> no, this is a general problem. I've seen this on Ethernet. >> I've spoken to the DAD/WIFI draft owners and we've agreed to add the >> id option to that draft and rename it to something less wifi specific. > > SEND has already defined a random Nonce option for > Neighbour Solicitation messages. > > Also defined are Timestamp options for these messages. > > Send requires both of these to be present in a DAD-NS. > > In this case, a node can keep track of (only) its fresh Nonces, > and it will be able to check if received DAD NS's are > its own. > > These options would even be able to be used in non-SEND > solicitations under the constraint that there's no trust > associated with them (since they're not signed messages). > > There's no further identifier definition required (although > it would be valuable to write a short draft on it). thanks for pointing out the SEND draft to me, I haven't followed that work for a while. yes, it seems that the Nonce option should work. a SEND node receiving these would interpret this message as a unsecured message as long as there is no trust association, right? if there is a trust association the message would be silently discarded. agree, that a short draft on how non-SEND nodes can use these options is needed. cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 13 08:11: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 IAA07978 for ; Fri, 13 Feb 2004 08:11:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ard5w-0003Pb-LX for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 08:11:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DDB0r8013098 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 08:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ard5w-0003PA-3f for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 08:11:00 -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 IAA07953 for ; Fri, 13 Feb 2004 08:10:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ard5v-0006UW-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 08:10:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ard4w-0006Ph-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 08:09:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ard4O-0006Lr-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 08:09:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ard42-00031V-Fp; Fri, 13 Feb 2004 08:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ard3y-000313-JQ for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 08:08:58 -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 IAA07912 for ; Fri, 13 Feb 2004 08:08:56 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ard3x-0006LF-00 for ipv6@ietf.org; Fri, 13 Feb 2004 08:08:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ard31-0006HS-00 for ipv6@ietf.org; Fri, 13 Feb 2004 08:08:00 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ard2C-0006Dg-00 for ipv6@ietf.org; Fri, 13 Feb 2004 08:07:08 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DD76v21049 for ; Fri, 13 Feb 2004 15:07:06 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 15:07:03 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 15:07:02 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 15:07:01 +0200 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: [node req] Question on Security considerations. Date: Fri, 13 Feb 2004 15:07:01 +0200 Message-ID: Thread-Topic: [node req] Question on Security considerations. Thread-Index: AcPyMkSXZWVFLp1KQL+6ENpv58svJQ== To: Cc: , X-OriginalArrivalTime: 13 Feb 2004 13:07:01.0136 (UTC) FILETIME=[44B2C900:01C3F232] 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, The Security AD commented the following: > For Section 8, RFCs 2401, 2402, and 2406 are currently being revised = by=20 > the IPsec group; that should be mentioned. This is no problem. > The crypto algorithm requirements should be better aligned with=20 > recommendations from the IPsec wg. There's a draft that lists 3DES as = > SHOULD, not MAY. Would it be appropriate to mention something like: The Security Area RECOMMENDS the use of 3DES. > I think that IKEv? should be a SHOULD, not a MAY. While the IESG = hasn't=20 > yet seen draft-bellovin-mandate-keymgmt, it will soon and it describes = > automated key management as a "strong SHOULD". That's certainly the=20 > consensus in the security area. I think that the WG has gone through this several times, and SHOULD has always seemed problematic for some uses. Does anyone have any = suggestions? > More generically, I don't think that this WG should standardize weaker = > security requirements than the security area thinks are appropriate,=20 > without strong justification. (Stronger requirements are fine -- they = > may have a different operational environment, or a different threat=20 > model.) My general comment is that if this document can point to existing RFCs for the security requirements, then I am happy to mandate whatever the pointers suggest (hint to the security area, provide pointers and I will include them). thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 13 08:16: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 IAA08193 for ; Fri, 13 Feb 2004 08:16:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdAk-000413-NF for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 08:15:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DDFw5q015431 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 08:15:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdAk-00040o-Iv for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 08:15:58 -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 IAA08160 for ; Fri, 13 Feb 2004 08:15:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArdAj-0006wR-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 08:15:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ard9p-0006qs-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 08:15:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ard8y-0006mT-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 08:14:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ard8s-0003i1-Gn; Fri, 13 Feb 2004 08:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ard8q-0003hd-KN for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 08:14:00 -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 IAA08104 for ; Fri, 13 Feb 2004 08:13:58 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ard8p-0006lR-00 for ipv6@ietf.org; Fri, 13 Feb 2004 08:13:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ard7v-0006gx-00 for ipv6@ietf.org; Fri, 13 Feb 2004 08:13:03 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ard7F-0006ck-00 for ipv6@ietf.org; Fri, 13 Feb 2004 08:12:21 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DDCJv28999 for ; Fri, 13 Feb 2004 15:12:19 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Feb 2004 15:12:16 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 15:12:19 +0200 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: [node req] Should I include points to current set of draft updates? Date: Fri, 13 Feb 2004 15:12:16 +0200 Message-ID: Thread-Topic: [node req] Should I include points to current set of draft updates? Thread-Index: AcPyMwDqcOn0OZ77Ru+yxQx9NAOMdQ== To: X-OriginalArrivalTime: 13 Feb 2004 13:12:19.0426 (UTC) FILETIME=[0269FC20:01C3F233] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I am updating the node requirements, should I put references in for the = current set of -bis documents? For example: 2461-bis 2462-bis ICMPv3 IPv6 over PPP=09 (anything I missed?) thanks, John =09 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 13 08:41: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 IAA08950 for ; Fri, 13 Feb 2004 08:41:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdZB-0005W3-KT for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 08:41:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DDfDjt021197 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 08:41:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdZB-0005Vo-Cu for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 08:41:13 -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 IAA08917 for ; Fri, 13 Feb 2004 08:41:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArdZA-0000xA-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 08:41:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArdYB-0000r0-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 08:40:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArdXH-0000m0-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 08:39:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdX4-00050M-A2; Fri, 13 Feb 2004 08:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdW6-0004yG-Il for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 08:38: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 IAA08829 for ; Fri, 13 Feb 2004 08:38:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArdW5-0000gS-00 for ipv6@ietf.org; Fri, 13 Feb 2004 08:38:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArdVB-0000cF-00 for ipv6@ietf.org; Fri, 13 Feb 2004 08:37:05 -0500 Received: from tank-fep1-0.inet.fi ([194.251.242.241] helo=fep16.tmt.tele.fi) by ietf-mx with esmtp (Exim 4.12) id 1ArdUW-0000Xr-00 for ipv6@ietf.org; Fri, 13 Feb 2004 08:36:25 -0500 Received: from [10.100.20.29] ([212.213.204.99]) by fep16.tmt.tele.fi (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with ESMTP id <20040213133621.EGKL13626.fep16.tmt.tele.fi@[10.100.20.29]>; Fri, 13 Feb 2004 15:36:21 +0200 From: "Jari Arkko" Reply-to: "Jari Arkko" To: john.loughney@nokia.com, ipv6@ietf.org Subject: Re: [node req] Should I include points to current set of draft upd ates? Date: Fri, 13 Feb 2004 15:35:26 +0200 Message-ID: <6nLqNPRTwM30.Lv5dWhwM@mail.inet.fi> X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I think you should normatively reference only those bis documents that are = RFCs, in RFC Editor queue, in IESG review or at least close to it. Otherwise it could be a long wait. Informative references for ongoing work are another matter. My 0.02=E2=82=AC --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 13 09:14: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 JAA09910 for ; Fri, 13 Feb 2004 09:14: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 1Are4x-0007so-J6 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 09:14:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DEE3I8030296 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 09:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Are4x-0007sZ-E7 for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 09:14:03 -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 JAA09894 for ; Fri, 13 Feb 2004 09:14:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Are4v-0003Yt-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 09:14:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Are40-0003Tv-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 09:13:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Are3V-0003PK-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 09:12:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Are2z-0007Wg-MV; Fri, 13 Feb 2004 09:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Are2v-0007WB-Hd for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 09:11: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 JAA09809 for ; Fri, 13 Feb 2004 09:11:54 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Are2t-0003Mb-00 for ipv6@ietf.org; Fri, 13 Feb 2004 09:11:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Are1v-0003FN-00 for ipv6@ietf.org; Fri, 13 Feb 2004 09:10:55 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Are0v-00036l-00 for ipv6@ietf.org; Fri, 13 Feb 2004 09:09:54 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DE9r316024 for ; Fri, 13 Feb 2004 16:09:53 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Feb 2004 16:09:52 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 16:09:52 +0200 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="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: [node req] Should I include points to current set of draft upd ates? Date: Fri, 13 Feb 2004 16:09:52 +0200 Message-ID: Thread-Topic: [node req] Should I include points to current set of draft upd ates? Thread-Index: AcPyNmewG6W1/k1OSpSJ4EJnAQG3tQABI7/A To: , X-OriginalArrivalTime: 13 Feb 2004 14:09:52.0815 (UTC) FILETIME=[0CCB53F0:01C3F23B] 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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgSmFyaSwNCg0KPiBJIHRoaW5rIHlvdSBzaG91bGQgbm9ybWF0aXZlbHkgcmVmZXJlbmNlIG9u bHkgdGhvc2UgYmlzIA0KPiBkb2N1bWVudHMgdGhhdCBhcmUgUkZDcywgaW4gUkZDIEVkaXRvciBx dWV1ZSwgaW4gSUVTRyByZXZpZXcgDQo+IG9yIGF0IGxlYXN0IGNsb3NlIHRvIGl0Lg0KPiANCj4g T3RoZXJ3aXNlIGl0IGNvdWxkIGJlIGEgbG9uZyB3YWl0Lg0KDQpPZiBjb3Vyc2UuDQogDQo+IElu Zm9ybWF0aXZlIHJlZmVyZW5jZXMgZm9yIG9uZ29pbmcgd29yayBhcmUgYW5vdGhlciBtYXR0ZXIu DQoNClRoaXMgaXMgd2hhdCBJIHdhcyByZWFsbHkgYXNraW5nLiAgU2hhbGwgSSBhbGVydCB0aGUg cmVhZGVyIG9mDQp0aGUgZG9jdW1lbnRzIHdoaWNoIGFyZSBiZWluZyB1cGRhdGVkPw0KDQpKb2hu DQo= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 13 09:24: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 JAA10274 for ; Fri, 13 Feb 2004 09:24:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreEe-00009V-M4 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 09:24:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DEO4wZ000579 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 09:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreEe-00009G-CJ for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 09:24: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 JAA10240 for ; Fri, 13 Feb 2004 09:24:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AreEc-0004N0-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 09:24:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AreDj-0004Ho-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 09:23:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AreCo-0004Dh-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 09:22:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreCg-0008HR-P0; Fri, 13 Feb 2004 09:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreBg-0008Fg-RL for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 09:21:00 -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 JAA10159 for ; Fri, 13 Feb 2004 09:20:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AreBf-00048a-00 for ipv6@ietf.org; Fri, 13 Feb 2004 09:20:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AreAj-00045L-00 for ipv6@ietf.org; Fri, 13 Feb 2004 09:20:02 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AreAV-00041p-00 for ipv6@ietf.org; Fri, 13 Feb 2004 09:19:47 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 52A286A906; Fri, 13 Feb 2004 16:19:46 +0200 (EET) Message-ID: <402CDC96.5000802@kolumbus.fi> Date: Fri, 13 Feb 2004 16:17:58 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: ipv6@ietf.org Subject: Re: [node req] Should I include points to current set of draft upd ates? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi Jari, > > >>I think you should normatively reference only those bis >>documents that are RFCs, in RFC Editor queue, in IESG review >>or at least close to it. >> >>Otherwise it could be a long wait. > > > Of course. > > >>Informative references for ongoing work are another matter. > > > This is what I was really asking. Shall I alert the reader of > the documents which are being updated? Why not -- could be useful. To be included, I think they should be at least in WG draft stage. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 13 10:11: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 KAA13417 for ; Fri, 13 Feb 2004 10:11:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreyP-0007pL-SR for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 10:11:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DFBLA0030081 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 10:11:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreyP-0007p6-N2 for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 10:11:21 -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 KAA13296 for ; Fri, 13 Feb 2004 10:11:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AreyN-000149-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 10:11:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArexT-0000vo-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 10:10:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArewM-0000n4-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 10:09:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArewC-0006ri-2i; Fri, 13 Feb 2004 10:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArevP-0006YT-4i for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 10:08:15 -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 KAA12744 for ; Fri, 13 Feb 2004 10:08:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArevK-0000bj-00 for ipv6@ietf.org; Fri, 13 Feb 2004 10:08:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Areu6-0000KC-00 for ipv6@ietf.org; Fri, 13 Feb 2004 10:06:55 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aresw-00006c-00 for ipv6@ietf.org; Fri, 13 Feb 2004 10:05:43 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id F2AC715214 for ; Sat, 14 Feb 2004 00:05:40 +0900 (JST) Date: Sat, 14 Feb 2004 00:05:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Re: [psg.com #246] [2461bisissue 246] Preferred lifetime > valid lifetime 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, 13 Feb 2004 02:36:14 +0000, >>>>> rt+ipv6-2461bis@rt.psg.com said: > What is the handling for the case where a prefix's preferred lifetime > exceeds the valid lifetime? > Suggestion: Specify that a router MUST NOT send a prefix option > containing preferred lifetime > valid lifetime > Current text in Preferred Lifetime description (sec 4.2): > Preferred Lifetime > 32-bit unsigned integer. The length of time in > seconds (relative to the time the packet is sent) > that addresses generated from the prefix via > stateless address autoconfiguration remain > preferred [ADDRCONF]. A value of all one bits > (0xffffffff) represents infinity. See [ADDRCONF]. > Note that the value of this field MUST NOT exceed > the Valid Lifetime field to avoid preferring > addresses that are no longer valid. Let me check: is this your suggested text in rfc2461bis? (BTW: I guess you meant "sec 4.6.2", not "sec 4.2") JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 13 10:48: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 KAA15840 for ; Fri, 13 Feb 2004 10:48:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfXv-0006i3-FS for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 10:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DFm3Id025785 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 10:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfXv-0006ho-Ae for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 10:48:03 -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 KAA15802 for ; Fri, 13 Feb 2004 10:47:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfXs-00049n-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 10:48:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfWw-00045l-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 10:47:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArfWE-00042G-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 10:46:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfVy-0006L6-Fw; Fri, 13 Feb 2004 10:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfV0-0006Fq-Of for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 10:45: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 KAA15683 for ; Fri, 13 Feb 2004 10:44:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfUy-0003vT-00 for ipv6@ietf.org; Fri, 13 Feb 2004 10:45:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfTz-0003qb-00 for ipv6@ietf.org; Fri, 13 Feb 2004 10:44:00 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1ArfT2-0003ks-00 for ipv6@ietf.org; Fri, 13 Feb 2004 10:43:00 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1DFgvvf014714; Fri, 13 Feb 2004 07:42:57 -0800 (PST) Received: from naexfe02.na.qualcomm.com (naexfe02.qualcomm.com [129.46.51.214]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1DFgslG004571; Fri, 13 Feb 2004 07:42:55 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.61]) by naexfe02.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 07:42:54 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: updates to IPv6 over PPP spec. X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 13 Feb 2004 07:42:54 -0800 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327D37@NAEX01.na.qualcomm.com> Thread-Topic: FW: updates to IPv6 over PPP spec. Thread-Index: AcPx+0Qb1whyra94RBCKav0wacjtfwASjdsQ From: "Barany, Pete" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 13 Feb 2004 15:42:54.0533 (UTC) FILETIME=[0BC1E750:01C3F248] 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 Agreed. I can take a stab at writing some text and forward it to the editor off-line. I wouldn't imagine that it would be more than a few sentences/one or two paragraphs. Thanks. -Pete -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Thursday, February 12, 2004 10:33 PM To: Barany, Pete Cc: ipv6@ietf.org Subject: Re: FW: updates to IPv6 over PPP spec. On Thu, 12 Feb 2004, Barany, Pete wrote: > I forgot to mention where this is explicitly stated. In TIA-835-C, > Section 3.2.1.4.2 "IPv6 Addressing": >=20 > --->BEGIN > For an IPv6 MS, the PDSN shall be the default router and the PPP > termination point. The PDSN shall allocate one globally unique /64 > prefix to each PPP link. The PDSN shall not construct any global address > from this prefix. > --->END Right -- but as PPPv6 is used in other scopes than 3GPP and 3GPP2 as=20 well, PPP specification should probably include some discussion of the=20 assumptions required for disabling DAD. > -----Original Message----- > From: Barany, Pete=20 > Sent: Thursday, February 12, 2004 7:46 AM > To: 'Pekka Savola' > Cc: Karim El-Malki (HF/EAB); ipv6@ietf.org > Subject: RE: updates to IPv6 over PPP spec. >=20 > The PDSN in cdma2000 does not have a global unicast address for the PPP > connection between itself and the mobile. It only has a link-local > address. The mobile has both a link-local and global unicast address. >=20 > Pete >=20 > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of > Pekka Savola > Sent: Wednesday, February 11, 2004 8:15 PM > To: Barany, Pete > Cc: Karim El-Malki (HF/EAB); ipv6@ietf.org > Subject: RE: updates to IPv6 over PPP spec. >=20 > On Wed, 11 Feb 2004, Barany, Pete wrote: > > The rationale also fails to account for 3GPP2 networks (cdma2000). > Here, > > PPP (IPV6CP) is used to obtain an IPv6 address for the mobile (or the > > MIPv6 CoA for the mobile). UMTS uses a PDP context instead. > >=20 > > Since 3GPP2 has mandated a restriction that the /64 prefix advertised > to > > a mobile by a PDSN (similar to 'GGSN' if you are a UMTS-only person) > be > > unique/exclusive to that PPP link, then there is no need for the > > suggested update #1 below. In fact, quite the contrary. >=20 > Umm.. but doesn't the access router which terminates the PPP link also > have an address from that /64 prefix (e.g., ::1) -- or does it have a > link-local address only? >=20 > In case such an assumption is made, it should be spelled out clearly=20 > enough. >=20 >=20 --=20 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 Feb 13 11: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 LAA16469 for ; Fri, 13 Feb 2004 11:01: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 1ArfkW-0007d3-Mh for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 11:01:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DG14X0029319 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 11:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfkW-0007cl-H5 for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 11:01: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 LAA16406 for ; Fri, 13 Feb 2004 11:01:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfkT-00055S-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 11:01:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfjZ-0004z8-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 11:00:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arfie-0004tL-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 10:59:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfiY-0007GK-12; Fri, 13 Feb 2004 10:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arfhb-0007E1-OA for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 10:58:03 -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 KAA16204 for ; Fri, 13 Feb 2004 10:57:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfhZ-0004nT-00 for ipv6@ietf.org; Fri, 13 Feb 2004 10:58:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arfgb-0004if-00 for ipv6@ietf.org; Fri, 13 Feb 2004 10:57:02 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Arffd-0004ax-00 for ipv6@ietf.org; Fri, 13 Feb 2004 10:56:01 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGW8C5>; Fri, 13 Feb 2004 10:55:39 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04213E@ftmail.lab.flarion.com> From: Soliman Hesham To: "'JINMEI Tatuya / ????'" , ipv6@ietf.org Subject: RE: [psg.com #246] [2461bisissue 246] Preferred lifetime > valid lifetime Date: Fri, 13 Feb 2004 10:55:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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 > > What is the handling for the case where a prefix's > preferred lifetime > > exceeds the valid lifetime? > > > Suggestion: Specify that a router MUST NOT send a prefix option > > containing preferred lifetime > valid lifetime > > > Current text in Preferred Lifetime description (sec 4.2): > > > Preferred Lifetime > > 32-bit unsigned integer. The length of time in > > seconds (relative to the time the packet is sent) > > that addresses generated from the prefix via > > stateless address autoconfiguration remain > > preferred [ADDRCONF]. A value of all one bits > > (0xffffffff) represents infinity. See > [ADDRCONF]. > > Note that the value of this field MUST > NOT exceed > > the Valid Lifetime field to avoid preferring > > addresses that are no longer valid. > > Let me check: is this your suggested text in rfc2461bis? => yes > > (BTW: I guess you meant "sec 4.6.2", not "sec 4.2") => Of course, that's what I meant :) Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 13 16:13: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 QAA04191 for ; Fri, 13 Feb 2004 16:13:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkcb-0004cT-Ak for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 16:13:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DLDDms017754 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 16:13:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkca-0004cH-ME for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 16:13:12 -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 QAA04133 for ; Fri, 13 Feb 2004 16:13:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkcY-0002Du-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 16:13:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arkbg-00028c-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 16:12:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arkav-00024P-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 16:11:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkaV-0003zo-DS; Fri, 13 Feb 2004 16:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkaB-0003wR-4j for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 16:10:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03816; Fri, 13 Feb 2004 16:10:39 -0500 (EST) Message-Id: <200402132110.QAA03816@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2096-update-07.txt Date: Fri, 13 Feb 2004 16:10:39 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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,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 : IP Forwarding Table MIB Author(s) : M. Wasserman, B. Haberman Filename : draft-ietf-ipv6-rfc2096-update-07.txt Pages : 36 Date : 2004-2-12 This document 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 related to the forwarding of Internet Protocol (IP) packets in an IP version- independent manner. This document obsoletes RFC 2096. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2096-update-07.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-rfc2096-update-07.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-2-13163242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2096-update-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-13163242.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 Fri Feb 13 17:08: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 RAA10331 for ; Fri, 13 Feb 2004 17:08: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 1ArlTt-0001yb-Le for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 17:08:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DM8GQ0007591 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 17:08:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlTr-0001yM-Mi for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 17:08:15 -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 RAA10283 for ; Fri, 13 Feb 2004 17:08:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlTp-0002ZI-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 17:08:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlSr-0002SD-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 17:07:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArlRu-0002Jd-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 17:06:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlRj-0001NH-2Z; Fri, 13 Feb 2004 17:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arfcl-00072s-Pa for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 10:53:03 -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 KAA15966 for ; Fri, 13 Feb 2004 10:52:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arfcj-0004TI-00 for ipv6@ietf.org; Fri, 13 Feb 2004 10:53:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arfbp-0004Px-00 for ipv6@ietf.org; Fri, 13 Feb 2004 10:52:05 -0500 Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx with smtp (Exim 4.12) id 1ArfbN-0004MV-00 for ipv6@ietf.org; Fri, 13 Feb 2004 10:51:37 -0500 Received: (qmail 22862 invoked by uid 0); 13 Feb 2004 15:51:34 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.147.54) by woodstock.binhost.com with SMTP; 13 Feb 2004 15:51:34 -0000 Message-Id: <5.2.0.9.2.20040213104954.0485f438@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Feb 2004 10:51:35 -0500 To: , From: Russ Housley Subject: Re: [node req] Question on Security considerations. 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Please take a look at these two documents: draft-ietf-ipsec-ikev2-algorithms-04.txt draft-ietf-ipsec-esp-ah-algorithms-01.txt At 03:07 PM 2/13/2004 +0200, john.loughney@nokia.com wrote: >Hi all, > >The Security AD commented the following: > > > For Section 8, RFCs 2401, 2402, and 2406 are currently being revised by > > the IPsec group; that should be mentioned. > >This is no problem. > > > The crypto algorithm requirements should be better aligned with > > recommendations from the IPsec wg. There's a draft that lists 3DES as > > SHOULD, not MAY. > >Would it be appropriate to mention something like: > > The Security Area RECOMMENDS the use of 3DES. > > > I think that IKEv? should be a SHOULD, not a MAY. While the IESG hasn't > > yet seen draft-bellovin-mandate-keymgmt, it will soon and it describes > > automated key management as a "strong SHOULD". That's certainly the > > consensus in the security area. > >I think that the WG has gone through this several times, and SHOULD has >always seemed problematic for some uses. Does anyone have any suggestions? > > > More generically, I don't think that this WG should standardize weaker > > security requirements than the security area thinks are appropriate, > > without strong justification. (Stronger requirements are fine -- they > > may have a different operational environment, or a different threat > > model.) > >My general comment is that if this document can point to existing RFCs >for the security requirements, then I am happy to mandate whatever >the pointers suggest (hint to the security area, provide pointers and >I will include them). > >thanks, >John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Feb 14 02:08: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 CAA06093 for ; Sat, 14 Feb 2004 02:08:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arttr-0005Z3-E5 for ipv6-archive@odin.ietf.org; Sat, 14 Feb 2004 02:07:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1E77dKl021374 for ipv6-archive@odin.ietf.org; Sat, 14 Feb 2004 02:07:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arttq-0005YE-1d for ipv6-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 02:07: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 CAA05407 for ; Sat, 14 Feb 2004 02:07:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arttm-0006pO-00 for ipv6-web-archive@ietf.org; Sat, 14 Feb 2004 02:07:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Artso-0006lQ-00 for ipv6-web-archive@ietf.org; Sat, 14 Feb 2004 02:06:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arts6-0006hn-00 for ipv6-web-archive@ietf.org; Sat, 14 Feb 2004 02:05:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArtrM-0004Db-HE; Sat, 14 Feb 2004 02:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Artqu-00043Q-Mm for ipv6@optimus.ietf.org; Sat, 14 Feb 2004 02:04:36 -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 CAA01887 for ; Sat, 14 Feb 2004 02:04:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Artqr-0006dy-00 for ipv6@ietf.org; Sat, 14 Feb 2004 02:04:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Artpx-0006ai-00 for ipv6@ietf.org; Sat, 14 Feb 2004 02:03:37 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1ArtpW-0006X7-00 for ipv6@ietf.org; Sat, 14 Feb 2004 02:03:10 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5993215214; Sat, 14 Feb 2004 16:03:02 +0900 (JST) Date: Sat, 14 Feb 2004 16:03:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Nicholas Carbone , Subject: Re: comment on RFC3542 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 Sun, 30 Nov 2003 15:58:17 +0200 (EET), >>>>> Pekka Savola said: >> And, in fact, the current implementation of the KAME project uses >> uint8_t for the align parameter. >> >> I don't know how to correct this one, though. Obviously, we cannot >> revise the document again just due to this problem. > Well, one could at least report it to: > http://www.rfc-editor.org/cgi-bin/errata.pl (link form the main page) Just FYI: I've reported this issue, and the errata page has just included the correction. > .. but most folks probably don't check that when reading the > specs.. I tend to agree... 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 Feb 14 02:37: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 CAA10818 for ; Sat, 14 Feb 2004 02:37:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AruLt-0004pv-V0 for ipv6-archive@odin.ietf.org; Sat, 14 Feb 2004 02:36:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1E7abQa018592 for ipv6-archive@odin.ietf.org; Sat, 14 Feb 2004 02:36:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AruLt-0004pi-1b for ipv6-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 02:36:37 -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 CAA10812 for ; Sat, 14 Feb 2004 02:36:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AruLp-0000jD-00 for ipv6-web-archive@ietf.org; Sat, 14 Feb 2004 02:36:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AruKs-0000fG-00 for ipv6-web-archive@ietf.org; Sat, 14 Feb 2004 02:35:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AruKa-0000bo-00 for ipv6-web-archive@ietf.org; Sat, 14 Feb 2004 02:35:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AruKM-0004Vs-SP; Sat, 14 Feb 2004 02:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AruJt-0004U6-J4 for ipv6@optimus.ietf.org; Sat, 14 Feb 2004 02:34:33 -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 CAA10688 for ; Sat, 14 Feb 2004 02:34:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AruJp-0000aQ-00 for ipv6@ietf.org; Sat, 14 Feb 2004 02:34:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AruIv-0000Wz-00 for ipv6@ietf.org; Sat, 14 Feb 2004 02:33:33 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AruIC-0000Tb-00 for ipv6@ietf.org; Sat, 14 Feb 2004 02:32:49 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 851F415214; Sat, 14 Feb 2004 16:32:49 +0900 (JST) Date: Sat, 14 Feb 2004 16:32:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Soliman Hesham Cc: ipv6@ietf.org Subject: Re: [psg.com #246] [2461bisissue 246] Preferred lifetime > valid lifetime In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F04213E@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F04213E@ftmail.lab.flarion.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,SUBJ_HAS_SPACES autolearn=no version=2.60 >>>>> On Fri, 13 Feb 2004 10:55:37 -0500, >>>>> Soliman Hesham said: >> > Preferred Lifetime >> > 32-bit unsigned integer. The length of time in >> > seconds (relative to the time the packet is sent) >> > that addresses generated from the prefix via >> > stateless address autoconfiguration remain >> > preferred [ADDRCONF]. A value of all one bits >> > (0xffffffff) represents infinity. See >> [ADDRCONF]. >> > Note that the value of this field MUST >> NOT exceed >> > the Valid Lifetime field to avoid preferring >> > addresses that are no longer valid. >> >> Let me check: is this your suggested text in rfc2461bis? > => yes Okay, then I'd rather put this requirement in "Router Configuration Variables" (Section 6.2.1). That is, I'd add to the following part AdvPrefixList ... Automatic address configuration [ADDRCONF] defines additional information associated with each the prefixes: ... AdvPreferredLifetime an additional requirement like this: The value MUST not be larger than AdvValidLifetime. Because this issue is particularly for the router behavior. For the host part, it is already pretty clear that host must ignore a prefix if preferred lifetime > valid lifetime. 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 Feb 14 12:54: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 MAA25238 for ; Sat, 14 Feb 2004 12:54:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3zc-0006rf-K3 for ipv6-archive@odin.ietf.org; Sat, 14 Feb 2004 12:54:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EHsGfI026381 for ipv6-archive@odin.ietf.org; Sat, 14 Feb 2004 12:54:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3zc-0006rQ-EM for ipv6-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 12:54:16 -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 MAA25192 for ; Sat, 14 Feb 2004 12:54:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3za-0005HR-00 for ipv6-web-archive@ietf.org; Sat, 14 Feb 2004 12:54:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3yb-0005AH-00 for ipv6-web-archive@ietf.org; Sat, 14 Feb 2004 12:53:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As3y3-00053x-00 for ipv6-web-archive@ietf.org; Sat, 14 Feb 2004 12:52:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3xR-0006Rs-RA; Sat, 14 Feb 2004 12: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 1As3xJ-0006RS-8Y for ipv6@optimus.ietf.org; Sat, 14 Feb 2004 12:51:53 -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 MAA25073 for ; Sat, 14 Feb 2004 12:51:49 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3xH-00050F-00 for ipv6@ietf.org; Sat, 14 Feb 2004 12:51:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3wM-0004x6-00 for ipv6@ietf.org; Sat, 14 Feb 2004 12:50:55 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1As3ve-0004u0-00 for ipv6@ietf.org; Sat, 14 Feb 2004 12:50:10 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1EHo4307520 for ; Sat, 14 Feb 2004 19:50:04 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 14 Feb 2004 19:50:04 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 14 Feb 2004 19:50:04 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 14 Feb 2004 19:50:03 +0200 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: [node req] Question on Security considerations. Date: Sat, 14 Feb 2004 19:50:03 +0200 Message-ID: Thread-Topic: [node req] Question on Security considerations. Thread-Index: AcPyfkFPybbwamstRk2D0yzhwZDGbwApI5wg To: , Cc: X-OriginalArrivalTime: 14 Feb 2004 17:50:03.0711 (UTC) FILETIME=[F983D4F0:01C3F322] 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 Russ, > Please take a look at these two documents: > draft-ietf-ipsec-ikev2-algorithms-04.txt > draft-ietf-ipsec-esp-ah-algorithms-01.txt Thanks for the pointers. These look reasonable to add to the=20 Node Req document. Does anyone have problems with me putting these as requirements in the Security section? John =20 > At 03:07 PM 2/13/2004 +0200, john.loughney@nokia.com wrote: > >Hi all, > > > >The Security AD commented the following: > > > > > For Section 8, RFCs 2401, 2402, and 2406 are currently=20 > being revised by > > > the IPsec group; that should be mentioned. > > > >This is no problem. > > > > > The crypto algorithm requirements should be better aligned with > > > recommendations from the IPsec wg. There's a draft that=20 > lists 3DES as > > > SHOULD, not MAY. > > > >Would it be appropriate to mention something like: > > > > The Security Area RECOMMENDS the use of 3DES. > > > > > I think that IKEv? should be a SHOULD, not a MAY. While=20 > the IESG hasn't > > > yet seen draft-bellovin-mandate-keymgmt, it will soon and=20 > it describes > > > automated key management as a "strong SHOULD". That's=20 > certainly the > > > consensus in the security area. > > > >I think that the WG has gone through this several times, and=20 > SHOULD has > >always seemed problematic for some uses. Does anyone have=20 > any suggestions? > > > > > More generically, I don't think that this WG should=20 > standardize weaker > > > security requirements than the security area thinks are=20 > appropriate, > > > without strong justification. (Stronger requirements are=20 > fine -- they > > > may have a different operational environment, or a=20 > different threat > > > model.) > > > >My general comment is that if this document can point to=20 > existing RFCs > >for the security requirements, then I am happy to mandate whatever > >the pointers suggest (hint to the security area, provide pointers and > >I will include them). > > > >thanks, > >John >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 15 00:07: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 AAA13217 for ; Sun, 15 Feb 2004 00:07:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsEUt-0001qo-9F for ipv6-archive@odin.ietf.org; Sun, 15 Feb 2004 00:07:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F57Fa9007113 for ipv6-archive@odin.ietf.org; Sun, 15 Feb 2004 00:07:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsEUs-0001qU-V9 for ipv6-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 00:07:14 -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 AAA13159 for ; Sun, 15 Feb 2004 00:07:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsEUq-0006ay-00 for ipv6-web-archive@ietf.org; Sun, 15 Feb 2004 00:07:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsETp-0006VE-00 for ipv6-web-archive@ietf.org; Sun, 15 Feb 2004 00:06:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsESv-0006Rl-00 for ipv6-web-archive@ietf.org; Sun, 15 Feb 2004 00:05:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsERl-0001OS-EU; Sun, 15 Feb 2004 00:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsEQx-0001Mp-65 for ipv6@optimus.ietf.org; Sun, 15 Feb 2004 00:03:11 -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 AAA13085 for ; Sun, 15 Feb 2004 00:03:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsEQu-0006Ks-00 for ipv6@ietf.org; Sun, 15 Feb 2004 00:03:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsEQ3-0006IE-00 for ipv6@ietf.org; Sun, 15 Feb 2004 00:02:15 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1AsEP5-0006An-00 for ipv6@ietf.org; Sun, 15 Feb 2004 00:01:15 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id ACF923C8 for ; Sun, 15 Feb 2004 00:00:45 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 15 Feb 2004 00:00:45 -0500 Message-Id: <20040215050045.ACF923C8@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.36% | 21 | 16.44% | 98404 | jinmei@isl.rdc.toshiba.co.jp 11.57% | 14 | 11.26% | 67422 | john.loughney@nokia.com 6.61% | 8 | 8.15% | 48759 | brian@innovationslab.net 6.61% | 8 | 7.18% | 43001 | jari.arkko@kolumbus.fi 6.61% | 8 | 5.16% | 30883 | rt+ipv6-2461bis@rt.psg.com 4.13% | 5 | 4.06% | 24327 | h.soliman@flarion.com 3.31% | 4 | 4.35% | 26018 | ipng-incoming@danlan.com 3.31% | 4 | 3.89% | 23280 | pbarany@qualcomm.com 3.31% | 4 | 3.00% | 17966 | rt+ipv6-2462bis@rt.psg.com 2.48% | 3 | 3.44% | 20565 | mukesh.gupta@nokia.com 2.48% | 3 | 2.69% | 16126 | francis.dupont@enst-bretagne.fr 2.48% | 3 | 2.48% | 14849 | kempf@docomolabs-usa.com 2.48% | 3 | 2.41% | 14415 | msa@burp.tkv.asdf.org 2.48% | 3 | 2.28% | 13658 | pekkas@netcore.fi 2.48% | 3 | 2.27% | 13576 | ot@cisco.com 2.48% | 3 | 1.87% | 11167 | zefram@fysh.org 1.65% | 2 | 1.83% | 10969 | internet-drafts@ietf.org 1.65% | 2 | 1.74% | 10439 | greg.daley@eng.monash.edu.au 1.65% | 2 | 1.69% | 10114 | alain.durand@sun.com 1.65% | 2 | 1.64% | 9813 | sra+ipng@hactrn.net 1.65% | 2 | 1.32% | 7895 | tjc@ecs.soton.ac.uk 1.65% | 2 | 0.99% | 5940 | bob.hinden@nokia.com 0.83% | 1 | 1.11% | 6615 | varada@txc.com 0.83% | 1 | 1.07% | 6396 | osprey67@yahoo.com 0.83% | 1 | 1.01% | 6031 | smb@research.att.com 0.83% | 1 | 0.92% | 5516 | raraghun@cisco.com 0.83% | 1 | 0.83% | 4989 | karim.el-malki@ericsson.com 0.83% | 1 | 0.81% | 4858 | felipe_alfaro@linuxmail.org 0.83% | 1 | 0.78% | 4684 | housley@vigilsec.com 0.83% | 1 | 0.72% | 4315 | michael.hunter@sun.com 0.83% | 1 | 0.70% | 4214 | slblake@torrentnet.com 0.83% | 1 | 0.70% | 4209 | syam@samsung.com 0.83% | 1 | 0.66% | 3951 | bmanning@isi.edu 0.83% | 1 | 0.54% | 3241 | itojun@itojun.org --------+------+--------+----------+------------------------ 100.00% | 121 |100.00% | 598605 | 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 Feb 15 20:53: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 UAA07785 for ; Sun, 15 Feb 2004 20:53:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXwc-0007Sj-Nt for ipv6-archive@odin.ietf.org; Sun, 15 Feb 2004 20:53:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G1rAmr028679 for ipv6-archive@odin.ietf.org; Sun, 15 Feb 2004 20:53:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXwc-0007SU-HV for ipv6-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 20:53:10 -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 UAA07781 for ; Sun, 15 Feb 2004 20:53:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsXwa-0000oV-00 for ipv6-web-archive@ietf.org; Sun, 15 Feb 2004 20:53:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsXve-0000jU-00 for ipv6-web-archive@ietf.org; Sun, 15 Feb 2004 20:52:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsXv8-0000eU-00 for ipv6-web-archive@ietf.org; Sun, 15 Feb 2004 20:51:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXuY-00073B-HA; Sun, 15 Feb 2004 20:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXuP-00072V-TL for ipv6@optimus.ietf.org; Sun, 15 Feb 2004 20:50:54 -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 UAA07689 for ; Sun, 15 Feb 2004 20:50:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsXuN-0000cj-00 for ipv6@ietf.org; Sun, 15 Feb 2004 20:50:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsXtU-0000Zd-00 for ipv6@ietf.org; Sun, 15 Feb 2004 20:49:56 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1AsXtA-0000WU-00 for ipv6@ietf.org; Sun, 15 Feb 2004 20:49:36 -0500 Received: from localhost ([130.194.13.84]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L6O31ZABAI8X3BAU@vaxh.its.monash.edu.au> for ipv6@ietf.org; Mon, 16 Feb 2004 11:55:48 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id E65D239C00D; Mon, 16 Feb 2004 11:55:46 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id B32012DC010; Mon, 16 Feb 2004 11:55:46 +1100 (EST) Date: Mon, 16 Feb 2004 11:55:46 +1100 From: Greg Daley Subject: Re: rfc2462bis -- loopback suppression To: Ole Troan Cc: Michael Hunter , =?ISO-8859-1?Q?JINMEI_Tatu?= =?ISO-8859-1?Q?ya_/_=BF=C0=CC=C0=C3=A3=BA=C8?= , ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <40301512.9070707@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <7t5d68lkvn8.fsf@mrwint.cisco.com> <20040212120940.0a67e23b.michael.hunter@eng.sun.com> <7t5hdxwhwym.fsf@mrwint.cisco.com> <402C0E53.2020008@eng.monash.edu.au> <7t5y8r7fcax.fsf@mrwint.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 Hi Ole, Ole Troan wrote: > Greg, > > >>>>This essentially the problem with DAD on wifi, right? That should >>>>make a general solution more interesting then just a corner case. >>> >>>no, this is a general problem. I've seen this on Ethernet. >>>I've spoken to the DAD/WIFI draft owners and we've agreed to add the >>>id option to that draft and rename it to something less wifi specific. >> >>SEND has already defined a random Nonce option for >>Neighbour Solicitation messages. >> >>Also defined are Timestamp options for these messages. >> >>Send requires both of these to be present in a DAD-NS. >> >>In this case, a node can keep track of (only) its fresh Nonces, >>and it will be able to check if received DAD NS's are >>its own. >> >>These options would even be able to be used in non-SEND >>solicitations under the constraint that there's no trust >>associated with them (since they're not signed messages). >> >>There's no further identifier definition required (although >>it would be valuable to write a short draft on it). > > > thanks for pointing out the SEND draft to me, I haven't followed that > work for a while. > > yes, it seems that the Nonce option should work. a SEND node receiving > these would interpret this message as a unsecured message as long as > there is no trust association, right? if there is a trust association > the message would be silently discarded. I believe that the messages aren't interpreted as 'secured' unless they have a valid signature. (the key used to verify the signature is often included in the SEND message). For DAD-NS/NA messages though, there's likely to be no existing relationship between the configuring node and a receiver. The SEND message in and of itself typically provides enough information to prove its ownership of a public key (and thus an address if CGA is used). This doesn't actually mean that unsecured DAD messages get silently discarded though. For the first DAD attempt, SEND actually allows unsecured NA's to indicate address duplication (though subsequent address configurations only listen to SEND). > agree, that a short draft on how non-SEND nodes can use these options > is needed. The shorter, the better... Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 16 01:55: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 BAA16810 for ; Mon, 16 Feb 2004 01:55: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 1Ascem-0005mS-EL for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 01:55:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G6t4xR022209 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 01:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ascel-0005m8-7d for ipv6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 01:55:03 -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 BAA16801 for ; Mon, 16 Feb 2004 01:55:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asceh-0002WE-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 01:55:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ascdo-0002TY-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 01:54:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AscdP-0002Qi-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 01:53:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ascco-0005S2-HO; Mon, 16 Feb 2004 01:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ascbr-0005RK-0i for ipv6@optimus.ietf.org; Mon, 16 Feb 2004 01:52:03 -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 BAA16680 for ; Mon, 16 Feb 2004 01:52:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ascbn-0002MD-00 for ipv6@ietf.org; Mon, 16 Feb 2004 01:51:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ascaq-0002JV-00 for ipv6@ietf.org; Mon, 16 Feb 2004 01:51:00 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1AscaC-0002HL-00 for ipv6@ietf.org; Mon, 16 Feb 2004 01:50:20 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel8.hp.com (Postfix) with ESMTP id 99DCB1C022A7; Mon, 16 Feb 2004 01:50:17 -0500 (EST) Received: from NT23057 (nt23057.india.hp.com [15.42.230.57]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i1G6IcZ20358; Mon, 16 Feb 2004 11:48:40 +0530 (IST) Reply-To: From: "Anil Kumar Reddy" To: "'srihari varada'" , Cc: "'Brian Haberman'" , "'Bob Hinden'" , "'Alex Conta'" , Subject: RE: updates to IPv6 over PPP spec. Date: Mon, 16 Feb 2004 12:20:00 +0530 Message-ID: <005801c3f459$1d7799f0$39e62a0f@NT23057> 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 V6.00.2800.1165 Importance: Normal In-Reply-To: <402A9BE7.4040406@txc.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 : : 4. RA (Route Advertisement) should be mentioned somewhere in : the Document for global unicast address configuration and other : configuration parameters. In IPCP, the IP address is part of : the IPCP. : But in IPv6CP, only the interface ID is negotiated and link local is : auto-configured. For a new comer, it took us a while to : figure out that : RA is used to configure the rest of stuff. : Yes, we should provide a generic statement on obtaining global unicast address using either stateless (RA) or stateful (DHCPv6) auto-configuration and mention that it is out of ppp scope. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 16 06:43: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 GAA12448 for ; Mon, 16 Feb 2004 06:43:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ash9f-0007OE-6k for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 06:43:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GBhFdQ028400 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 06:43:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ash9e-0007Nz-WC for ipv6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 06:43:15 -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 GAA12433 for ; Mon, 16 Feb 2004 06:43:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ash9a-0005Hs-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 06:43:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ash8g-0005Ew-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 06:42:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ash81-0005CK-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 06:41:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ash7W-000759-Dl; Mon, 16 Feb 2004 06:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asa0I-0005gI-EG for ipv6@optimus.ietf.org; Sun, 15 Feb 2004 23:05: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 XAA12105 for ; Sun, 15 Feb 2004 23:05:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asa0D-00016J-00 for ipv6@ietf.org; Sun, 15 Feb 2004 23:05:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsZzD-00013h-00 for ipv6@ietf.org; Sun, 15 Feb 2004 23:04:00 -0500 Received: from 94.180.32.202.ts.2iij.net ([202.32.180.94] helo=mail.64translator.com) by ietf-mx with esmtp (Exim 4.12) id 1AsZyG-0000z0-00 for ipv6@ietf.org; Sun, 15 Feb 2004 23:03:00 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.6p3/8.12.6) with ESMTP id i1G42O40049694 for ; Mon, 16 Feb 2004 13:02:24 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Received: from localhost (dhcp166.64translator.com [10.21.32.166]) by bahamas.64translator.com (8.12.9p2/8.12.9) with SMTP id i1G42JAv053254 for ; Mon, 16 Feb 2004 13:02:19 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Date: Mon, 16 Feb 2004 13:02:19 +0900 From: Yukiyo Akisada To: ipv6@ietf.org Subject: RFC2461: be more clearer about TLL option in NA Message-Id: <20040216130219.0b000c1f.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i386-portbld-freebsd4.7) 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, all. RFC2461 says TLL option SHOULD be requires in NA while responding to unicast NS. 4.4. Neighbor Advertisement Message Format ---------------------------------------------------------------- 1351 Possible options: 1352 1353 Target link-layer address 1354 The link-layer address for the target, i.e., the 1355 sender of the advertisement. This option MUST be 1356 included on link layers that have addresses when 1357 responding to multicast solicitations. When 1358 responding to a unicast Neighbor Solicitation this 1359 option SHOULD be included. but RFC2461 also says 'MAY' be omitted. 7.2.4. Sending Solicited Neighbor Advertisements ---------------------------------------------------------------- 3387 If the solicitation's IP Destination Address is 3388 not a multicast address, the Target Link-Layer Address option MAY be 3389 omitted; the neighboring node's cached value must already be current 3390 in order for the solicitation to have been received. It isn't contradiction, but it is unclear. The former seems that it disallows omission of TLL option, and the latter seems that it allows omission. I think 2461bis can be more clear about this option. Regards. ---- Yukiyo Akisada -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 16 07:10: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 HAA13446 for ; Mon, 16 Feb 2004 07:10:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshZl-00010T-8D for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 07:10:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GCADQq003866 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 07:10:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshZl-00010H-11 for ipv6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 07:10:13 -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 HAA13390 for ; Mon, 16 Feb 2004 07:10:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AshZg-0006qS-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 07:10:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AshYj-0006kh-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 07:09:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AshXo-0006fR-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 07:08:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshXe-0000TE-UV; Mon, 16 Feb 2004 07:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshWs-0000Gs-O0 for ipv6@optimus.ietf.org; Mon, 16 Feb 2004 07:07:14 -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 HAA13197 for ; Mon, 16 Feb 2004 07:07:10 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AshWo-0006Zv-00 for ipv6@ietf.org; Mon, 16 Feb 2004 07:07:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AshVy-0006WG-00 for ipv6@ietf.org; Mon, 16 Feb 2004 07:06:18 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AshVH-0006Sx-00 for ipv6@ietf.org; Mon, 16 Feb 2004 07:05:35 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1GC5Z314343 for ; Mon, 16 Feb 2004 14:05:35 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 16 Feb 2004 14:05:35 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Feb 2004 14:05:35 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Feb 2004 14:05:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Updated Node Requirements Date: Mon, 16 Feb 2004 14:05:34 +0200 Message-ID: Thread-Topic: updates to IPv6 over PPP spec. Thread-Index: AcP0WaTJlIMdIcuURMqbIAsHAmrsqgAKzBXA To: X-OriginalArrivalTime: 16 Feb 2004 12:05:35.0094 (UTC) FILETIME=[2EE2A960:01C3F485] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I have submitted the updated Node Requirements draft, based upon the set of issues raised by the IESG. While in the queue for publication, a copy can be found here: http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-08.txt The issue tracker can be found here (in sorted order): http://danforsberg.info:8080/draft-ietf-ipv6-node-requirements/issue?%3Ac= olumns=3Dtitle%2Ccategory%2Cid%2Ccreation%2Ccreator%2Cpriority%2Cstatus%2= Cassignedto&%3Apagesize=3D50&%3Astartwith=3D0&%3Asort=3Dcreation&%3Agroup= =3Ddocument&%3Agroupdir=3Don thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 16 07:34: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 HAA14044 for ; Mon, 16 Feb 2004 07:34:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ashx3-0002SZ-16 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 07:34:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GCYGLi009454 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 07:34:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ashx2-0002SP-Qx for ipv6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 07:34:16 -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 HAA14006 for ; Mon, 16 Feb 2004 07:34:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ashx2-0000OU-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 07:34:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ashw3-0000Jt-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 07:33:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ashv5-0000G2-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 07:32:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ashut-0001zE-F4; Mon, 16 Feb 2004 07:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ashu6-0001yH-U8 for ipv6@optimus.ietf.org; Mon, 16 Feb 2004 07:31:14 -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 HAA13915 for ; Mon, 16 Feb 2004 07:31:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ashu6-0000Cl-00 for ipv6@ietf.org; Mon, 16 Feb 2004 07:31:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asht8-0000AB-00 for ipv6@ietf.org; Mon, 16 Feb 2004 07:30:15 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Ashsj-00007p-00 for ipv6@ietf.org; Mon, 16 Feb 2004 07:29:49 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGXGCN>; Mon, 16 Feb 2004 07:29:28 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04215F@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Yukiyo Akisada'" , ipv6@ietf.org Subject: RE: RFC2461: be more clearer about TLL option in NA Date: Mon, 16 Feb 2004 07:29:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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 Thanks, unfortunately I already submitted the draft but I'll create a new issue for it. Hesham > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of > Yukiyo Akisada > Sent: Sunday, February 15, 2004 11:02 PM > To: ipv6@ietf.org > Subject: RFC2461: be more clearer about TLL option in NA > > > Hi, all. > > RFC2461 says TLL option SHOULD be requires in NA while > responding to unicast NS. > > 4.4. Neighbor Advertisement Message Format > ---------------------------------------------------------------- > 1351 Possible options: > 1352 > 1353 Target link-layer address > 1354 The link-layer address for > the target, i.e., the > 1355 sender of the > advertisement. This option MUST be > 1356 included on link layers > that have addresses when > 1357 responding to multicast > solicitations. When > 1358 responding to a unicast > Neighbor Solicitation this > 1359 option SHOULD be included. > > but RFC2461 also says 'MAY' be omitted. > > 7.2.4. Sending Solicited Neighbor Advertisements > ---------------------------------------------------------------- > 3387 If the solicitation's > IP Destination Address is > 3388 not a multicast address, the Target > Link-Layer Address option MAY be > 3389 omitted; the neighboring node's cached value > must already be current > 3390 in order for the solicitation to have been received. > > It isn't contradiction, but it is unclear. > > The former seems that it disallows omission of TLL option, > and the latter seems that it allows omission. > > I think 2461bis can be more clear about this option. > > Regards. > > > ---- > Yukiyo Akisada > > -------------------------------------------------------------------- > 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 Feb 16 10:40: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 KAA26036 for ; Mon, 16 Feb 2004 10:40: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 1AskrA-00079b-3C for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 10:40:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GFeODV027497 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 10:40:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askr9-00079Q-Nd for ipv6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 10:40: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 KAA25980 for ; Mon, 16 Feb 2004 10:40:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Askr7-0005EP-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 10:40:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AskqC-00059i-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 10:39:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Askpr-00056q-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 10:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askn8-00064o-EI; Mon, 16 Feb 2004 10:36:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskmL-0005du-A6 for ipv6@optimus.ietf.org; Mon, 16 Feb 2004 10:35:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25591; Mon, 16 Feb 2004 10:35:19 -0500 (EST) Message-Id: <200402161535.KAA25591@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2011-update-07.txt Date: Mon, 16 Feb 2004 10:35:19 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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,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-07.txt Pages : 133 Date : 2004-2-11 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-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-07.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-07.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-2-16105956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2011-update-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2011-update-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16105956.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 16 11:21: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 LAA00336 for ; Mon, 16 Feb 2004 11:20:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslTz-0002Nm-GY for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 11:20:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GGKV2l009152 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 11:20:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslTy-0002NX-O2 for ipv6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 11:20:30 -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 LAA00290 for ; Mon, 16 Feb 2004 11:20:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AslTx-0002pN-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 11:20:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AslR3-0002K1-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 11:17:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AslQ0-00028M-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 11:16:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AslPy-0007gG-NV for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 11:16:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslPe-0001yP-QB; Mon, 16 Feb 2004 11:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslPE-0001xG-TD for ipv6@optimus.ietf.org; Mon, 16 Feb 2004 11:15:36 -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 LAA29875 for ; Mon, 16 Feb 2004 11:15:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AslPD-00023F-00 for ipv6@ietf.org; Mon, 16 Feb 2004 11:15:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AslO5-0001xJ-00 for ipv6@ietf.org; Mon, 16 Feb 2004 11:14:26 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AslNI-0001tQ-00 for ipv6@ietf.org; Mon, 16 Feb 2004 11:13:36 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0932015214 for ; Tue, 17 Feb 2004 01:13:36 +0900 (JST) Date: Tue, 17 Feb 2004 01:13:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: responses to comments on the scope-arch document 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,HTML_MESSAGE autolearn=no version=2.60 Just FYI, here is a summary of the resolutions for comments on the scope-arch document, to make it sure that none of them was missed. But I may have still missed something, in which case please point it out. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp ============ Comments from Juergen Schoenwaelder a) I think it would be helpful if the document would refer to . => added the reference. b) Is there a particular reason why we can not just say that the default zone is indicated by a zone index which MUST (or SHOULD if we have to compromise) be zero? => made it a SHOULD. ============ Comments from Pekka Savola: 1) the number of authors is too many (6). => changed the organization of authors to meet the requirement 2) there is some really, really weird text in section 4 about address scopes: ...that is, there are no "IPv4 auto-configuration" addresses. => adopted the suggested change 3) I think this statement in section 5 needs to be spelled out a bit more: Each interface belongs to exactly one zone of each possible scope. => revised the text (which was agreed in the ML) 4) I'm not sure whether I see the immediate need for the unique subnet multicast scope assignment, as below: => removed "subnet-local" (note: this notion has already been removed from the base addr-arch spec) 5) In the section 7, "sending packets", IMHO it would be useful to actually describe the process of how the outgoing interface is identified, => do not change anything on this (the issue is addressed in the original text) 6) In the section 9, "Forwarding", I think the text about picking the destination address zone could be enhanced a bit: => do not change anything on this (this decision was accepted in a discussion on the ML) 7) In the section 9, "Forwarding", the second rule about sending an ICMP DU is specified. Has it already been considered whether this applies to multicast destination addresses as well? => clarified this point in the text. 8) multicast routing in section 10 is rather weak. => revised the text to address this. 9) I think the EBGP peering example should be removed from section 11.4. => removed the example. 10) Similar bad ideas are described in section 11.7, about how to use IPv6 addresses in URL's. => adopted the suggested change. 11) Note that there is a normative reference to the ICMPv6-bis document, which has been pretty much stalled for the last 2 years or so. => addressed by referring to the old RFC with additional notes. editorial --------- When an implementation interprets the format, it should construct the "full" zone ID, which contains the scope type, from the part and the scope type specified by the
part. unless I have completely misunderstood the spec, the first "scope type" should actually be "scope zone" :-) => addressed this by referring to section 6. All other editorial comments were addressed in a straightforward way. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 16 11:21: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 LAA00425 for ; Mon, 16 Feb 2004 11:21:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslUN-0002Ok-R5 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 11:20:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GGKt76009210 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 11:20:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslUM-0002OT-DZ for ipv6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 11:20:54 -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 LAA00327 for ; Mon, 16 Feb 2004 11:20:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AslUL-0002tW-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 11:20:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AslRO-0002N8-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 11:17:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AslQA-00028M-01 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 11:16:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AslIL-0007V4-Hg for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 11:08:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslHu-0001B1-MQ; Mon, 16 Feb 2004 11:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslHi-00016v-EW for ipv6@optimus.ietf.org; Mon, 16 Feb 2004 11:07:50 -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 LAA28804 for ; Mon, 16 Feb 2004 11:07:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AslHf-000120-00 for ipv6@ietf.org; Mon, 16 Feb 2004 11:07:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AslFd-0000c7-00 for ipv6@ietf.org; Mon, 16 Feb 2004 11:05:42 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AslDe-0000A5-00 for ipv6@ietf.org; Mon, 16 Feb 2004 11:03:39 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 20DF115210 for ; Tue, 17 Feb 2004 01:03:29 +0900 (JST) Date: Tue, 17 Feb 2004 01:03:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: a new revision of the scoping-arch draft 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 you may have noticed, a new revision of draft-ietf-ipv6-scoping-arch is now available. Major changes in this revision, which are basically responses to the comments for the wg last call, are as follows: - specified that zone ID zero SHOULD be reserved for the default zone. - referred to section 6 when explaining the interpretation of the part of the % notation. (to explain when zone ID contains the information of scope) - clarified that the beyond-scope ICMP error is only sent against unicast packets. - changed the reference for ICMPv6 from an I-D to the old RFC to resolve the dependency issue. added a note about this accordingly. - removed the notion of subnet-local (multicast scope) according to the latest base address architecture. - revised the last sentence of section 5 to make it clear that an interface belongs to a scope zone regardless of what kind of unicast address the interface has or of which multicast groups the node joins on the interface. - removed the EBGP peering example from Section 11.4. - used multicast "group" instead of "prefix". - referred to draft-ietf-ipv6-deprecate-site-local-02.txt - added a contributors section and re-organized the author list to meet the guideline from the RFC editor. - moved RFC 3493 to informative reference, and added a reference to the scope API I-D (expired, though). noted the API support is a future extension. I believe I've addressed all the issues raised so far in this revision, and the document is now ready to be sent to the IESG. If I miss something, please let me know. 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 Mon Feb 16 15:43: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 PAA20548 for ; Mon, 16 Feb 2004 15:43:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspZg-0003M3-Dw for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 15:42:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKgeA6012889 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 15:42:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspZg-0003Lo-8v for ipv6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 15:42:40 -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 PAA20432 for ; Mon, 16 Feb 2004 15:42:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspZe-0002eg-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 15:42:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspYh-0002W6-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 15:41:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AspXp-0002QA-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 15:40:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspX9-000260-3Y; Mon, 16 Feb 2004 15:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspWR-0001uH-W0 for ipv6@optimus.ietf.org; Mon, 16 Feb 2004 15:39:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19711; Mon, 16 Feb 2004 15:39:17 -0500 (EST) Message-Id: <200402162039.PAA19711@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-icmp-v3-03.txt Date: Mon, 16 Feb 2004 15:39:17 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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,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 : Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-v3-03.txt Pages : 23 Date : 2004-2-16 This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipngwg-icmp-v3-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-ipngwg-icmp-v3-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-2-16122854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-v3-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16122854.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 Feb 18 16:27:05 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 QAA22428 for ; Wed, 18 Feb 2004 16:27:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZDJ-00085o-Bl for ipv6-archive@odin.ietf.org; Wed, 18 Feb 2004 16:26:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ILQbeQ031107 for ipv6-archive@odin.ietf.org; Wed, 18 Feb 2004 16:26:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZDJ-00085e-6u for ipv6-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 16:26:37 -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 QAA22406 for ; Wed, 18 Feb 2004 16:26:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZDH-0001fM-00 for ipv6-web-archive@ietf.org; Wed, 18 Feb 2004 16:26:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZCP-0001dO-00 for ipv6-web-archive@ietf.org; Wed, 18 Feb 2004 16:25:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtZBj-0001bZ-00 for ipv6-web-archive@ietf.org; Wed, 18 Feb 2004 16:24:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZAo-0007Yc-2I; Wed, 18 Feb 2004 16:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYKD-0000Nv-L2 for ipv6@optimus.ietf.org; Wed, 18 Feb 2004 15:29:41 -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 PAA18047 for ; Wed, 18 Feb 2004 15:29:39 -0500 (EST) From: Mark_Andrews@isc.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtYKC-0004So-00 for ipv6@ietf.org; Wed, 18 Feb 2004 15:29:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtYIo-0004FX-00 for ipv6@ietf.org; Wed, 18 Feb 2004 15:28:15 -0500 Received: from farside.isc.org ([204.152.187.5]) by ietf-mx with esmtp (Exim 4.12) id 1AtYHZ-0003ur-00 for ipv6@ietf.org; Wed, 18 Feb 2004 15:26:57 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 096A6A829 for ; Wed, 18 Feb 2004 20:26:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i1IKQO3S059354 for ; Thu, 19 Feb 2004 07:26:24 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200402182026.i1IKQO3S059354@drugs.dv.isc.org> Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-node-requirements-08.txt In-reply-to: Your message of "Wed, 18 Feb 2004 09:58:49 CDT." <200402181458.JAA15586@ietf.org> Date: Thu, 19 Feb 2004 07:26:24 +1100 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 "Those nodes are NOT RECOMMENDED to support the experimental A6 and DNAME Resource Records [RFC-3363]." I object to recommending that DNAME's not be supported. RFC 3363 does NOT say that. It says that they shouldn't be use in the reverse tree for RENUMBERING purposes. Even then the logic to get to that decision is DUBIOUS at best. If RFC 3363 was ever to be revised I would be pushing for the entire section on DNAME to be removed. We really should not be saying were in the DNS tree DNAME can be used. RFC 3363 most definitly does not recommend that DNAMES be not supported. I really suspect that we will want to use DNAME for renumbering even without A6 and bit-string labels. Trying to get multiple levels of delegation updated quickly is a pain. Just look at the problems we are having going from IP6.INT to IP6.ARPA. Do we want this pain level with every renumber event. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 18 20:27: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 UAA05989 for ; Wed, 18 Feb 2004 20:27:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atcxi-0002Mo-GT for ipv6-archive@odin.ietf.org; Wed, 18 Feb 2004 20:26:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J1Qklg009092 for ipv6-archive@odin.ietf.org; Wed, 18 Feb 2004 20:26:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atcxi-0002MZ-8h for ipv6-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 20:26:46 -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 UAA05979 for ; Wed, 18 Feb 2004 20:26:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atcxg-0007UC-00 for ipv6-web-archive@ietf.org; Wed, 18 Feb 2004 20:26:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atcwl-0007ST-00 for ipv6-web-archive@ietf.org; Wed, 18 Feb 2004 20:25:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atcwa-0007Qm-00 for ipv6-web-archive@ietf.org; Wed, 18 Feb 2004 20:25:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atcw3-00024O-Qs; Wed, 18 Feb 2004 20: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 1Atcvl-00023f-57 for ipv6@optimus.ietf.org; Wed, 18 Feb 2004 20:24: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 UAA05926 for ; Wed, 18 Feb 2004 20:24:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atcvj-0007Pp-00 for ipv6@ietf.org; Wed, 18 Feb 2004 20:24:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atcur-0007OG-00 for ipv6@ietf.org; Wed, 18 Feb 2004 20:23:50 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AtcuW-0007Ju-00; Wed, 18 Feb 2004 20:23:29 -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 i1J1MtL28236; Wed, 18 Feb 2004 17:22:55 -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 i1J1Y6lN013000 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 18 Feb 2004 17:34:15 -0800 Message-ID: <40340FCD.9070609@innovationslab.net> Date: Wed, 18 Feb 2004 20:22:21 -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: The IESG , Margaret Wasserman , Thomas Narten CC: IPv6 Mailing List Subject: Request To Advance : "Unique Local IPv6 Unicast Addresses" 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 & Thomas, On behalf of the IPv6 working group, the chairs request the advancement of: Title : Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-unique-local-addr-03.txt Pages : 16 Date : 2004-2-13 as a Proposed Standard. The -02 version completed working group last call on 02/02/2004. This version addresses issues raised during the last call period. Regards, Brian & Bob IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 19 00:12: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 AAA13601 for ; Thu, 19 Feb 2004 00:12:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgTg-0004t4-DS for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 00:12:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J5C00Y018780 for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 00:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgTg-0004sp-86 for ipv6-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 00:12:00 -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 AAA13598 for ; Thu, 19 Feb 2004 00:11:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtgTd-0002Ko-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 00:11:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtgSg-0002I7-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 00:10:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtgS9-0002FZ-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 00:10:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgRo-0004a1-Ad; Thu, 19 Feb 2004 00:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgRj-0004Z2-7e for ipv6@optimus.ietf.org; Thu, 19 Feb 2004 00:09:59 -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 AAA13524 for ; Thu, 19 Feb 2004 00:09:55 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtgRg-0002Ei-00 for ipv6@ietf.org; Thu, 19 Feb 2004 00:09:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtgQk-0002Bq-00 for ipv6@ietf.org; Thu, 19 Feb 2004 00:08:58 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AtgPx-00029G-00 for ipv6@ietf.org; Thu, 19 Feb 2004 00:08:09 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1J587K09956; Thu, 19 Feb 2004 07:08:07 +0200 (EET) X-Scanned: Thu, 19 Feb 2004 07:08:03 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i1J583kF007617; Thu, 19 Feb 2004 07:08:03 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 006xvpTF; Thu, 19 Feb 2004 07:08:03 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1J582711340; Thu, 19 Feb 2004 07:08:02 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 19 Feb 2004 07:08:02 +0200 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: I-D ACTION:draft-ietf-ipv6-node-requirements-08.txt Date: Thu, 19 Feb 2004 07:08:01 +0200 Message-ID: Thread-Topic: I-D ACTION:draft-ietf-ipv6-node-requirements-08.txt Thread-Index: AcP2ZdhckLz0JJBUSJeFYvz+Sa9OmQAP+5Mg To: Cc: X-OriginalArrivalTime: 19 Feb 2004 05:08:02.0649 (UTC) FILETIME=[59B42C90:01C3F6A6] 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 Mark, > "Those nodes are NOT RECOMMENDED to support the experimental A6 and > DNAME Resource Records [RFC-3363]." >=20 > I object to recommending that DNAME's not be supported. RFC > 3363 does NOT say that. It says that they shouldn't be use > in the reverse tree for RENUMBERING purposes. Even then the > logic to get to that decision is DUBIOUS at best. >=20 > If RFC 3363 was ever to be revised I would be pushing for the > entire section on DNAME to be removed. We really should not > be saying were in the DNS tree DNAME can be used. >=20 > RFC 3363 most definitly does not recommend that DNAMES be not > supported. So, what should the document say? The Node Requirements doc shouldn't update RFC-3363, so that would be another issue. 3363 does say: The issues for DNAME in the reverse mapping tree appears to be closely tied to the need to use fragmented A6 in the main tree: if one is necessary, so is the other, and if one isn't necessary, the other isn't either. Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated. How about: "Those nodes are NOT RECOMMENDED to support the experimental A6=20 Resource Records [RFC-3363]. Usage of DNAME Reseource Records in the reverse tree is deprecated." John =20 > I really suspect that we will want to use DNAME for renumbering > even without A6 and bit-string labels. Trying to get > multiple levels of delegation updated quickly is a pain. > Just look at the problems we are having going from IP6.INT > to IP6.ARPA. Do we want this pain level with every renumber > event. >=20 > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 19 00:58: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 AAA15457 for ; Thu, 19 Feb 2004 00:58:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AthC7-0007sa-QA for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 00:57:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J5vt9Z030282 for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 00:57:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AthC7-0007sL-Jn for ipv6-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 00:57:55 -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 AAA15431 for ; Thu, 19 Feb 2004 00:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AthC4-0004dm-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 00:57:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AthB7-0004bG-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 00:56:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AthAR-0004ZR-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 00:56:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AthAJ-0007VF-CU; Thu, 19 Feb 2004 00:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AthAE-0007Ub-37 for ipv6@optimus.ietf.org; Thu, 19 Feb 2004 00:55:58 -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 AAA15384 for ; Thu, 19 Feb 2004 00:55:54 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AthAB-0004Z2-00 for ipv6@ietf.org; Thu, 19 Feb 2004 00:55:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ath9H-0004XQ-00 for ipv6@ietf.org; Thu, 19 Feb 2004 00:54:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ath8p-0004Vb-00 for ipv6@ietf.org; Thu, 19 Feb 2004 00:54:31 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1J5sVK16907; Thu, 19 Feb 2004 07:54:31 +0200 (EET) X-Scanned: Thu, 19 Feb 2004 07:54:27 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i1J5sRhq002200; Thu, 19 Feb 2004 07:54:27 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00l4PmXx; Thu, 19 Feb 2004 07:54:25 EET 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 i1J5sP701286; Thu, 19 Feb 2004 07:54:25 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 19 Feb 2004 07:54:23 +0200 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: I-D ACTION:draft-ietf-ipv6-node-requirements-08.txt Date: Thu, 19 Feb 2004 07:54:24 +0200 Message-ID: Thread-Topic: I-D ACTION:draft-ietf-ipv6-node-requirements-08.txt Thread-Index: AcP2qgWVnYNB2nagR9uEHBYLmEHTDQAArNOA To: Cc: X-OriginalArrivalTime: 19 Feb 2004 05:54:23.0284 (UTC) FILETIME=[D3176740:01C3F6AC] 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 Mark, > > "Those nodes are NOT RECOMMENDED to support the experimental A6=20 > > Resource Records [RFC-3363]. Usage of DNAME Reseource Records = in > > the reverse tree is deprecated." > > > > John=20 >=20 > Just don't mention DNAME at all. Note DNAME support will > be manditory with DNSSEC so the only issue is whether we > discourage the use under IP6.ARPA which I (and lots of others > in dnsext) now believe we got wrong. >=20 > "Those nodes are NOT RECOMMENDED to support the experimental A6 > Resource Records [RFC-3363]." That would be OK with me. Any other opinions? 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 Feb 19 03:57: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 DAA06180 for ; Thu, 19 Feb 2004 03:57:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtjzX-0005Lt-Uk for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 03:57:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J8v7cU020563 for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 03:57:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtjzX-0005La-Jy for ipv6-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 03:57:07 -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 DAA06158 for ; Thu, 19 Feb 2004 03:57:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtjzV-0005uN-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 03:57:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtjyY-0005qo-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 03:56:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atjxt-0005nt-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 03:55:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtjxY-0004tI-8u; Thu, 19 Feb 2004 03:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtjwV-0004m2-FG for ipv6@optimus.ietf.org; Thu, 19 Feb 2004 03:53:59 -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 DAA06001 for ; Thu, 19 Feb 2004 03:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtjwS-0005j9-00 for ipv6@ietf.org; Thu, 19 Feb 2004 03:53:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atjvd-0005hl-00 for ipv6@ietf.org; Thu, 19 Feb 2004 03:53:06 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AtjvE-0005fS-00 for ipv6@ietf.org; Thu, 19 Feb 2004 03:52:41 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 1C20370055E; Thu, 19 Feb 2004 19:52:28 +1100 (EST) Date: Thu, 19 Feb 2004 19:52:28 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Subject: Optimistic DAD _again!_ Message-ID: <20040219085228.GA22803@zoic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL autolearn=no version=2.60 Hi IPv6ers, You might recall some time ago I stirred up some interest in my Optimistic DAD draft, which seeks to eliminate DAD delay without significantly increasing the risk involved in address collision. In the meantime it's picked up a couple of independant implementations[1] and a couple of conference publications[2]. It was debated fairly thoroughly in MobileIP WG, (I presented the idea to the WG in San Francisco[3]) but has since been judged to be outside the scope of that group, as it is applies to any situation needing fast address configuration, not just MobileIP. IPv6 WG seems the proper place for it to be developed further, and I'd like to open it up for debate here with the aim of moving it towards standardization. The latest version is: ... and it's _still_ only 13 pages long. Please let me know what you think ... and if there's enough interest maybe we can discuss it further at Seoul. -----Nick 'sharkey' Moore. [1] One by our team at Monash, one by Ed Remmel of Elmic Systems [2] See for refs ... [3] ... and for slides from these presentations. -- Nick Moore, Resarch Fellow | Monash University CTIE | Australian Telecommunications CRC | -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 19 06:04: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 GAA13940 for ; Thu, 19 Feb 2004 06:04: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 1AtlyP-0007Cn-1f for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 06:04:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JB45ws027691 for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 06:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtlyO-0007CY-Rb for ipv6-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 06:04: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 GAA13918 for ; Thu, 19 Feb 2004 06:04:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtlyL-0005s4-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 06:04:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtlxR-0005pL-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 06:03:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atlwp-0005nH-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 06:02:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtlwQ-0006s3-OK; Thu, 19 Feb 2004 06:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atgpp-0006GC-JY for ipv6@optimus.ietf.org; Thu, 19 Feb 2004 00:34:53 -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 AAA14928 for ; Thu, 19 Feb 2004 00:34:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atgpn-0003s2-00 for ipv6@ietf.org; Thu, 19 Feb 2004 00:34:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atgox-0003qM-00 for ipv6@ietf.org; Thu, 19 Feb 2004 00:34:00 -0500 Received: from farside.isc.org ([204.152.187.5]) by ietf-mx with esmtp (Exim 4.12) id 1Atgo9-0003lk-00 for ipv6@ietf.org; Thu, 19 Feb 2004 00:33:09 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id C0A15A829 for ; Thu, 19 Feb 2004 05:32:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i1J5WX3S066757; Thu, 19 Feb 2004 16:32:34 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200402190532.i1J5WX3S066757@drugs.dv.isc.org> To: john.loughney@nokia.com Cc: ipv6@ietf.org From: Mark Andrews Subject: Re: I-D ACTION:draft-ietf-ipv6-node-requirements-08.txt In-reply-to: Your message of "Thu, 19 Feb 2004 07:08:01 +0200." Date: Thu, 19 Feb 2004 16:32:33 +1100 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 > Mark, > > > > "Those nodes are NOT RECOMMENDED to support the experimental A6 and > > DNAME Resource Records [RFC-3363]." > > > > I object to recommending that DNAME's not be supported. RFC > > 3363 does NOT say that. It says that they shouldn't be use > > in the reverse tree for RENUMBERING purposes. Even then the > > logic to get to that decision is DUBIOUS at best. > > > > If RFC 3363 was ever to be revised I would be pushing for the > > entire section on DNAME to be removed. We really should not > > be saying were in the DNS tree DNAME can be used. > > > > RFC 3363 most definitly does not recommend that DNAMES be not > > supported. > > So, what should the document say? The Node Requirements doc shouldn't > update RFC-3363, so that would be another issue. It may however pay us to rev RFC-3363 just to remove the offending section prior to getting out the node requirements. > 3363 does say: > > The issues for DNAME in the reverse mapping tree appears to be > closely tied to the need to use fragmented A6 in the main tree: if > one is necessary, so is the other, and if one isn't necessary, the > other isn't either. Therefore, in moving RFC 2874 to experimental, > the intent of this document is that use of DNAME RRs in the reverse > tree be deprecated. > > How about: > > "Those nodes are NOT RECOMMENDED to support the experimental A6 > Resource Records [RFC-3363]. Usage of DNAME Reseource Records in > the reverse tree is deprecated." > > John Just don't mention DNAME at all. Note DNAME support will be manditory with DNSSEC so the only issue is whether we discourage the use under IP6.ARPA which I (and lots of others in dnsext) now believe we got wrong. "Those nodes are NOT RECOMMENDED to support the experimental A6 Resource Records [RFC-3363]." Mark > > I really suspect that we will want to use DNAME for renumbering > > even without A6 and bit-string labels. Trying to get > > multiple levels of delegation updated quickly is a pain. > > Just look at the problems we are having going from IP6.INT > > to IP6.ARPA. Do we want this pain level with every renumber > > event. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 19 08:52: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 IAA18567 for ; Thu, 19 Feb 2004 08:52: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 1AtobG-0003Yq-4k for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 08:52:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JDqM1w013685 for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 08:52:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtobF-0003Ye-Gi for ipv6-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 08:52:21 -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 IAA18563 for ; Thu, 19 Feb 2004 08:52:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtobE-0005Hw-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 08:52:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtoaF-0005EE-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 08:51:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtoZw-0005Al-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 08:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtoZ0-0003E3-TJ; Thu, 19 Feb 2004 08:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtoY9-0003Cj-VD for ipv6@optimus.ietf.org; Thu, 19 Feb 2004 08:49:09 -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 IAA18471 for ; Thu, 19 Feb 2004 08:49:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtoY8-00055r-00 for ipv6@ietf.org; Thu, 19 Feb 2004 08:49:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtoXC-000539-00 for ipv6@ietf.org; Thu, 19 Feb 2004 08:48:11 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtoWK-0004zB-00 for ipv6@ietf.org; Thu, 19 Feb 2004 08:47:17 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1JDkjf21017 for ; Thu, 19 Feb 2004 15:46:45 +0200 Date: Thu, 19 Feb 2004 15:46:45 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: Re: [psg.com #247] [2461bis issue 247] On-link assumption harmful for dual stack nodes 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 Note: I think you should also point to, using informational reference, to draft-ietf-v6ops-onlinkassumption-00.txt, in the appropriate place in "CHANGES FROM RFC 2461" -- to give some more background to this. On Fri, 13 Feb 2004 rt+ipv6-2461bis@rt.psg.com wrote: > On-link assumptions in 2461 considered harmful. > This issue was raised by Alain and documented in: > draft-ietf-v6ops-onlinkassumption-00.txt > draft-ietf-v6ops-v6onbydefault-00.txt > Also see related issue in section 2.4 of: > http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt > > Suggestion: > > Remove on-link assumption from section 5.2. > This sentence was removed from section 5.2. > > > -------------------------------------------------------------------- > 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 Feb 19 10:52: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 KAA24421 for ; Thu, 19 Feb 2004 10:52:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtqTO-0007yJ-Av for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 10:52:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JFqMNM030642 for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 10:52:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtqTO-0007y9-5i for ipv6-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 10:52:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24408 for ; Thu, 19 Feb 2004 10:52:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtqTL-00045w-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 10:52:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtqST-00042c-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 10:51:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtqRe-0003z6-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 10:50:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtqR9-0007Ri-42; Thu, 19 Feb 2004 10:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtqQd-0007PA-Gb for ipv6@optimus.ietf.org; Thu, 19 Feb 2004 10:49:31 -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 KAA24230 for ; Thu, 19 Feb 2004 10:49:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtqQb-0003t7-00 for ipv6@ietf.org; Thu, 19 Feb 2004 10:49:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtqPh-0003nL-00 for ipv6@ietf.org; Thu, 19 Feb 2004 10:48:34 -0500 Received: from web41802.mail.yahoo.com ([66.218.93.136]) by ietf-mx with smtp (Exim 4.12) id 1AtqOa-0003da-00 for ipv6@ietf.org; Thu, 19 Feb 2004 10:47:24 -0500 Message-ID: <20040219154653.94304.qmail@web41802.mail.yahoo.com> Received: from [63.159.88.109] by web41802.mail.yahoo.com via HTTP; Thu, 19 Feb 2004 07:46:53 PST Date: Thu, 19 Feb 2004 07:46:53 -0800 (PST) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2004: May 13-14, 2004, Las Vegas To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1470029510-1077205613=:93199" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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,HTML_FONTCOLOR_BLUE, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2 autolearn=no version=2.60 --0-1470029510-1077205613=:93199 Content-Type: text/plain; charset=us-ascii CONFERENCE ANNOUNCEMENT & CALL FOR PRESENTATIONS ------------------------------------------------------------------------------ INTERNETWORKING 2004 Technical Program: May 13-14, 2004 Las Vegas, Nevada http://www.caitr.org/internetworking04/ In conjunction with NetWorld+Interop Las Vegas 2004 -------------------------------------------------------------------------------- The Internetworking 2004 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words should be submitted (in plain text format) to submissions at caitr.org for review and possible inclusion in the program, no later than February 25, 2004. Topics of interest include, but are not limited to the following: Voice over IP (VoIP) Virtual Private Networks Routing and Quality of Service (QoS) Network Processors Network Security Service Integration Operational Support Systems Transition from IPv4 to IPv6 and Interworking Network Survivability and Fault Management Wireless Internet Next Generation Mobile Networks Internetworking IP and Optical Networks Internetworking MPLS with Legacy ATM and Frame Relay Networks Fiber To The Home (FTTH) High Speed Transport Layer Protocols Unicast and Multicast Routing and Convergence Storage Area Networks (SANs) Peer to Peer Networking Pervasive Computing Grid Computing IP Video Conferencing High Definition Video Distribution For additional information, please contact info at caitr.org, or the conference technical chair, Dr. Parviz Yegani (). --0-1470029510-1077205613=:93199 Content-Type: text/html; charset=us-ascii
CONFERENCE ANNOUNCEMENT & CALL FOR PRESENTATIONS

------------------------------------------------------------------------------
      INTERNETWORKING 2004
Technical Program: May 13-14, 2004
          Las Vegas, Nevada
http://www.caitr.org/internetworking04/
In conjunction with NetWorld+Interop Las Vegas 2004
--------------------------------------------------------------------------------
The Internetworking 2004 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains.

Summaries not exceeding 250 words should be submitted (in plain text format) to submissions at caitr.org for review and possible inclusion in the program, no later than February 25, 2004.

Topics of interest include, but are not limited to the following:

   Voice over IP (VoIP)
   Virtual Private Networks
   Routing and Quality of Service (QoS)
   Network Processors
   Network Security
   Service Integration
   Operational Support Systems
   Transition from IPv4 to IPv6 and Interworking
   Network Survivability and Fault Management
   Wireless Internet
   Next Generation Mobile Networks
   Internetworking IP and Optical Networks
   Internetworking MPLS with Legacy ATM and Frame Relay Networks
   Fiber To The Home (FTTH)
   High Speed Transport Layer Protocols
   Unicast and Multicast Routing and Convergence
   Storage Area Networks (SANs)
   Peer to Peer Networking
   Pervasive Computing
   Grid Computing
   IP Video Conferencing
   High Definition Video Distribution

For additional information, please contact info at caitr.org, or the conference technical chair, Dr. Parviz Yegani (<pyegani at cisco.com>).
--0-1470029510-1077205613=:93199-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 19 18:29: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 SAA02936 for ; Thu, 19 Feb 2004 18:29:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atxbk-0000zW-6T for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 18:29:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JNTSfs003799 for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 18:29:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atxbj-0000zC-Ey for ipv6-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 18:29: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 SAA02923 for ; Thu, 19 Feb 2004 18:29:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atxbg-0001qk-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 18:29:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atxan-0001oK-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 18:28:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atxa0-0001mM-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 18:27:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtxZN-0000Wk-97; Thu, 19 Feb 2004 18:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtxYp-0000UH-BR for ipv6@optimus.ietf.org; Thu, 19 Feb 2004 18:26: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 SAA02818 for ; Thu, 19 Feb 2004 18:26:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtxYm-0001iw-00 for ipv6@ietf.org; Thu, 19 Feb 2004 18:26:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtxXm-0001fw-00 for ipv6@ietf.org; Thu, 19 Feb 2004 18:25:23 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AtxWq-0001cX-00 for ipv6@ietf.org; Thu, 19 Feb 2004 18:24:24 -0500 Message-ID: <03b601c3f73f$922d52b0$936015ac@dclkempt40> From: "James Kempf" To: "Nick 'Sharkey' Moore" , References: <20040219085228.GA22803@zoic.org> Subject: Re: Optimistic DAD _again!_ Date: Thu, 19 Feb 2004 15:24:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Nick, I'd certainly be interested in hearing about this and having the IPv6 group take it up, since the MIP group declined to take it up. I haven't read the draft in a while, but I will try to take a look at it before the meeting. If there is enough interest, I am not sure whether it would be a standalone item or rather folded into 2642bis, though. Do you have a preference? What do the WG chairs think? jak ----- Original Message ----- From: "Nick 'Sharkey' Moore" To: Sent: Thursday, February 19, 2004 12:52 AM Subject: Optimistic DAD _again!_ > Hi IPv6ers, > > You might recall some time ago I stirred up some interest > in my Optimistic DAD draft, which seeks to eliminate DAD delay > without significantly increasing the risk involved in address > collision. In the meantime it's picked up a couple of independant > implementations[1] and a couple of conference publications[2]. > > It was debated fairly thoroughly in MobileIP WG, > (I presented the idea to the WG in San Francisco[3]) but > has since been judged to be outside the scope of that group, > as it is applies to any situation needing fast address > configuration, not just MobileIP. > > IPv6 WG seems the proper place for it to be developed > further, and I'd like to open it up for debate here with the > aim of moving it towards standardization. > > The latest version is: > > ... and it's _still_ only 13 pages long. > > Please let me know what you think ... and if there's enough > interest maybe we can discuss it further at Seoul. > > -----Nick 'sharkey' Moore. > > > [1] One by our team at Monash, one by Ed Remmel of Elmic Systems > [2] See for refs ... > [3] ... and for slides from these presentations. > -- > Nick Moore, Resarch Fellow | > Monash University CTIE | > Australian Telecommunications CRC | > > -------------------------------------------------------------------- > 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 Feb 19 20:04: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 UAA08599 for ; Thu, 19 Feb 2004 20:04:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atz4n-0000re-Ce for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 20:03:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K13XcR003319 for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 20:03:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atz4n-0000rS-6A for ipv6-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 20:03:33 -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 UAA08522 for ; Thu, 19 Feb 2004 20:03:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atz4l-0001g7-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 20:03:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atz3n-0001b4-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 20:02:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atz2r-0001XD-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 20:01:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atz2N-00008s-CT; Thu, 19 Feb 2004 20:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atz26-00006f-0H for ipv6@optimus.ietf.org; Thu, 19 Feb 2004 20:00:46 -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 UAA08382 for ; Thu, 19 Feb 2004 20:00:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atz24-0001SB-00 for ipv6@ietf.org; Thu, 19 Feb 2004 20:00:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atz19-0001M0-00 for ipv6@ietf.org; Thu, 19 Feb 2004 19:59:48 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Atz0I-0001AI-00 for ipv6@ietf.org; Thu, 19 Feb 2004 19:58:54 -0500 content-class: urn:content-classes:message Subject: RE: Optimistic DAD _again!_ Date: Thu, 19 Feb 2004 19:58:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Optimistic DAD _again!_ Thread-Index: AcP2xh99xE1w1ZqAS/mKjctZ7Gu4QQAhSDOg From: "Soliman Hesham" To: "Nick 'Sharkey' Moore" , 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 Nick,=20 I think optimistic DAD is a very useful (and essential) tool for mobile nodes in multiaccess links (e.g. WLANs) since=20 it eliminates a major delay component. So I'd support this=20 draft for a std track RFC.=20 I'm also surprised that this work is not addressed in DNA as I thought it'd be in the heart of the DNA charter. But regardless, it needs to be done if we want MIPv6 to be useful in WLANs. Hesham > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On=20 > Behalf Of Nick > 'Sharkey' Moore > Sent: Thursday, February 19, 2004 3:52 AM > To: ipv6@ietf.org > Subject: Optimistic DAD _again!_ >=20 >=20 > Hi IPv6ers, >=20 > You might recall some time ago I stirred up some interest > in my Optimistic DAD draft, which seeks to eliminate DAD delay > without significantly increasing the risk involved in address > collision. In the meantime it's picked up a couple of independant > implementations[1] and a couple of conference publications[2]. >=20 > It was debated fairly thoroughly in MobileIP WG,=20 > (I presented the idea to the WG in San Francisco[3]) but > has since been judged to be outside the scope of that group, > as it is applies to any situation needing fast address=20 > configuration, not just MobileIP. >=20 > IPv6 WG seems the proper place for it to be developed > further, and I'd like to open it up for debate here with the > aim of moving it towards standardization. >=20 > The latest version is: > > ... and it's _still_ only 13 pages long. >=20 > Please let me know what you think ... and if there's enough > interest maybe we can discuss it further at Seoul. >=20 > -----Nick 'sharkey' Moore. >=20 >=20 > [1] One by our team at Monash, one by Ed Remmel of Elmic Systems > [2] See for refs ... > [3] ... and for slides from these presentations. > --=20 > Nick Moore, Resarch Fellow | > Monash University CTIE |=20 Australian Telecommunications CRC | -------------------------------------------------------------------- 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 Feb 20 02:24: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 CAA06938 for ; Fri, 20 Feb 2004 02:24:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au50u-0003Fg-J4 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 02:23:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K7Nusf012482 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 02:23:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au50s-0003FA-Mn for ipv6-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 02:23:54 -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 CAA06901 for ; Fri, 20 Feb 2004 02:23:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au50p-0005Ai-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 02:23:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au502-00057B-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 02:23:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au4zY-00052D-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 02:22:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4z5-0002RN-BX; Fri, 20 Feb 2004 02:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4yr-0002I3-6j for ipv6@optimus.ietf.org; Fri, 20 Feb 2004 02:21:49 -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 CAA06695 for ; Fri, 20 Feb 2004 02:21:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au4yn-0004z3-00 for ipv6@ietf.org; Fri, 20 Feb 2004 02:21:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au4xz-0004vn-00 for ipv6@ietf.org; Fri, 20 Feb 2004 02:20:56 -0500 Received: from fep20-0.kolumbus.fi ([193.229.0.47] helo=fep20-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1Au4xa-0004rz-00 for ipv6@ietf.org; Fri, 20 Feb 2004 02:20:30 -0500 Received: from kolumbus.fi ([62.248.154.14]) by fep20-app.kolumbus.fi with ESMTP id <20040220072029.MESH15980.fep20-app.kolumbus.fi@kolumbus.fi>; Fri, 20 Feb 2004 09:20:29 +0200 Message-ID: <4035B4C4.9060703@kolumbus.fi> Date: Fri, 20 Feb 2004 09:18:28 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nick 'Sharkey' Moore" CC: ipv6@ietf.org Subject: Re: Optimistic DAD _again!_ References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I support work on optimistic DAD. I would propose it to be taken up by the IPv6 WG. Not as a part of the 2462bis effort but separately. I would also note that optimistic DAD is useful for anything that expects a fast attachment time or frequent movements, not just MIPv6 but also HIP and MOBIKE. I believe the reason it was not taken up by the DNA group was not that they did not want it, but rather that it was felt that the expertise resides more in the IPv6 WG. --Jari Soliman Hesham wrote: > Nick, > > I think optimistic DAD is a very useful (and essential) > tool for mobile nodes in multiaccess links (e.g. WLANs) since > it eliminates a major delay component. So I'd support this > draft for a std track RFC. > > I'm also surprised that this work is not addressed in DNA > as I thought it'd be in the heart of the DNA charter. But > regardless, it needs to be done if we want MIPv6 to be useful > in WLANs. > > Hesham > > > -----Original Message----- > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On > > Behalf Of Nick > > 'Sharkey' Moore > > Sent: Thursday, February 19, 2004 3:52 AM > > To: ipv6@ietf.org > > Subject: Optimistic DAD _again!_ > > > > > > Hi IPv6ers, > > > > You might recall some time ago I stirred up some interest > > in my Optimistic DAD draft, which seeks to eliminate DAD delay > > without significantly increasing the risk involved in address > > collision. In the meantime it's picked up a couple of independant > > implementations[1] and a couple of conference publications[2]. > > > > It was debated fairly thoroughly in MobileIP WG, > > (I presented the idea to the WG in San Francisco[3]) but > > has since been judged to be outside the scope of that group, > > as it is applies to any situation needing fast address > > configuration, not just MobileIP. > > > > IPv6 WG seems the proper place for it to be developed > > further, and I'd like to open it up for debate here with the > > aim of moving it towards standardization. > > > > The latest version is: > > > > ... and it's _still_ only 13 pages long. > > > > Please let me know what you think ... and if there's enough > > interest maybe we can discuss it further at Seoul. > > > > -----Nick 'sharkey' Moore. > > > > > > [1] One by our team at Monash, one by Ed Remmel of Elmic Systems > > [2] See for refs ... > > [3] ... and for slides from these presentations. > > -- > > Nick Moore, Resarch Fellow | > > Monash University CTIE | > > Australian Telecommunications CRC | > > > -------------------------------------------------------------------- > 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 Fri Feb 20 02:59: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 CAA08834 for ; Fri, 20 Feb 2004 02:59:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5Yn-00086d-IG for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 02:58:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K7wvwU031158 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 02:58:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5Yn-00086Q-1u for ipv6-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 02:58: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 CAA08818 for ; Fri, 20 Feb 2004 02:58:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au5Yj-0007jB-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 02:58:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au5Xt-0007f4-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 02:58:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au5XA-0007aC-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 02:57:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5Ww-0007dd-4U; Fri, 20 Feb 2004 02:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5Wf-0007cW-6I for ipv6@optimus.ietf.org; Fri, 20 Feb 2004 02:56: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 CAA08700 for ; Fri, 20 Feb 2004 02:56:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au5Wb-0007WK-00 for ipv6@ietf.org; Fri, 20 Feb 2004 02:56:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au5Vg-0007RN-00 for ipv6@ietf.org; Fri, 20 Feb 2004 02:55:44 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1Au5Us-0007Kq-00 for ipv6@ietf.org; Fri, 20 Feb 2004 02:54:55 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id DDFF6704F3C; Fri, 20 Feb 2004 18:54:42 +1100 (EST) Date: Fri, 20 Feb 2004 18:54:42 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: Jari Arkko Subject: Re: Optimistic DAD _again!_ Message-ID: <20040220075442.GI27905@zoic.org> References: <4035B4C4.9060703@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4035B4C4.9060703@kolumbus.fi> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-20, Jari Arkko wrote: > > I support work on optimistic DAD. I would propose > it to be taken up by the IPv6 WG. Not as a part of > the 2462bis effort but separately. Thanks Jari, Hesham, James for your interest ... I hope we'll get a chance to discuss in the WG. > I would also note that optimistic DAD is useful for > anything that expects a fast attachment time or > frequent movements, not just MIPv6 but also HIP > and MOBIKE. Yep, that's part of the reason it was felt that it was outside the scope of MobileIP. Applies even to nodes which do not care about getting traffic redirected to them but merely want to send datagrams in a timely manner. > I believe the reason it was not taken up by the DNA > group was not that they did not want it, but rather > that it was felt that the expertise resides more in > the IPv6 WG. Yep. There is some overlap with DNA ... after all, we are both trying to do things very quickly and with minimal signalling. But DNA is being kept to a very tight focus (which is probably a good thing). IPv6 WG is where Optimistic DAD must sink or swim! -----Nick 'sharkey' Moore (quietly optimistic) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 20 06:31: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 GAA16113 for ; Fri, 20 Feb 2004 06:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8s2-0007d1-JT for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 06:31:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KBV2M0029319 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 06:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8s2-0007ci-8X for ipv6-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 06:31: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 GAA16101 for ; Fri, 20 Feb 2004 06:30:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au8ry-0006OP-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 06:30:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au8r3-0006Kh-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 06:30:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au8qS-0006Gj-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 06:29:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8q5-0007BA-N0; Fri, 20 Feb 2004 06:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8pA-00074A-BF for ipv6@optimus.ietf.org; Fri, 20 Feb 2004 06:28: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 GAA15951 for ; Fri, 20 Feb 2004 06:27:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au8p6-0006CE-00 for ipv6@ietf.org; Fri, 20 Feb 2004 06:28:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au8oG-00068a-00 for ipv6@ietf.org; Fri, 20 Feb 2004 06:27:08 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1Au8nn-00063R-00 for ipv6@ietf.org; Fri, 20 Feb 2004 06:26:39 -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 i1KBQAL10942 for ; Fri, 20 Feb 2004 03:26:10 -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 i1KBbVlN020714 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 20 Feb 2004 03:37:37 -0800 Message-ID: <4035EE96.6020407@innovationslab.net> Date: Fri, 20 Feb 2004 06:25:10 -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: ipv6@ietf.org Subject: Tentative Agenda for Seoul Content-Type: multipart/mixed; boundary="------------060406010402060807060005" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 multi-part message in MIME format. --------------060406010402060807060005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, Attached is the tentative agenda for Seoul. The chairs are still formulating other items. If you have a topic/document/issue you would like included, please contact the chairs. Regards, Brian & Bob IPv6 WG co-chairs --------------060406010402060807060005 Content-Type: text/plain; name="Agenda.txt" Content-Disposition: inline; filename="Agenda.txt" Content-Transfer-Encoding: 7bit Tuesday (02/02/04) 1545-1800 ------------------------------ 1. Intro & Agenda Bashing chairs 5 minutes 2. Document Status chairs 2 minutes 3. Charter Update Hinden 10 minutes 4. Node Requirements Loughney 10 minutes - draft-ietf-ipv6-node-requirements-08.txt - Goal: IESG comments review 5. 2461bis Soliman 15 minutes - draft- - Goal: status update 6. 2462bis Tatuya 15 minutes - draft-ietf-ipv6-rfc2462bis-00.txt - Goal: status update 7. ICMP Updates Gupta/Hinden 15 minutes - draft-ietf-ipngwg-icmp-v3-03.txt - Goal: status update 8. Multi-protocol getnameinfo Jun-ichiro 5 minutes - draft-itojun-ipv6-getnameinfo-multiproto-01.txt - Goal: Informational 9. Optimistic DAD N. Moore 10 minutes - draft-moore-ipv6-optimistic-dad-04.txt - Goal: Informational --------------060406010402060807060005-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 20 06:34: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 GAA16340 for ; Fri, 20 Feb 2004 06:34:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8uw-000859-3U for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 06:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KBY2gx031057 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 06:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8uv-00084m-MY for ipv6-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 06:34: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 GAA16289 for ; Fri, 20 Feb 2004 06:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au8ur-0006eC-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 06:33:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au8tw-0006Z5-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 06:33:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au8t4-0006UR-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 06:32:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8sz-0007eW-Oc; Fri, 20 Feb 2004 06:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8s1-0007cO-Hf for ipv6@optimus.ietf.org; Fri, 20 Feb 2004 06:31: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 GAA16098 for ; Fri, 20 Feb 2004 06:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au8rx-0006OK-00 for ipv6@ietf.org; Fri, 20 Feb 2004 06:30:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au8r2-0006KY-00 for ipv6@ietf.org; Fri, 20 Feb 2004 06:30:01 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1Au8qN-0006Et-00 for ipv6@ietf.org; Fri, 20 Feb 2004 06:29:19 -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 i1KBSoL10961 for ; Fri, 20 Feb 2004 03:28:50 -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 i1KBeElN020732 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 20 Feb 2004 03:40:17 -0800 Message-ID: <4035EF39.7070605@innovationslab.net> Date: Fri, 20 Feb 2004 06:27:53 -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: ipv6@ietf.org Subject: Call for Scribes 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 All, This is a call for volunteer scribes for the Seoul meeting. We have one slot on Tuesday afternoon. If you are willing to act as a scribe for the IPv6 WG meeting, please let the chairs know. Thanks, Brian & Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 20 09:33: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 JAA23726 for ; Fri, 20 Feb 2004 09:33:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBiI-0005eF-N8 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 09:33:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KEXA4S021711 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 09:33:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBiI-0005e5-CM for ipv6-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 09:33:10 -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 JAA23695 for ; Fri, 20 Feb 2004 09:33:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuBiG-0004J3-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 09:33:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuBhF-0004E1-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 09:32:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuBgf-00049x-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 09:31:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBgF-0005DS-IL; Fri, 20 Feb 2004 09:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBfh-0005CK-P7 for ipv6@optimus.ietf.org; Fri, 20 Feb 2004 09:30:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23535; Fri, 20 Feb 2004 09:30:26 -0500 (EST) Message-Id: <200402201430.JAA23535@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2012-update-06.txt Date: Fri, 20 Feb 2004 09:30:25 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 Transmission Control Protocol (TCP) Author(s) : R. Raghunarayan Filename : draft-ietf-ipv6-rfc2012-update-06.txt Pages : 30 Date : 2004-2-20 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 Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2012 and 2452. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2012-update-06.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-rfc2012-update-06.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-2-20095358.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2012-update-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2012-update-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-20095358.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 Fri Feb 20 15:24: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 PAA12294 for ; Fri, 20 Feb 2004 15:24:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHBK-0006T0-Oa for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 15:23:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KKNUnx024850 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 15:23:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHBK-0006Sj-E1 for ipv6-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 15:23:30 -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 PAA12267 for ; Fri, 20 Feb 2004 15:23:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuHBJ-0006Rc-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 15:23:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuHAK-0006M5-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 15:22:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuH9T-0006GH-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 15:21:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuH82-0005NB-LZ; Fri, 20 Feb 2004 15:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuH7E-00059x-2n for ipv6@optimus.ietf.org; Fri, 20 Feb 2004 15:19:17 -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 PAA11913 for ; Fri, 20 Feb 2004 15:19:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuH7C-00066N-00 for ipv6@ietf.org; Fri, 20 Feb 2004 15:19:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuH6K-00062t-00 for ipv6@ietf.org; Fri, 20 Feb 2004 15:18:21 -0500 Received: from evrtwa1-ar8-4-65-025-155.evrtwa1.dsl-verizon.net ([4.65.25.155] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1AuH5x-0005yn-00 for ipv6@ietf.org; Fri, 20 Feb 2004 15:17:57 -0500 Received: from eaglet (127.0.0.1:4416) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 20 Feb 2004 12:18:01 -0800 From: "Tony Hain" To: "'Alain Durand'" , "'Brian Haberman'" , "'Bob Hinden'" Cc: "'The IESG'" , "'Margaret Wasserman'" , "'IPv6 Mailing List'" , "'Thomas Narten'" Subject: RE: Request To Advance : "Unique Local IPv6 Unicast Addresses" Date: Fri, 20 Feb 2004 12:17:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcP3l4pdxfwvSbdFTbunqz6Hg99hVwAVJM0w In-Reply-To: <4F02942E-6386-11D8-9E3D-00039376A6AA@sun.com> 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.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alain, The current document does not enforce a business model (earlier versions did), but does set technical constraints. Personally I don't think it is possible to 'Provide mechanisms that prevent hoarding', so the requirement 'without any procedure for de-allocation' creates a problem once hoarding has been detected. I do not object to the current document as this specific issue will be resolved by an update once the system is in operation and practical experience exposes that flaw. Recommending against all-zero's is not only a waste of time, it specifically directs people to the thing you are trying to avoid. There is nothing that a document can do to prevent a consultant from configuring all of his customers with the same prefix. He can run [RANDOM] once and use that everywhere, yet is in full compliance with the document. Even more of a problem, an equipment manufacturer could run [RANDOM] once and burn that value into every piece of equipment they ship. The best a document can do is highlight the issues raised by duplicate assignments, and provide a mechanism which solves them if used as directed. As much as some people want to, it is not the IETF's job to legislate operational behavior. The language in this document is appropriate and it should be published. Tony BTW: why wasn't draft-hain-templin-ipv6-localcomm-04.txt sent at the same time as the unique address & deprecation drafts? They are all dealing with the same issue. > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Alain > Durand > Sent: Friday, February 20, 2004 1:22 AM > To: Brian Haberman; Bob Hinden > Cc: The IESG; Margaret Wasserman; IPv6 Mailing List; Alain Durand; Thomas > Narten > Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" > > Dears ADs, > > I found it very unfortunate that the chair decided to request to > advance this document > without answering two major issues I raised during the last call: > > - Permanent allocation is equivalent of selling address space, which is > very different from > the notion of stewardship that are now in place for any IP address > allocation today. > There are a number of legal questions not answered around this point. > More, this is imposing a business model to the entity that will be in > charge of the allocations, > and I believe that the IETF should refrain from imposing business > model. > > - The document does not contain any wording recommending against the > 'all zero' self allocation. > It merely say that: > "Locally assigned global IDs MUST be generated with a pseudo-random > algorithm consistent with [RANDOM].". However, it should be noted > that [RANDOM] > or RFC1750 does not contain any mandate, just provide ideas on how > to do things. > An 'all zero' self allocation would create the prefix FD00::/48 and > will be very tempting > to use by many. > This working group just spend more than a year to deprecate the site > local > fec0::/10 prefixes, just to reinvent it here. > > As the request to advance this document came from the Ipv6 wg chairs, > representing the wg, > it is my opinion that the IPv6 Working Groug has made an incorrect > technical choice which > places the quality and/or integrity of the Working Group's product(s) > in significant > jeopardy. > > As the request to advance this document has already been sent to you, > ADs, > this is my appeal to you to reject it and send it back to the working > group. > > - Alain. > > > > > > On Feb 18, 2004, at 5:22 PM, Brian Haberman wrote: > > > Margaret & Thomas, > > On behalf of the IPv6 working group, the chairs request the > > advancement of: > > > > Title : Unique Local IPv6 Unicast Addresses > > Author(s) : R. Hinden, B. Haberman > > Filename : draft-ietf-ipv6-unique-local-addr-03.txt > > Pages : 16 > > Date : 2004-2-13 > > > > as a Proposed Standard. The -02 version completed working group last > > call on 02/02/2004. This version addresses issues raised during the > > last call period. > > > > Regards, > > Brian & Bob > > IPv6 WG co-chairs > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > 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 Feb 20 21:45: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 VAA29338 for ; Fri, 20 Feb 2004 21:45:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuN8w-0003Jt-66 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 21:45:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L2jQhU012755 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 21:45:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuN8v-0003Je-LI for ipv6-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 21:45: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 VAA29317 for ; Fri, 20 Feb 2004 21:45:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuN8s-0003Im-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 21:45:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuN7w-0003FG-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 21:44:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuN74-0003Br-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 21:43:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuN6c-00031H-Fq; Fri, 20 Feb 2004 21:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuN67-00030N-Qc for ipv6@optimus.ietf.org; Fri, 20 Feb 2004 21:42: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 VAA29230 for ; Fri, 20 Feb 2004 21:42:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuN64-00037d-00 for ipv6@ietf.org; Fri, 20 Feb 2004 21:42:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuN59-00033s-00 for ipv6@ietf.org; Fri, 20 Feb 2004 21:41:32 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AuN4h-0002zU-00; Fri, 20 Feb 2004 21:41:03 -0500 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id i1L2eok07341; Fri, 20 Feb 2004 18:40:50 -0800 (PST) From: Bill Manning Message-Id: <200402210240.i1L2eok07341@boreas.isi.edu> Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" In-Reply-To: from Tony Hain at "Feb 20, 4 12:17:51 pm" To: alh-ietf@tndh.net (Tony Hain) Date: Fri, 20 Feb 2004 18:40:50 -0800 (PST) Cc: Alain.Durand@Sun.COM, brian@innovationslab.net, bob.hinden@nokia.com, iesg-secretary@ietf.org, margaret@thingmagic.com, ipv6@ietf.org, narten@us.ibm.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit % Alain, % % The current document does not enforce a business model (earlier versions % did), but does set technical constraints. Personally I don't think it is % possible to 'Provide mechanisms that prevent hoarding', so the requirement % 'without any procedure for de-allocation' creates a problem once hoarding % has been detected. I do not object to the current document as this specific % issue will be resolved by an update once the system is in operation and % practical experience exposes that flaw. its not that the document "enforces" a business model, it that it creates "property rights" e.g. owned address space. this is -NEW- and is an area untrodden by the IESG/IAB. % mechanism which solves them if used as directed. As much as some people want % to, it is not the IETF's job to legislate operational behavior. The language % in this document is appropriate and it should be published. Operational behaviour is one thing, creating legal assests is something else. This is a -VERY- bad idea. --bill % Tony % % > -----Original Message----- % > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Alain % > Durand % > Sent: Friday, February 20, 2004 1:22 AM % > To: Brian Haberman; Bob Hinden % > Cc: The IESG; Margaret Wasserman; IPv6 Mailing List; Alain Durand; Thomas % > Narten % > Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" % > % > Dears ADs, % > % > I found it very unfortunate that the chair decided to request to % > advance this document % > without answering two major issues I raised during the last call: % > % > - Permanent allocation is equivalent of selling address space, which is % > very different from % > the notion of stewardship that are now in place for any IP address % > allocation today. % > There are a number of legal questions not answered around this point. % > More, this is imposing a business model to the entity that will be in % > charge of the allocations, % > and I believe that the IETF should refrain from imposing business % > model. % > % > - The document does not contain any wording recommending against the % > 'all zero' self allocation. % > It merely say that: % > "Locally assigned global IDs MUST be generated with a pseudo-random % > algorithm consistent with [RANDOM].". However, it should be noted % > that [RANDOM] % > or RFC1750 does not contain any mandate, just provide ideas on how % > to do things. % > An 'all zero' self allocation would create the prefix FD00::/48 and % > will be very tempting % > to use by many. % > This working group just spend more than a year to deprecate the site % > local % > fec0::/10 prefixes, just to reinvent it here. % > % > As the request to advance this document came from the Ipv6 wg chairs, % > representing the wg, % > it is my opinion that the IPv6 Working Groug has made an incorrect % > technical choice which % > places the quality and/or integrity of the Working Group's product(s) % > in significant % > jeopardy. % > % > As the request to advance this document has already been sent to you, % > ADs, % > this is my appeal to you to reject it and send it back to the working % > group. % > % > - Alain. % > % > % > % > % > % > On Feb 18, 2004, at 5:22 PM, Brian Haberman wrote: % > % > > Margaret & Thomas, % > > On behalf of the IPv6 working group, the chairs request the % > > advancement of: % > > % > > Title : Unique Local IPv6 Unicast Addresses % > > Author(s) : R. Hinden, B. Haberman % > > Filename : draft-ietf-ipv6-unique-local-addr-03.txt % > > Pages : 16 % > > Date : 2004-2-13 % > > % > > as a Proposed Standard. The -02 version completed working group last % > > call on 02/02/2004. This version addresses issues raised during the % > > last call period. % > > % > > Regards, % > > Brian & Bob % > > IPv6 WG co-chairs % > > % > > % > > % > > -------------------------------------------------------------------- % > > IETF IPv6 working group mailing list % > > ipv6@ietf.org % > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 % > > -------------------------------------------------------------------- % > % > % > -------------------------------------------------------------------- % > 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 % -------------------------------------------------------------------- % -- --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 Sun Feb 22 00: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 AAA01406 for ; Sun, 22 Feb 2004 00:07: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 1Aulpo-0004KI-Uk for ipv6-archive@odin.ietf.org; Sun, 22 Feb 2004 00:07:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M57Kmf016614 for ipv6-archive@odin.ietf.org; Sun, 22 Feb 2004 00:07:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aulpo-0004JO-1y for ipv6-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 00:07:20 -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 AAA01395 for ; Sun, 22 Feb 2004 00:07:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aulpl-0006Jg-00 for ipv6-web-archive@ietf.org; Sun, 22 Feb 2004 00:07:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aulou-0006FZ-00 for ipv6-web-archive@ietf.org; Sun, 22 Feb 2004 00:06:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aulo0-0006Aq-00 for ipv6-web-archive@ietf.org; Sun, 22 Feb 2004 00:05:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aulmb-0003tO-EC; Sun, 22 Feb 2004 00:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aulll-0003st-T2 for ipv6@optimus.ietf.org; Sun, 22 Feb 2004 00:03:09 -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 AAA01203 for ; Sun, 22 Feb 2004 00:03:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aullj-00063u-00 for ipv6@ietf.org; Sun, 22 Feb 2004 00:03:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aulkr-00061L-00 for ipv6@ietf.org; Sun, 22 Feb 2004 00:02:14 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1Auljy-0005ue-00 for ipv6@ietf.org; Sun, 22 Feb 2004 00:01:18 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 852BF1B2 for ; Sun, 22 Feb 2004 00:00:48 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 22 Feb 2004 00:00:48 -0500 Message-Id: <20040222050048.852BF1B2@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 --------+------+--------+----------+------------------------ 15.79% | 6 | 16.65% | 31433 | internet-drafts@ietf.org 7.89% | 3 | 7.94% | 14997 | john.loughney@nokia.com 7.89% | 3 | 7.09% | 13376 | h.soliman@flarion.com 7.89% | 3 | 6.36% | 12006 | brian@innovationslab.net 5.26% | 2 | 5.72% | 10803 | jinmei@isl.rdc.toshiba.co.jp 5.26% | 2 | 5.44% | 10278 | mark_andrews@isc.org 5.26% | 2 | 4.40% | 8312 | sharkey@zoic.org 5.26% | 2 | 4.12% | 7778 | ipv6-request@ietf.org 5.26% | 2 | 3.36% | 6351 | iesg-secretary@ietf.org 2.63% | 1 | 4.25% | 8020 | alh-ietf@tndh.net 2.63% | 1 | 4.18% | 7885 | bmanning@isi.edu 2.63% | 1 | 3.95% | 7460 | info@caitr.org 2.63% | 1 | 3.37% | 6367 | jari.arkko@kolumbus.fi 2.63% | 1 | 3.20% | 6048 | alain.durand@sun.com 2.63% | 1 | 3.16% | 5967 | greg.daley@eng.monash.edu.au 2.63% | 1 | 2.86% | 5406 | pthubert@cisco.com 2.63% | 1 | 2.75% | 5192 | sra+ipng@hactrn.net 2.63% | 1 | 2.65% | 5000 | kempf@docomolabs-usa.com 2.63% | 1 | 2.51% | 4729 | yukiyo.akisada@jp.yokogawa.com 2.63% | 1 | 2.11% | 3980 | pekkas@netcore.fi 2.63% | 1 | 2.08% | 3931 | sakreddy@india.hp.com 2.63% | 1 | 1.83% | 3446 | ipv6-in@kooks.net --------+------+--------+----------+------------------------ 100.00% | 38 |100.00% | 188765 | 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 Feb 22 23:24: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 XAA22762 for ; Sun, 22 Feb 2004 23:24:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av7dM-00037K-Hq for ipv6-archive@odin.ietf.org; Sun, 22 Feb 2004 23:23:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N4NuBb011977 for ipv6-archive@odin.ietf.org; Sun, 22 Feb 2004 23:23:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av7dK-000376-Hn for ipv6-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 23:23:54 -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 XAA22697 for ; Sun, 22 Feb 2004 23:23:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av7dI-0005LW-00 for ipv6-web-archive@ietf.org; Sun, 22 Feb 2004 23:23:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av7cJ-0005GN-00 for ipv6-web-archive@ietf.org; Sun, 22 Feb 2004 23:22:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Av7bM-0005D2-00 for ipv6-web-archive@ietf.org; Sun, 22 Feb 2004 23:21:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av7ab-0002iE-Ti; Sun, 22 Feb 2004 23:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av7aO-0002gD-HW for ipv6@optimus.ietf.org; Sun, 22 Feb 2004 23:20:55 -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 XAA22631 for ; Sun, 22 Feb 2004 23:20:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av7aM-00059d-00 for ipv6@ietf.org; Sun, 22 Feb 2004 23:20:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av7ZY-00057T-00 for ipv6@ietf.org; Sun, 22 Feb 2004 23:20:01 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1Av7Yc-00050H-00 for ipv6@ietf.org; Sun, 22 Feb 2004 23:19:02 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HTI00K01RYPQ6@mailout1.samsung.com> for ipv6@ietf.org; Mon, 23 Feb 2004 13:18:26 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HTI00MEWRYPKY@mailout1.samsung.com> for ipv6@ietf.org; Mon, 23 Feb 2004 13:18:25 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTI001WPRYOK8@mmp2.samsung.com> for ipv6@ietf.org; Mon, 23 Feb 2004 13:18:25 +0900 (KST) Date: Mon, 23 Feb 2004 13:18:26 +0900 From: "S. Daniel Park" Subject: FW: [DNA] IETF 59 Session [IPv6 DAD Optimization Goals and Requirements] To: ipv6@ietf.org Cc: "'S. Daniel Park'" , "'Greg Daley'" , "'Pekka Nikander'" , ??? Message-id: <089b01c3f9c4$1556eb70$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_LixA4hbiECyYChcZKxqojQ)" 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_LixA4hbiECyYChcZKxqojQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Below is a DNA WG agenda at 59th IETF and DAD Optimization will be discussed as indicated in this agenda. For this work, a draft was proposed in the DNA BoF (before) as below; http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt-requiremen t-02.txt Is there anyone agreedable to help with the work ? Regards Daniel >Detecting Network Attachment WG (dna) >Tuesday, March 2 at 1415-1515 ============================= >CHAIRS: Greg Daley (greg.daley@eng.monash.edu.au) > Pekka Nikander (pekka.nikander@nomadiclab.com) >AGENDA: > 5 min Agenda bashing Chairs > 5 min WG status Chairs > - chartering > - editors > - review group > 10 min Draft status - overall Chairs > - DAD optimization work at IPv6 > - adopting drafts as WG items --Boundary_(ID_LixA4hbiECyYChcZKxqojQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT FW: [DNA] IETF 59 Session [IPv6 DAD Optimization Goals and Requirements]

Below is a DNA WG agenda at 59th IETF and DAD Optimization will be
discussed as indicated in this agenda.  For this work, a draft was proposed
in the DNA BoF (before) as below;
http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt-requirement-02.txt

Is there anyone agreedable to help with the work ?


Regards

Daniel


>Detecting Network Attachment WG (dna)

>Tuesday, March 2 at 1415-1515
=============================

>CHAIRS: Greg Daley (greg.daley@eng.monash.edu.au)
>         Pekka Nikander (pekka.nikander@nomadiclab.com)


>AGENDA:

>   5 min  Agenda bashing                  Chairs
>   5 min  WG status                       Chairs
>          - chartering
>          - editors
>          - review group
>  10 min  Draft status - overall          Chairs
>          - DAD optimization work at IPv6
>          - adopting drafts as WG items

--Boundary_(ID_LixA4hbiECyYChcZKxqojQ)-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 23 01:20: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 BAA26212 for ; Mon, 23 Feb 2004 01:20:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9Rj-0001Me-Pj for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 01:20:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N6K3Zo005238 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 01:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9Rh-0001M6-Kq for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 01:20: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 BAA26207 for ; Mon, 23 Feb 2004 01:19:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av9Re-0004a4-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 01:19:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av9Ql-0004Wv-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 01:19:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Av9QM-0004Tz-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 01:18:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9Pm-00016N-DJ; Mon, 23 Feb 2004 01:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9Ox-0000zr-4u for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 01:17:11 -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 BAA26108 for ; Mon, 23 Feb 2004 01:17:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av9Ou-0004Od-00 for ipv6@ietf.org; Mon, 23 Feb 2004 01:17:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av9Nq-0004L0-00 for ipv6@ietf.org; Mon, 23 Feb 2004 01:16:02 -0500 Received: from usen-221x249x121x227.ap-us01.usen.ad.jp ([221.249.121.227] helo=coconut.itojun.org) by ietf-mx with esmtp (Exim 4.12) id 1Av9NG-0004Hs-00 for ipv6@ietf.org; Mon, 23 Feb 2004 01:15:27 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id AE40BD0; Mon, 23 Feb 2004 15:15:20 +0900 (JST) To: pthubert@cisco.com Cc: ipv6@ietf.org Subject: RE: Optimistic DAD _again!_ In-Reply-To: Your message of "Fri, 20 Feb 2004 08:26:20 -0000" References: X-Mailer: Cue version 0.6 (040210-0635/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040223061520.AE40BD0@coconut.itojun.org> Date: Mon, 23 Feb 2004 15:15:20 +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 IPv6ers, > > > > You might recall some time ago I stirred up some interest > > in my Optimistic DAD draft, which seeks to eliminate DAD delay > > without significantly increasing the risk involved in address > > collision. In the meantime it's picked up a couple of independant > > implementations[1] and a couple of conference publications[2]. > > > > It was debated fairly thoroughly in MobileIP WG, > > (I presented the idea to the WG in San Francisco[3]) but > > has since been judged to be outside the scope of that group, > > as it is applies to any situation needing fast address > > configuration, not just MobileIP. > > > > IPv6 WG seems the proper place for it to be developed > > further, and I'd like to open it up for debate here with the > > aim of moving it towards standardization. > > > > The latest version is: > > > > ... and it's _still_ only 13 pages long. > > > > Please let me know what you think ... and if there's enough > > interest maybe we can discuss it further at Seoul. i don't think it necessary to raise this discussion again. IIRC it was not accepted with sane reason. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 23 02:03: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 CAA01424 for ; Mon, 23 Feb 2004 02:03: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 1AvA7L-0005Nh-Nq for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 02:03:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N733GH020674 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 02:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvA7K-0005NG-SJ for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 02:03: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 CAA00840 for ; Mon, 23 Feb 2004 02:02:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvA7H-00077O-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 02:02:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvA6K-00074P-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 02:02:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvA5e-00071b-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 02:01:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvA5O-0004Wy-Po; Mon, 23 Feb 2004 02:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvA4U-00042r-Qa for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 02:00:07 -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 CAA27500 for ; Mon, 23 Feb 2004 02:00:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvA4R-0006xo-00 for ipv6@ietf.org; Mon, 23 Feb 2004 02:00:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvA3S-0006uj-00 for ipv6@ietf.org; Mon, 23 Feb 2004 01:59:03 -0500 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 1AvA2n-0006p8-00 for ipv6@ietf.org; Mon, 23 Feb 2004 01:58:21 -0500 Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id BFE0C8; Mon, 23 Feb 2004 09:10:35 +0200 (EET) In-Reply-To: <089b01c3f9c4$1556eb70$67cadba8@LocalHost> References: <089b01c3f9c4$1556eb70$67cadba8@LocalHost> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9A390E86-65CD-11D8-8F32-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, "'Greg Daley'" , ??? From: Pekka Nikander Subject: Re: [DNA] IETF 59 Session [IPv6 DAD Optimization Goals and Requirements] Date: Mon, 23 Feb 2004 08:57:53 +0200 To: "S. Daniel Park" X-Mailer: Apple Mail (2.612) 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 Daniel, > Below is a DNA WG agenda at 59th IETF and DAD Optimization will be > discussed as indicated in this agenda.=A0 The intention is mostly to inform people that the work is continuing, but that it will be transferred to the IPv6 WG. > For this work, a draft was proposed > in the DNA BoF (before) as below; > http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt-=20 > requirement-02.txt > > Is there anyone agreedable to help with the work ? I'd be glad to introduce you to Bob Hinden (if you don't know each other already). Basically, Bob would very much like to get rid of DAD altogether. Hence, IMHO your work on requirements and the work on optimistic DAD will probably get quite favourable attention from him. However, note that it will still take some time before IPv6 WG gets rechartered and before DAD optimisation will get to the charter. In the meanwhile, it is good to continue with the individual drafts, and trying to solicit feedback from various people. I'll try to read and comment your draft on my way to Seoul. Unfortunately I'm too busy to do it earlier. --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 23 05:18: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 FAA17638 for ; Mon, 23 Feb 2004 05:18:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDAC-0001cj-FT for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 05:18:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NAICuS006240 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 05:18:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDAC-0001cZ-54 for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 05:18:12 -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 FAA17585 for ; Mon, 23 Feb 2004 05:18:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvDA8-000551-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 05:18:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvD9A-0004zM-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 05:17:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvD8E-0004up-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 05:16:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvD85-0000yC-Vc; Mon, 23 Feb 2004 05:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvD7F-0000qG-PL for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 05:15:12 -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 FAA17452 for ; Mon, 23 Feb 2004 05:15:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvD7C-0004qW-00 for ipv6@ietf.org; Mon, 23 Feb 2004 05:15:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvD6K-0004nS-00 for ipv6@ietf.org; Mon, 23 Feb 2004 05:14:12 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AvD5r-0004k7-00 for ipv6@ietf.org; Mon, 23 Feb 2004 05:13:43 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id F1F14702D5E; Mon, 23 Feb 2004 21:13:37 +1100 (EST) Date: Mon, 23 Feb 2004 21:13:37 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: Jun-ichiro itojun Hagino Subject: Re: Optimistic DAD _again!_ Message-ID: <20040223101337.GA25356@zoic.org> Mail-Followup-To: ipv6@ietf.org, Jun-ichiro itojun Hagino References: <20040223061520.AE40BD0@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040223061520.AE40BD0@coconut.itojun.org> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-23, Jun-ichiro itojun Hagino wrote: > > > Hi IPv6ers, > > > > > > You might recall some time ago I stirred up some interest > > > in my Optimistic DAD draft, [...] > > i don't think it necessary to raise this discussion again. > IIRC it was not accepted with sane reason. Previously, it was neither accepted or refused: it was deemed that the IPv6 WG was not taking on new work. If the WG is able to take on new work now, I think it's worth consideration ... NB: If you have specific technical issues with the draft, I'd really like to hear about them so we can try and fix them. If they turn out to be unfixable, I guess it'll go away ... thanks, -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 23 05:28: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 FAA17929 for ; Mon, 23 Feb 2004 05:28:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDJz-0002IQ-Nt for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 05:28:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NASJHZ008824 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 05:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDJz-0002IF-8m for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 05:28: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 FAA17919 for ; Mon, 23 Feb 2004 05:28:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvDJw-0005ht-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 05:28:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvDJ1-0005dc-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 05:27:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvDIZ-0005Yz-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 05:26:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDHn-0001zD-2w; Mon, 23 Feb 2004 05:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDGs-0001yN-4L for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 05:25: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 FAA17790 for ; Mon, 23 Feb 2004 05:25:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvDGo-0005U7-00 for ipv6@ietf.org; Mon, 23 Feb 2004 05:25:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvDFs-0005RY-00 for ipv6@ietf.org; Mon, 23 Feb 2004 05:24:05 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AvDF3-0005P1-00 for ipv6@ietf.org; Mon, 23 Feb 2004 05:23:14 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id B829F702D65; Mon, 23 Feb 2004 21:23:12 +1100 (EST) Date: Mon, 23 Feb 2004 21:23:12 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: JINMEI@zoic.org, Tatuya@zoic.org, /@zoic.org, "\"?$B?@L\"@C#.zoic.org":H Subject: Re: Optimistic DAD _again!_ Message-ID: <20040223102311.GE24076@zoic.org> Mail-Followup-To: ipv6@ietf.org, JINMEI@zoic.org, Tatuya@zoic.org, /@zoic.org, "?$B?@L"@C#.zoic.org:H References: <20040219085228.GA22803@zoic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-23, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> "Nick 'Sharkey' Moore" said: > > > You might recall some time ago I stirred up some interest > > in my Optimistic DAD draft, [...] > > Please let me know what you think ... and if there's enough > > interest maybe we can discuss it further at Seoul. > > I'd like to know if there has been a consensus to pursue any sort of > DAD optimization in the first place. There have surely been lots of > discussions related to this issue, and, as far as I can recall, the > idea of optimization has never been adopted. It's definitely one of the bigger issues in MobileIPv6, but I think that the implications go beyond that which is why it's appropriate to IPv6 WG. > One fundamental question that I remember is whether optimizing DAD > really makes much sense while there are other kinds of delays such as > random delay (up to 1 second) for the first RS and random delay at > routers before responding to an RS. Without addressing the > fundamental question(s), we'd simply restart similar divergent > discussions, waisting lots of energy and time without seeing progress. Yes. My presentation at MobileIP WG at IETF-56 listed four component delays in MobileIPv6 handovers: * Movement Detection Delay * Router Advertisement Delay * DAD Delay * Binding Update RTT We've been working on the possible ways to eliminate each of these delays ... Optimistic DAD is one solution to one delay. You might find the stuff at interesting ... > p.s. I've read the latest draft and have some (mainly editorial) > comments. I'll post the comments in a separate message. Thanks! -----Nick -- Nick 'Sharkey' Moore "Heroism on command, senseless violence, and all the loathsome nonsense that goes by the name of patriotism -- how passionately I hate them!" -- Albert Einstein -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 23 05:33: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 FAA18189 for ; Mon, 23 Feb 2004 05:33: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 1AvDOc-0002rP-Md for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 05:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NAX6vo010989 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 05:33:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDOc-0002rA-Ib for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 05:33: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 FAA18118 for ; Mon, 23 Feb 2004 05:33:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvDOZ-00061Y-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 05:33:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvDNa-0005w6-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 05:32:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvDMc-0005s4-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 05:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDLg-0002LU-HU; Mon, 23 Feb 2004 05:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDKn-0002Jc-3A for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 05:29:09 -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 FAA17957 for ; Mon, 23 Feb 2004 05:29:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvDKj-0005lG-00 for ipv6@ietf.org; Mon, 23 Feb 2004 05:29:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvDJp-0005h2-00 for ipv6@ietf.org; Mon, 23 Feb 2004 05:28:10 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AvDIr-0005cA-00 for ipv6@ietf.org; Mon, 23 Feb 2004 05:27:09 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3750F1521E; Mon, 23 Feb 2004 19:27:10 +0900 (JST) Date: Mon, 23 Feb 2004 19:27:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: sharkey@zoic.org Cc: ipv6@ietf.org Subject: comments on draft-moore-ipv6-optimistic-dad-04.txt 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 Here are comments on draft-moore-ipv6-optimistic-dad-04.txt. I have one relatively-substantial comment and several editorial ones. The relatively-substantial comment is: I don't see the strong need for the unsolicited neighbor advertisements described in Section 3.1: * (adds to 7.2.6) The Optimistic node MAY send an unsolicited Neighbour Advertisement to All Nodes when it first configures an address. The Override flag on this advertisement MUST be set to 0. * (adds to 7.2.6) The Optimistic node SHOULD send an unsolicited NA to All Nodes when it completes DAD. The Override flag on this advertisement SHOULD be set to 1. In particular, I don't understand why we SHOULD send the unsolicited NA in the latter case. Other (mostly) editorial comments. 1. the draft contain many acronyms without or before (clearly) showing the original term. those include: DAD, ND, SAA, SLLAO, RS, RA, ON, NC, NS, NA, MN, and LLAO. 2. The second paragraph of Introduction contains an incomplete sentence. ... Disruption is minimized by limiting nodes' participation in Neighbour Discovery while their addresses are still Tentative, (or perhaps the comma should actually be a period) 3. One definition in Section 1.3 is not well defined (IMO): Well-Distributed Address - Address suffixes used for Optimistic DAD should be well distributed, eg: there should be an equal probability of any given suffix occuring. This minimizes the probability of an address collision. I would say this is a requirement, not a definition. I'd also like to point out "well distributed" is not really clear in a definition, but this is probably a minor issue (I can live with the wording). 3. In section 2, * Never using a Tentative address ... .... Another address, or the unspecified address, may be used, or the RS may be send without an SLLAO. s/may be send/may be sent/ 4. In section 2. When the MN wants to contact another neighbour, but it cannot because ... I guess MN stands for "mobile node" (see my first comment BTW), but I don't see why we need to use this word here. As far as I can see, there is nothing specific to a mobile node in this context. 5. In the same paragraph, ...The router should then provide the MN with a ICMP redirect, which may ... s/a ICMP/an ICMP/ 6. In Section 3.2 * (modifies 5.5) If an initial suffix is not supplied, a new suffix SHOULD be generated as per "Address Generation" below. What does "initial suffix" mean? RFC2462 (or its bis) doesn't use this wording. 7. In Section 3.2 * (modifies 5.4.5) ... If the address is a link-local address formed from a fixed interface identifier, the interface SHOULD be disabled. Otherwise, if the address was What does "a fixed interface identifier" mean? (e.g.) An interface identifier derived from a hardware address like EUI-64? FYI, the latest rfc2462bis draft contains the following sentence in Section 5.4.5: If the address is a link-local address formed from an interface identifier based on the hardware address (e.g., EUI-64), the interface SHOULD be disabled. 8. In Section 3.3 * If the interface offers a method to create a supposedly globally unique IPv6 address, this address MAY be used for the initial attempt. This is not very clear to me. What exactly does "a supposedly globally unique" mean? For instance, is an EUI-64 based IPv6 address supposedly globally unique? 9. In Section 3.3 * In order to minimize the effect of DoS attacks, a delay of at least RETRANS_TIMER (as used in [RFC2461]) milliseconds MUST be introduced between attempts if DAD has already failed more than once. An exponential backoff SHOULD be used. Does more than once mean "two times or more" (the answer should be yes in the literal sense)? If so, why don't we need a delay after the first failure? 10. In Section 3.4 ... In order to minimize the probability of an undetected address collision, it would seem prudent to always configure and check the link-local address for any given suffix as well as checking the actual address being configured. I'm not really sure what "the actual address" means. Do you mean "non link-local address"? 11. In Section 4.2 ... An NA with O=0,S=0 and no LLAO may [Note 1], however cause the NC entry to be set to STALE, causing NUD to be performed on the address. Shouldn't the "no LLAO" really be "with LLAO"? If not, what is the purpose of this NA (O=0,S=0, no LLAO)? 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 Feb 23 07:41: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 HAA22004 for ; Mon, 23 Feb 2004 07:41:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFOb-0003Zr-3I for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 07:41:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NCfD2q013745 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 07:41:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFOa-0003Zc-SK for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 07:41:12 -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 HAA21979 for ; Mon, 23 Feb 2004 07:41:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvFOa-0005qE-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 07:41:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvFNf-0005mg-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 07:40:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvFMz-0005jI-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 07:39:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFMT-00039l-O8; Mon, 23 Feb 2004 07:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFLe-00037W-Vg for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 07:38:11 -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 HAA21808 for ; Mon, 23 Feb 2004 07:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvFLe-0005ez-00 for ipv6@ietf.org; Mon, 23 Feb 2004 07:38:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvFKi-0005cM-00 for ipv6@ietf.org; Mon, 23 Feb 2004 07:37:13 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AvFKV-0005ZW-00 for ipv6@ietf.org; Mon, 23 Feb 2004 07:36:59 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HTJ00L01F0IQ4@mailout1.samsung.com> for ipv6@ietf.org; Mon, 23 Feb 2004 21:36:18 +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 <0HTJ00FJ3F0IYS@mailout1.samsung.com> for ipv6@ietf.org; Mon, 23 Feb 2004 21:36:18 +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 <0HTJ00A0TF0HXF@mmp1.samsung.com> for ipv6@ietf.org; Mon, 23 Feb 2004 21:36:18 +0900 (KST) Date: Mon, 23 Feb 2004 21:36:19 +0900 From: "S. Daniel Park" Subject: Re: Optimistic DAD _again!_ In-reply-to: To: =?ks_c_5601-1987?B?J0pJTk1FSSBUYXR1eWEgLyA/lr6SQo3GJw==?= , sharkey@zoic.org Cc: ipv6@ietf.org Message-id: <002a01c3fa09$a308f9f0$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_9ftNeNZOc8a83UnRssX7Tg)" 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.8 required=5.0 tests=AWL,HTML_30_40, 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_9ftNeNZOc8a83UnRssX7Tg) Content-type: text/plain; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT >One fundamental question that I remember is whether optimizing DAD >really makes much sense while there are other kinds of delays such as >random delay (up to 1 second) for the first RS and random delay at >routers before responding to an RS. Without addressing the >fundamental question(s), we'd simply restart similar divergent >discussions, waisting lots of energy and time without seeing progress. So, one draft was proposed to clarify what you indicate and I posted it on the IPv6 mailing list. http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt- requirement-02.txt Regards - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. --Boundary_(ID_9ftNeNZOc8a83UnRssX7Tg) Content-type: text/html; charset=ks_c_5601-1987 Content-Transfer-Encoding: quoted-printable Re: Optimistic DAD _again!_

>One = fundamental question that I remember is whether optimizing = DAD
>really = makes much sense while there are other kinds of delays such = as
>random = delay (up to 1 second) for the first RS and random delay = at
>routers = before responding to an RS.  Without addressing the
>fundamental question(s), we'd simply restart = similar divergent
>discussions, waisting lots of energy and time = without seeing progress.

So, one draft = was proposed to clarify what you indicate and I posted it on the IPv6 = mailing list.
http://www.ietf.org/internet-drafts/draft-park-dna-= ipv6dadopt-requirement-02.txt




Regards

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

= --Boundary_(ID_9ftNeNZOc8a83UnRssX7Tg)-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 23 08:26: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 IAA23983 for ; Mon, 23 Feb 2004 08:26:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG6A-0007Cj-Lp for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 08:26:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NDQE04027687 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 08:26:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG6A-0007CU-GI for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 08:26:14 -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 IAA23933 for ; Mon, 23 Feb 2004 08:26:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvG69-0001lB-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 08:26:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvG5B-0001es-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 08:25:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvG4E-0001YW-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 08:24:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG41-0006bp-Qf; Mon, 23 Feb 2004 08:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG3F-0006JM-P1 for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 08:23:13 -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 IAA23692 for ; Mon, 23 Feb 2004 08:23:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvG3E-0001So-00 for ipv6@ietf.org; Mon, 23 Feb 2004 08:23:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvG2H-0001P9-00 for ipv6@ietf.org; Mon, 23 Feb 2004 08:22:14 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AvG1t-0001MH-00 for ipv6@ietf.org; Mon, 23 Feb 2004 08:21:49 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 743D015214 for ; Mon, 23 Feb 2004 22:21:42 +0900 (JST) Date: Mon, 23 Feb 2004 22:21:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis issue 275] DAD text inconsistencies 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 Since we have a discussion about optimistic DAD, this is probably a good chance to start a related discussion for rfc2462bis. As you know, there have been many discussions on DAD, including - whether omitting/optimizing DAD is a good idea - (if yes) in which case we can omit DAD - DAD vs DIID - ... without getting any convergence (particularly about DAD omission/optimization or DIID), unfortunately. Through the past discussion and by considering the purpose of rfc2462bis, I believe rfc2462bis is NOT the place where DAD optimization or DAD omission or DIID should be specified (even if we agree on introducing some of them). And I believe we agree on this as a base line. Meanwhile, one source of the confusion is an unclear wording of RFC2462. It says in Section 5.4 that - Each individual unicast address SHOULD be tested for uniqueness. and then says ... In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier. I do not necessarily think this is inconsistent (whereas the issue title contains "inconsistencies"), but the "MAY" following the "SHOULD" has surely tempted people to cause the DAD related discussions and to propose DAD omission/optimization or DIID. In my understanding, we have basically agreed in the passed discussion that we should honor the sense of the "SHOULD" rather than the "MAY". (but I may be wrong here, in which case please correct me) Having considered these points, possible resolutions *for rfc2462bis* that I can think of are: 1. harden the requirement: Each individual unicast address MUST be tested for uniqueness. No MAY for omitting the rule (i.e., remove it). We can use SHOULD instead of MUST if we need compromise. 2. MUST run DAD on all addresses for which the interface identifier is NOT globally unique (such as non EUI-64 ID). This is a proposal by Thomas Narten in June 2001. (see the issue tracker for more background information) 3. do nothing for this in rfc2462bis; leave Section 5.4 as is, do not add any text. 4. no change in the protocol specification, but add an appendix (or something) to discuss the issue on the effect of omitting/optimizing DAD. I personally prefer option 1, because this makes the intention very clear, avoiding further similar discussions and waste of energy. "MUST" may be too strong for compatibility with existing implementations, and if so, we can use "SHOULD". (And this does even not conflict with the proposed "optimistic DAD") I would not take option 2, though this makes the specification a bit clearer, since even EUI-64 IDs can collide (due to manufacturer error, etc). We could live with option 3. After all, current RFC2462 does not have an "error" on this point. This option may be a bit irresponsible, though, since the unclear text has caused diverging discussions without success. We could also live with option 4, although I do not have a concrete idea on what should be written in the appendix. Even though I have my own preference, I'm quite open to other opinions. I'd really like to make a consensus on this quickly and move forward. 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 Mon Feb 23 08:30: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 IAA24274 for ; Mon, 23 Feb 2004 08:30:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGAD-0007vG-Qn for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 08:30:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NDUPuQ030448 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 08:30:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGAD-0007v1-J1 for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 08:30:25 -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 IAA24267 for ; Mon, 23 Feb 2004 08:30:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvGAC-0002Dq-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 08:30:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvG9N-00028y-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 08:29:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvG8w-00023s-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 08:29:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG8r-0007XB-3U; Mon, 23 Feb 2004 08:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG84-0007Rk-Fq for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 08:28:12 -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 IAA24115 for ; Mon, 23 Feb 2004 08:28:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvG83-0001zs-00 for ipv6@ietf.org; Mon, 23 Feb 2004 08:28:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvG75-0001sg-00 for ipv6@ietf.org; Mon, 23 Feb 2004 08:27:12 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvG68-0001kv-00 for ipv6@ietf.org; Mon, 23 Feb 2004 08:26:12 -0500 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i1NDQBOr003271 for ; Mon, 23 Feb 2004 13:26:11 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA28181 for ; Mon, 23 Feb 2004 13:26:10 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i1NDQ9619915 for ipv6@ietf.org; Mon, 23 Feb 2004 13:26:09 GMT Date: Mon, 23 Feb 2004 13:26:09 +0000 From: Tim Chown To: "'IPv6 Mailing List'" Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" Message-ID: <20040223132609.GF15488@login.ecs.soton.ac.uk> Mail-Followup-To: 'IPv6 Mailing List' References: <4F02942E-6386-11D8-9E3D-00039376A6AA@sun.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 Fri, Feb 20, 2004 at 12:17:51PM -0800, Tony Hain wrote: > Alain, > > Recommending against all-zero's is not only a waste of time, it specifically > directs people to the thing you are trying to avoid. There is nothing that a > document can do to prevent a consultant from configuring all of his > customers with the same prefix. He can run [RANDOM] once and use that > everywhere, yet is in full compliance with the document. Even more of a > problem, an equipment manufacturer could run [RANDOM] once and burn that > value into every piece of equipment they ship. The best a document can do is > highlight the issues raised by duplicate assignments, and provide a > mechanism which solves them if used as directed. As much as some people want > to, it is not the IETF's job to legislate operational behavior. The language > in this document is appropriate and it should be published. I agree, but I think Alain is right here so could the document not point out at least why all zeros is bad? I recall asking the same question in Minneapolis... I would add a third paragraph in 3.2.2 after the RANDOM paragraph that says something like: "The use of random IDs in the locally assigned Global ID prefix gives an assurance that any network numbered using such a prefix is highly unlikely to have that address space clash with any other network that has another locally assigned Global ID prefix allocated to it. This is a particularly useful property when considering a number of scenarios, e.g. networks that merge, overlapping VPN address space or hosts mobile between such networks." I'm sure those words could be improved, but it at least gives the carrot or incentive to the reader (who might otherwise think "why should I have to type in 8 random characters in my prefix when zero would work?"). Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 23 09:05: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 JAA26020 for ; Mon, 23 Feb 2004 09:05:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGi3-0002xx-P7 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 09:05:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NE5NGG011395 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 09: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 1AvGi3-0002xi-KA for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 09: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 JAA25991 for ; Mon, 23 Feb 2004 09:05:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvGi2-0004xh-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 09:05:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvGh5-0004sW-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 09:04:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvGgM-0004o1-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 09:03:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGfl-0002Vc-Cn; Mon, 23 Feb 2004 09:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGf5-0002JN-D8 for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 09:02: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 JAA25764 for ; Mon, 23 Feb 2004 09:02:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvGf3-0004gv-00 for ipv6@ietf.org; Mon, 23 Feb 2004 09:02:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvGe2-0004bK-00 for ipv6@ietf.org; Mon, 23 Feb 2004 09:01:15 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AvGdG-0004TR-00 for ipv6@ietf.org; Mon, 23 Feb 2004 09:00:26 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1NDxoL24420; Mon, 23 Feb 2004 14:59:50 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1NDxoSj026057; Mon, 23 Feb 2004 14:59:50 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402231359.i1NDxoSj026057@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-reply-to: Your message of Mon, 23 Feb 2004 22:21:49 +0900. Date: Mon, 23 Feb 2004 14:59:50 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 In your previous mail you wrote: As you know, there have been many discussions on DAD, including - whether omitting/optimizing DAD is a good idea => IMHO this is the same thing, i.e., optimizing gives the same result than omitting. - (if yes) in which case we can omit DAD - DAD vs DIID => the last one finished by a decision (DAD, not DIID). I asked the WG chairs to clarify this point at a previous meeting, cf http://www.ietf.org/proceedings/02jul/145.htm look at "DAD vs. DIID Discussion -- Chairs", BTW slides are at http://playground.sun.com/ipng/presentations/July2002/yokohama-dad-vs-diid.pdf - ... without getting any convergence (particularly about DAD omission/optimization or DIID), unfortunately. Having considered these points, possible resolutions *for rfc2462bis* that I can think of are: 1. harden the requirement: Each individual unicast address MUST be tested for uniqueness. No MAY for omitting the rule (i.e., remove it). We can use SHOULD instead of MUST if we need compromise. => I vote for this in the context of RFC 2462bis. I personally prefer option 1, because this makes the intention very clear, avoiding further similar discussions and waste of energy. "MUST" may be too strong for compatibility with existing implementations, and if so, we can use "SHOULD". (And this does even not conflict with the proposed "optimistic DAD") => I agree. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 23 17:58: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 RAA29328 for ; Mon, 23 Feb 2004 17:58:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvP1t-000218-NW for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 17:58:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NMwPb3007748 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 17:58:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvP1t-00020t-Hw for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 17:58:25 -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 RAA29193 for ; Mon, 23 Feb 2004 17:58:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvP1q-0007Sn-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 17:58:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvP0k-0007I7-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 17:57:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvOzu-00078Q-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 17:56:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOzb-0001U9-G8; Mon, 23 Feb 2004 17:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOz8-0001SS-9F for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 17:55:34 -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 RAA28955 for ; Mon, 23 Feb 2004 17:55:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvOz5-00075g-00 for ipv6@ietf.org; Mon, 23 Feb 2004 17:55:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvOyB-000727-00 for ipv6@ietf.org; Mon, 23 Feb 2004 17:54:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AvOxk-0006yJ-00 for ipv6@ietf.org; Mon, 23 Feb 2004 17:54:08 -0500 Received: from [220.240.241.2] (helo=anchovy.zoic.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AvOxe-0004j8-EC for ipv6@ietf.org; Mon, 23 Feb 2004 17:54:02 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id EF90B701E70; Tue, 24 Feb 2004 09:48:30 +1100 (EST) Date: Tue, 24 Feb 2004 09:48:30 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: Francis Dupont Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies Message-ID: <20040223224829.GB29653@zoic.org> Mail-Followup-To: ipv6@ietf.org, Francis Dupont References: <200402231359.i1NDxoSj026057@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402231359.i1NDxoSj026057@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-23, Francis Dupont wrote: > [JINMEI Tatuya wrote:] > > > > - whether omitting/optimizing DAD is a good idea > > => IMHO this is the same thing, i.e., optimizing gives the same result > than omitting. Omitting DAD altogether removes the ability to detect and correct address collisions, whereas optimizations such as Optimistic DAD mean that while there may be a short term disruption the problem will be detected and corrected. > > - (if yes) in which case we can omit DAD > > - DAD vs DIID > > => the last one finished by a decision (DAD, not DIID). I asked the > WG chairs to clarify this point at a previous meeting, cf > http://www.ietf.org/proceedings/02jul/145.htm > look at "DAD vs. DIID Discussion -- Chairs", BTW slides are at > http://playground.sun.com/ipng/presentations/July2002/yokohama-dad-vs-diid.pdf Which is great, and will be even better when 2461/2bis are adopted, but there are already many implementations out there. Thus my suggestion in Optimistic DAD section 3.4 that when configuring an address PREFIX::SUFFIX, you should be sure toalso configure and check LINKLOCAL::SUFFIX. Is this going to be required by 'new' DAD? I'm not 100% sure about the DAD vs DIID changes yet. -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 23 22:40: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 WAA10704 for ; Mon, 23 Feb 2004 22:40:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvTQU-0006cM-Fo for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 22:40:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O3e6O4025432 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 22:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvTQR-0006c0-Jx for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 22:40:03 -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 WAA10701 for ; Mon, 23 Feb 2004 22:39:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvTQO-0006ZE-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 22:40:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvTPT-0006Rb-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 22:39:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvTOp-0006L3-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 22:38:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvTOa-0005x7-3N; Mon, 23 Feb 2004 22:38:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvTOR-0005wH-Lw for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 22:37:59 -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 WAA10623 for ; Mon, 23 Feb 2004 22:37:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvTOO-0006HW-00 for ipv6@ietf.org; Mon, 23 Feb 2004 22:37:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvTNU-0006B5-00 for ipv6@ietf.org; Mon, 23 Feb 2004 22:37:00 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AvTMq-00063S-00 for ipv6@ietf.org; Mon, 23 Feb 2004 22:36:21 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1AvTMr-0001Ju-GC for ipv6@ietf.org; Tue, 24 Feb 2004 03:36:21 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #264 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 #264] Dead code in DoS Algorithm In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Tue, 24 Feb 2004 03:36:21 +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 This is almost an editorial fix, and the change was included in the latest I-D. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Feb 23 22:41: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 WAA10808 for ; Mon, 23 Feb 2004 22:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvTRQ-0006fB-DN for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 22:41:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O3f4AU025607 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 22:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvTRQ-0006ew-8h for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 22:41: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 WAA10752 for ; Mon, 23 Feb 2004 22:40:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvTRM-0006jB-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 22:41:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvTQP-0006ZU-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 22:40:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvTPU-0006RE-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 22:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvTPS-0006CO-0C; Mon, 23 Feb 2004 22:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvTOS-0005wN-7z for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 22:38:00 -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 WAA10626 for ; Mon, 23 Feb 2004 22:37:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvTOO-0006Hc-00 for ipv6@ietf.org; Mon, 23 Feb 2004 22:37:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvTNV-0006BG-00 for ipv6@ietf.org; Mon, 23 Feb 2004 22:37:01 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AvTMr-00063T-00 for ipv6@ietf.org; Mon, 23 Feb 2004 22:36:21 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1AvTMs-0001KA-3z for ipv6@ietf.org; Tue, 24 Feb 2004 03:36:22 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #264 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 #264] Dead code in DoS Algorithm In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Tue, 24 Feb 2004 03:36: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=NO_REAL_NAME autolearn=no version=2.60 This is almost an editorial fix, and the change was included in the latest I-D. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 04:22: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 EAA08667 for ; Tue, 24 Feb 2004 04:22:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYlE-00056k-Bk for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 04:21:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O9Lqes019628 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 04:21:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYlD-00056R-F5 for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 04:21: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 EAA08653 for ; Tue, 24 Feb 2004 04:21:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvYlA-00061T-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 04:21:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvYkI-0005xz-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 04:20:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvYk2-0005uL-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 04:20:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYjU-0004rl-Qv; Tue, 24 Feb 2004 04:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYjK-0004qh-30 for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 04:19:54 -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 EAA08572 for ; Tue, 24 Feb 2004 04:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvYjH-0005tc-00 for ipv6@ietf.org; Tue, 24 Feb 2004 04:19:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvYiI-0005pm-00 for ipv6@ietf.org; Tue, 24 Feb 2004 04:18:50 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AvYhn-0005l0-00 for ipv6@ietf.org; Tue, 24 Feb 2004 04:18:19 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1O9HjG22050; Tue, 24 Feb 2004 10:17:45 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1O9HjSj029096; Tue, 24 Feb 2004 10:17:45 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402240917.i1O9HjSj029096@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Nick 'Sharkey' Moore" cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-reply-to: Your message of Tue, 24 Feb 2004 09:48:30 +1100. <20040223224829.GB29653@zoic.org> Date: Tue, 24 Feb 2004 10:17:45 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 In your previous mail you wrote: > > - whether omitting/optimizing DAD is a good idea > > => IMHO this is the same thing, i.e., optimizing gives the same result > than omitting. Omitting DAD altogether removes the ability to detect and correct address collisions, whereas optimizations such as Optimistic DAD mean that while there may be a short term disruption the problem will be detected and corrected. => in the real world this kind of problem cannot be corrected... The only thing you can do is to avoid to reproduce the same error again. Regards Francis.Dupont@enst-bretagne.fr PS: optimistic DAD is like optimistic russian roulette: look at in the chamber after to check it is empty. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 05:01: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 FAA10371 for ; Tue, 24 Feb 2004 05:01:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZNC-00081p-Gl for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 05:01:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OA15Ne030851 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 05:01:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZN7-00080u-Qi for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 05:01: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 FAA10351 for ; Tue, 24 Feb 2004 05:00:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZN4-0001cd-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 05:00:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZMF-0001XG-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 05:00:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvZLb-0001RE-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 04:59:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZLE-0007hI-Ji; Tue, 24 Feb 2004 04:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZL6-0007g8-2e for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 04:58:58 -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 EAA10219 for ; Tue, 24 Feb 2004 04:58:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZL2-0001Nw-00 for ipv6@ietf.org; Tue, 24 Feb 2004 04:58:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZK9-0001KE-00 for ipv6@ietf.org; Tue, 24 Feb 2004 04:57:58 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx with esmtp (Exim 4.12) id 1AvZJv-0001GB-00 for ipv6@ietf.org; Tue, 24 Feb 2004 04:57:44 -0500 Received: from localhost ([130.194.13.84]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L6ZS85P4UM9365BN@vaxc.its.monash.edu.au> for ipv6@ietf.org; Tue, 24 Feb 2004 20:54:55 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id D849839C00D; Tue, 24 Feb 2004 20:54:54 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id A127B2DC010; Tue, 24 Feb 2004 20:54:54 +1100 (EST) Date: Tue, 24 Feb 2004 20:54:54 +1100 From: Greg Daley Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies To: Francis Dupont Cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <403B1F6E.3040707@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <200402240917.i1O9HjSj029096@givry.rennes.enst-bretagne.fr> 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 Francis, Francis Dupont wrote: > In your previous mail you wrote: > > > > - whether omitting/optimizing DAD is a good idea > > > > => IMHO this is the same thing, i.e., optimizing gives the same result > > than omitting. > > Omitting DAD altogether removes the ability to detect and correct > address collisions, whereas optimizations such as Optimistic DAD > mean that while there may be a short term disruption the problem > will be detected and corrected. > > => in the real world this kind of problem cannot be corrected... > The only thing you can do is to avoid to reproduce the same error again. That's a rather broad statement to make, since there may not be L2 address conflicts, and EUI based v6 addresses may not be used. What really matters then is the effect on (the real) address owner's and configuring node's applications. I think it's worth getting implementors' experience with address conflicts with DAD, without DAD and with optimizations. > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: optimistic DAD is like optimistic russian roulette: look at in the > chamber after to check it is empty. That's highly emotive talk which doesn't help the discussion. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 05:08: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 FAA10660 for ; Tue, 24 Feb 2004 05:08:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZTy-0000Kq-Vt for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 05:08:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OA86BE001268 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 05:08:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZTx-0000KM-BR for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 05:08:05 -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 FAA10646 for ; Tue, 24 Feb 2004 05:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZTs-0002GA-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 05:08:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZSy-0002BG-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 05:07:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvZSI-00025u-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 05:06:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZS1-0008RJ-KX; Tue, 24 Feb 2004 05:06:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZRr-0008Qj-Mr for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 05:05:55 -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 FAA10556 for ; Tue, 24 Feb 2004 05:05:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZRo-00024Q-00 for ipv6@ietf.org; Tue, 24 Feb 2004 05:05:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZQz-00020j-00 for ipv6@ietf.org; Tue, 24 Feb 2004 05:05:02 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AvZQS-0001vu-00 for ipv6@ietf.org; Tue, 24 Feb 2004 05:04:29 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 4825E70A7B0; Tue, 24 Feb 2004 21:04:26 +1100 (EST) Date: Tue, 24 Feb 2004 21:04:25 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: Francis Dupont Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies Message-ID: <20040224100425.GA1668@zoic.org> Mail-Followup-To: ipv6@ietf.org, Francis Dupont References: <20040223224829.GB29653@zoic.org> <200402240917.i1O9HjSj029096@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402240917.i1O9HjSj029096@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-24, Francis Dupont wrote: > [Nick 'sharkey' Moore wrote:] > > > Omitting DAD altogether removes the ability to detect and correct > > address collisions, whereas optimizations such as Optimistic DAD > > mean that while there may be a short term disruption the problem > > will be detected and corrected. > > => in the real world this kind of problem cannot be corrected... > The only thing you can do is to avoid to reproduce the same error again. Was there a specific non-recoverable scenario you had in mind there? -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 05:32: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 FAA11678 for ; Tue, 24 Feb 2004 05:32:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZrJ-000275-0Y for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 05:32:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OAWCPt008122 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 05:32:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZrI-00026v-RC for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 05:32:12 -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 FAA11663 for ; Tue, 24 Feb 2004 05:32:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZrF-0004Jk-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 05:32:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZqS-0004DQ-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 05:31:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvZpn-00046E-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 05:30:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZpB-0001pW-1Q; Tue, 24 Feb 2004 05:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZoC-0001iv-Pa for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 05:29:00 -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 FAA11472 for ; Tue, 24 Feb 2004 05:28:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZo9-0003y8-00 for ipv6@ietf.org; Tue, 24 Feb 2004 05:28:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZnF-0003tU-00 for ipv6@ietf.org; Tue, 24 Feb 2004 05:28:02 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AvZml-0003oH-00 for ipv6@ietf.org; Tue, 24 Feb 2004 05:27:31 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1OAQtG26790; Tue, 24 Feb 2004 11:26:55 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1OAQtSj029701; Tue, 24 Feb 2004 11:26:55 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402241026.i1OAQtSj029701@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: greg.daley@eng.monash.edu.au cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-reply-to: Your message of Tue, 24 Feb 2004 20:54:54 +1100. <403B1F6E.3040707@eng.monash.edu.au> Date: Tue, 24 Feb 2004 11:26:55 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 In your previous mail you wrote: > Omitting DAD altogether removes the ability to detect and correct > address collisions, whereas optimizations such as Optimistic DAD > mean that while there may be a short term disruption the problem > will be detected and corrected. > > => in the real world this kind of problem cannot be corrected... > The only thing you can do is to avoid to reproduce the same error again. That's a rather broad statement to make, since there may not be L2 address conflicts, and EUI based v6 addresses may not be used. => L2 address conflicts are very uncommon. Personally I never got one. The usual problem is a config which is copied but not updated, and the auto-conf does not save you because it is not used for every nodes. What really matters then is the effect on (the real) address owner's and configuring node's applications. => usually both the real owner and the offender are dead. Murphy's law makes the real owner an important server. I think it's worth getting implementors' experience with address conflicts with DAD, without DAD and with optimizations. => I am an implementor and from time to time a network manager so I can say that: - address duplications happen - at least once DAD saved us from real trouble even the IPv6 network was very small at this time So I really believe in the DAD usefulness and if you'd like to remove or "optimize" DAD on one of my networks my answer will be "NO!". Regards Francis.Dupont@enst-bretagne.fr > PS: optimistic DAD is like optimistic russian roulette: look at in the > chamber after to check it is empty. That's highly emotive talk which doesn't help the discussion. => the optimistic DAD is an old topic now and I believe some of us don't (didn't? :-) understand our opinion about it. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 05:45: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 FAA12229 for ; Tue, 24 Feb 2004 05:45:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ava3b-0003Dj-H3 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 05:44:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OAitHj012373 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 05:44:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ava3b-0003DU-Bb for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 05:44:55 -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 FAA12222 for ; Tue, 24 Feb 2004 05:44:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ava3X-0005YE-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 05:44:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ava2Z-0005UY-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 05:43:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ava25-0005RI-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 05:43:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ava1l-0002s8-O4; Tue, 24 Feb 2004 05:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ava1e-0002rf-1F for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 05:42:54 -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 FAA12181 for ; Tue, 24 Feb 2004 05:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ava1a-0005Qg-00 for ipv6@ietf.org; Tue, 24 Feb 2004 05:42:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ava0g-0005N2-00 for ipv6@ietf.org; Tue, 24 Feb 2004 05:41:55 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Ava03-0005B9-00 for ipv6@ietf.org; Tue, 24 Feb 2004 05:41:15 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1OAegG27866; Tue, 24 Feb 2004 11:40:42 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1OAegSj029747; Tue, 24 Feb 2004 11:40:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402241040.i1OAegSj029747@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Nick 'Sharkey' Moore" cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-reply-to: Your message of Tue, 24 Feb 2004 21:04:25 +1100. <20040224100425.GA1668@zoic.org> Date: Tue, 24 Feb 2004 11:40:42 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 In your previous mail you wrote: > => in the real world this kind of problem cannot be corrected... > The only thing you can do is to avoid to reproduce the same error again. Was there a specific non-recoverable scenario you had in mind there? => just ask large network managers. Address duplication is a real nightmare to fix in the real world. Francis.Dupont@enst-bretagne.fr PS: as I explained already many times in this list, the decision to omit/optimize/junk the DAD must be in the hand of the network manager, as he is the guy who shall have to cleanup the mess when the should-not- happen event will happen. And this is very easy, just say that the DupAddrDetectTransmits configuration parameter MUST be set according to the link policy (today policies are more link-type, what I'd like to get is a per-link policy defined by the local network manager). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 06:22: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 GAA13497 for ; Tue, 24 Feb 2004 06:22:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvadR-0005Iq-Up for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 06:21:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OBLvMs020372 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 06:21:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvadR-0005IT-4j for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 06:21: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 GAA13485 for ; Tue, 24 Feb 2004 06:21:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvadN-0000pd-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 06:21:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvacV-0000ld-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 06:21:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avac1-0000hV-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 06:20:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avabi-00053m-9a; Tue, 24 Feb 2004 06:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvabV-00052n-IQ for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 06: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 GAA13427 for ; Tue, 24 Feb 2004 06:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvabR-0000g5-00 for ipv6@ietf.org; Tue, 24 Feb 2004 06:19:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvaaX-0000cS-00 for ipv6@ietf.org; Tue, 24 Feb 2004 06:18:57 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AvaZn-0000Yc-00 for ipv6@ietf.org; Tue, 24 Feb 2004 06:18:11 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id A7E456A904; Tue, 24 Feb 2004 13:18:12 +0200 (EET) Message-ID: <403B3272.4040202@kolumbus.fi> Date: Tue, 24 Feb 2004 13:16:02 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: greg.daley@eng.monash.edu.au, "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies References: <200402241026.i1OAQtSj029701@givry.rennes.enst-bretagne.fr> In-Reply-To: <200402241026.i1OAQtSj029701@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francis Dupont wrote: > So I really believe in the DAD usefulness and if you'd like to remove > or "optimize" DAD on one of my networks my answer will be "NO!". I believe the optimistic DAD folks are very keen on keeping the DAD functional. That is, it is a requirement that networks and nodes must be able to recover from a collision situation. No one is proposing removing DAD. Since most folks appear to agree that any optimization is not a part of 2462bis and that Jinmei's option 1 is reasonable, I think we can close the issue for 2462bis. As for the rest, I believe we should discuss optimistic or optimized DAD schemes under a different thread, since this really has nothing to do with 2462bis. And for that discussion, let's not label someone's method a priori as "removal". There may be specific concerns in the specific methods, but if that's the case then they have to be corrected or rejected. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 06:29: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 GAA13692 for ; Tue, 24 Feb 2004 06:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvakI-0005oI-MB for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 06:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OBT23F022330 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 06:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvakI-0005o4-Hn for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 06:29: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 GAA13680 for ; Tue, 24 Feb 2004 06:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvakE-0001Nl-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 06:28:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvajK-0001JL-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 06:28:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvaiT-0001Em-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 06:27:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvaiL-0005Uh-QN; Tue, 24 Feb 2004 06:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvahM-0005Te-DQ for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 06:26:00 -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 GAA13612 for ; Tue, 24 Feb 2004 06:25:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvahI-0001AD-00 for ipv6@ietf.org; Tue, 24 Feb 2004 06:25:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvagN-00015u-00 for ipv6@ietf.org; Tue, 24 Feb 2004 06:25:00 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Avafb-00011q-00 for ipv6@ietf.org; Tue, 24 Feb 2004 06:24:11 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 6387D6A902; Tue, 24 Feb 2004 13:24:12 +0200 (EET) Message-ID: <403B33DA.3030809@kolumbus.fi> Date: Tue, 24 Feb 2004 13:22:02 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies References: <200402241040.i1OAegSj029747@givry.rennes.enst-bretagne.fr> In-Reply-To: <200402241040.i1OAegSj029747@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francis Dupont wrote: > In your previous mail you wrote: > > > => in the real world this kind of problem cannot be corrected... > > The only thing you can do is to avoid to reproduce the same error again. > > Was there a specific non-recoverable scenario you had in mind there? > > => just ask large network managers. Address duplication is a real > nightmare to fix in the real world. Sure. But aren't you assuming that they have to go in and manually recover? I believe what the optimistic or optimized DAD folks intend to do is to provide a *protocol* that allows both (a) faster operation and (b) recovery if a collision happens. I am unable to say for sure if, say, draft-moore, accomplishes this goal. It probably needs more analysis before we can be certain. However, I do not see any obvious problems. Note: In some cases the collisions is due to L2 address collision, which I agree is quite troublesome. But optimistic DAD does not appear to change anything with regards to this. If you get a collision then you detect that with optimistic DAD as well, and then follow 2462bis rules to disable the interface, or whatever that was required. And in many cases the address collision is not based on L2. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 07:11: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 HAA15272 for ; Tue, 24 Feb 2004 07:11: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 1AvbOz-0000QK-5K for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 07:11:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OCB5fF001622 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 07:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbOy-0000Q5-U7 for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 07:11: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 HAA15234 for ; Tue, 24 Feb 2004 07:11:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbOu-00057R-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 07:11:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbNw-00051w-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 07:10:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvbNH-0004xT-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 07:09:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbN1-0008U2-Hu; Tue, 24 Feb 2004 07:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbM7-0008Qv-6w for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 07:08:07 -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 HAA15140 for ; Tue, 24 Feb 2004 07:08:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbM2-0004sZ-00 for ipv6@ietf.org; Tue, 24 Feb 2004 07:08:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbL5-0004nw-00 for ipv6@ietf.org; Tue, 24 Feb 2004 07:07:04 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AvbKn-0004j8-00 for ipv6@ietf.org; Tue, 24 Feb 2004 07:06:45 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 3F31E6A902; Tue, 24 Feb 2004 14:06:37 +0200 (EET) Message-ID: <403B3DCB.80301@kolumbus.fi> Date: Tue, 24 Feb 2004 14:04:27 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies References: <200402241040.i1OAegSj029747@givry.rennes.enst-bretagne.fr> <403B33DA.3030809@kolumbus.fi> In-Reply-To: <403B33DA.3030809@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry to respond to my own e-mail. But I wanted to clarify one thing. Manual recovery is fixing the problem, like reconfiguring the address. The recovery that optimistic DAD provides is however different. It just corrects a temporary disruption that the optimistic assumption may have caused. Whether you have DAD or optimistic DAD running at the bottom is insignificant to the network manager, iff optimistic DAD detects collisions reliably. Jari Arkko wrote: > Francis Dupont wrote: > >> In your previous mail you wrote: >> >> > => in the real world this kind of problem cannot be corrected... >> > The only thing you can do is to avoid to reproduce the same error >> again. >> Was there a specific non-recoverable scenario you had in mind >> there? >> => just ask large network managers. Address duplication is a real >> nightmare to fix in the real world. > > > Sure. But aren't you assuming that they have to go in and manually > recover? I believe what the optimistic or optimized DAD > folks intend to do is to provide a *protocol* that allows both > (a) faster operation and (b) recovery if a collision happens. > > I am unable to say for sure if, say, draft-moore, accomplishes this goal. > It probably needs more analysis before we can be certain. However, > I do not see any obvious problems. > > Note: In some cases the collisions is due to L2 address collision, > which I agree is quite troublesome. But optimistic DAD does not > appear to change anything with regards to this. If you get a collision > then you detect that with optimistic DAD as well, and then follow > 2462bis rules to disable the interface, or whatever that was required. > And in many cases the address collision is not based on L2. > > --Jari > > > -------------------------------------------------------------------- > 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 Feb 24 09:08: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 JAA21093 for ; Tue, 24 Feb 2004 09:08: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 1AvdER-0000Ce-IQ for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 09:08:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OE8JEn000774 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 09:08:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdER-0000CP-7D for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 09:08: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 JAA21072 for ; Tue, 24 Feb 2004 09:08:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvdEP-0000sz-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:08:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvdDV-0000mS-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:07:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvdCo-0000fT-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:06:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdCF-00080T-16; Tue, 24 Feb 2004 09:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdBr-0007yh-KL for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 09:05: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 JAA20733 for ; Tue, 24 Feb 2004 09:05:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvdBq-0000UE-00 for ipv6@ietf.org; Tue, 24 Feb 2004 09:05:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvdAm-0000Ih-00 for ipv6@ietf.org; Tue, 24 Feb 2004 09:04:33 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Avd9m-00005g-00 for ipv6@ietf.org; Tue, 24 Feb 2004 09:03:30 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1OE2mG07699; Tue, 24 Feb 2004 15:02:48 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1OE2iSj030222; Tue, 24 Feb 2004 15:02:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402241402.i1OE2iSj030222@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-reply-to: Your message of Tue, 24 Feb 2004 13:22:02 +0200. <403B33DA.3030809@kolumbus.fi> Date: Tue, 24 Feb 2004 15:02:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 In your previous mail you wrote: > => just ask large network managers. Address duplication is a real > nightmare to fix in the real world. Sure. But aren't you assuming that they have to go in and manually recover? => it is the case for IPv4 because this kind of event is very rare so there is no need to add an automatic recover tool. But IMHO the real question is where are these problems for? They don't come from hazard but in 99.99% of cases from configuration errors. I believe what the optimistic or optimized DAD folks intend to do is to provide a *protocol* that allows both (a) faster operation and (b) recovery if a collision happens. => this is a half baked solution, i.e., either you don't want duplicates on your network and you enforce DAD, or you accept possible problems and you makes the live of mobile nodes (and of implementors) far easier. I am unable to say for sure if, say, draft-moore, accomplishes this goal. It probably needs more analysis before we can be certain. However, I do not see any obvious problems. => the problem is the goal of optimistic/optimized DAD has no interest. Note: In some cases the collisions is due to L2 address collision, which I agree is quite troublesome. => L2 address collisions are fatal. And IMHO we should not even try to solve them at L3 (:-). But optimistic DAD does not appear to change anything with regards to this. If you get a collision then you detect that with optimistic DAD as well, and then follow 2462bis rules to disable the interface, or whatever that was required. => what we need is collision avoidance, no collision detection after damage. And in many cases the address collision is not based on L2. => currently there are three common ways to assign addresses: - EUI64 based, i.e., relying on L2 address universal uniqueness (read my EMEI draft to use it on mobile phones too) - RFC 3401, i.e., relying on the "birthday" paradox - manual, i.e., relying on the care of node managers. Obviously only the last one is a real source of trouble. Unfortunately it is a common case for routers (EUI64 requires that you work only with a mouse and cut&paste), some servers (DNS servers for instance, when you look at http://www.root-servers.org/ you get no EUI64 based IID) and some other cases (multi-interface KAME hosts here). But this should be easy to avoid this case on a link dedicated to mobile nodes... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 09:19: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 JAA21814 for ; Tue, 24 Feb 2004 09:19:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdOs-00014Z-7m for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 09:19:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OEJ6uw004116 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 09:19:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdOr-00014J-QS for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 09:19:05 -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 JAA21784 for ; Tue, 24 Feb 2004 09:19:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvdOq-0002Cr-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:19:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvdNv-00027V-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:18:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvdN4-00022Y-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:17:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdMr-0000hx-T5; Tue, 24 Feb 2004 09:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdM2-0000fa-NR for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 09:16:10 -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 JAA21659 for ; Tue, 24 Feb 2004 09:16:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvdM0-0001vG-00 for ipv6@ietf.org; Tue, 24 Feb 2004 09:16:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvdL3-0001nb-00 for ipv6@ietf.org; Tue, 24 Feb 2004 09:15:11 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AvdK4-0001ZK-00 for ipv6@ietf.org; Tue, 24 Feb 2004 09:14:09 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1OEDUG08518; Tue, 24 Feb 2004 15:13:30 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1OEDUSj030290; Tue, 24 Feb 2004 15:13:30 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402241413.i1OEDUSj030290@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-reply-to: Your message of Tue, 24 Feb 2004 14:04:27 +0200. <403B3DCB.80301@kolumbus.fi> Date: Tue, 24 Feb 2004 15:13:30 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 In your previous mail you wrote: Sorry to respond to my own e-mail. => our keyboards have large enter keys, and often more than one (:-). But I wanted to clarify one thing. Manual recovery is fixing the problem, like reconfiguring the address. => and in some cases (*all* the real cases I saw in fact) it was the only way to fix the problem. The recovery that optimistic DAD provides is however different. It just corrects a temporary disruption that the optimistic assumption may have caused. Whether you have DAD or optimistic DAD running at the bottom is insignificant to the network manager, iff optimistic DAD detects collisions reliably. => you make a hidden and wrong assumption on the real source of the problem... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 09:58: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 JAA23629 for ; Tue, 24 Feb 2004 09:58:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ave0a-0004fg-9r for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 09:58:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OEw4iB017950 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 09:58:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ave0a-0004fR-5a for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 09:58: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 JAA23587 for ; Tue, 24 Feb 2004 09:58:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ave0Y-00068O-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:58:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avdzd-00062W-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:57:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Avdyh-0005xD-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:56:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Avdyh-00052h-LC for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:56:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdyd-0004HV-2q; Tue, 24 Feb 2004 09:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdxz-000449-5d for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 09:55: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 JAA23439 for ; Tue, 24 Feb 2004 09:55:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avdxx-0005qd-00 for ipv6@ietf.org; Tue, 24 Feb 2004 09:55:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvdxG-0005hb-00 for ipv6@ietf.org; Tue, 24 Feb 2004 09:54:39 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AvdwB-0005TT-00 for ipv6@ietf.org; Tue, 24 Feb 2004 09:53:31 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1OEquG10650; Tue, 24 Feb 2004 15:52:56 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1OEqvSj030687; Tue, 24 Feb 2004 15:52:57 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402241452.i1OEqvSj030687@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: greg.daley@eng.monash.edu.au cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-reply-to: Your message of Tue, 24 Feb 2004 21:44:12 +1100. <403B2AFC.1060506@eng.monash.edu.au> Date: Tue, 24 Feb 2004 15:52:57 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 In your previous mail you wrote: > => usually both the real owner and the offender are dead. Murphy's law > makes the real owner an important server. This is not going to happen in Nick's optimistic DAD draft. => I disagree: even in Nick's draft the second system has both a service disruption and has to switch to another address. So as to be the second system is just a matter of race Murphy's law implies it will be the important one. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 10:09: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 KAA24572 for ; Tue, 24 Feb 2004 10:09: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 1AveBG-0000gk-8t for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 10:09:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OF966Y002639 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 10:09:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AveBG-0000gU-36 for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 10:09: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 KAA24514 for ; Tue, 24 Feb 2004 10:09:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AveBD-0007CN-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 10:09:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AveAU-00076s-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 10:08:19 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ave9d-00070U-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 10:07:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ave9d-00059z-LM for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 10:07:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ave9G-00089t-SJ; Tue, 24 Feb 2004 10:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ave8P-0007wZ-Pn for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 10:06:09 -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 KAA24158 for ; Tue, 24 Feb 2004 10:06:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ave8N-0006rv-00 for ipv6@ietf.org; Tue, 24 Feb 2004 10:06:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ave7V-0006nE-00 for ipv6@ietf.org; Tue, 24 Feb 2004 10:05:14 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1Ave78-0006iF-00 for ipv6@ietf.org; Tue, 24 Feb 2004 10:04:50 -0500 Received: from localhost ([130.194.13.81]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L6ZTXB58A2902I6B@vaxh.its.monash.edu.au> for ipv6@ietf.org; Tue, 24 Feb 2004 21:44:13 +1100 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id EA8E11B000D; Tue, 24 Feb 2004 21:44:12 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id D947C12400B; Tue, 24 Feb 2004 21:44:12 +1100 (EST) Date: Tue, 24 Feb 2004 21:44:12 +1100 From: Greg Daley Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies To: Francis Dupont Cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <403B2AFC.1060506@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <200402241026.i1OAQtSj029701@givry.rennes.enst-bretagne.fr> 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 Francis, Francis Dupont wrote: > In your previous mail you wrote: > > > Omitting DAD altogether removes the ability to detect and correct > > address collisions, whereas optimizations such as Optimistic DAD > > mean that while there may be a short term disruption the problem > > will be detected and corrected. > > > > => in the real world this kind of problem cannot be corrected... > > The only thing you can do is to avoid to reproduce the same error again. > > That's a rather broad statement to make, > since there may not be L2 address conflicts, and > EUI based v6 addresses may not be used. > > => L2 address conflicts are very uncommon. Personally I never got one. > The usual problem is a config which is copied but not updated, > and the auto-conf does not save you because it is not used for every nodes. > > What really matters then is the effect on (the real) > address owner's and configuring node's applications. > > => usually both the real owner and the offender are dead. Murphy's law > makes the real owner an important server. This is not going to happen in Nick's optimistic DAD draft. The procedures don't affect existing neighbour cache entries (such as would be in place for an important server). Additionally, the procedure cleans up cache entries for itself, and provides for stifling of upper layer (non-)reachability indications from the tentative address. Maybe you're thinking about another (prior) proposal. > I think it's worth getting implementors' experience > with address conflicts with DAD, without DAD and with > optimizations. > > => I am an implementor and from time to time a network manager so > I can say that: > - address duplications happen > - at least once DAD saved us from real trouble even the IPv6 network > was very small at this time > So I really believe in the DAD usefulness and if you'd like to remove > or "optimize" DAD on one of my networks my answer will be "NO!". Well I'm not sure if optimize has any sinister meanings. An optimization doesn't necessarily remove or undermine an existing procedure (if done correctly). > Regards > > Francis.Dupont@enst-bretagne.fr > > > PS: optimistic DAD is like optimistic russian roulette: look at in the > > chamber after to check it is empty. > > That's highly emotive talk which doesn't help the discussion. > > => the optimistic DAD is an old topic now and I believe some of us don't > (didn't? :-) understand our opinion about it. Roulette aside, I'm sure that if you can shoot a hole in the draft's technical merits, it will go away. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 10:13: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 KAA25053 for ; Tue, 24 Feb 2004 10:13:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AveF6-00025K-Jn for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 10:13:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OFD4wo008008 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 10:13:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AveF6-000253-EQ for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 10:13: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 KAA24986 for ; Tue, 24 Feb 2004 10:13:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AveF4-0007aA-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 10:13:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AveE5-0007Us-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 10:12:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AveDJ-0007R0-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 10:11:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AveD9-00016p-1k; Tue, 24 Feb 2004 10:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AveCF-0000uS-4l for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 10:10:07 -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 KAA24634 for ; Tue, 24 Feb 2004 10:10:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AveCD-0007JC-00 for ipv6@ietf.org; Tue, 24 Feb 2004 10:10:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AveBC-0007CA-00 for ipv6@ietf.org; Tue, 24 Feb 2004 10:09:02 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AveAM-00071T-00 for ipv6@ietf.org; Tue, 24 Feb 2004 10:08:10 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1OF7ZG11882; Tue, 24 Feb 2004 16:07:35 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1OF7ZSj030776; Tue, 24 Feb 2004 16:07:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402241507.i1OF7ZSj030776@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-reply-to: Your message of Tue, 24 Feb 2004 16:49:57 +0200. <403B6495.80005@kolumbus.fi> Date: Tue, 24 Feb 2004 16:07:35 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 In your previous mail you wrote: > => what we need is collision avoidance, no collision detection after > damage. Here I have a slightly different opinion. There are two questions: do we want avoidance or detection, and whether optimistic DAD implies "possible problems". Regarding the first question, I think what we can achieve depends on how the address is assigned, random/ eui/conf. Generally, for the last two we can only provide detection and then wait for further input from the user; for the first we can still continue and use another address. But this has little to do with regular or optimistic DAD, both provide detection as the name implies. => I have a different conclusion from your argument: detection is enough when the recovery is always easy and without drawback, i.e., only in the first assignment method (random). With other methods (eui/conf), a collision is a major problem so it is important to avoid it and not only to detect it. Regarding the second question, I do not agree that an optimistic DAD implies problems. It seems reasonable that an optimized variant would detect duplicates with an equivalent reliability as regular DAD; both send similar messages and expect other nodes to answer. Would you agree? => yes but my argument is that detection is not enough. But perhaps you are worried about the possible temporary disruptions to ongoing traffic? => yes. Is that your concern? => no only because one of the two collided systems should loose its address. I looked at Nick's draft, and did not find it alarming myself. But others may have a different opinion. Let me ask you this: if it was shown that a particular optimistic DAD protocol did not have even temporary disruptions, would you still think it implies "possible problems"? => read my answer to the next comment. > I am unable to say for sure if, say, draft-moore, accomplishes this goal. > It probably needs more analysis before we can be certain. However, > I do not see any obvious problems. > > => the problem is the goal of optimistic/optimized DAD has no interest. I'm not sure I can parse what you are saying. => easy: the optimistic/optimized DAD stuff solves the wrong problem. There seems to be some people who do have an interest in quick startup & movement times. => in this case they should use dedicated links where DAD is disabled, RAs are used at a silly high rate, etc. I agree that DAD is not the only issue to look at here -- I once calculated the number of messages that were required on a wireless LAN for L2 & L3 network attachment if you needed access control, link layer security, mobility, and so on. That number was pretty high, over a dozen even in the most optimistic scenario, significantly worse in others. And then there were multiple delay periods, all contributing to the overall delay. DAD is one of these delay periods. => so you should agree that dedicated links are a good solution, and no DAD is a part of the specific tuning. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 10:47: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 KAA27042 for ; Tue, 24 Feb 2004 10:47:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvemB-0000Xv-FH for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 10:47:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OFlFbP002099 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 10:47:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvemB-0000Xm-9B for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 10:47:15 -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 KAA27026 for ; Tue, 24 Feb 2004 10:47:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avem8-0002rr-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 10:47:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avel6-0002mI-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 10:46:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvekU-0002hf-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 10:45:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avek4-0000Em-0g; Tue, 24 Feb 2004 10:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvejB-0000DL-NP for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 10:44:10 -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 KAA26959 for ; Tue, 24 Feb 2004 10:44:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avej9-0002cc-00 for ipv6@ietf.org; Tue, 24 Feb 2004 10:44:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AveiE-0002Yc-00 for ipv6@ietf.org; Tue, 24 Feb 2004 10:43:10 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AvehM-0002Pb-00 for ipv6@ietf.org; Tue, 24 Feb 2004 10:42:16 -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 i1OFfgL23634; Tue, 24 Feb 2004 07:41:42 -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 i1OFrNlN018051 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 24 Feb 2004 07:53:27 -0800 Message-ID: <403B7091.1@innovationslab.net> Date: Tue, 24 Feb 2004 10:41:05 -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: Francis Dupont CC: Jari Arkko , "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies References: <200402241507.i1OF7ZSj030776@givry.rennes.enst-bretagne.fr> In-Reply-To: <200402241507.i1OF7ZSj030776@givry.rennes.enst-bretagne.fr> 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 While the topic of Optimistic DAD is interesting, I believe we are getting work items crossed here. The consensus I see is to not make changes to 2462 wrt Optimistic DAD. Therefore, we can drop this discussion as it relates to the 2462 update. There is a slot in Seoul to discuss Optimistic DAD in general. If people wish to discuss it prior to Seoul, please do so in another thread. We now return you to your regular programming... 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 Feb 24 13:15: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 NAA02312 for ; Tue, 24 Feb 2004 13:15:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avh5X-0004RL-Ip for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 13:15:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OIFNeG017068 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 13:15:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avh5W-0004RD-Rh for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 13:15:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02289 for ; Tue, 24 Feb 2004 13:15:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avh5U-0001v7-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 13:15:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avh4X-0001oP-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 13:14:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avh3u-0001j8-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 13:13:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avh3F-0003na-RH; Tue, 24 Feb 2004 13:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avh2S-0003m3-7S for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 13:12:16 -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 NAA02067 for ; Tue, 24 Feb 2004 13:12:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avh2Q-0001cW-00 for ipv6@ietf.org; Tue, 24 Feb 2004 13:12:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avh1X-0001Xd-00 for ipv6@ietf.org; Tue, 24 Feb 2004 13:11:15 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Avh0r-0001OB-00; Tue, 24 Feb 2004 13:10:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1OI9ma30276; Tue, 24 Feb 2004 10:09:48 -0800 X-mProtect: <200402241809> 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 smtpdjirqWf; Tue, 24 Feb 2004 10:09:45 PST Message-ID: <403B936C.4040501@iprg.nokia.com> Date: Tue, 24 Feb 2004 10:09:48 -0800 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: Alain Durand CC: Brian Haberman , Bob Hinden , The IESG , Margaret Wasserman , IPv6 Mailing List , Thomas Narten , ftemplin@iprg.nokia.com Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" References: <40340FCD.9070609@innovationslab.net> <4F02942E-6386-11D8-9E3D-00039376A6AA@sun.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 Alain, Speaking only as an individual wg participant, I appreciate the concerns you are raising but am hoping that you are not contemplating a divisive and time-consuming appeals process such as the one we have just come through for site local deprecation. Please consider that published documents are by no means fixed for all time; rather, there is clear past precedence for course-corrections once operational experience is gained, e.g., through supplementary documents, BCPs, updates to existing documents, etc. (We are in fact seeing numerous instances of the latter in current wg activities.) Regards, Fred L. Templin ftemplin@iprg.nokia.com Alain Durand wrote: > > Dears ADs, > > I found it very unfortunate that the chair decided to request to > advance this document > without answering two major issues I raised during the last call: > > - Permanent allocation is equivalent of selling address space, which > is very different from > the notion of stewardship that are now in place for any IP address > allocation today. > There are a number of legal questions not answered around this point. > More, this is imposing a business model to the entity that will be > in charge of the allocations, > and I believe that the IETF should refrain from imposing business > model. > > - The document does not contain any wording recommending against the > 'all zero' self allocation. > It merely say that: > "Locally assigned global IDs MUST be generated with a pseudo-random > algorithm consistent with [RANDOM].". However, it should be noted > that [RANDOM] > or RFC1750 does not contain any mandate, just provide ideas on how > to do things. > An 'all zero' self allocation would create the prefix FD00::/48 and > will be very tempting > to use by many. > This working group just spend more than a year to deprecate the site > local > fec0::/10 prefixes, just to reinvent it here. > > As the request to advance this document came from the Ipv6 wg chairs, > representing the wg, > it is my opinion that the IPv6 Working Groug has made an incorrect > technical choice which > places the quality and/or integrity of the Working Group's product(s) > in significant > jeopardy. > > As the request to advance this document has already been sent to you, > ADs, > this is my appeal to you to reject it and send it back to the working > group. > > - Alain. > > > > > > On Feb 18, 2004, at 5:22 PM, Brian Haberman wrote: > >> Margaret & Thomas, >> On behalf of the IPv6 working group, the chairs request the >> advancement of: >> >> Title : Unique Local IPv6 Unicast Addresses >> Author(s) : R. Hinden, B. Haberman >> Filename : draft-ietf-ipv6-unique-local-addr-03.txt >> Pages : 16 >> Date : 2004-2-13 >> >> as a Proposed Standard. The -02 version completed working group last >> call on 02/02/2004. This version addresses issues raised during the >> last call period. >> >> Regards, >> Brian & Bob >> IPv6 WG co-chairs >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > 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 Feb 24 13:15: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 NAA02329 for ; Tue, 24 Feb 2004 13:15:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avh5a-0004Rt-6N for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 13:15:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OIFQ6W017094 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 13:15:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avh5X-0004RQ-Lj for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 13:15: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 NAA02292 for ; Tue, 24 Feb 2004 13:15:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avh5V-0001vE-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 13:15:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avh4Y-0001oX-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 13:14:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avh3u-0001j9-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 13:13:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avh3H-0003nm-6A; Tue, 24 Feb 2004 13:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avh2V-0003mG-BY for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 13:12:17 -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 NAA02082 for ; Tue, 24 Feb 2004 13:12:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avh2T-0001cv-00 for ipv6@ietf.org; Tue, 24 Feb 2004 13:12:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avh1b-0001YG-00 for ipv6@ietf.org; Tue, 24 Feb 2004 13:11:20 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Avh19-0001Rf-00; Tue, 24 Feb 2004 13:10:51 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1OIA6631034; Tue, 24 Feb 2004 10:10:06 -0800 X-mProtect: <200402241810> 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 smtpdFw49BB; Tue, 24 Feb 2004 10:10:02 PST Message-ID: <403B937C.6090102@iprg.nokia.com> Date: Tue, 24 Feb 2004 10:10:04 -0800 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: Tony Hain CC: "'Alain Durand'" , "'Brian Haberman'" , "'Bob Hinden'" , "'The IESG'" , "'Margaret Wasserman'" , "'IPv6 Mailing List'" , "'Thomas Narten'" , ftemplin@iprg.nokia.com Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" References: 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 Tony, I agree that 'draft-hain-templin-ipv6-localcomm' has served the useful purpose of focusing the discussion, but (like an RFP or BAA) its sole purpose was to issue a call for solution alternatives; not to propose solution alternatives or otherwise seek a more active role in itself. As such, I believe the 'hain-templin' document should remain current only until an acceptable solution has been identified and progressed. Thereafter, the 'hain-templin' document should gracefully expire with perhaps a "tombstone" marker left behind as a matter of historical record, i.e., I don't believe any further progression will be necessary. Regards, Fred L. Templin ftemplin@iprg.nokia.com Tony Hain wrote: >Alain, > >The current document does not enforce a business model (earlier versions >did), but does set technical constraints. Personally I don't think it is >possible to 'Provide mechanisms that prevent hoarding', so the requirement >'without any procedure for de-allocation' creates a problem once hoarding >has been detected. I do not object to the current document as this specific >issue will be resolved by an update once the system is in operation and >practical experience exposes that flaw. > >Recommending against all-zero's is not only a waste of time, it specifically >directs people to the thing you are trying to avoid. There is nothing that a >document can do to prevent a consultant from configuring all of his >customers with the same prefix. He can run [RANDOM] once and use that >everywhere, yet is in full compliance with the document. Even more of a >problem, an equipment manufacturer could run [RANDOM] once and burn that >value into every piece of equipment they ship. The best a document can do is >highlight the issues raised by duplicate assignments, and provide a >mechanism which solves them if used as directed. As much as some people want >to, it is not the IETF's job to legislate operational behavior. The language >in this document is appropriate and it should be published. > >Tony > >BTW: why wasn't draft-hain-templin-ipv6-localcomm-04.txt sent at the same >time as the unique address & deprecation drafts? They are all dealing with >the same issue. > > > > > >>-----Original Message----- >>From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Alain >>Durand >>Sent: Friday, February 20, 2004 1:22 AM >>To: Brian Haberman; Bob Hinden >>Cc: The IESG; Margaret Wasserman; IPv6 Mailing List; Alain Durand; Thomas >>Narten >>Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" >> >>Dears ADs, >> >>I found it very unfortunate that the chair decided to request to >>advance this document >>without answering two major issues I raised during the last call: >> >>- Permanent allocation is equivalent of selling address space, which is >>very different from >> the notion of stewardship that are now in place for any IP address >>allocation today. >> There are a number of legal questions not answered around this point. >> More, this is imposing a business model to the entity that will be in >>charge of the allocations, >> and I believe that the IETF should refrain from imposing business >>model. >> >>- The document does not contain any wording recommending against the >>'all zero' self allocation. >> It merely say that: >> "Locally assigned global IDs MUST be generated with a pseudo-random >> algorithm consistent with [RANDOM].". However, it should be noted >>that [RANDOM] >> or RFC1750 does not contain any mandate, just provide ideas on how >>to do things. >> An 'all zero' self allocation would create the prefix FD00::/48 and >>will be very tempting >> to use by many. >> This working group just spend more than a year to deprecate the site >>local >> fec0::/10 prefixes, just to reinvent it here. >> >>As the request to advance this document came from the Ipv6 wg chairs, >>representing the wg, >>it is my opinion that the IPv6 Working Groug has made an incorrect >>technical choice which >>places the quality and/or integrity of the Working Group's product(s) >>in significant >>jeopardy. >> >>As the request to advance this document has already been sent to you, >>ADs, >>this is my appeal to you to reject it and send it back to the working >>group. >> >> - Alain. >> >> >> >> >> >>On Feb 18, 2004, at 5:22 PM, Brian Haberman wrote: >> >> >> >>>Margaret & Thomas, >>> On behalf of the IPv6 working group, the chairs request the >>>advancement of: >>> >>> Title : Unique Local IPv6 Unicast Addresses >>> Author(s) : R. Hinden, B. Haberman >>> Filename : draft-ietf-ipv6-unique-local-addr-03.txt >>> Pages : 16 >>> Date : 2004-2-13 >>> >>>as a Proposed Standard. The -02 version completed working group last >>>call on 02/02/2004. This version addresses issues raised during the >>>last call period. >>> >>>Regards, >>>Brian & Bob >>>IPv6 WG co-chairs >>> >>> >>> >>>-------------------------------------------------------------------- >>>IETF IPv6 working group mailing list >>>ipv6@ietf.org >>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>>-------------------------------------------------------------------- >>> >>> >>-------------------------------------------------------------------- >>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 Feb 24 13:22: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 NAA02790 for ; Tue, 24 Feb 2004 13:22: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 1AvhCE-0005Ai-Mn for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 13:22:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OIMIKD019874 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 13:22:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhCE-0005AT-44 for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 13:22:18 -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 NAA02749 for ; Tue, 24 Feb 2004 13:22:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvhCC-0002g0-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 13:22:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvhBD-0002aM-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 13:21:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvhAS-0002VR-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 13:20:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhA4-0004mR-Ib; Tue, 24 Feb 2004 13:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avh9M-0004jx-2D for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 13:19:20 -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 NAA02566 for ; Tue, 24 Feb 2004 13:19:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avh9J-0002NR-00 for ipv6@ietf.org; Tue, 24 Feb 2004 13:19:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avh8Q-0002Hd-00 for ipv6@ietf.org; Tue, 24 Feb 2004 13:18:23 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Avh7j-000280-00; Tue, 24 Feb 2004 13:17:39 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1OIGXE09846; Tue, 24 Feb 2004 10:16:33 -0800 X-mProtect: <200402241816> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKX2gTU; Tue, 24 Feb 2004 10:16:29 PST Message-ID: <403B94E1.8000901@iprg.nokia.com> Date: Tue, 24 Feb 2004 10:16:01 -0800 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: Bill Manning CC: Tony Hain , Alain.Durand@Sun.COM, brian@innovationslab.net, bob.hinden@nokia.com, iesg-secretary@ietf.org, margaret@thingmagic.com, ipv6@ietf.org, narten@us.ibm.com, ftemplin@iprg.nokia.com Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" References: <200402210240.i1L2eok07341@boreas.isi.edu> 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 Bill, Whether or not this would be new and untrodden, I believe we need to step forward together into the unknown - under the confidence that careful monitoring and any necessary course-corrections will see us through the uncharted waters. Regards, Fred L. Templin ftemplin@iprg.nokia.com Bill Manning wrote: >% Alain, >% >% The current document does not enforce a business model (earlier versions >% did), but does set technical constraints. Personally I don't think it is >% possible to 'Provide mechanisms that prevent hoarding', so the requirement >% 'without any procedure for de-allocation' creates a problem once hoarding >% has been detected. I do not object to the current document as this specific >% issue will be resolved by an update once the system is in operation and >% practical experience exposes that flaw. > > its not that the document "enforces" a business model, > it that it creates "property rights" e.g. owned address > space. this is -NEW- and is an area untrodden by the > IESG/IAB. > >% mechanism which solves them if used as directed. As much as some people want >% to, it is not the IETF's job to legislate operational behavior. The language >% in this document is appropriate and it should be published. > > Operational behaviour is one thing, creating legal assests > is something else. This is a -VERY- bad idea. > >--bill > > >% Tony >% >% > -----Original Message----- >% > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Alain >% > Durand >% > Sent: Friday, February 20, 2004 1:22 AM >% > To: Brian Haberman; Bob Hinden >% > Cc: The IESG; Margaret Wasserman; IPv6 Mailing List; Alain Durand; Thomas >% > Narten >% > Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" >% > >% > Dears ADs, >% > >% > I found it very unfortunate that the chair decided to request to >% > advance this document >% > without answering two major issues I raised during the last call: >% > >% > - Permanent allocation is equivalent of selling address space, which is >% > very different from >% > the notion of stewardship that are now in place for any IP address >% > allocation today. >% > There are a number of legal questions not answered around this point. >% > More, this is imposing a business model to the entity that will be in >% > charge of the allocations, >% > and I believe that the IETF should refrain from imposing business >% > model. >% > >% > - The document does not contain any wording recommending against the >% > 'all zero' self allocation. >% > It merely say that: >% > "Locally assigned global IDs MUST be generated with a pseudo-random >% > algorithm consistent with [RANDOM].". However, it should be noted >% > that [RANDOM] >% > or RFC1750 does not contain any mandate, just provide ideas on how >% > to do things. >% > An 'all zero' self allocation would create the prefix FD00::/48 and >% > will be very tempting >% > to use by many. >% > This working group just spend more than a year to deprecate the site >% > local >% > fec0::/10 prefixes, just to reinvent it here. >% > >% > As the request to advance this document came from the Ipv6 wg chairs, >% > representing the wg, >% > it is my opinion that the IPv6 Working Groug has made an incorrect >% > technical choice which >% > places the quality and/or integrity of the Working Group's product(s) >% > in significant >% > jeopardy. >% > >% > As the request to advance this document has already been sent to you, >% > ADs, >% > this is my appeal to you to reject it and send it back to the working >% > group. >% > >% > - Alain. >% > >% > >% > >% > >% > >% > On Feb 18, 2004, at 5:22 PM, Brian Haberman wrote: >% > >% > > Margaret & Thomas, >% > > On behalf of the IPv6 working group, the chairs request the >% > > advancement of: >% > > >% > > Title : Unique Local IPv6 Unicast Addresses >% > > Author(s) : R. Hinden, B. Haberman >% > > Filename : draft-ietf-ipv6-unique-local-addr-03.txt >% > > Pages : 16 >% > > Date : 2004-2-13 >% > > >% > > as a Proposed Standard. The -02 version completed working group last >% > > call on 02/02/2004. This version addresses issues raised during the >% > > last call period. >% > > >% > > Regards, >% > > Brian & Bob >% > > IPv6 WG co-chairs >% > > >% > > >% > > >% > > -------------------------------------------------------------------- >% > > IETF IPv6 working group mailing list >% > > ipv6@ietf.org >% > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >% > > -------------------------------------------------------------------- >% > >% > >% > -------------------------------------------------------------------- >% > 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 Feb 24 13:54: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 NAA03670 for ; Tue, 24 Feb 2004 13:54:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhhD-0006vM-6Q for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 13:54:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OIsJlO026609 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 13:54:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhhC-0006v6-Ho for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 13:54:18 -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 NAA03664 for ; Tue, 24 Feb 2004 13:54:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvhhA-0005Kz-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 13:54:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvhgE-0005Fw-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 13:53:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avhfb-0005Ae-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 13:52:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avhez-0006b6-SO; Tue, 24 Feb 2004 13: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 1AvheG-0006Zv-Bl for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 13:51:16 -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 NAA03563 for ; Tue, 24 Feb 2004 13:51:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvheE-00054z-00 for ipv6@ietf.org; Tue, 24 Feb 2004 13:51:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvhdG-00050Q-00 for ipv6@ietf.org; Tue, 24 Feb 2004 13:50:15 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1Avhd2-0004vl-00 for ipv6@ietf.org; Tue, 24 Feb 2004 13:50:01 -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 i1OInQL24911; Tue, 24 Feb 2004 10:49:26 -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 i1OJ0slN018794 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 24 Feb 2004 11:01:03 -0800 Message-ID: <403B9C7F.2070602@innovationslab.net> Date: Tue, 24 Feb 2004 13:48:31 -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: alain.durand@sun.com CC: Margaret Wasserman , Thomas Narten , bob.hinden@nokia.com, "IETF IPv6 Mailing List" Subject: Appeal Response - Request To Advance : "Unique Local IPv6 Unicast Addresses" 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, At 01:22 AM 2/20/2004, Alain Durand wrote: >Dears ADs, Since the appeal process starts with the working group chairs, we are responding as such. >I found it very unfortunate that the chair decided to request to advance >this document >without answering two major issues I raised during the last call: Before forwarding the document to the IESG we reviewed the discussion of all issues raised during the w.g. last call and concluded that the current draft resolved issues where there was a consensus to make changes. There were many significant changes (e.g., removing the requirement to charge for the central allocations, etc.). We did not see that there was any consensus to make the changes you requested. >- Permanent allocation is equivalent of selling address space, which is >very different from > the notion of stewardship that are now in place for any IP address > allocation today. > There are a number of legal questions not answered around this point. > More, this is imposing a business model to the entity that will be in > charge of the allocations, > and I believe that the IETF should refrain from imposing business model. We believe that the current draft is very clear that it is not imposing a business model. It clearly states a set of requirements for how these prefixes should be allocated. Earlier versions of the draft may have had that issue, but based on comments received during the working group last call, this text was changed. In addition there were a number of comments from Geoff Huston on the business model issue that led to changes in earlier versions of the draft. We do not agree that permanent address allocations as called for in this draft is the same as selling address space. We also note that there are other types of IPv6 addresses that are allocated in similar manner. This includes link-local addresses, site-local addresses (currently being deprecated), multicast addresses, and NSAP addresses. There are similar blocks of addresses in IPv4. The Unique Local Addresses defined in the draft meet a clearly defined need that has been discussed at great length in the working group. The permanency of these addresses is an important part of the requirements. They are by definition different from how other global IPv6 unicast addresses are allocated and managed. This is why they were defined in the first place. >- The document does not contain any wording recommending against the 'all >zero' self allocation. > It merely say that: > "Locally assigned global IDs MUST be generated with a pseudo-random > algorithm consistent with [RANDOM].". However, it should be noted > that [RANDOM] > or RFC1750 does not contain any mandate, just provide ideas on how to > do things. > An 'all zero' self allocation would create the prefix FD00::/48 and > will be very tempting > to use by many. > This working group just spend more than a year to deprecate the site local > fec0::/10 prefixes, just to reinvent it here. When you raised this issue on the mailing list the subsequent discussion indicated that the document was very clear on what was required (i.e., what MUST be done as you quote above) and that there wasn't any reason to provide a list of exceptions to this. Quoting from Christian Huitema's email dated Wed, 28 Jan 2004: "The draft already says that we MUST assign these numbers exactly one way. Why on earth would we need to enumerate the 25 ways that should not be used?" You logic seems to be that we are reinventing site-local addresses because we only describe what someone MUST do and do not describe how to turn this back into site-local addresses. We believe your suggestion would have the opposite effect from what you desire. Also, if someone wants to use site-locals, they can just ignore the deprecation document and keep using them. Why would they need to bother to use this prefix. >As the request to advance this document came from the Ipv6 wg chairs, >representing the wg, >it is my opinion that the IPv6 Working Groug has made an incorrect >technical choice which >places the quality and/or integrity of the Working Group's product(s) in >significant >jeopardy. > >As the request to advance this document has already been sent to you, ADs, >this is my appeal to you to reject it and send it back to the working group. For the reasons stated above, we do not agree that our action was incorrect and deny your appeal. Regards, Brian Haberman and Bob Hinden IPv6 Working Group Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 14:44: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 OAA05887 for ; Tue, 24 Feb 2004 14:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AviTK-0002cS-Sn for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 14:44:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OJi2DE010058 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 14:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AviTK-0002c1-J7 for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 14:44: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 OAA05787 for ; Tue, 24 Feb 2004 14:43:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AviTH-00022d-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 14:43:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AviRz-0001n9-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 14:42:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AviQs-0001dL-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 14:41:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AviQQ-0002AB-SC; Tue, 24 Feb 2004 14:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AviPc-00025e-Qw for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 14:40:12 -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 OAA05523 for ; Tue, 24 Feb 2004 14:40:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AviPa-0001Ui-00 for ipv6@ietf.org; Tue, 24 Feb 2004 14:40:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AviOe-0001Qb-00 for ipv6@ietf.org; Tue, 24 Feb 2004 14:39:13 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AviNp-0001Lj-00 for ipv6@ietf.org; Tue, 24 Feb 2004 14:38:21 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id D0F0D7000A2; Wed, 25 Feb 2004 06:38:03 +1100 (EST) Date: Wed, 25 Feb 2004 06:38:00 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: Francis Dupont Subject: Re: Optimistic DAD _still_! Message-ID: <20040224193756.GA5036@zoic.org> Mail-Followup-To: ipv6@ietf.org, Francis Dupont References: <403B2AFC.1060506@eng.monash.edu.au> <200402241452.i1OEqvSj030687@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402241452.i1OEqvSj030687@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-24, Francis Dupont wrote: > [Greg Daley wrote:] > > > This is not going to happen in Nick's optimistic DAD draft. > > => I disagree: even in Nick's draft the second system has both > a service disruption and has to switch to another address. > So as to be the second system is just a matter of race Murphy's law > implies it will be the important one. ... and the result to the second system of an address collision under unmodified DAD is ...? We're talking about an extremely rare event here, an address collision of _well-distributed addresses_, eg: 3041-like or SEND-CGA-like addresses. Opti-DAD explicitly excludes manually configured addresses (although it may be used with EUI-64s). Just how many nodes _per network_ were you thinking of having? And when it happens, the first node may get a few stray packets and the second node will have its address configuration delayed by a few milliseconds -- but not for as long as it would have taken to perform DAD anyway. I don't see the disaster in this. cheers, -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Feb 24 14:54: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 OAA06615 for ; Tue, 24 Feb 2004 14:54:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avid9-0003e4-7o for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 14:54:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OJsBqZ014006 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 14:54:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avid8-0003dp-Um for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 14:54:10 -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 OAA06594 for ; Tue, 24 Feb 2004 14:54:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avid6-00039f-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 14:54:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvicA-000352-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 14:53:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvibG-00030u-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 14:52:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avib3-0003JQ-HO; Tue, 24 Feb 2004 14: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 1AviaG-0003Hp-0r for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 14:51:12 -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 OAA06518 for ; Tue, 24 Feb 2004 14:51:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AviaD-0002vw-00 for ipv6@ietf.org; Tue, 24 Feb 2004 14:51:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AviZG-0002s2-00 for ipv6@ietf.org; Tue, 24 Feb 2004 14:50:11 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AviYX-0002oM-00 for ipv6@ietf.org; Tue, 24 Feb 2004 14:49:26 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id B3AE77000A2; Wed, 25 Feb 2004 06:49:23 +1100 (EST) Date: Wed, 25 Feb 2004 06:49:23 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: Francis Dupont , Jari Arkko Subject: Re: Optimistic DAD _still!_ Message-ID: <20040224194923.GB5036@zoic.org> Mail-Followup-To: ipv6@ietf.org, Francis Dupont , Jari Arkko References: <403B6495.80005@kolumbus.fi> <200402241507.i1OF7ZSj030776@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402241507.i1OF7ZSj030776@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-24, Francis Dupont wrote: > [Jari Arkko wrote:] > > > => what we need is collision avoidance, no collision detection after > > damage. > > > [...] Generally, for the last two we can only provide detection > > and then wait for further input from the user; for the first we can > > still continue and use another address. But this has little to > > do with regular or optimistic DAD, both provide detection as the > > name implies. > > => I have a different conclusion from your argument: detection is enough > when the recovery is always easy and without drawback, i.e., only > in the first assignment method (random). With other methods (eui/conf), > a collision is a major problem so it is important to avoid it and > not only to detect it. Optimistic DAD explicitly excludes manually configured addresses -- because in my opinion they're FAR MORE LIKELY to collide than randomly chosen ones. Human error dwarfs N/2^62 for any sane N. EUI-derived addresses may be configured Optimistically, but if they collide the node instead configured with a random address. (or CGA-derived addresses resalt). > > Regarding the second question, I do not agree that an optimistic > > DAD implies problems. It seems reasonable that an optimized > > variant would detect duplicates with an equivalent reliability as > > regular DAD; both send similar messages and expect other nodes to > > answer. Would you agree? > > => yes but my argument is that detection is not enough. But that is all that the current RFC2461/2462 behaviour provides! > > > the problem is the goal of optimistic/optimized DAD has no interest. > > > I'm not sure I can parse what you are saying. > > => easy: the optimistic/optimized DAD stuff solves the wrong problem. So, which problem would you like to see solved? -----Nick -- Nick 'Sharkey' Moore "(I never even thought of using a radio controlled toy on an airplane, but now that they say I can't, I'm guessing it's way fun.)" -- Penn Jillette -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 25 01:18: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 BAA29863 for ; Wed, 25 Feb 2004 01:18: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 1AvsMO-0007Y8-Nq for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 01:17:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P6HW36029014 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 01:17:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsMO-0007Xt-GU for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 01:17: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 BAA29845 for ; Wed, 25 Feb 2004 01:17:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvsML-0001ZP-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 01:17:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvsLN-0001UR-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 01:16:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvsKX-0001QW-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 01:15:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsJz-0007B8-NA; Wed, 25 Feb 2004 01:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsJU-00079r-EP for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 01:14:33 -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 BAA29797 for ; Wed, 25 Feb 2004 01:14:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvsJR-0001L8-00 for ipv6@ietf.org; Wed, 25 Feb 2004 01:14:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvsIV-0001H5-00 for ipv6@ietf.org; Wed, 25 Feb 2004 01:13:32 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1AvsI8-0001Cr-00; Wed, 25 Feb 2004 01:13:08 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i1P6D8NE000113; Tue, 24 Feb 2004 23:13:08 -0700 (MST) 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 <0HTM0018DMLWRO@edgemail1.Central.Sun.COM>; Tue, 24 Feb 2004 23:13:08 -0700 (MST) Received: from [67.75.228.177] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HTM00DJKMLPX9@mail.sun.net>; Tue, 24 Feb 2004 23:13:08 -0700 (MST) Date: Tue, 24 Feb 2004 22:13:20 -0800 From: Alain Durand Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" In-reply-to: <403B936C.4040501@iprg.nokia.com> To: Fred Templin Cc: Brian Haberman , The IESG , Margaret Wasserman , Bob Hinden , IPv6 Mailing List , Thomas Narten Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <40340FCD.9070609@innovationslab.net> <4F02942E-6386-11D8-9E3D-00039376A6AA@sun.com> <403B936C.4040501@iprg.nokia.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 Feb 24, 2004, at 10:09 AM, Fred Templin wrote: > Alain, > > Speaking only as an individual wg participant, I appreciate the > concerns > you are raising but am hoping that you are not contemplating a divisive > and time-consuming appeals process such as the one we have just come > through for site local deprecation. No. Stalling tactics go nowhere. I sincerely believe that there are some serious issues in the document in its current form. I also believe that those issues are fairly easy to address. I'm not a partisan of Site Local nor a partisan of those new local addresses. However, if the wg decides to go with it, fine. Once the issues I've raised are taken care of, I'd like to see this document progress quickly so the wg could move on to other important topics. > Please consider that published documents are by no means fixed for > all time; rather, there is clear past precedence for course-corrections > once operational experience is gained, e.g., through supplementary > documents, BCPs, updates to existing documents, etc. (We are in > fact seeing numerous instances of the latter in current wg activities.) I understand that. This is not the case here. There are known issues at this point, they are not difficult to fix, let's fix them now. This is the responsibility of the wg. - 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 Feb 25 02:32: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 CAA00356 for ; Wed, 25 Feb 2004 02:32:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtWl-0003yd-Ic for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 02:32:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P7WJUp015281 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 02:32:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtWk-0003y5-Hr for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 02:32: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 CAA00190 for ; Wed, 25 Feb 2004 02:32:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvtWg-0001bm-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 02:32:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvtVC-0001K3-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 02:30:43 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AvtU9-00013l-01 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 02:29:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AvtNL-00048p-B6 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 02:22:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtMq-0001uy-S0; Wed, 25 Feb 2004 02:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtML-0001ix-7I for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 02:21: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 CAA20986 for ; Wed, 25 Feb 2004 02:21:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvtMH-0000LI-00 for ipv6@ietf.org; Wed, 25 Feb 2004 02:21:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvtLJ-0000Gd-00 for ipv6@ietf.org; Wed, 25 Feb 2004 02:20:29 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AvtKL-0000C8-00; Wed, 25 Feb 2004 02:19:29 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1P7JUjJ012521; Wed, 25 Feb 2004 00:19:30 -0700 (MST) 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 <0HTM00FD0POHOX@edgemail1.Central.Sun.COM>; Wed, 25 Feb 2004 00:19:30 -0700 (MST) Received: from [65.58.153.41] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HTM000H9POBIU@mail.sun.net>; Wed, 25 Feb 2004 00:19:29 -0700 (MST) Date: Tue, 24 Feb 2004 23:19:43 -0800 From: Alain Durand Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" In-reply-to: To: Tony Hain Cc: "'Brian Haberman'" , "'The IESG'" , "'Thomas Narten'" , "'IPv6 Mailing List'" , "'Bob Hinden'" , "'Margaret Wasserman'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.612) 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Feb 20, 2004, at 12:17 PM, Tony Hain wrote: > Alain, > > The current document does not enforce a business model (earlier > versions > did), but does set technical constraints. I disagree. There are no technical constraints that mandates that the allocations have to be permanent. As such, I believe it is up to the entity in charge of the allocation to decide to give permanent allocations or charge recurrent fees, not the IETF. > Personally I don't think it is > possible to 'Provide mechanisms that prevent hoarding', so the > requirement > 'without any procedure for de-allocation' creates a problem once > hoarding > has been detected. I do not object to the current document as this > specific > issue will be resolved by an update once the system is in operation and > practical experience exposes that flaw. Permanent, irrevocable allocations of chunks of finite address space are, IMHO, not very wise. But again, this is address assignment policy, not IETF business. > Recommending against all-zero's is not only a waste of time, it > specifically > directs people to the thing you are trying to avoid. There is nothing > that a > document can do to prevent a consultant from configuring all of his > customers with the same prefix. He can run [RANDOM] once and use that > everywhere, yet is in full compliance with the document. Even more of a > problem, an equipment manufacturer could run [RANDOM] once and burn > that > value into every piece of equipment they ship. The best a document can > do is > highlight the issues raised by duplicate assignments, and provide a > mechanism which solves them if used as directed. This is exactly what I'm asking for. I like TIm Chown suggestion few days ago. > As much as some people want > to, it is not the IETF's job to legislate operational behavior. The > language > in this document is appropriate and it should be published. No it is not, as there are known issues and it is the wg duty to at least mention 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 Wed Feb 25 02:33: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 CAA00646 for ; Wed, 25 Feb 2004 02:33:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtXY-0004Fe-Qv for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 02:33:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P7X8Hb016327 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 02:33:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtXY-0004F8-1D for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 02:33:08 -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 CAA00506 for ; Wed, 25 Feb 2004 02:33:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvtXU-0001mw-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 02:33:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvtW9-0001Un-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 02:31:42 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AvtUM-00014z-01 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 02:29:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AvtDQ-0003xl-73 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 02:12:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtD7-0006xo-DX; Wed, 25 Feb 2004 02:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtCh-0006lb-0u for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 02:11:35 -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 CAA14540 for ; Wed, 25 Feb 2004 02:11:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvtCd-00075S-00 for ipv6@ietf.org; Wed, 25 Feb 2004 02:11:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvtBl-0006wh-00 for ipv6@ietf.org; Wed, 25 Feb 2004 02:10:37 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AvtAu-0006s2-00 for ipv6@ietf.org; Wed, 25 Feb 2004 02:09:44 -0500 Message-ID: <001a01c3fb6e$6b35fb20$1e6115ac@dclkempt40> From: "James Kempf" To: "Nick 'Sharkey' Moore" Cc: "IPV6 WG" References: <20040219085228.GA22803@zoic.org> Subject: Re: Optimistic DAD _again!_ Date: Tue, 24 Feb 2004 23:10:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The issue always has been where in IETF to get these collection of delays addressed in a co-ordinated fashion. DNA was thought to be the venue, but it has chosen not to. Given we have to address the delays piecemeal, then OptiDAD seems like a place to start. jak ----- Original Message ----- From: )> To: "Nick 'Sharkey' Moore" Cc: Sent: Monday, February 23, 2004 1:52 AM Subject: Re: Optimistic DAD _again!_ > >>>>> On Thu, 19 Feb 2004 19:52:28 +1100, > >>>>> "Nick 'Sharkey' Moore" said: > > > You might recall some time ago I stirred up some interest > > in my Optimistic DAD draft, which seeks to eliminate DAD delay > > without significantly increasing the risk involved in address > > collision. In the meantime it's picked up a couple of independant > > implementations[1] and a couple of conference publications[2]. > > (snip) > > > Please let me know what you think ... and if there's enough > > interest maybe we can discuss it further at Seoul. > > I'd like to know if there has been a consensus to pursue any sort of > DAD optimization in the first place. There have surely been lots of > discussions related to this issue, and, as far as I can recall, the > idea of optimization has never been adopted. > > One fundamental question that I remember is whether optimizing DAD > really makes much sense while there are other kinds of delays such as > random delay (up to 1 second) for the first RS and random delay at > routers before responding to an RS. Without addressing the > fundamental question(s), we'd simply restart similar divergent > discussions, waisting lots of energy and time without seeing progress. > > p.s. I've read the latest draft and have some (mainly editorial) > comments. I'll post the comments in a separate message. > > 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 Feb 25 06:22: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 GAA10979 for ; Wed, 25 Feb 2004 06:22:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avx6j-00079e-KH for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 06:21:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PBLfWS027496 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 06:21:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avx6j-00079P-D2 for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 06:21:41 -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 GAA10921 for ; Wed, 25 Feb 2004 06:21:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avx6f-0002jz-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 06:21:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avx5k-0002d0-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 06:20:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avx4k-0002X9-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 06:19:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avx4A-0006dl-6D; Wed, 25 Feb 2004 06:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avx3q-0006bv-RM for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 06:18:42 -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 GAA10835 for ; Wed, 25 Feb 2004 06:18:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avx3m-0002QJ-00 for ipv6@ietf.org; Wed, 25 Feb 2004 06:18:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avx2o-0002JU-00 for ipv6@ietf.org; Wed, 25 Feb 2004 06:17:39 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1Avx1x-00029G-00 for ipv6@ietf.org; Wed, 25 Feb 2004 06:16:45 -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 i1PBGEL31099 for ; Wed, 25 Feb 2004 03:16:14 -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 i1PBRxlN022037 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 25 Feb 2004 03:28:04 -0800 Message-ID: <403C83F6.2030506@innovationslab.net> Date: Wed, 25 Feb 2004 06:16:06 -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: "" Subject: IPv6 WG: Call for Scribes 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 All, The chairs are soliciting volunteers to be scribes for the IPv6 WG session in Seoul. If you are willing to perform this duty, please contact us. Thanks, Brian & Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 25 09:34: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 JAA18053 for ; Wed, 25 Feb 2004 09:34:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw06q-0005kL-Kr for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 09:34:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PEY04j022083 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 09:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw06q-0005k6-FP for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 09:34:00 -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 JAA18021 for ; Wed, 25 Feb 2004 09:33:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw06o-0005hl-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 09:33:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw05m-0005ZW-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 09:32:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw04s-0005Tp-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 09:31:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw03z-00054f-B4; Wed, 25 Feb 2004 09:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw03t-00053Z-8t for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 09:30:59 -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 JAA17860 for ; Wed, 25 Feb 2004 09:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw03q-0005Mh-00 for ipv6@ietf.org; Wed, 25 Feb 2004 09:30:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw02z-0005HP-00 for ipv6@ietf.org; Wed, 25 Feb 2004 09:30:02 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Aw02T-0005Bb-00 for ipv6@ietf.org; Wed, 25 Feb 2004 09:29:29 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id D33066A905; Wed, 25 Feb 2004 16:29:27 +0200 (EET) Message-ID: <403CB0C4.4020608@kolumbus.fi> Date: Wed, 25 Feb 2004 16:27:16 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: Optimistic DAD _still_! References: <200402241507.i1OF7ZSj030776@givry.rennes.enst-bretagne.fr> In-Reply-To: <200402241507.i1OF7ZSj030776@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Francis, > There seems to be some > people who do have an interest in quick startup & movement times. > > => in this case they should use dedicated links where DAD is disabled, > RAs are used at a silly high rate, etc. > > I agree that DAD is not the only issue to look at here -- I once > calculated the number of messages that were required on a wireless > LAN for L2 & L3 network attachment if you needed access control, link layer > security, mobility, and so on. That number was pretty high, over a > dozen even in the most optimistic scenario, significantly worse in > others. And then there were multiple delay periods, all contributing > to the overall delay. DAD is one of these delay periods. > > => so you should agree that dedicated links are a good solution, > and no DAD is a part of the specific tuning. Ok. I'm beginning to understand your point... Yes, disabling DAD is indeed possible today via setting DupAddrDetectTransmits to zero. And some important link layers are using this approach, typically combined with something else that ensures duplicates are not generated in the first place. For instance, RFC 3316 says what 3G mobile phones do in this respect. For these link layers optimistic DAD will not help, as there was no delay to begin with. On the other hand, these link layers are not the only ones available. Ethernet-type link layers are important too, and there we don't have any convenient mechanism to avoid duplicates besides DAD; and I personally would say that I'd rather leave DAD turned on in my wireless LAN. Now, from the point of view of an end user, this implies that there are the following choices: 1. Start using a link layer technology where dedicated links are possible and DAD disabling does not cause duplicates. No delays involved. 2. Use a link layer where dedicated links are not possible, and disable DAD, accept the risk of collisions. No delays involved here either. 3. Use a link layer where dedicated links are not possible, keep using DAD. Delay introduced into movements and attachments. I think the desire to provide an optimized DAD procedure comes from the fact that people are stuck with a given link layer technology but are still uncomfortable with either option 2 or 3. That is, they would rather have 4. Use a link layer where dedicated links are not possible, keep using DAD to prevent collisions, but do this in a smarter way which avoids delays. This would be the "eat the cake and save it too" option, which in this case is possible if new protocols are introduced. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 25 13:54: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 NAA05052 for ; Wed, 25 Feb 2004 13:54:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4AY-0002nZ-8z for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 13:54:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PIs6XM010751 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 13:54:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4AX-0002nK-Th for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 13:54: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 NAA05046 for ; Wed, 25 Feb 2004 13:54:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4AV-0004q5-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 13:54:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw49a-0004kY-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 13:53:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw48y-0004ev-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 13:52:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw48Z-0002BS-3a; Wed, 25 Feb 2004 13:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3zj-0001EL-TB for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 13:42:58 -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 NAA04425 for ; Wed, 25 Feb 2004 13:42:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3zh-0003e9-00 for ipv6@ietf.org; Wed, 25 Feb 2004 13:42:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw3yo-0003ZW-00 for ipv6@ietf.org; Wed, 25 Feb 2004 13:41:59 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3xq-0003Vt-00; Wed, 25 Feb 2004 13:40:58 -0500 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id i1PIePK23389; Wed, 25 Feb 2004 10:40:25 -0800 (PST) From: Bill Manning Message-Id: <200402251840.i1PIePK23389@boreas.isi.edu> Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" In-Reply-To: <403B94E1.8000901@iprg.nokia.com> from Fred Templin at "Feb 24, 4 10:16:01 am" To: ftemplin@iprg.nokia.com (Fred Templin) Date: Wed, 25 Feb 2004 10:40:24 -0800 (PST) Cc: bmanning@ISI.EDU, alh-ietf@tndh.net, Alain.Durand@Sun.COM, brian@innovationslab.net, bob.hinden@nokia.com, iesg-secretary@ietf.org, margaret@thingmagic.com, ipv6@ietf.org, narten@us.ibm.com, ftemplin@iprg.nokia.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit be prepared to defend yourself in court(s) in any number of jurisdictions. You should check w/ the RIRs on their role/position wrt legal precident on address/prefix ownership. You should have the ISOC/IETF legal team review the creation of property rights by the WG chairs and the IESG. Its not going to be easy and its not clear the effort justifies the exposure, at least to me. If you do this, I will have to rethink my use of IPv6 as tainted goods. The IETF should stick to -PROTOCOL- development, not create property rights to be fought over in courts. YMMV --bill % Bill, % % Whether or not this would be new and untrodden, I believe % we need to step forward together into the unknown - under % the confidence that careful monitoring and any necessary % course-corrections will see us through the uncharted waters. % % Regards, % % Fred L. Templin % ftemplin@iprg.nokia.com % % Bill Manning wrote: % % >% Alain, % >% % >% The current document does not enforce a business model (earlier versions % >% did), but does set technical constraints. Personally I don't think it is % >% possible to 'Provide mechanisms that prevent hoarding', so the requirement % >% 'without any procedure for de-allocation' creates a problem once hoarding % >% has been detected. I do not object to the current document as this specific % >% issue will be resolved by an update once the system is in operation and % >% practical experience exposes that flaw. % > % > its not that the document "enforces" a business model, % > it that it creates "property rights" e.g. owned address % > space. this is -NEW- and is an area untrodden by the % > IESG/IAB. % > % >% mechanism which solves them if used as directed. As much as some people want % >% to, it is not the IETF's job to legislate operational behavior. The language % >% in this document is appropriate and it should be published. % > % > Operational behaviour is one thing, creating legal assests % > is something else. This is a -VERY- bad idea. % > % >--bill % > % > % >% Tony % >% % >% > -----Original Message----- % >% > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Alain % >% > Durand % >% > Sent: Friday, February 20, 2004 1:22 AM % >% > To: Brian Haberman; Bob Hinden % >% > Cc: The IESG; Margaret Wasserman; IPv6 Mailing List; Alain Durand; Thomas % >% > Narten % >% > Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" % >% > % >% > Dears ADs, % >% > % >% > I found it very unfortunate that the chair decided to request to % >% > advance this document % >% > without answering two major issues I raised during the last call: % >% > % >% > - Permanent allocation is equivalent of selling address space, which is % >% > very different from % >% > the notion of stewardship that are now in place for any IP address % >% > allocation today. % >% > There are a number of legal questions not answered around this point. % >% > More, this is imposing a business model to the entity that will be in % >% > charge of the allocations, % >% > and I believe that the IETF should refrain from imposing business % >% > model. % >% > % >% > - The document does not contain any wording recommending against the % >% > 'all zero' self allocation. % >% > It merely say that: % >% > "Locally assigned global IDs MUST be generated with a pseudo-random % >% > algorithm consistent with [RANDOM].". However, it should be noted % >% > that [RANDOM] % >% > or RFC1750 does not contain any mandate, just provide ideas on how % >% > to do things. % >% > An 'all zero' self allocation would create the prefix FD00::/48 and % >% > will be very tempting % >% > to use by many. % >% > This working group just spend more than a year to deprecate the site % >% > local % >% > fec0::/10 prefixes, just to reinvent it here. % >% > % >% > As the request to advance this document came from the Ipv6 wg chairs, % >% > representing the wg, % >% > it is my opinion that the IPv6 Working Groug has made an incorrect % >% > technical choice which % >% > places the quality and/or integrity of the Working Group's product(s) % >% > in significant % >% > jeopardy. % >% > % >% > As the request to advance this document has already been sent to you, % >% > ADs, % >% > this is my appeal to you to reject it and send it back to the working % >% > group. % >% > % >% > - Alain. % >% > % >% > % >% > % >% > % >% > % >% > On Feb 18, 2004, at 5:22 PM, Brian Haberman wrote: % >% > % >% > > Margaret & Thomas, % >% > > On behalf of the IPv6 working group, the chairs request the % >% > > advancement of: % >% > > % >% > > Title : Unique Local IPv6 Unicast Addresses % >% > > Author(s) : R. Hinden, B. Haberman % >% > > Filename : draft-ietf-ipv6-unique-local-addr-03.txt % >% > > Pages : 16 % >% > > Date : 2004-2-13 % >% > > % >% > > as a Proposed Standard. The -02 version completed working group last % >% > > call on 02/02/2004. This version addresses issues raised during the % >% > > last call period. % >% > > % >% > > Regards, % >% > > Brian & Bob % >% > > IPv6 WG co-chairs % >% > > % >% > > % >% > > % >% > > -------------------------------------------------------------------- % >% > > IETF IPv6 working group mailing list % >% > > ipv6@ietf.org % >% > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 % >% > > -------------------------------------------------------------------- % >% > % >% > % >% > -------------------------------------------------------------------- % >% > 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 % >% -------------------------------------------------------------------- % >% % > % > % > % > % % -- --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 Wed Feb 25 14:46: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 OAA07919 for ; Wed, 25 Feb 2004 14:46:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4yt-00084t-1t for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 14:46:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJk7go031045 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 14:46:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4ys-00084e-Ql for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 14:46: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 OAA07902 for ; Wed, 25 Feb 2004 14:46:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4yq-0002Lm-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 14:46:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4xv-0002FV-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 14:45:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4xA-00029v-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 14:44:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4ws-0007Zy-Ai; Wed, 25 Feb 2004 14:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4vy-0007YZ-SP for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 14:43: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 OAA07769 for ; Wed, 25 Feb 2004 14:43:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4vw-000234-00 for ipv6@ietf.org; Wed, 25 Feb 2004 14:43:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4v4-0001xg-00 for ipv6@ietf.org; Wed, 25 Feb 2004 14:42:10 -0500 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4uX-0001ro-00 for ipv6@ietf.org; Wed, 25 Feb 2004 14:41:37 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id OAA11976; Wed, 25 Feb 2004 14:41:30 -0500 (EST) Date: Wed, 25 Feb 2004 14:41:30 -0500 (EST) From: Dan Lanciani Message-Id: <200402251941.OAA11976@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-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.1 required=5.0 tests=AWL,NO_COST autolearn=no version=2.60 Alain Durand wrote: |- Permanent allocation is equivalent of selling address space, No, it is not. Address space could be given away at no cost just as it was in the beginning. A fee may be a useful tool to discourage hoarding, but there may be other equally effective (or even more effective) ways to achieve that goal. A fee may be useful to help fund a registry, but it may not be necessary if some entity decides to maintain the registry as a public service (still not unheard of). In either case, fees are a means to an end. They are not the end itself. |which is |very different from | the notion of stewardship that are now in place for any IP address |allocation today. The address rental model (or "stewardship" as you euphemistically call it) arose from the perceived need to limit IPv4 core routing table growth, and eventually to conserve actual IPv4 address space. The model was perpetuated to IPv6 routable address space through an (IMHO questionable) argument that IPv6 routing had to work exactly the same as IPv4 routing. Rental is not an intrinsic property of address allocation nor has it always been the norm. As above, it is a means to an end. Moreover, as money tends to corrupt, it is at best a necessary evil. It seems disingenuous to suggest that the current rental model for routables can justify a similar rental model for this new type of address space given that the (dubious to begin with) arguments for the former don't apply to the latter. Arguably we should spend more time examining the "necessity" of the rental model for routables with an eye to restoring end user routable address ownership and the end-to-end paradigm that made the original internet so powerful. | There are a number of legal questions not answered around this point. I have yet to see any substantive questions, or at least any questions that don't have self-evident answers. You had raised the issue of transfer. I think it is obvious to anyone who wants these new addresses to be useful that it is not desirable to hold up a corporate merger while a hierarchy of registries decides how much money they can charge for the transfer. The deep legal questions have yet appear. On the other hand, there are some serious practical problems with the model that you propose. The one that worries me the most (and for which you offered no solution) is: how do we decide who is allowed to compete in the registry business? Is it possible to impose your competitive registry business model without precluding any low-to-no cost providers? | More, this is imposing a business model to the entity that will be in |charge of the allocations, | and I believe that the IETF should refrain from imposing business |model. It's a little late for that. The IETF is perpetually imposing business models, if only indirectly. The aforementioned address rental model is among them, as would be your suggested competitive registry model. In general, it seems that folks start to object to the imposition of business models only when they don't like the particular business model in question... 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 Wed Feb 25 14:57: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 OAA08545 for ; Wed, 25 Feb 2004 14:57:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw59h-0001Nf-GA for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 14:57:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJvHsa005301 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 14:57:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw59h-0001NQ-CY for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 14:57:17 -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 OAA08519 for ; Wed, 25 Feb 2004 14:57:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw59e-0003Z7-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 14:57:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw58x-0003S4-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 14:56:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw57m-0003M0-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 14:55:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw57X-0000bR-SI; Wed, 25 Feb 2004 14:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw56g-0000MU-5H for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 14:54:10 -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 OAA08382 for ; Wed, 25 Feb 2004 14:54:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw56d-0003Fa-00 for ipv6@ietf.org; Wed, 25 Feb 2004 14:54:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw55i-00039s-00 for ipv6@ietf.org; Wed, 25 Feb 2004 14:53:11 -0500 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 1Aw54x-000347-00 for ipv6@ietf.org; Wed, 25 Feb 2004 14:52:24 -0500 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id B2B768392 for ; Wed, 25 Feb 2004 20:52:29 +0100 (CET) From: "Jeroen Massar" To: Subject: RE: Request To Advance : "Unique Local IPv6 Unicast Addresses" Date: Wed, 25 Feb 2004 20:50:37 +0100 Organization: Unfix Message-ID: <005401c3fbd8$a401e080$210d640a@unfix.org> 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.4510 Importance: Normal In-Reply-To: <200402251941.OAA11976@ss10.danlan.com> 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.1 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- > Alain Durand wrote: > > |- Permanent allocation is equivalent of selling address space, I have only one note on the "unique local ipv6 address" subject: Organisations wanting "unconnected addressspace" should go to an existing organisation that they think will outlast them in age and that already has a LIR allocation allocated. Give them some money to make them happy and request a /48 from them. As long as the organisation owning the superblock of that /48 doesn't go belly up you have yourself a globally unique /48. This is the same idea as getting a 'globally unique domainname' pay "Example Corp." some money and they will be happy to give you youruniquedomain.example.com. I even think that some ISP could see business in this, they request a prefix from the RIR's and have 200 customers without problems ;) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQDz8jCmqKFIzPnwjEQK5wQCfaP2fsbREkxSUaL+1jwcPPeLwnEYAnRF3 ePDjTIvJzYVunI/YHk7UPxlm =4ETg -----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 Wed Feb 25 15:20: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 PAA11211 for ; Wed, 25 Feb 2004 15:20:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Vw-0005Sp-TX for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 15:20:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PKKFFt020978 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 15:20:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Vs-0005RI-81 for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 15:20:12 -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 PAA11130 for ; Wed, 25 Feb 2004 15:20:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Vp-0006am-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 15:20:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5Ux-0006Ty-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 15:19:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5U2-0006KR-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 15:18:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Tm-0004U2-1H; Wed, 25 Feb 2004 15:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Sm-00042f-E8 for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 15:17:00 -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 PAA10662 for ; Wed, 25 Feb 2004 15:16:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Sl-00066w-00 for ipv6@ietf.org; Wed, 25 Feb 2004 15:16:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5Ro-0005yJ-00 for ipv6@ietf.org; Wed, 25 Feb 2004 15:16:00 -0500 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Qr-0005mZ-00 for ipv6@ietf.org; Wed, 25 Feb 2004 15:15:01 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA12521; Wed, 25 Feb 2004 15:14:59 -0500 (EST) Date: Wed, 25 Feb 2004 15:14:59 -0500 (EST) From: Dan Lanciani Message-Id: <200402252014.PAA12521@ss10.danlan.com> To: ipv6@ietf.org Subject: RE: Request To Advance : "Unique Local IPv6 Unicast Addresses" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 "Jeroen Massar" wrote: |I have only one note on the "unique local ipv6 address" subject: | |Organisations wanting "unconnected addressspace" should go to |an existing organisation that they think will outlast them in age |and that already has a LIR allocation allocated. Give them some |money to make them happy and request a /48 from them. | |As long as the organisation owning the superblock of that /48 |doesn't go belly up you have yourself a globally unique /48. | |This is the same idea as getting a 'globally unique domainname' |pay "Example Corp." some money and they will be happy to give |you youruniquedomain.example.com. | |I even think that some ISP could see business in this, they |request a prefix from the RIR's and have 200 customers without |problems ;) I'm sure that some ISP could see business in this. What I don't understand is why it is necessary or desirable to create a revenue stream for ISPs in this way. Could you explain how it is beneficial to the v6 user community to add an artificial address rental cost to internal networking operations? 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 Wed Feb 25 15:31: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 PAA11951 for ; Wed, 25 Feb 2004 15:31:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5gd-0007wH-G8 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 15:31:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PKVJjP030511 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 15:31:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5ga-0007w1-1z for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 15:31:16 -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 PAA11902 for ; Wed, 25 Feb 2004 15:31:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5gY-0007m5-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 15:31:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5fa-0007d1-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 15:30:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5ei-0007Vb-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 15:29:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5eP-0007WX-Td; Wed, 25 Feb 2004 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5dV-0007VF-Bq for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 15:28:05 -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 PAA11763 for ; Wed, 25 Feb 2004 15:28:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5dU-0007MN-00 for ipv6@ietf.org; Wed, 25 Feb 2004 15:28:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5cb-0007Gq-00 for ipv6@ietf.org; Wed, 25 Feb 2004 15:27:10 -0500 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 1Aw5c7-0007BT-00 for ipv6@ietf.org; Wed, 25 Feb 2004 15:26:39 -0500 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id CF3228392; Wed, 25 Feb 2004 21:26:47 +0100 (CET) From: "Jeroen Massar" To: "'Dan Lanciani'" , Subject: RE: Request To Advance : "Unique Local IPv6 Unicast Addresses" Date: Wed, 25 Feb 2004 21:24:46 +0100 Organization: Unfix Message-ID: <005b01c3fbdd$69bbded0$210d640a@unfix.org> 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.4510 Importance: Normal In-Reply-To: <200402252014.PAA12521@ss10.danlan.com> 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.1 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Dan Lanciani wrote: > "Jeroen Massar" wrote: > > |I have only one note on the "unique local ipv6 address" subject: > | > |Organisations wanting "unconnected addressspace" should go to > |an existing organisation that they think will outlast them in age > |and that already has a LIR allocation allocated. Give them some > |money to make them happy and request a /48 from them. > I'm sure that some ISP could see business in this. What I > don't understand is why it is necessary or desirable to create a revenue > stream for ISPs in this way. Could you explain how it is beneficial to the v6 > user community add an artificial address rental cost to internal > networking operations? I never said that it would be benificial to the user community, of which I am one who currently also only gets 1 public IP for his ADSL line unless I pay a lot extra to get some extra v4 addresses. But it is one solution that can be taken *now* by the (many?) companies that require this scenario. The 'pay some money' in the scenario above could also be replaced by 'rub his back' or 'donate a keg of beer' which makes many ISP's happy already. One could also request a /48 from one of the many Tunnel Broker systems out there and just don't use it globally ;) I am personally still at thought that most if not any system will be internet connected at some point and that organisations should get globally routable space and firewall it away. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQD0EjimqKFIzPnwjEQL4TgCfcfhh1ANbAYFi+RZGq+oMNDwMJeIAnjDm RbKjzNUWkrkW9aDEPhi3h4oz =kLL1 -----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 Wed Feb 25 15:52: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 PAA13894 for ; Wed, 25 Feb 2004 15:52: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 1Aw60x-0001ap-Sk for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 15:52:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PKqJ3v006122 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 15:52:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw60x-0001ae-Nd for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 15:52: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 PAA13874 for ; Wed, 25 Feb 2004 15:52:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw60w-0002p1-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 15:52:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5zy-0002dz-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 15:51:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5zA-0002T6-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 15:50:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5ym-00018t-Fh; Wed, 25 Feb 2004 15:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5xo-00014R-7U for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 15:49: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 PAA13427 for ; Wed, 25 Feb 2004 15:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5xm-0002Gz-00 for ipv6@ietf.org; Wed, 25 Feb 2004 15:49:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5wm-00029A-00 for ipv6@ietf.org; Wed, 25 Feb 2004 15:48:01 -0500 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5vv-00023R-00 for ipv6@ietf.org; Wed, 25 Feb 2004 15:47:08 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA13289; Wed, 25 Feb 2004 15:47:05 -0500 (EST) Date: Wed, 25 Feb 2004 15:47:05 -0500 (EST) From: Dan Lanciani Message-Id: <200402252047.PAA13289@ss10.danlan.com> To: ipv6@ietf.org Subject: RE: Request To Advance : "Unique Local IPv6 Unicast Addresses" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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 "Jeroen Massar" wrote: |Dan Lanciani wrote: | |> "Jeroen Massar" wrote: |> |> |I have only one note on the "unique local ipv6 address" subject: |> | |> |Organisations wanting "unconnected addressspace" should go to |> |an existing organisation that they think will outlast them in age |> |and that already has a LIR allocation allocated. Give them some |> |money to make them happy and request a /48 from them. | | |> I'm sure that some ISP could see business in this. What I |> don't understand is why it is necessary or desirable to create a revenue |> stream for ISPs in this way. Could you explain how it is beneficial to the v6 |> user community add an artificial address rental cost to internal |> networking operations? | |I never said that it would be benificial to the user community, Then why do it? |But it is one solution that can be taken *now* by the (many?) companies |that require this scenario. You appear to be suggesting it as an alternative to the proposed permanent allocations which this thread is about. In that context it has been proposed before. I do not believe that it is a good reason to delay (or worse, reject) the current proposal for permanent allocations. |The 'pay some money' in the scenario above could also be replaced |by 'rub his back' or 'donate a keg of beer' which makes many ISP's |happy already. One could also request a /48 from one of the many |Tunnel Broker systems out there and just don't use it globally ;) Why have this uncertainty in cost (and even in availability) when we can have simple, permanent allocations as proposed? 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 Wed Feb 25 16:31: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 QAA16025 for ; Wed, 25 Feb 2004 16:31:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw6cY-0004jt-DX for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 16:31:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PLVAPO018214 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 16:31:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw6cY-0004jh-0F for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 16:31:10 -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 QAA16003 for ; Wed, 25 Feb 2004 16:31:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6cW-00071O-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 16:31:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw6be-0006vE-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 16:30:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6at-0006ow-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 16:29:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw6aU-000498-Ht; Wed, 25 Feb 2004 16:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw6Tk-0003de-8A for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 16:22: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 QAA15377 for ; Wed, 25 Feb 2004 16:22:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6Ti-0005xQ-00 for ipv6@ietf.org; Wed, 25 Feb 2004 16:22:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw6So-0005qu-00 for ipv6@ietf.org; Wed, 25 Feb 2004 16:21:06 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1Aw6Ry-0005f8-00; Wed, 25 Feb 2004 16:20:14 -0500 Received: from ssprunk (ip145.post-vineyard.dfw.ygnition.net [66.135.181.145]) by ns2.sea (8.12.11/8.12.5) with SMTP id i1PLJfKk026849; Wed, 25 Feb 2004 13:19:42 -0800 Message-ID: <018a01c3fbe5$160c6720$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Bill Manning" , "Fred Templin" Cc: , , , , , , , , , References: <200402251840.i1PIePK23389@boreas.isi.edu> Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" Date: Wed, 25 Feb 2004 15:18:43 -0600 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.6 required=5.0 tests=AWL,NO_COST autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Bill Manning" > be prepared to defend yourself in court(s) in any number of jurisdictions. > ... You should have the ISOC/IETF legal team review the creation of > property rights by the WG chairs and the IESG. Its not going to be easy > and its not clear the effort justifies the exposure, at least to me. Exactly what would an allocation authority be sued for anyways? The property in question has no inherent value (being effectively infinite and free) and there's no obvious basis for ownership disputes when said property can be replaced at little to no cost. > You should check w/ the RIRs on their role/position > wrt legal precident on address/prefix ownership. As businesses that owe their livelihood to having monopolies on address rental, I would think any position they take should be taken with a grain of salt. > If you do this, I will have to rethink my use of IPv6 as tainted > goods. The IETF should stick to -PROTOCOL- development, not create > property rights to be fought over in courts. As many others have noted, this is not new ground. Nearly every number that IANA hands out, from ports to MIME types to pre-RIR addresses, is by convention assumed to be the permanent property of whoever it's allocated to. The RIRs' renting of addresses is an abberration, not the norm. 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 Wed Feb 25 20:12: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 UAA27890 for ; Wed, 25 Feb 2004 20:12:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwA4P-0006AX-TH for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 20:12:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q1C9tN023710 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 20:12:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwA4P-0006AL-Iw for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 20:12:09 -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 UAA27868 for ; Wed, 25 Feb 2004 20:12:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwA4N-0007L0-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 20:12:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwA3U-0007F2-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 20:11:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwA2n-0007Ab-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 20:10:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwA2N-0005l7-UW; Wed, 25 Feb 2004 20:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwA1d-0005iz-8H for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 20:09:17 -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 UAA27737 for ; Wed, 25 Feb 2004 20:09:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwA1b-00075Z-00 for ipv6@ietf.org; Wed, 25 Feb 2004 20:09:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwA0b-000716-00 for ipv6@ietf.org; Wed, 25 Feb 2004 20:08:14 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Aw9zt-0006wS-00 for ipv6@ietf.org; Wed, 25 Feb 2004 20:07:29 -0500 Message-ID: <032f01c3fc04$f6282280$1e6115ac@dclkempt40> From: "James Kempf" To: "Francis Dupont" , "Jari Arkko" Cc: "Nick 'Sharkey' Moore" , References: <200402241402.i1OE2iSj030222@givry.rennes.enst-bretagne.fr> Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies Date: Wed, 25 Feb 2004 16:15:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Francis, > => this is a half baked solution, i.e., either you don't want duplicates > on your network and you enforce DAD, or you accept possible problems > and you makes the live of mobile nodes (and of implementors) far easier. > So let me ask a question. If you believe optimized DAD is a half baked solution then why isn't DAD also a half baked solution? The reason I ask this is because both don't really do anything to get rid of address collisons, they just provide a procedure for detecting them. The difference is that optimized DAD is intended to fail more quickly and allow a node to use the address while it is tentative. Now it is possible that the protocol described in Nick's draft has some flaws that would cause problems for detection, but I don't think that should stop us from trying to figure out some way of improving DAD so it functions better for mobile nodes. > => the problem is the goal of optimistic/optimized DAD has no interest. > Well, that certainly isn't the case for me, and I will take the liberty of saying that I believe most mobile wireless service providers interested in IPv6 would agree. >> => what we need is collision avoidance, no collision detection after > damage. > Ah, now I believe I understand your objections better. I agree this would be ideal, as this could replace DAD as well. Perhaps you'd like to make a proposal? It seems like it might be difficult to provably prevent collisions though. > And in many cases the address collision is not based on L2. > > => currently there are three common ways to assign addresses: > - EUI64 based, i.e., relying on L2 address universal uniqueness > (read my EMEI draft to use it on mobile phones too) As I believe Nick mentions in the draft, this doesn't guarantee uniqueness because mistakes sometimes occur in manufacturer assignment of addresses, and there is also the possibility of attacks. > - RFC 3401, i.e., relying on the "birthday" paradox > - manual, i.e., relying on the care of node managers. > Obviously only the last one is a real source of trouble. Unfortunately > it is a common case for routers (EUI64 requires that you work only with > a mouse and cut&paste), some servers (DNS servers for instance, when you > look at http://www.root-servers.org/ you get no EUI64 based IID) and > some other cases (multi-interface KAME hosts here). But this should be > easy to avoid this case on a link dedicated to mobile nodes... > What about DHCP? Perhaps you believe that DHCP will never be used in IPv6 networks, but there are some people who believe it will still be important. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Feb 25 22:05: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 WAA01719 for ; Wed, 25 Feb 2004 22:05:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwBpq-0007Kv-0W for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 22:05:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q35DcS028200 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 22:05:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwBpp-0007Kl-PW for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 22:05:13 -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 WAA01685 for ; Wed, 25 Feb 2004 22:05:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwBpm-0001NK-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 22:05:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwBou-0001ID-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 22:04:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwBnw-0001DB-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 22:03:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwBnh-0006rA-G3; Wed, 25 Feb 2004 22:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwBmv-0006nj-EN for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 22:02:13 -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 WAA01592 for ; Wed, 25 Feb 2004 22:02:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwBms-00017a-00 for ipv6@ietf.org; Wed, 25 Feb 2004 22:02:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwBm0-00013R-00 for ipv6@ietf.org; Wed, 25 Feb 2004 22:01:17 -0500 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 1AwBl9-0000xK-00 for ipv6@ietf.org; Wed, 25 Feb 2004 22:00:23 -0500 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 026118392; Thu, 26 Feb 2004 04:00:23 +0100 (CET) From: "Jeroen Massar" To: "'Dan Lanciani'" , Subject: RE: Request To Advance : "Unique Local IPv6 Unicast Addresses" Date: Thu, 26 Feb 2004 03:58:30 +0100 Organization: Unfix Message-ID: <000201c3fc14$6aab1bd0$210d640a@unfix.org> 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.4510 Importance: Normal In-Reply-To: <200402252047.PAA13289@ss10.danlan.com> 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.1 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Dan Lanciani wrote: > "Jeroen Massar" wrote: > > |Dan Lanciani wrote: > | > |> "Jeroen Massar" wrote: > |> > |> |I have only one note on the "unique local ipv6 address" subject: > |> | > |> |Organisations wanting "unconnected addressspace" should go to > |> |an existing organisation that they think will outlast them in age > |> |and that already has a LIR allocation allocated. Give them some > |> |money to make them happy and request a /48 from them. > | > | > |> I'm sure that some ISP could see business in this. What I > |> don't understand is why it is necessary or desirable to create a revenue > |> stream for ISPs in this way. Could you explain how it is beneficial to the v6 > |> user community add an artificial address rental cost to internal > |> networking operations? > | > |I never said that it would be benificial to the user community, > > Then why do it? Because it is "yet another option" and also one that is available now and doesn't need anything from the IETF, IANA or anybody else? > |But it is one solution that can be taken *now* by the (many?) companies > |that require this scenario. > > You appear to be suggesting it as an alternative to the > proposed permanent allocations which this thread is about. In that context it > has been proposed before. I do not believe that it is a good reason to delay > (or worse, reject) the current proposal for permanent allocations. I never said (or wrote for that matter) that I was against this proposal either ;) To clarify I commented on a reply which mentioned the money issue... > |The 'pay some money' in the scenario above could also be replaced > |by 'rub his back' or 'donate a keg of beer' which makes many ISP's > |happy already. One could also request a /48 from one of the many > |Tunnel Broker systems out there and just don't use it globally ;) > > Why have this uncertainty in cost (and even in availability) > when we can have simple, permanent allocations as proposed? Alternate proposal, nothing against the unique-local proposal, some others raised cost concerns, thus I mentioned this alternative to them. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQD1g1SmqKFIzPnwjEQJHIACfeZZL0ojwOvf8wde7GJVU5HlEkAcAn0PO UkEOOCeLj6DPkBufWH37Jvh4 =p3hn -----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 Thu Feb 26 01:50: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 BAA09716 for ; Thu, 26 Feb 2004 01:50:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFLe-0006zg-Jz for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 01:50:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q6oIQo026878 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 01:50:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFLe-0006zR-EL for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 01:50:18 -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 BAA09698 for ; Thu, 26 Feb 2004 01:50:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwFLb-00069D-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 01:50:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwFKd-00064p-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 01:49:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwFJi-0005wg-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 01:48:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFJR-0006gp-UV; Thu, 26 Feb 2004 01:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFIo-0006g8-4I for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 01:47:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09610 for ; Thu, 26 Feb 2004 01:47:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwFIk-0005ug-00 for ipv6@ietf.org; Thu, 26 Feb 2004 01:47:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwFHr-0005qj-00 for ipv6@ietf.org; Thu, 26 Feb 2004 01:46:23 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AwFHa-0005mT-00 for ipv6@ietf.org; Thu, 26 Feb 2004 01:46:06 -0500 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id i1Q6k4i15052; Wed, 25 Feb 2004 22:46:04 -0800 (PST) From: Bill Manning Message-Id: <200402260646.i1Q6k4i15052@boreas.isi.edu> Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" In-Reply-To: <200402252005.PAA12353@ss10.danlan.com> from Dan Lanciani at "Feb 25, 4 03:05:56 pm" To: ipng-incoming@danlan.com (Dan Lanciani) Date: Wed, 25 Feb 2004 22:46:03 -0800 (PST) Cc: ipv6@ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit % Bill Manning wrote: % % | be prepared to defend yourself in court(s) in any number of % | jurisdictions. % % Against whom exactly would he be defending? Presumably the litigation would % be initiated by someone who had a financial stake in the matter. Are you % acknowledging that the current address rental model exists for profit rather % than as a solution to the technical problem of address & routing table slot % consumption? I am not impuning anything wrt routing table issues. Positing a US based example... GE uses FD00:42:: Ford uses FD00:42:: - the prefixes become entrenched in their respective corporate cultures. A tiff breaks out and they go to court and cite the IESG & the then current WG chairs for the creation of address blocks as property. this is -NOT- how the current address delegation model works. % | You should check w/ the RIRs on their role/position % | wrt legal precident on address/prefix ownership. % % Umm, wouldn't they (at least some of them) be a bit biased since it is % additional revenue that they might want for themselves? what revenue? % % | You should % | have the ISOC/IETF legal team review the creation of property rights % | by the WG chairs and the IESG. % % How do these allocations create property rights any more than the original % IPv4 allocations used before the rental model was introduced? the early delegations have very nebulous documentation (mostly) as to the terms and conditions under which they were delegated. That is not the case here. % % | Its not going to be easy and its % | not clear the effort justifies the exposure, at least to me. % % It is true that these days it is possible to cook up a legal storm about % almost anything. What is the true reason for doing so in this case? The IETF is making a fundamental change in address delegation policy w/o consultation with the existing, operational groups who manage address delegations. Fundamental changes should have a very clear and well thought out/documented reason why the changes are being considered and why objections are being overridden. Which does not seem to be the case here. % | If you do this, I will have to rethink my use of IPv6 as tainted % | goods. % % I think a lot of folks will rethink their use of IPv6 if they can't get % permanent address space. No space delegations are permanent. % % | The IETF should stick to -PROTOCOL- development, not create % | property rights to be fought over in courts. % % But the IETF has already (at least indirectly) created property rights--and % very valuable ones--for the registries and ISPs who rent addresses. A rental % property is still a property. Your complaint seems to be with property rights % for end users, not with property rights in general. That was not the IETF. That was governments and operators. The IAB concured with these groups in establishing RIRs. And if you will take the time to review the legal history, you will note that the RIRs do not claim ownership. In fact US legal precident (and in other venues as well) indicates that address delegations are -NOT- property/assets. RIRs are custodians. % % Dan Lanciani % ddl@danlan.*com % % -------------------------------------------------------------------- % IETF IPv6 working group mailing list % ipv6@ietf.org % Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 % -------------------------------------------------------------------- % -- --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 Thu Feb 26 03:43: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 DAA27890 for ; Thu, 26 Feb 2004 03:43:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwH78-0000EN-2u for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 03:43:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q8hQtm000888 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 03:43:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwH77-0000EE-Hs for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 03:43:25 -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 DAA27866 for ; Thu, 26 Feb 2004 03:43:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwH75-0001Sk-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 03:43:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwH6C-0001ND-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 03:42:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwH5Q-0001ID-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 03:41:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwH4s-00089d-KR; Thu, 26 Feb 2004 03:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwH4D-00088y-Cc for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 03:40:25 -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 DAA27719 for ; Thu, 26 Feb 2004 03:40:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwH4A-0001BL-00 for ipv6@ietf.org; Thu, 26 Feb 2004 03:40:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwH3G-00016s-00 for ipv6@ietf.org; Thu, 26 Feb 2004 03:39:27 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AwH2T-00012A-00 for ipv6@ietf.org; Thu, 26 Feb 2004 03:38:37 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7FCE015210 for ; Thu, 26 Feb 2004 17:38:37 +0900 (JST) Date: Thu, 26 Feb 2004 17:38:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies 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, 23 Feb 2004 22:21:49 +0900, >>>>> JINMEI Tatuya said: > Since we have a discussion about optimistic DAD, this is probably a > good chance to start a related discussion for rfc2462bis. (...snip...) > Having considered these points, possible resolutions *for rfc2462bis* > that I can think of are: > 1. harden the requirement: Each individual unicast address MUST be > tested for uniqueness. No MAY for omitting the rule (i.e., remove > it). We can use SHOULD instead of MUST if we need compromise. > I personally prefer option 1, because this makes the intention very > clear, avoiding further similar discussions and waste of energy. > "MUST" may be too strong for compatibility with existing > implementations, and if so, we can use "SHOULD". (And this does even > not conflict with the proposed "optimistic DAD") So far, I've not seen an objection to Option 1, and two people (Francis and Jari) seem to agree on this approach. So, I'd now like to propose a concrete change. The simplest way to implement the option would be to remove the second exception shown in Section 5.4 of RFC2462. That is, the revised text would be: 5.4 Duplicate Address Detection Duplicate Address Detection is performed on unicast addresses prior to assigning them to an interface whose DupAddrDetectTransmits variable is greater than zero. Duplicate Address Detection MUST take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration. On the other hand, Duplicate Address Detection MUST NOT be performed on anycast addresses. The procedure for detecting duplicate addresses uses Neighbor Solicitation and Advertisement messages as described below... Can we live with this simple resolution? If yes, is the requirement of "DAD **MUST** take place" acceptable? I believe this is acceptable in essence, but I'd like to know this does not cause a severe compatibility issue with existing implementations that conform to RFC2462. 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 Feb 26 04:51: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 EAA01338 for ; Thu, 26 Feb 2004 04:51:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIAy-0006Y9-Qu for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 04:51:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q9pSsA025166 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 04:51:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIAw-0006Xp-Qz for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 04:51: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 EAA01319 for ; Thu, 26 Feb 2004 04:51:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwIAt-0000SR-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 04:51:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwI9x-0000Ns-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 04:50:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwI9L-0000JZ-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 04:49:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwI8c-0006D1-AS; Thu, 26 Feb 2004 04: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 1AwI81-0006A1-Ho for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 04:48:25 -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 EAA01270 for ; Thu, 26 Feb 2004 04:48:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwI7y-0000El-00 for ipv6@ietf.org; Thu, 26 Feb 2004 04:48:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwI71-0000BN-00 for ipv6@ietf.org; Thu, 26 Feb 2004 04:47:24 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AwI6i-00007i-00 for ipv6@ietf.org; Thu, 26 Feb 2004 04:47:04 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1Q9l029006395; Thu, 26 Feb 2004 11:47:00 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1Q9kwo8006390; Thu, 26 Feb 2004 11:46:58 +0200 Date: Thu, 26 Feb 2004 11:46:58 +0200 Message-Id: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> From: Markku Savela To: jinmei@isl.rdc.toshiba.co.jp CC: ipv6@ietf.org In-reply-to: (message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= on Thu, 26 Feb 2004 17:38:47 +0900) Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies References: Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= > So, I'd now like to propose a concrete change. The simplest way to > implement the option would be to remove the second exception shown in > Section 5.4 of RFC2462. That is, the revised text would be: > > 5.4 Duplicate Address Detection > > Duplicate Address Detection is performed on unicast addresses prior > to assigning them to an interface whose DupAddrDetectTransmits > variable is greater than zero. Duplicate Address Detection MUST take > place on all unicast addresses, regardless of whether they are > obtained through stateful, stateless or manual configuration. On the > other hand, Duplicate Address Detection MUST NOT be performed on > anycast addresses. > > The procedure for detecting duplicate addresses uses Neighbor > Solicitation and Advertisement messages as described below... > > Can we live with this simple resolution? You are ignoring the installed base. There are already out and delivered, and in real use, implementations which do the DAD only for the link local. And if the ID is used combined with global prefixes, the it is assumed DAD on link local is sufficient. This is valid as per currently valid RFC, and still consider this a sensible implementation. Apparently, nobody else truly supports the multiple IDs and prefixes, with full combination? In such case, doing DAD on each new combination for each announced prefix on RA is frightening. And even with single id and new prefix this is not good: on RA with a new global prefix, every node on the link is going to do DAD based on its ID and new prefix. And, as far as I know, there is no delay requirement here, so everyone is doing it at same time. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 26 04:58: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 EAA01606 for ; Thu, 26 Feb 2004 04:58:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIHo-0007LH-8v for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 04:58:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q9wWAq028218 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 04:58:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIHn-0007L3-7D for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 04:58:31 -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 EAA01599 for ; Thu, 26 Feb 2004 04:58:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwIHk-00014y-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 04:58:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwIGo-00010O-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 04:57:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwIGT-0000vX-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 04:57:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIGM-00071B-0m; Thu, 26 Feb 2004 04:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIFx-0006zA-CH for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 04:56:37 -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 EAA01531 for ; Thu, 26 Feb 2004 04:56:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwIFt-0000vA-00 for ipv6@ietf.org; Thu, 26 Feb 2004 04:56:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwIEs-0000qr-00 for ipv6@ietf.org; Thu, 26 Feb 2004 04:55:31 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AwIE4-0000lR-00 for ipv6@ietf.org; Thu, 26 Feb 2004 04:54:40 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id A3640700B9C; Thu, 26 Feb 2004 20:54:32 +1100 (EST) Date: Thu, 26 Feb 2004 20:54:32 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies Message-ID: <20040226095432.GA19372@zoic.org> Mail-Followup-To: ipv6@ietf.org, "JINMEI Tatuya / ?$B?@L@C#:H" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-26, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > So far, I've not seen an objection to Option 1, and two people > (Francis and Jari) seem to agree on this approach. [...] > Can we live with this simple resolution? I don't object to Option 1 either, and I think the standard has to be made clearer on exactly what needs to be done. > If yes, is the requirement of "DAD **MUST** take place" acceptable? I > believe this is acceptable in essence, but I'd like to know this does > not cause a severe compatibility issue with existing implementations > that conform to RFC2462. My only concern would be whether or not there needs to be a requirement to defend LINKLOCAL::SUFFIX when configuring UNICASTPREFIX::SUFFIX. Otherwise, a configuring 'old DIID' node may not detect a collision with an existing '2462-bis DAD' node, since the former will only check the Link Local and the latter might not be defending that. (I'm thinking here of nodes which use RFC3041-like random or SEND-CGA-like hash generated addresses) -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 26 06:16: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 GAA04772 for ; Thu, 26 Feb 2004 06:16:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJVC-0006An-QX for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 06:16:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QBGQxA023725 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 06:16:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJVC-0006Aa-K4 for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 06:16: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 GAA04720 for ; Thu, 26 Feb 2004 06:16:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJV8-0000ox-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 06:16:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJUF-0000ix-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 06:15:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwJTE-0000cg-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 06:14:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJSr-0005jk-86; Thu, 26 Feb 2004 06:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJS2-0005db-JA for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 06:13:10 -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 GAA04533 for ; Thu, 26 Feb 2004 06:13:06 -0500 (EST) Resent-From: sharkey@zoic.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJRy-0000Rv-00 for ipv6@ietf.org; Thu, 26 Feb 2004 06:13:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJR4-0000J3-00 for ipv6@ietf.org; Thu, 26 Feb 2004 06:12:11 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AwJQE-00008w-00 for ipv6@ietf.org; Thu, 26 Feb 2004 06:11:19 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id E48F0700B9C; Thu, 26 Feb 2004 22:11:17 +1100 (EST) Date: Thu, 26 Feb 2004 22:10:39 +1100 From: "Nick 'Sharkey' Moore" To: Christian Vogt Subject: Re: [Mobopts] consecutive FMIP-handovers Message-ID: <20040226111039.GB19372@zoic.org> References: <200402230708.QAA01483@imd.m.ecl.ntt.co.jp> <007901c3fa12$9bda82d0$5347038d@tm.unikarlsruhe.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007901c3fa12$9bda82d0$5347038d@tm.unikarlsruhe.de> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Resent-Date: Thu, 26 Feb 2004 22:11:17 +1100 Resent-To: ipv6@ietf.org Resent-Message-Id: <20040226111117.E48F0700B9C@anchovy.zoic.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.4 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-23, Christian Vogt wrote: > > Did you take a look at HMIPv6? > > If I am not mistaken, then your approach is very similar to > how the HMIPv6 folks try to combine HMIPv6 with FMIPv6. > (See appendix A of [1].) ... and not far different from draft-moore-mobopts-edge-handovers-00's "Alternative Version", either. That being said, EH is awfully close to HMIP and FMIP anyway ... Still, it can't be a totally silly idea if we are all working on it! -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 26 06:29: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 GAA05431 for ; Thu, 26 Feb 2004 06:29:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJgx-00078S-6E for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 06:28:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QBSZF6027422 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 06:28:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJgw-00078D-QK for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 06:28:34 -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 GAA05427 for ; Thu, 26 Feb 2004 06:28:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJgs-0002JU-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 06:28:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJfw-0002Ew-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 06:27:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwJfc-0002AF-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 06:27:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJfS-0006lZ-Am; Thu, 26 Feb 2004 06:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJf0-0006ks-H5 for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 06:26:34 -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 GAA05359 for ; Thu, 26 Feb 2004 06:26:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJew-00028q-00 for ipv6@ietf.org; Thu, 26 Feb 2004 06:26:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJe1-00023n-00 for ipv6@ietf.org; Thu, 26 Feb 2004 06:25:34 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AwJdP-0001xz-00 for ipv6@ietf.org; Thu, 26 Feb 2004 06:24:56 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 5512E700B9C; Thu, 26 Feb 2004 22:24:55 +1100 (EST) Date: Thu, 26 Feb 2004 22:24:54 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Subject: Re: [Mobopts] consecutive FMIP-handovers Message-ID: <20040226112454.GA20028@zoic.org> Mail-Followup-To: ipv6@ietf.org References: <200402230708.QAA01483@imd.m.ecl.ntt.co.jp> <007901c3fa12$9bda82d0$5347038d@tm.unikarlsruhe.de> <20040226111039.GB19372@zoic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040226111039.GB19372@zoic.org> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-26, Nick 'Sharkey' Moore wrote: > Still, it can't be a totally silly idea if we are all working on it! Ooops, that was meant to go to mobopts! Sorry. Trying to do too many things at once ... -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 26 07:05: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 HAA06717 for ; Thu, 26 Feb 2004 07:05:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKFm-0002GB-30 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 07:04:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QC4YRE008680 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 07:04:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKFl-0002Ft-GV for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 07:04:33 -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 HAA06710 for ; Thu, 26 Feb 2004 07:04:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwKFh-0005bN-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 07:04:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwKEo-0005WX-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 07:03:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwKES-0005Ro-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 07:03:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKEH-0001Zd-Ld; Thu, 26 Feb 2004 07:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKDv-0001ZN-3u for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 07:02: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 HAA06658 for ; Thu, 26 Feb 2004 07:02:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwKDq-0005R2-00 for ipv6@ietf.org; Thu, 26 Feb 2004 07:02:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwKCv-0005MC-00 for ipv6@ietf.org; Thu, 26 Feb 2004 07:01:38 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AwKCa-0005H6-00 for ipv6@ietf.org; Thu, 26 Feb 2004 07:01:16 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 15DBC15210; Thu, 26 Feb 2004 21:01:11 +0900 (JST) Date: Thu, 26 Feb 2004 21:01:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Nick 'Sharkey' Moore" Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-Reply-To: <20040226095432.GA19372@zoic.org> References: <20040226095432.GA19372@zoic.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=AWL autolearn=no version=2.60 >>>>> On Thu, 26 Feb 2004 20:54:32 +1100, >>>>> "Nick 'Sharkey' Moore" said: >> If yes, is the requirement of "DAD **MUST** take place" acceptable? I >> believe this is acceptable in essence, but I'd like to know this does >> not cause a severe compatibility issue with existing implementations >> that conform to RFC2462. > My only concern would be whether or not there needs to be > a requirement to defend LINKLOCAL::SUFFIX when configuring > UNICASTPREFIX::SUFFIX. > Otherwise, a configuring 'old DIID' node may not detect a collision > with an existing '2462-bis DAD' node, since the former will only > check the Link Local and the latter might not be defending that. > (I'm thinking here of nodes which use RFC3041-like random > or SEND-CGA-like hash generated addresses) Sorry, I don't understand the concern...by which scenario might the latter not be defending the link-local address? (perhaps I don't understand what you meant by "defend"...) 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 Feb 26 07:19: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 HAA07333 for ; Thu, 26 Feb 2004 07:19:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKTP-0004LK-Ao for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 07:18:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QCIdZS016691 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 07:18:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKTP-0004L7-1Q for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 07:18: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 HAA07330 for ; Thu, 26 Feb 2004 07:18:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwKTO-0006uR-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 07:18:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwKST-0006p9-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 07:17:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwKSA-0006jw-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 07:17:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKRq-00041B-7Q; Thu, 26 Feb 2004 07:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKRN-0003zx-Fy for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 07:16:33 -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 HAA07234 for ; Thu, 26 Feb 2004 07:16:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwKRM-0006iA-00 for ipv6@ietf.org; Thu, 26 Feb 2004 07:16:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwKQO-0006dS-00 for ipv6@ietf.org; Thu, 26 Feb 2004 07:15:32 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AwKQ6-0006ZG-00 for ipv6@ietf.org; Thu, 26 Feb 2004 07:15:14 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 64A1070C404; Thu, 26 Feb 2004 23:15:08 +1100 (EST) Date: Thu, 26 Feb 2004 23:15:08 +1100 From: "Nick 'Sharkey' Moore" To: "JINMEI Tatuya / ?$B?@L@C#:H" Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies Message-ID: <20040226121507.GD19372@zoic.org> Mail-Followup-To: "JINMEI Tatuya / ?$B?@L@C#:H" , ipv6@ietf.org References: <20040226095432.GA19372@zoic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-26, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Thu, 26 Feb 2004 20:54:32 +1100, > >>>>> "Nick 'Sharkey' Moore" said: > > > My only concern would be whether or not there needs to be > > a requirement to defend LINKLOCAL::SUFFIX when configuring > > UNICASTPREFIX::SUFFIX. [...] > Sorry, I don't understand the concern...by which scenario might the > latter not be defending the link-local address? (perhaps I don't > understand what you meant by "defend"...) Sorry, that's me being obscure: By 'defend' I mean 'send an NA in response to an NS for that address from the unspecified address', eg: to 'defend' that address as being yours. The scenario being that under non-IID based allocations such as RFC3041 or SEND-CGA, a node offered prefixes A, B and C may configure different suffixes X, Y and Z ... thus the addresses A::X, B::Y, C::Z. This breaks the old assumption that all allocated addresses (on a given interface) will have the same suffix. In order to defend the address C::Z from 'old-style DIID' nodes, the new-style node would have to reply to NSs for LINKLOCAL::Z too. I'm not sure that's explicitly explained in the text (maybe I've just missed it?) cheers, hope that clarifies things? -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 26 07:42: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 HAA08035 for ; Thu, 26 Feb 2004 07:42:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKpq-000676-IQ for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 07:41:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QCfoaV023494 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 07:41:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKpq-00066q-0d for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 07:41:50 -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 HAA07971 for ; Thu, 26 Feb 2004 07:41:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwKpp-0001Me-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 07:41:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwKnf-0000uL-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 07:39:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AwKnC-0000p3-01 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 07:39:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AwKmM-0003wG-Or for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 07:38:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKmA-0005et-NU; Thu, 26 Feb 2004 07: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 1AwKln-0005aJ-3d for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 07:37: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 HAA07893 for ; Thu, 26 Feb 2004 07:37:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwKlm-0000kA-00 for ipv6@ietf.org; Thu, 26 Feb 2004 07:37:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwKkw-0000fR-00 for ipv6@ietf.org; Thu, 26 Feb 2004 07:36:47 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AwKkB-0000aS-00 for ipv6@ietf.org; Thu, 26 Feb 2004 07:35:59 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5270B15210; Thu, 26 Feb 2004 21:35:58 +0900 (JST) Date: Thu, 26 Feb 2004 21:36:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-Reply-To: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> References: <200402260946.i1Q9kwo8006390@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=AWL autolearn=no version=2.60 >>>>> On Thu, 26 Feb 2004 11:46:58 +0200, >>>>> Markku Savela said: >> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >> So, I'd now like to propose a concrete change. The simplest way to >> implement the option would be to remove the second exception shown in >> Section 5.4 of RFC2462. That is, the revised text would be: >> >> 5.4 Duplicate Address Detection >> >> Duplicate Address Detection is performed on unicast addresses prior >> to assigning them to an interface whose DupAddrDetectTransmits >> variable is greater than zero. Duplicate Address Detection MUST take >> place on all unicast addresses, regardless of whether they are >> obtained through stateful, stateless or manual configuration. On the >> other hand, Duplicate Address Detection MUST NOT be performed on >> anycast addresses. >> >> The procedure for detecting duplicate addresses uses Neighbor >> Solicitation and Advertisement messages as described below... >> >> Can we live with this simple resolution? > You are ignoring the installed base. There are already out and > delivered, and in real use, implementations which do the DAD only for > the link local. If I were really ignoring the installed base, I would simply declare the new text without asking the questions (in my previous message). I would be happy if I could get the above comment from you while I'm listening to others since the first message of this thread... Anyway, any comments at this stage are, of course, welcome. > This is valid as per currently valid RFC, Yes, but: > and still consider this a > sensible implementation. Apparently, nobody else truly supports the > multiple IDs and prefixes, with full combination? In such case, doing > DAD on each new combination for each announced prefix on RA is > frightening. basically, you seem to argue for DIID (against) DAD. Though I agree that DIID vs DAD is somewhat controversial and there is surely a tradeoff between those two, I believe the wg consensus was we should honor DAD rather than DIID (as Francis showed some pointers). And, I don't see the need for revisiting the discussion. I proposed the text for rfc2462bis in my previous message because it will make the specification simpler and clearer based on the "consensus", and three others apparently agreed (I admit I cannot call this a "majority" though) Of course, it is not my goal in rfc2462bis to invalidate existing implementations compliant to RFC2462, including those that implement "DIID". Fortunately, the tightened requirement will not introduce interoperability issue (IMO): when a (global) address collide, if a DAD node comes after a DIID node, the DAD node will detect the duplication and stop using the address. If a DIID node comes after a DAD node, and the corresponding link-local address happens to not collide, the DIID node cannot detect the duplication, and the two nodes will continue to use the duplicate address. This is bad, but is not worse than the RFC2462 world. So, I'm wondering if we can deal with this by some moderate wording. (for example, "future implementations MUST do DAD"). > And even with single id and new prefix this is not good: on RA with a > new global prefix, every node on the link is going to do DAD based on > its ID and new prefix. And, as far as I know, there is no delay > requirement here, so everyone is doing it at same time. Hmm, this is a good point. An obvious workaround is to impose a random delay when the node is starting a DAD process for an address configured by multicasted RA. Does this kind of additional requirement make sense? > all If so, should we include this 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 Feb 26 08:34: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 IAA11687 for ; Thu, 26 Feb 2004 08:34:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLeI-0003q7-Kq for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 08:33:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QDXwvB014753 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 08:33:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLeI-0003ps-Fl for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 08:33:58 -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 IAA11502 for ; Thu, 26 Feb 2004 08:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwLeH-0000ns-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 08:33:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwLc1-0000JK-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 08:31:37 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AwLb8-0000DV-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 08:30:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AwLXy-0004yT-UZ for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 08:27:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLXZ-0002vw-P5; Thu, 26 Feb 2004 08:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLX5-0002pf-Lj for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 08:26:31 -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 IAA11343 for ; Thu, 26 Feb 2004 08:26:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwLX4-0007im-00 for ipv6@ietf.org; Thu, 26 Feb 2004 08:26:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwLWC-0007fI-00 for ipv6@ietf.org; Thu, 26 Feb 2004 08:25:37 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AwLVw-0007b1-00 for ipv6@ietf.org; Thu, 26 Feb 2004 08:25:21 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1QDPERI008253; Thu, 26 Feb 2004 15:25:14 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1QDPDcR008250; Thu, 26 Feb 2004 15:25:13 +0200 Date: Thu, 26 Feb 2004 15:25:13 +0200 Message-Id: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> From: Markku Savela To: jinmei@isl.rdc.toshiba.co.jp CC: ipv6@ietf.org In-reply-to: (message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= on Thu, 26 Feb 2004 21:36:07 +0900) Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.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 > From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= > basically, you seem to argue for DIID (against) DAD. Though I agree > that DIID vs DAD is somewhat controversial and there is surely a > tradeoff between those two, I believe the wg consensus was we should > honor DAD rather than DIID (as Francis showed some pointers). And, I > don't see the need for revisiting the discussion. Yes, DIID probably (or something similar). I believe that simplest solution is that a specific ID value can be allowed only for single node on the link. Any use of same ID part with any prefix by another node should be viewed as an address collision. I've expressed this opinion years ago, on this list and elsewhere. So assumed my "vote" would have already been noted. But, I guess one needs to repeat opinion at least once per week, to be noted. It is very frustrating to see incorrect (IMHO) decisions being made by "consensus". -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 26 14:49: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 OAA05202 for ; Thu, 26 Feb 2004 14:49:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRUz-0005bU-KY for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 14:48:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QJmjrW021539 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 14:48:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRUz-0005bK-C5 for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 14:48: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 OAA05168 for ; Thu, 26 Feb 2004 14:48:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwRUw-0004hD-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 14:48:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRTz-0004b2-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 14:47:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwRTD-0004V3-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 14:46:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRRR-00051F-Ta; Thu, 26 Feb 2004 14:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRRG-00050J-RE for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 14:44:54 -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 OAA04916 for ; Thu, 26 Feb 2004 14:44:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwRRE-0004IP-00 for ipv6@ietf.org; Thu, 26 Feb 2004 14:44:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRQK-0004DK-00 for ipv6@ietf.org; Thu, 26 Feb 2004 14:43:56 -0500 Received: from cs180204.pp.htv.fi ([213.243.180.204] helo=hades.pp.htv.fi ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AwRQ0-00047O-00 for ipv6@ietf.org; Thu, 26 Feb 2004 14:43:37 -0500 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id i1QJjNbG015357; Thu, 26 Feb 2004 21:45:23 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id i1QJjLIp015356; Thu, 26 Feb 2004 21:45:21 +0200 Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies From: Mika Liljeberg 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=UTF-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1077824721.10991.14.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 26 Feb 2004 21:45:21 +0200 Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Mon, 2004-02-23 at 15:21, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 wrote: > Having considered these points, possible resolutions *for rfc2462bis* > that I can think of are: >=20 > 1. harden the requirement: Each individual unicast address MUST be > tested for uniqueness. No MAY for omitting the rule (i.e., remove > it). We can use SHOULD instead of MUST if we need compromise. >=20 > 2. MUST run DAD on all addresses for which the interface identifier is > NOT globally unique (such as non EUI-64 ID). This is a proposal by > Thomas Narten in June 2001. (see the issue tracker for more > background information) >=20 > 3. do nothing for this in rfc2462bis; leave Section 5.4 as is, do not > add any text. >=20 > 4. no change in the protocol specification, but add an appendix (or > something) to discuss the issue on the effect of > omitting/optimizing DAD. Option 5, add the following clarification: A node that has the configured address PREFIX::IID and follows the "DAD all addresses" logic MUST defend FE80::IID as well as PREFIX::ID. A node that follows the "DAD only link-local address" logic MUST defend all addresses derived from IID. The above will allow DAD and DIID to coexist peacefully. My vote goes to option 5. Failing that, option 4 seems least objectionable. Regards, MikaL -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 26 17: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 RAA14969 for ; Thu, 26 Feb 2004 17:58:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUSB-0004st-Lo for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 17:58:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QMw3mZ018769 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 17:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUSB-0004sX-1a for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 17:58:03 -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 RAA14940 for ; Thu, 26 Feb 2004 17:57:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwUS8-0002HB-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 17:58:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwURF-0002BV-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 17:57:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwUQf-000250-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 17:56:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUQG-0004Ud-0r; Thu, 26 Feb 2004 17:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUQ5-0004Te-Ok for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 17:55:53 -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 RAA14804 for ; Thu, 26 Feb 2004 17:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwUQ2-00021i-00 for ipv6@ietf.org; Thu, 26 Feb 2004 17:55:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwUP8-0001wM-00 for ipv6@ietf.org; Thu, 26 Feb 2004 17:54:55 -0500 Received: from usen-221x249x121x227.ap-us01.usen.ad.jp ([221.249.121.227] helo=coconut.itojun.org) by ietf-mx with esmtp (Exim 4.12) id 1AwUOL-0001rW-00 for ipv6@ietf.org; Thu, 26 Feb 2004 17:54:05 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 9DF1FAB; Fri, 27 Feb 2004 07:54:03 +0900 (JST) To: sharkey@zoic.org Cc: ipv6@ietf.org, msa@burp.tkv.asdf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-Reply-To: Your message of "Fri, 27 Feb 2004 07:09:02 +1100" <20040226200901.GB23217@zoic.org> References: <20040226200901.GB23217@zoic.org> X-Mailer: Cue version 0.6 (040210-0635/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040226225403.9DF1FAB@coconut.itojun.org> Date: Fri, 27 Feb 2004 07:54:03 +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 > > Yes, DIID probably (or something similar). I believe that simplest > > solution is that a specific ID value can be allowed only for single > > node on the link. Any use of same ID part with any prefix by another > > node should be viewed as an address collision. > > I can see where you are coming from: for DAD to safely > interoperate with DIID it must send even more messages: wouldn't > it be nice to just send a single NS/NA pair? After all, > DIID is already compatible with DIID. this i remember very precisely. we have already discussed DIID/DAD to death and picked DAD already. i don't think it necessary to open the topic up again. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 26 18:45: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 SAA17336 for ; Thu, 26 Feb 2004 18:45:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwVBc-0005Rp-A6 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 18:45:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QNj07S020935 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 18:45:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwVBc-0005Ra-4L for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 18:45:00 -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 SAA17323 for ; Thu, 26 Feb 2004 18:44:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwVBZ-0006RC-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 18:44:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwVAd-0006Lr-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 18:44:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwVA0-0006GL-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 18:43:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwV9i-00054K-8Y; Thu, 26 Feb 2004 18:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwV9Z-00053Q-GH for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 18:42:53 -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 SAA17251 for ; Thu, 26 Feb 2004 18:42:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwV9W-0006EJ-00 for ipv6@ietf.org; Thu, 26 Feb 2004 18:42:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwV8a-00069J-00 for ipv6@ietf.org; Thu, 26 Feb 2004 18:41:53 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AwV7g-00063x-00 for ipv6@ietf.org; Thu, 26 Feb 2004 18:40:57 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id BBFB471B7FB; Fri, 27 Feb 2004 10:40:49 +1100 (EST) Date: Fri, 27 Feb 2004 10:40:49 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies Message-ID: <20040226234049.GA24880@zoic.org> Mail-Followup-To: ipv6@ietf.org References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040226200901.GB23217@zoic.org> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-27, Nick 'Sharkey' Moore wrote: > > I'm convinced that a change needs to be made to the wording to > resolve this issue, but I'm not sure which is the better option. My suggested text for "DAD but interoperable with DIID": [5.4. Duplicate Address Detection][...] - Each individual unicast address MUST be tested for uniqueness. - When configuring a global unicast address, the link-local address with the same suffix as that address MUST be configured and tested for uniqueness in order to maintain interoperability with RFC2462 behaviour. -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 26 19:39: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 TAA18973 for ; Thu, 26 Feb 2004 19:39:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwW1o-0000i9-Cb for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 19:38:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R0cuBt002732 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 19:38:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwW1o-0000hz-4t for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 19:38:56 -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 TAA18921 for ; Thu, 26 Feb 2004 19:38:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwW1m-0003VB-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 19:38:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwW0v-0003Py-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 19:38:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwW0E-0003KV-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 19:37:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwVz0-00005S-TH; Thu, 26 Feb 2004 19:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwVyu-0008WK-Sz for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 19:35: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 TAA18826 for ; Thu, 26 Feb 2004 19:35:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwVyt-0003EJ-00 for ipv6@ietf.org; Thu, 26 Feb 2004 19:35:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwVxw-00039e-00 for ipv6@ietf.org; Thu, 26 Feb 2004 19:34:56 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1AwVxR-00034x-00 for ipv6@ietf.org; Thu, 26 Feb 2004 19:34:26 -0500 Received: from localhost ([130.194.13.85]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L73EO7VZK48X3JIT@vaxh.its.monash.edu.au> for ipv6@ietf.org; Fri, 27 Feb 2004 11:10:10 +1100 Received: from broink.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 11586158002; Fri, 27 Feb 2004 11:10:10 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by broink.its.monash.edu.au (Postfix) with ESMTP id EF2D9120009; Fri, 27 Feb 2004 11:10:09 +1100 (EST) Date: Fri, 27 Feb 2004 11:10:09 +1100 From: Greg Daley Subject: Defending against DIID (was Re: [rfc2462bis issue 275] DAD text inconsistencies) To: Jun-ichiro itojun Hagino Cc: sharkey@zoic.org, ipv6@ietf.org, msa@burp.tkv.asdf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <403E8AE1.8070401@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <20040226200901.GB23217@zoic.org> <20040226225403.9DF1FAB@coconut.itojun.org> 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 itojun, I think Nick was expressing frustration in this case, rather than proposing to adopt a bad solution. Jun-ichiro itojun Hagino wrote: >>>Yes, DIID probably (or something similar). I believe that simplest >>>solution is that a specific ID value can be allowed only for single >>>node on the link. Any use of same ID part with any prefix by another >>>node should be viewed as an address collision. >> >>I can see where you are coming from: for DAD to safely >>interoperate with DIID it must send even more messages: wouldn't >>it be nice to just send a single NS/NA pair? After all, >>DIID is already compatible with DIID. > > > this i remember very precisely. we have already discussed DIID/DAD to > death and picked DAD already. i don't think it necessary to open the > topic up again. > What we really need is a way to ensure that we can use DAD in a way which prevents existing DIID nodes from causing troubles. We can tell people that DIID exists, but is deprecated, and has to be dealt with to ensure backward compatability with old devices. We can handle this by ensuring that addresses which are in use by a DAD node aren't assumed to be available by DAD nodes. This will may need algorithmic modification in some cases. Essentially, a newly configuring DIID node MUST send a DAD NS for the fe80::suffix address. This goes to the solicited nodes' address for the suffix. Whan the existing node has completed DAD on a prefix::suffix address, it is already a member of the same solicited nodes' address. Therefore, even if it doesn't have the particular target address configured (it hasn't got fe80::suffix configured itself) it will see the DAD NS from the DIID node. Since we know that nodes attempting to do DIID will do DAD on the link-local address, any other addresses configured for DIID should be tentative at the time. Transmission of an DAD defence for the currently configured prefix::suffix address should work to prevent DAD. If the host already posesses the fe80::suffix address, that would be used instead (and is sufficient for defending against DIID). Only in the case where the link local address wasn't configured (CGA addresses for SEND, rfc-3041 addresses) would the algorithmic modification be required. In the SEND case, it is unlikely that any suffix will be configured more than once on an interface (which means only one message will respond to the DAD attempt). In the case that the configuring node was doing full DAD for a number of addresses with the same suffix, it will have already joined the solicited nodes' group. Therefore, it should receive the DAD defence NA from the node. Even if it hasn't already sent the DAD NS for a global prefix, it may still receive the DAD defence NA, since it receives the solicited nodes' datagram. In the worst case, the defending node will transmit a defence for both the link-local and the global prefix DAD NS's. Greg Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 26 20:34: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 UAA21245 for ; Thu, 26 Feb 2004 20:34:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwWtG-0003pL-O6 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 20:34:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R1YAeB014705 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 20:34:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwWtF-0003p6-UZ for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 20:34:09 -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 UAA21242 for ; Thu, 26 Feb 2004 20:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwWtD-00013w-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 20:34:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwWsD-0000y2-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 20:33:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwWro-0000sK-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 20:32:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwWrB-0003VW-BY; Thu, 26 Feb 2004 20:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwWqC-0003Tz-Ng for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 20:31: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 UAA21075 for ; Thu, 26 Feb 2004 20:30:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwWqA-0000lf-00 for ipv6@ietf.org; Thu, 26 Feb 2004 20:30:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwWpH-0000fx-00 for ipv6@ietf.org; Thu, 26 Feb 2004 20:30:04 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1AwWoP-0000TT-00 for ipv6@ietf.org; Thu, 26 Feb 2004 20:29:09 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i1R1SVLc006667 for ; Thu, 26 Feb 2004 19:28:31 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 19:24:02 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Feb 2004 19:28:29 -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 17VGV70R; Thu, 26 Feb 2004 20:28:35 -0500 Date: Thu, 26 Feb 2004 20:28:18 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830D8F6ABC@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-OriginalArrivalTime: 27 Feb 2004 01:24:02.0890 (UTC) FILETIME=[6249B2A0:01C3FCD0] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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, 26 Feb 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: >If yes, is the requirement of "DAD **MUST** take place" acceptable? I >believe this is acceptable in essence, but I'd like to know this does >not cause a severe compatibility issue with existing implementations >that conform to RFC2462. The stock linux IP stack does the DAD for all the addresses autoconfigured from an advertised prefix and so it will not be affected. I know this for kernel 2.4.x and 2.6.3 Regards Suresh This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 26 20:41: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 UAA21686 for ; Thu, 26 Feb 2004 20:41: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 1AwWzv-0004bi-PD for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 20:41:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R1f33S017704 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 20:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwWzv-0004bT-Jm for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 20:41:03 -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 UAA21667 for ; Thu, 26 Feb 2004 20:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwWzt-0001sN-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 20:41:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwWyu-0001n5-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 20:40:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwWyP-0001i7-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 20:39:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwWxy-0004Gk-92; Thu, 26 Feb 2004 20:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwWx7-0004Fm-C8 for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 20:38:09 -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 UAA21483 for ; Thu, 26 Feb 2004 20:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwWx5-0001aW-00 for ipv6@ietf.org; Thu, 26 Feb 2004 20:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwWwC-0001R6-00 for ipv6@ietf.org; Thu, 26 Feb 2004 20:37:12 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwWvC-0001IZ-00 for ipv6@ietf.org; Thu, 26 Feb 2004 20:36:10 -0500 Received: from localhost ([130.194.13.84]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L73HJAUQHC8WW209@vaxc.its.monash.edu.au> for ipv6@ietf.org; Fri, 27 Feb 2004 12:32:29 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 97CE039C00D; Fri, 27 Feb 2004 12:32:29 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 10FD62DC012; Fri, 27 Feb 2004 12:32:29 +1100 (EST) Date: Fri, 27 Feb 2004 12:32:28 +1100 From: Greg Daley Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies To: "Nick 'Sharkey' Moore" Cc: ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <403E9E2C.3040208@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040226234049.GA24880@zoic.org> 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 Sharkey, Nick 'Sharkey' Moore wrote: > On 2004-02-27, Nick 'Sharkey' Moore wrote: > >>I'm convinced that a change needs to be made to the wording to >>resolve this issue, but I'm not sure which is the better option. > > > My suggested text for "DAD but interoperable with DIID": > > [5.4. Duplicate Address Detection][...] > > - Each individual unicast address MUST be tested for uniqueness. > > - When configuring a global unicast address, the link-local > address with the same suffix as that address MUST be configured > and tested for uniqueness in order to maintain interoperability > with RFC2462 behaviour. I think that configuring additional addresses which don't match the prefix used to generate the suffix in the CGA is going to cause problems. (the following is simplified): Essentially, the CGA is generated from a nonce, a prefix and a public key. in this case: prefix::PrK(Hash(Nonce,prefix,PuK)). The recipient of the nonce and public key (provided in SEND messages can check that the private key owner generated the address. If the prefix changes and the suffix stays the same: the receiver would have fe80::PrK(Hash(Nonce,Prefix,PuK)) and the Nonce and PuK, but not the original prefix. Unless the recipient knows the original prefix, the hash is useless (doesn't prove anything). The messages would have to be treated as unsecured for SEND (unless new SEND procedures were defined). I'm pretty sure that SEND nodes work around unsecured messages in the case of DAD (they currently accept a single unsecured DAD NA response. The solution is pretty ugly though, since it relies upon function which is hacked into SEND. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Feb 26 21:56: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 VAA24926 for ; Thu, 26 Feb 2004 21:56:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwYA1-0000ih-Sm for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 21:55:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R2tXOR002761 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 21:55:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwYA1-0000iS-O5 for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 21:55:33 -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 VAA24808 for ; Thu, 26 Feb 2004 21:55:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwY9y-00029v-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 21:55:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwY8t-0001vy-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 21:54:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AwY8F-0001ol-01 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 21:53:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AwY1J-0004uR-5i for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 21:46:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwY0p-0008QI-7U; Thu, 26 Feb 2004 21:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwY0k-0008PT-Lj for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 21:45:58 -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 VAA24488 for ; Thu, 26 Feb 2004 21:45:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwY0h-0001F6-00 for ipv6@ietf.org; Thu, 26 Feb 2004 21:45:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwXzp-0001Ar-00 for ipv6@ietf.org; Thu, 26 Feb 2004 21:45:02 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AwXz7-00016E-00 for ipv6@ietf.org; Thu, 26 Feb 2004 21:44:17 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 184C271B7FE; Fri, 27 Feb 2004 13:44:09 +1100 (EST) Date: Fri, 27 Feb 2004 13:44:08 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: Greg Daley Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies Message-ID: <20040227024408.GB24880@zoic.org> Mail-Followup-To: ipv6@ietf.org, Greg Daley References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040226234049.GA24880@zoic.org> <403E9E2C.3040208@eng.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403E9E2C.3040208@eng.monash.edu.au> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-27, Greg Daley wrote: > Nick 'Sharkey' Moore wrote: > > > > - When configuring a global unicast address, the link-local > > address with the same suffix as that address MUST be configured > > and tested for uniqueness in order to maintain interoperability > > with RFC2462 behaviour. > > I think that configuring additional addresses which > don't match the prefix used to generate the suffix in > the CGA is going to cause problems. Good point. However, the MN registering A::X only needs to defend the LL::X against DIID-compatible nodes. I think we can assume that SEND-CGA nodes will follow the _new_ DAD standard. So the unsecured defensive NA should be okay, since it won't be needed against SEND-CGA nodes. ... I think. Any SENDites want to comment? NB: Is there a plan for 3041bis? It's rather bound up with DIID too. cheers, -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 27 00:27: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 AAA00402 for ; Fri, 27 Feb 2004 00:27:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwaWk-0000wU-3P for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 00:27:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R5RAnQ003616 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 00:27:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwaWj-0000wF-Uo for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 00:27:10 -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 AAA00374 for ; Fri, 27 Feb 2004 00:27:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwaWh-0001rx-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:27:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwaVl-0001lr-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:26:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwaV4-0001gM-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:25:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwaUi-0000Yb-OB; Fri, 27 Feb 2004 00:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwaTp-0000S2-VQ for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 00:24:10 -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 AAA00220 for ; Fri, 27 Feb 2004 00:24:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwaTn-0001ZJ-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:24:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwaSs-0001UA-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:23:11 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AwaSY-0001Oi-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:22:51 -0500 Message-ID: <011a01c3fcf1$d0352e90$036015ac@dclkempt40> From: "James Kempf" To: "Nick 'Sharkey' Moore" , Cc: "Greg Daley" References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040226234049.GA24880@zoic.org> <403E9E2C.3040208@eng.monash.edu.au> <20040227024408.GB24880@zoic.org> Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies Date: Thu, 26 Feb 2004 21:23:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Not quite sure I entirely understand the issue, but SEND makes no change in the basic underlying DAD algorithm. If the address suffix generated from the key hash changes due to a change in the prefix, then the address has to be re-DAD-ed. If the node decides to reuse the old suffix, then the address isn't a CGA and SEND can't be used. SEND includes support for interoperation between SEND and nonSEND nodes, so it should work if a node decides not to use SEND. jak ----- Original Message ----- From: "Nick 'Sharkey' Moore" To: Cc: "Greg Daley" Sent: Thursday, February 26, 2004 6:44 PM Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies > On 2004-02-27, Greg Daley wrote: > > Nick 'Sharkey' Moore wrote: > > > > > > - When configuring a global unicast address, the link-local > > > address with the same suffix as that address MUST be configured > > > and tested for uniqueness in order to maintain interoperability > > > with RFC2462 behaviour. > > > > I think that configuring additional addresses which > > don't match the prefix used to generate the suffix in > > the CGA is going to cause problems. > > Good point. However, the MN registering A::X only needs to > defend the LL::X against DIID-compatible nodes. > I think we can assume that SEND-CGA nodes will follow the > _new_ DAD standard. So the unsecured defensive NA should be okay, > since it won't be needed against SEND-CGA nodes. > > ... I think. Any SENDites want to comment? > > NB: Is there a plan for 3041bis? It's rather bound up with > DIID too. > > cheers, > -----Nick > > -------------------------------------------------------------------- > 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 Feb 27 00: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 AAA00712 for ; Fri, 27 Feb 2004 00:37:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwagP-0001ku-VP for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 00:37:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R5b9Lt006738 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 00:37:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwagP-0001kW-Ip for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 00:37:09 -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 AAA00666 for ; Fri, 27 Feb 2004 00:37:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwagN-0002rv-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:37:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwafL-0002l7-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:36:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwaeR-0002gG-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:35:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwaeO-0001Gp-3n; Fri, 27 Feb 2004 00:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwadN-0001Fl-TA for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 00:34: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 AAA00575 for ; Fri, 27 Feb 2004 00:33:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwadL-0002a3-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:33:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwacT-0002Ut-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:33:05 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Awaba-0002Pt-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:32:11 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8DF8D15214; Fri, 27 Feb 2004 14:32:09 +0900 (JST) Date: Fri, 27 Feb 2004 14:32:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Nick 'Sharkey' Moore" Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-Reply-To: <20040227024408.GB24880@zoic.org> References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040226234049.GA24880@zoic.org> <403E9E2C.3040208@eng.monash.edu.au> <20040227024408.GB24880@zoic.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=AWL autolearn=no version=2.60 >>>>> On Fri, 27 Feb 2004 13:44:08 +1100, >>>>> "Nick 'Sharkey' Moore" said: > NB: Is there a plan for 3041bis? It's rather bound up with > DIID too. A quick response. I guess you are talking about the following part of RFC3041: Note: because multiple temporary addresses are generated from the same associated randomized interface identifier, there is little benefit in running DAD on every temporary address. This document recommends that DAD be run on the first address generated from a given randomized identifier, but that DAD be skipped on all subsequent addresses generated from the same randomized interface identifier. (the last paragraph of Section 3.3) However, RFC3041 actually has a successor, draft-ietf-ipngwg-temp-addresses-v2-00.txt (expired for a long period though), which reversed the logic: Note: although multiple temporary addresses are generated from the same associated randomized interface identifier, DAD should still be run on every temporary address. Otherwise, it is possible that two nodes will select the same interface identifier but not detect the collision if they run DAD on addresses generated from different prefixes. (the last paragraph of Section 3.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 Fri Feb 27 00:43: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 AAA00974 for ; Fri, 27 Feb 2004 00:43:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwamF-0002nN-07 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 00:43:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R5hASo010745 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 00:43:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwamE-0002nE-RC for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 00:43:10 -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 AAA00956 for ; Fri, 27 Feb 2004 00:43:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwamC-0003Tl-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:43:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwalC-0003NK-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:42:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwakI-0003IB-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:41:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwakC-00029x-Bu; Fri, 27 Feb 2004 00:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwajE-00028M-I0 for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 00:40: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 AAA00868 for ; Fri, 27 Feb 2004 00:40:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwajB-0003Bu-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:40:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwaiG-000372-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:39:05 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AwahU-00031H-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:38:16 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D152315210; Fri, 27 Feb 2004 14:38:16 +0900 (JST) Date: Fri, 27 Feb 2004 14:38:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Nick 'Sharkey' Moore" Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-Reply-To: <20040226121507.GD19372@zoic.org> References: <20040226095432.GA19372@zoic.org> <20040226121507.GD19372@zoic.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=AWL autolearn=no version=2.60 >>>>> On Thu, 26 Feb 2004 23:15:08 +1100, >>>>> "Nick 'Sharkey' Moore" said: >> Sorry, I don't understand the concern...by which scenario might the >> latter not be defending the link-local address? (perhaps I don't >> understand what you meant by "defend"...) > Sorry, that's me being obscure: By 'defend' I mean 'send an NA in > response to an NS for that address from the unspecified address', > eg: to 'defend' that address as being yours. > The scenario being that under non-IID based allocations such as > RFC3041 or SEND-CGA, a node offered prefixes A, B and C may > configure different suffixes X, Y and Z ... thus the addresses > A::X, B::Y, C::Z. > This breaks the old assumption that all allocated addresses (on > a given interface) will have the same suffix. In order to > defend the address C::Z from 'old-style DIID' nodes, the new-style > node would have to reply to NSs for LINKLOCAL::Z too. > I'm not sure that's explicitly explained in the text (maybe I've > just missed it?) > cheers, hope that clarifies things? Honestly, I was not 100% sure about the point when I first saw the message. But I think I now understand it by the succeeding messages in this thread. Thanks for the elaboration. 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 Feb 27 00:44: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 AAA01051 for ; Fri, 27 Feb 2004 00:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awan6-0002p9-Ff for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 00:44:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R5i4TL010849 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 00:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awan6-0002ou-Bm for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 00:44: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 AAA00995 for ; Fri, 27 Feb 2004 00:44:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awan3-0003bQ-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:44:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awam6-0003Su-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:43:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awal8-0003Me-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awal7-0002Sg-Vs; Fri, 27 Feb 2004 00:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwakA-00029W-SS for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 00:41: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 AAA00885 for ; Fri, 27 Feb 2004 00:40:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awak8-0003Gi-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:41:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwajE-0003CF-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:40:05 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AwaiW-00037v-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:39:20 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 56AD471B801; Fri, 27 Feb 2004 16:39:13 +1100 (EST) Date: Fri, 27 Feb 2004 16:39:13 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies Message-ID: <20040227053912.GA26483@zoic.org> Mail-Followup-To: ipv6@ietf.org, "JINMEI Tatuya / ?$B?@L@C#:H" References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040226234049.GA24880@zoic.org> <403E9E2C.3040208@eng.monash.edu.au> <20040227024408.GB24880@zoic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-27, JINMEI Tatuya / ?$B?@L@C#:H wrote: > "Nick 'Sharkey' Moore" said: > > > > NB: Is there a plan for 3041bis? It's rather bound up with > > DIID too. > > A quick response. I guess you are talking about the following part of > RFC3041: [...] (the last paragraph of Section 3.3) Yep, and the other references to 'Interface Identifier' throughout, since we're no longer really making up an II and generating addresses from it, we're just making up random suffixes. Well, that's how I'd see it, anyway. > However, RFC3041 actually has a successor, > draft-ietf-ipngwg-temp-addresses-v2-00.txt (expired for a long period > though), which reversed the logic: Ah, thanks, I hadn't seen that. I'll have a read. I guess that'd be the basis for 3041bis if we decide we need one. -----Nick -- Nick 'Sharkey' Moore "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 27 00:50: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 AAA01304 for ; Fri, 27 Feb 2004 00:50:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awat0-0003J4-R3 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 00:50:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R5oAnv012704 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 00:50:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awat0-0003Ip-N2 for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 00:50:10 -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 AAA01268 for ; Fri, 27 Feb 2004 00:50:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awasy-0004GF-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:50:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awarw-00049C-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:49:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awaqz-00042p-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:48:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awaqw-0002yG-6u; Fri, 27 Feb 2004 00:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwaqK-0002wx-Pt for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 00:47:24 -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 AAA01157 for ; Fri, 27 Feb 2004 00:47:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwaqI-0003yC-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:47:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwapC-0003ro-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:46:14 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx with esmtp (Exim 4.12) id 1Awaot-0003mG-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:45:55 -0500 Received: from localhost ([130.194.13.84]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L73Q8R3VEI8Y5DAT@vaxc.its.monash.edu.au> for ipv6@ietf.org; Fri, 27 Feb 2004 16:41:18 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id C516039C00D; Fri, 27 Feb 2004 16:41:17 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id A4AB42DC012; Fri, 27 Feb 2004 16:41:17 +1100 (EST) Date: Fri, 27 Feb 2004 16:41:17 +1100 From: Greg Daley Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies To: "Nick 'Sharkey' Moore" Cc: ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <403ED87D.6000207@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040226234049.GA24880@zoic.org> <403E9E2C.3040208@eng.monash.edu.au> <20040227024408.GB24880@zoic.org> 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 Sharkey, Nick 'Sharkey' Moore wrote: > On 2004-02-27, Greg Daley wrote: > >>Nick 'Sharkey' Moore wrote: >> >>> - When configuring a global unicast address, the link-local >>> address with the same suffix as that address MUST be configured >>> and tested for uniqueness in order to maintain interoperability >>> with RFC2462 behaviour. >> >>I think that configuring additional addresses which >>don't match the prefix used to generate the suffix in >>the CGA is going to cause problems. > > > Good point. However, the MN registering A::X only needs to > defend the LL::X against DIID-compatible nodes. > I think we can assume that SEND-CGA nodes will follow the > _new_ DAD standard. So the unsecured defensive NA should be okay, > since it won't be needed against SEND-CGA nodes. > > ... I think. Any SENDites want to comment? I'm not really a SENDite, but... > NB: Is there a plan for 3041bis? It's rather bound up with > DIID too. I think that you're right about this (! missed that) since the SEND devices will have distinct IIDs for each prefix anyway, DIID isn't useful for them. It doesn't mean I like your solution... :) Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 27 00:57: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 AAA01524 for ; Fri, 27 Feb 2004 00:57: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 1Awazj-0003oP-27 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 00:57:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R5v762014647 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 00:57:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awazi-0003oA-Od for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 00:57: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 AAA01499 for ; Fri, 27 Feb 2004 00:57:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awazg-0004rg-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:57:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awayj-0004mO-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:56:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awaxp-0004hD-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 00:55:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awaxj-0003Ss-I2; Fri, 27 Feb 2004 00:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awawm-0003R3-ST for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 00:54: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 AAA01429 for ; Fri, 27 Feb 2004 00:54:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awawk-0004bx-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:54:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awavw-0004Xy-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:53:13 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Awav6-0004TE-00 for ipv6@ietf.org; Fri, 27 Feb 2004 00:52:20 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5537F15214; Fri, 27 Feb 2004 14:52:20 +0900 (JST) Date: Fri, 27 Feb 2004 14:52:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Nick 'Sharkey' Moore" Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-Reply-To: <20040226200901.GB23217@zoic.org> References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.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=AWL autolearn=no version=2.60 >>>>> On Fri, 27 Feb 2004 07:09:02 +1100, >>>>> "Nick 'Sharkey' Moore" said: >> Yes, DIID probably (or something similar). I believe that simplest >> solution is that a specific ID value can be allowed only for single >> node on the link. Any use of same ID part with any prefix by another >> node should be viewed as an address collision. > I can see where you are coming from: for DAD to safely > interoperate with DIID it must send even more messages: wouldn't > it be nice to just send a single NS/NA pair? After all, > DIID is already compatible with DIID. > I'm convinced that a change needs to be made to the wording to > resolve this issue, but I'm not sure which is the better option. > I'm also dubious about relying on votes at IETF meetings for > technical issues ... because often an option which seems 'obvious' > at the time actually isn't once the drafts have been considered > in detail. And most of the WG attendees won't have considered > them in detail before the meeting. Sad but true. (I know this is not a technical discussion, so I'll try to refrain myself from making further posting on this particular point. But feel free to respond to this message, of course) I see your frustration, but we have been experiencing similar cases for controversial discussions many times here in the IETF. The "consensus" or "decision" often looks like an unreasonable result just supported by a majority without thinking the issue carefully, if you are against the consensus. Let's just recall the recent site-local discussions... Unfortunately, we must often make a decision, or even compromise anyway to move forward. Even though there are some valid points in DIID, I don't think what we have now in this discussion is worth revisiting the past decision and delaying the process. 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 Feb 27 01:36: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 BAA02433 for ; Fri, 27 Feb 2004 01:36:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwbbU-0005vk-SA for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 01:36:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R6a8G8022790 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 01:36:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwbbU-0005vV-Bi for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 01:36:08 -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 BAA02424 for ; Fri, 27 Feb 2004 01:36:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwbbR-0000Od-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 01:36:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwbaV-0000Ju-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 01:35:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwbZv-0000FR-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 01: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 1AwbZS-0005aC-1d; Fri, 27 Feb 2004 01:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwbYb-0005Z0-Fh for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 01:33:09 -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 BAA02365 for ; Fri, 27 Feb 2004 01:33:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwbYY-0000Ar-00 for ipv6@ietf.org; Fri, 27 Feb 2004 01:33:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwbXc-00006K-00 for ipv6@ietf.org; Fri, 27 Feb 2004 01:32:09 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AwbXR-000016-00 for ipv6@ietf.org; Fri, 27 Feb 2004 01:31:58 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 62E2815210; Fri, 27 Feb 2004 15:31:58 +0900 (JST) Date: Fri, 27 Feb 2004 15:32:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Nick 'Sharkey' Moore" Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-Reply-To: <20040226200901.GB23217@zoic.org> References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.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=AWL autolearn=no version=2.60 >>>>> On Fri, 27 Feb 2004 07:09:02 +1100, >>>>> "Nick 'Sharkey' Moore" said: > I'm convinced that a change needs to be made to the wording to > resolve this issue, but I'm not sure which is the better option. > I'm also dubious about relying on votes at IETF meetings for > technical issues ... because often an option which seems 'obvious' > at the time actually isn't once the drafts have been considered > in detail. And most of the WG attendees won't have considered > them in detail before the meeting. Sad but true. > Questions for the group: > * DIID offers less signalling. What advantages does DAD offer? An obvious advantage is less probability of (missing) duplication (as was pointed out even in this thread several times). A supplemental advantage would be simplicity and clarity in the specification (and probably in implementations). I know this kind of argument is more or less subjective and may not be convincing though. The important thing is that we had discussed these tradeoffs long before, and we made a decision for DAD. I admit there are some new issues (e.g., SEND CGAs are obviously new), but I personally don't think they are powerful enough to revisit the decision. > * Does DAD retain these advantages when made compatible with DIID? > (by testing/defending LL::X, as per my earlier suggestion) > * Can backwards compatibility be dispensed with? > (I'm going to be a hard sell on that one ...) Honestly speaking, I don't see the need for making DAD "compatible" with DIID in the first place. Recall that DAD is not "compatible" with DIID in this sense, even with the current RFC2462. Since there are currently always-DAD implementations as well as DIID ones, we already have the "compatibility" issue. That is, this is not a new compatibility issue introdueced by the proposed change (MUST do DAD, period.) in rfc2462bis. Meanwhile, even DAD is not perfect in that we can still miss duplication due to a timing problem or packet loss. Even if we introduce some new effort to make DAD compatible with DIID, it will not be perfect either. I thus conclude that we don't need a change, at least in rfc2462bis, to make DAD compatible with DIID. Again, my plan is simple. - just say "MUST do DAD for all unicast addresses" (or SHOULD if we need a wording compromise) in rfc2462bis. - this does not make the current status worse in the sense of "compatibility" with DIID, since there are already always-DAD nodes. - as implementations gradually migrate to rfc2462bis, the "compatibility" issue will go away automatically. Even if DIID implementations remain forever, the situation will basically be the same as the current one. But as I said in a previous message, it's not my purpose to invalidate existing DIID implementations. For example, I don't want to see a DIID implementation be called "non-compliant" in a spec-conformance test event, etc. If I can avoid the scenario by adding some careful note in rfc2462bis, I'm willing to do that. 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 Feb 27 02:24: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 CAA17696 for ; Fri, 27 Feb 2004 02:24:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcM9-0008ND-ME for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 02:24:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R7OLH6032148 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 02:24:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcM7-0008MK-J1 for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 02:24: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 CAA17648 for ; Fri, 27 Feb 2004 02:24:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwcM4-0005eA-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 02:24:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwcLD-0005Y9-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 02:23:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwcKO-0005RL-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 02:22:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcJv-0007Fr-54; Fri, 27 Feb 2004 02:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcJN-00073H-78 for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 02:21: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 CAA17339 for ; Fri, 27 Feb 2004 02:21:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwcJ9-0005JH-00 for ipv6@ietf.org; Fri, 27 Feb 2004 02:21:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwcIK-0005DV-00 for ipv6@ietf.org; Fri, 27 Feb 2004 02:20:25 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AwcHl-00056U-00 for ipv6@ietf.org; Fri, 27 Feb 2004 02:19:49 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0BB0715210; Fri, 27 Feb 2004 16:19:49 +0900 (JST) Date: Fri, 27 Feb 2004 16:20:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Soliman Hesham Cc: IETF Mailing List Subject: Re: [2461bis issue 250] Reception of prefix option with prefix length > 64 In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F042123@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F042123@ftmail.lab.flarion.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,SUBJ_HAS_SPACES autolearn=no version=2.60 Catching up an old topic... >>>>> On Tue, 10 Feb 2004 07:26:05 -0500, >>>>> Soliman Hesham said: > What should a node do upon reception of a prefix option with the prefix > length set to a value >64? > The issue can be stated more accurately to say: > What should a host do upon reception of a prefix option with the prefix > length set to a value != 64? You appear to focus on the address configuration side of this issue. And RFC2461 is quite clear that the prefix handling in RFC2461 should be separate from that in RFC2462, so I'd see this as a 2462bis issue and not a 2461bis issue. Regarding rfc2461bis, my impression is that the receiving node must accept an prefix information in terms of the ND (2461 or bis) part regardless of the prefix length. For example, assuming a 64-bit interface identifier, if we receive an RA containing an prefix information option with 80-bit prefix length and with the L and A bits both being set, RFC2462 clearly says that the prefix MUST be ignored in terms of address configuration: If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. (RFC2462 Section 5.5.3, ) However, I think the receiving node should still consider the prefix as valid in terms of ND (i.e., consider it as "on-link") and modify the next-hop determination accordingly. The questions are: 1. is this a correct understanding of the intention of RFC2461? 2. if yes, is this a reasonable behavior? 3. if yes (for both 1 and 2), should this explicitly be documented in rfc2461bis? And my personal answers are: yes for 1 (of course. this is my understanding). not sure for 2, but I don't oppose to the behavior (though I'll need to change my own implementation). probably yes for 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 Fri Feb 27 02:26: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 CAA17968 for ; Fri, 27 Feb 2004 02:26:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcO8-0000Yk-5z for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 02:26:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R7QO1M002144 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 02:26:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcO7-0000YV-RY for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 02:26: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 CAA17896 for ; Fri, 27 Feb 2004 02:26:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwcO4-0005tb-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 02:26:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwcNB-0005mn-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 02:25:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwcMG-0005fh-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 02:24:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcLq-00085W-Tx; Fri, 27 Feb 2004 02:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcL8-0007qe-Q0 for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 02:23:18 -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 CAA17549 for ; Fri, 27 Feb 2004 02:23:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwcL5-0005Wu-00 for ipv6@ietf.org; Fri, 27 Feb 2004 02:23:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwcKC-0005Qj-00 for ipv6@ietf.org; Fri, 27 Feb 2004 02:22:21 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1AwcJn-0005Jt-00 for ipv6@ietf.org; Fri, 27 Feb 2004 02:21:55 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HTQ00946EURIR@mailout3.samsung.com> for ipv6@ietf.org; Fri, 27 Feb 2004 16:16:03 +0900 (KST) Received: from ep_mmp1 (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 <0HTQ00F0TETRQA@mailout3.samsung.com> for ipv6@ietf.org; Fri, 27 Feb 2004 16:15:27 +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 <0HTQ003IVETRJ5@mmp1.samsung.com> for ipv6@ietf.org; Fri, 27 Feb 2004 16:15:27 +0900 (KST) Date: Fri, 27 Feb 2004 16:15:30 +0900 From: "S. Daniel Park" Subject: RE: [rfc2462bis issue 275] DAD text inconsistencies In-reply-to: To: =?ks_c_5601-1987?B?J0pJTk1FSSBUYXR1eWEgLyA/lr6SQo3GJw==?= , "'Markku Savela'" Cc: ipv6@ietf.org Message-id: <00bc01c3fd01$7ba1c5e0$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=ks_c_5601-1987 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 > > And even with single id and new prefix this is not good: on > > RA with a new global prefix, every node on the link is going to do > > DAD based on its ID and new prefix. And, as far as I know, > > there is no delay requirement here, so everyone is doing it at > > same time. > > Hmm, this is a good point. An obvious workaround is to impose a > random delay when the node is starting a DAD process for an address > configured by multicasted RA. > > Does this kind of additional requirement make sense? > all > If so, should we include this in rfc2462bis? no change in the main sentence but add an appendix (or something) to discuss the issue on the random delays of the multiple RAs...but isn't bound for multi6 ? Regards - 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 Feb 27 03:05: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 DAA19760 for ; Fri, 27 Feb 2004 03:05: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 1Awczo-0004Ik-Gk for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 03:05:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R85Kxa016512 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 03:05:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awczl-0004ID-UL for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 03:05:17 -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 DAA19739 for ; Fri, 27 Feb 2004 03:05:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awczi-0002Cp-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 03:05:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awcyo-00025o-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 03:04:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awcxz-0001zl-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 03:03:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awcwc-0003uv-AQ; Fri, 27 Feb 2004 03:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awcvs-0003sl-FU for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 03:01:16 -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 DAA19608 for ; Fri, 27 Feb 2004 03:01:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awcvo-0001m4-00 for ipv6@ietf.org; Fri, 27 Feb 2004 03:01:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awcuq-0001fx-00 for ipv6@ietf.org; Fri, 27 Feb 2004 03:00:13 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AwcuB-0001al-00 for ipv6@ietf.org; Fri, 27 Feb 2004 02:59:32 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 76D7571B807; Fri, 27 Feb 2004 18:59:25 +1100 (EST) Date: Fri, 27 Feb 2004 18:59:25 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies Message-ID: <20040227075924.GA28029@zoic.org> Mail-Followup-To: ipv6@ietf.org, "JINMEI Tatuya / ?$B?@L@C#:H" References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-27, JINMEI Tatuya / ?$B?@L@C#:H wrote: > "Nick 'Sharkey' Moore" said: > > > > * DIID offers less signalling. What advantages does DAD offer? > > An obvious advantage is less probability of (missing) duplication (as > was pointed out even in this thread several times). ... if you're testing multiple addresses with the same suffix, there'll be more chance of collision with another node using the same suffix, true. But it'd be more elegant to increase DupAddrTransmits if that were your aim. And SEND-CGA nodes will configure different suffixes per prefix: odds are, only one will collide. But honestly, I don't really want to reopen the DAD vs DIID debate either. I'm happy to do DAD. I'd be happier if it was interoperable with DIID, because of the installed base. > A supplemental advantage would be simplicity and clarity in the > specification (and probably in implementations). I know this kind of > argument is more or less subjective and may not be convincing though. It's pretty close to convincing me -- the concept of an Interface Identifier is unnecessary and can be done without, so I 'like' DAD better. > Honestly speaking, I don't see the need for making DAD "compatible" > with DIID in the first place. Recall that DAD is not "compatible" > with DIID in this sense, even with the current RFC2462. There is not currently a true DAD vs. DIID division. 2462 specifies that nodes SHOULD test all addresses, and they MUST test the LL. That bit is written on the assumption that all suffixes will be the same -- otherwise it is meaningless. All I'm proposing (see my previous post with the very short bit of suggested text) is to clarify the rules for the post-IID era, with a check for the link-local to maintain compatibility with 2462-compliant nodes *whether they check all addresses or just the LL*. > Meanwhile, even DAD is not perfect in that we can still miss > duplication due to a timing problem or packet loss. Even if we > introduce some new effort to make DAD compatible with DIID, it will > not be perfect either. True, true, I suggest increasing DupAddrTransmits in Optimistic DAD for this reason. > I thus conclude that we don't need a change, at least in rfc2462bis, > to make DAD compatible with DIID. > > Again, my plan is simple. > > - just say "MUST do DAD for all unicast addresses" (or SHOULD if we > need a wording compromise) in rfc2462bis. I'm happy with MUST. > - this does not make the current status worse in the sense of > "compatibility" with DIID, since there are already always-DAD nodes. see above. If I haven't explained myself properly, just let me know. Again, this is only an individual opinion that backwards compatibility in this case is acheivable and important. Anyway, see you all in Seoul, -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 27 03:08: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 DAA19980 for ; Fri, 27 Feb 2004 03:08:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awd2m-0004u5-99 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 03:08:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R88NKb018838 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 03:08:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awd2k-0004tb-3j for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 03:08:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19948 for ; Fri, 27 Feb 2004 03:08:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awd2g-0002d0-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 03:08:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awd1t-0002WC-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 03:07:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awd17-0002OV-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 03:06:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awd0V-0004LX-Aj; Fri, 27 Feb 2004 03:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awczt-0004J2-4X for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 03:05:25 -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 DAA19748 for ; Fri, 27 Feb 2004 03:05:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awczp-0002Ds-00 for ipv6@ietf.org; Fri, 27 Feb 2004 03:05:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awcyu-00026w-00 for ipv6@ietf.org; Fri, 27 Feb 2004 03:04:25 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AwcyW-000202-00 for ipv6@ietf.org; Fri, 27 Feb 2004 03:04:00 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id A0FE371B807; Fri, 27 Feb 2004 19:03:59 +1100 (EST) Date: Fri, 27 Feb 2004 19:03:59 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies Message-ID: <20040227080359.GB28029@zoic.org> Mail-Followup-To: ipv6@ietf.org, "JINMEI Tatuya / ?$B?@L@C#:H" References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-27, JINMEI Tatuya / ?$B?@L@C#:H wrote: > "Nick 'Sharkey' Moore" said: > > > > I'm also dubious about relying on votes at IETF meetings for > > technical issues ... because often an option which seems 'obvious' > > at the time actually isn't once the drafts have been considered > > in detail. And most of the WG attendees won't have considered > > them in detail before the meeting. Sad but true. > > (I know this is not a technical discussion, so I'll try to refrain > myself from making further posting on this particular point. But feel > free to respond to this message, of course) Nah, I'll quit my whinging. > Let's just recall the recent site-local discussions... No, please, let's just not! :-) (If I go suddenly silent on this issue for a while, I'm not sulking, I'm flying ...) -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 27 07:37: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 HAA28221 for ; Fri, 27 Feb 2004 07:37:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwhF4-00072e-P0 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 07:37:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RCbMVc027048 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 07:37:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwhF4-00071v-2S for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 07:37:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28209 for ; Fri, 27 Feb 2004 07:37:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwhF3-0006Nc-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 07:37:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwhEG-0006IQ-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 07:36:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwhDW-0006Cg-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 07:35:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwhBp-0006U4-Vi; Fri, 27 Feb 2004 07:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwhB9-0006T7-49 for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 07:33:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28067 for ; Fri, 27 Feb 2004 07:33:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwhB8-00060J-00 for ipv6@ietf.org; Fri, 27 Feb 2004 07:33:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwhAB-0005vc-00 for ipv6@ietf.org; Fri, 27 Feb 2004 07:32:21 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Awh9m-0005qr-00 for ipv6@ietf.org; Fri, 27 Feb 2004 07:31:54 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3284E15214 for ; Fri, 27 Feb 2004 21:31:47 +0900 (JST) Date: Fri, 27 Feb 2004 21:31:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis issue 277] M/O flags and DHCPv6 User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 (note: this is a long message.) One major open issue of rfc2462bis is semantics of the M/O bit, what "stateful configuration" means, etc. Ralph Droms raised a set of questions in March 2003: a. the text needs to be updated to use RFC 2119 keywords b. which keywords? c. what is "the stateful configuration protocol"? d. if the answer to "c" is DHCPv6, should RFC 2462 more explicitly reference the configuration-only version of DHCPv6 in the description of the 'O'flag? I've been thinking about these questions, and I now have my personal answers. Since this message is lengthy, I'll first summarize the major (proposed) changes as follows: - clarify that the stateful protocol *is* DHCPv6. For example, say in Section 1 that: In this document, Stateful autoconfiguration for IPv6 means DHCPv6 [7]. - change the first part of Section 5.5.2 to: If a link has no routers, a host MAY attempt to use stateful autoconfiguration to obtain addresses and other configuration information. An implementation MAY provide a way to enable the invocation of stateful autoconfiguration in this case, but the default SHOULD be disabled. (i.e. change MUST in the first sentence to MAY, and modify the second sentence accordingly) - use "SHOULD" instead of "should" in some related sentences of Section 5.5.3. For example, we'll have the following sentence: If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host SHOULD invoke the stateful address autoconfiguration protocol, ... If you have time, and particularly if you have objections to some of the above changes, please look at the following discussions. *** regarding question c **** I'd first like to answer this question. RFC2462 currently says: Stateful autoconfiguration for IPv6 is the subject of future work [DHCPv6]. (Section 1) And, considering the latest standardization status, the current revision of rfc2462bis says: Stateful autoconfiguration for IPv6 is the subject of DHCPv6 [7]. However, I still don't think this is crystal clear. I believe we should first clarify whether "stateful autoconfiguration" *equals to* DHCPv6 (as specified in RFC3315), or whether we should still leave the possibility of (future) other stateful protocols. And then we should clarify this point in rfc2462bis more explicitly. Personally, I would prefer the first option (i.e., the "stateful protocol" equals to DHCPv6). Flexibility is in general a good thing, but in this case, I don't see a reasonable practical reason to leave other possibilities with ambiguous wording, particularly because the ambiguity has annoyed people and caused similar questions/discussions again and again. If we can agree on this, I'll change the above sentence like: In this document, Stateful autoconfiguration for IPv6 means DHCPv6 [7]. In the followings, I assume we adopt this interpretation (but it won't matter much even if we do not). *** regarding question a **** First, I think we can concentrate on Section 5 "PROTOCOL SPECIFICATION" (and its subsections). For example, someone pointed out that the following sentence in section 4 is "ambiguous": A "managed address configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain addresses. because it uses "should", not "SHOULD". But I don't think we should care about the wording in Section 4, since it's just an overview of the protocol, not the protocol specification itself. In fact, there are no RFC2119 keywords throughout Section 4. Of course, we may have to revisit the wording when we resolve question b ("which keyword?") though. Concentrating on Section 5, I've found the following candidates of RFC2119 keywords: ====================== start candidates ====================== 1. Section 5.2 ManagedFlag Copied from the M flag field (i.e., the ... The flag indicates whether or not addresses are to be configured using the stateful autoconfiguration mechanism. where "are to be" may need to be, e.g., "SHOULD be". 2. Section 5.2 OtherConfigFlag Copied from the O flag field (i.e., the "other ... The flag indicates whether or not information other than addresses is to be obtained using the stateful autoconfiguration mechanism. where "is to be" may need to be, e.g., "SHOULD be". 3. Section 5.5.3 ... If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address autoconfiguration protocol, ... where "the host should invoke" may need to be, e.g., "the host SHOULD invoke". 4. Section 5.5.3 ... If the value of the ManagedFlag changes from TRUE to FALSE, the host should continue running the stateful address autoconfiguration, ... where "the host should continue" may need to be, e.g., "the host SHOULD continue". 5. Section 5.5.3 ... If the value of OtherConfigFlag changes from FALSE to TRUE, the host should invoke the stateful autoconfiguration protocol, ... where "the host should invoke" may need to be, e.g., "the host SHOULD invoke". 6. Section 5.5.3 ... If the value of the OtherConfigFlag changes from TRUE to FALSE, the host should continue running the stateful address autoconfiguration protocol, ... where "the host should continue" may need to be, e.g., "the host SHOULD continue". ====================== end candidates ====================== In my current impression, we can leave 1 and 2 unchanged, but we'll need to use RFC2119 keywords for the rest. *** regarding question b **** In addition to the above candidates, the following parts already using RFC2119 keywords will need to be discussed here: 7. Section 5.5.2 If a link has no routers, a host MUST attempt to use stateful autoconfiguration to obtain addresses and other configuration information. 8. Section 5.5.2 An implementation MAY provide a way to disable the invocation of stateful autoconfiguration in this case, but the default SHOULD be enabled. 9. Section 5.5.3 In particular, a host MUST NOT reinvoke stateful address configuration if it is already participating in the stateful protocol as a result of an earlier advertisement. 10. Section 5.5.3 In particular, a host MUST NOT reinvoke stateful configuration if it is already participating in the stateful protocol as a result of an earlier advertisement. To choose appropriate keywords, I'd like to be synchronized with the node requirements draft (draft-ietf-ipv6-node-requirements-08.txt). It says in Section 4.5.5 that: Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- 3315] is the standard stateful address configuration protocol; see section 5.3 for DHCPv6 support. Nodes which do not support Stateful Address Autoconfiguration may be unable to obtain any IPv6 addresses aside from link-local addresses when it receives a router advertisement with the 'M' flag (Managed address configuration) set and which contains no prefixes advertised for Stateless Address Autoconfiguration (see section 4.5.2). ... That is (in my understanding), implementing DHCPv6 is basically optional with warnings about the case of not implementing it. I know this was a controversial issue, but I believe the node-requirements draft made a reasonable decision in terms of practical and realistic deployment path while honoring future flexibility. So, I'd like to propose changing candidate 7 to: If a link has no routers, a host MAY attempt to use stateful autoconfiguration to obtain addresses and other configuration information. Similarly, change candidate 8 to: An implementation MAY provide a way to enable the invocation of stateful autoconfiguration in this case, but the default SHOULD be disabled. Another reason for the change is because we can at least use link-local addresses within a single link without a router. For candidates 3 to 6, I think "SHOULD" is appropriate, since this only happens the network manager explicitly turns on the M or O flag and the effect of this setting is described in the node-requirements draft with warnings. I also think "MUST NOT"s in candidates 9 and 10 are okay for the same reason. *** regarding question d **** (I interpret "the configuration-only version of DHCPv6" as so called "stateless DHCPv6" described in draft-ietf-dhc-dhcpv6-stateless-04.txt.) This is not a strong opinion, but I'd currently say "no" for this question. The reasons are: - in my opinion, the stateless DHCPv6 service should be a "ubiquitous" service, and hosts that need autoconfiguration should try it by default (that is, without seeing an O flag set, which needs an explicit configuration in routers). - the O bit indicates a "stateful" mechanism for other configuration information than addresses. If the information actually includes some real "other" stateful resources (probably in a future extension), using the stateless version of DHCPv6 may result in an incomplete service. Even if we agree on my opinion, however, it might still be useful to note that the protocol invoked by the O bit should be the full-spec DHCPv6 instead of the stateless version. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Feb 27 09: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 JAA02431 for ; Fri, 27 Feb 2004 09: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 1AwicD-0004wA-N5 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 09:05:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RE5Ldi018977 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 09:05:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwicD-0004w0-Fh for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 09:05:21 -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 JAA02406 for ; Fri, 27 Feb 2004 09:05:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwicC-0000mw-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 09:05:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwibN-0000hD-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 09:04:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwiaV-0000ap-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 09:03:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwiZ0-0004Ud-Ej; Fri, 27 Feb 2004 09:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwiY3-0004P6-IM for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 09:01:03 -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 JAA02131 for ; Fri, 27 Feb 2004 09:01:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwiY1-00004Y-00 for ipv6@ietf.org; Fri, 27 Feb 2004 09:01:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwiX8-0007gC-00 for ipv6@ietf.org; Fri, 27 Feb 2004 09:00:06 -0500 Received: from usen-221x249x121x227.ap-us01.usen.ad.jp ([221.249.121.227] helo=coconut.itojun.org) by ietf-mx with esmtp (Exim 4.12) id 1AwiVu-0007Qv-00 for ipv6@ietf.org; Fri, 27 Feb 2004 08:58:50 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id D3BE3B2; Fri, 27 Feb 2004 22:58:47 +0900 (JST) To: jinmei@isl.rdc.toshiba.co.jp Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID In-Reply-To: Your message of "Fri, 27 Feb 2004 17:25:13 +0900" References: X-Mailer: Cue version 0.6 (040210-0635/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040227135847.D3BE3B2@coconut.itojun.org> Date: Fri, 27 Feb 2004 22:58:47 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > I've been thinking about this issue for a while. Currently, I'm not > sure if we need to do something in rfc2462bis for this issue. (snip) > Please someone clarify this point. Then I'll consider what is > necessary for rfc2462bis (or whether we need to do something in the > first place) for this matter. i guess it is either: - interface ID is always 64 bit, no matter what. addr-arch should be simplified and state that interface ID is 64 bit. - stateless addrconf (and maybe ND?) is currently defined only for unicast prefixes starting with "001", where interface ID is 64 bit. stateless addrconf (and maybe ND) for other unicast prefixes is left as a homework for readers. i really hate the latter, as the latter means that currently-available implementation won't work for unicast prefixes other than "001". let us pick the former and simplify. 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 Feb 27 09: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 JAA04067 for ; Fri, 27 Feb 2004 09:36:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awj5s-0007r3-A4 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 09:36:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1REa0pw030187 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 09:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awj5s-0007qo-4f for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 09:36:00 -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 JAA03977 for ; Fri, 27 Feb 2004 09:35:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awj5q-0004oY-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 09:35:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awj2n-00045n-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 09:32:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Awj1U-0003v6-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 09:31:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AwiyO-0006ag-9l for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 09:28:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwiyA-0007Dp-Gk; Fri, 27 Feb 2004 09:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwixZ-0007D7-Ud for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 09:27:25 -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 JAA03743 for ; Fri, 27 Feb 2004 09:27:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwixY-0003YC-00 for ipv6@ietf.org; Fri, 27 Feb 2004 09:27:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awiwc-0003TH-00 for ipv6@ietf.org; Fri, 27 Feb 2004 09:26:27 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwiwB-0003NW-00 for ipv6@ietf.org; Fri, 27 Feb 2004 09:25:59 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1REPJK11820; Fri, 27 Feb 2004 16:25:19 +0200 Date: Fri, 27 Feb 2004 16:25:19 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: jinmei@isl.rdc.toshiba.co.jp, Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID In-Reply-To: <20040227135847.D3BE3B2@coconut.itojun.org> 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, 27 Feb 2004, Jun-ichiro itojun Hagino wrote: > > I've been thinking about this issue for a while. Currently, I'm not > > sure if we need to do something in rfc2462bis for this issue. > (snip) > > Please someone clarify this point. Then I'll consider what is > > necessary for rfc2462bis (or whether we need to do something in the > > first place) for this matter. > > i guess it is either: > - interface ID is always 64 bit, no matter what. addr-arch should be > simplified and state that interface ID is 64 bit. > - stateless addrconf (and maybe ND?) is currently defined only for > unicast prefixes starting with "001", where interface ID is 64 bit. > stateless addrconf (and maybe ND) for other unicast prefixes is left > as a homework for readers. How about: - stateless address autoconf is only defined when the prefix is 64 bits. If the received router advertisement has some other prefix length, don't use the prefix. I guess this is close to your first assumption -- only, I would probably not revise addr-arch at all. That's beyond the scope of this document IMHO. -- 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 Feb 27 17:57: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 RAA00524 for ; Fri, 27 Feb 2004 17:57:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwquW-0005KD-91 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 17:56:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RMumvq020463 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 17:56:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwquV-0005Jy-Rc for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 17:56:47 -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 RAA00509 for ; Fri, 27 Feb 2004 17:56:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwquT-0003rt-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 17:56:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awqtc-0003lF-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 17:55:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awqt5-0003eQ-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 17:55:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awqsq-0004u7-6n; Fri, 27 Feb 2004 17:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwqsY-0004t8-N1 for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 17:54:47 -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 RAA00394 for ; Fri, 27 Feb 2004 17:54:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwqsW-0003d1-00 for ipv6@ietf.org; Fri, 27 Feb 2004 17:54:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwqrV-0003Wl-00 for ipv6@ietf.org; Fri, 27 Feb 2004 17:53:42 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1Awqqk-0003Rf-00 for ipv6@ietf.org; Fri, 27 Feb 2004 17:52:55 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1RMqtjJ026975 for ; Fri, 27 Feb 2004 15:52:55 -0700 (MST) 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 <0HTR00KEIM86IW@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Fri, 27 Feb 2004 15:52:55 -0700 (MST) Received: from [67.75.228.252] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HTR00DJTM7Y2D@mail.sun.net> for ipv6@ietf.org; Fri, 27 Feb 2004 15:52:54 -0700 (MST) Date: Fri, 27 Feb 2004 14:53:09 -0800 From: Alain Durand Subject: Appeal on "Unique Local IPv6 Unicast Addresses" In-reply-to: <403B9C7F.2070602@innovationslab.net> To: Margaret Wasserman , Thomas Narten Cc: Brian Haberman , IETF IPv6 Mailing List , "'Bob Hinden'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <403B9C7F.2070602@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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Feb 24, 2004, at 10:48 AM, Brian Haberman wrote: > Alain, > > At 01:22 AM 2/20/2004, Alain Durand wrote: > >> Dears ADs, > > Since the appeal process starts with the working group chairs, we > are responding as such. > >> I found it very unfortunate that the chair decided to request to >> advance this document >> without answering two major issues I raised during the last call: > > Before forwarding the document to the IESG we reviewed the discussion > of > all issues raised during the w.g. last call and concluded that the > current draft resolved issues where there was a consensus to make > changes. There were many significant changes (e.g., removing the > requirement to charge for the central allocations, etc.). We did not > see that there was any consensus to make the changes you requested. My appeal is not on the process but on technical merits, > >> - Permanent allocation is equivalent of selling address space, which >> is very different from >> the notion of stewardship that are now in place for any IP address >> allocation today. >> There are a number of legal questions not answered around this >> point. >> More, this is imposing a business model to the entity that will be >> in charge of the allocations, >> and I believe that the IETF should refrain from imposing business >> model. > > We believe that the current draft is very clear that it is not > imposing a business model. It clearly states a set of requirements > for how these > prefixes should be allocated. Earlier versions of the draft may have > had that issue, but based on comments received during the working > group > last call, this text was changed. In addition there were a number of > comments from Geoff Huston on the business model issue that led to > changes in earlier versions of the draft. > > We do not agree that permanent address allocations as called for in > this > draft is the same as selling address space. We clearly differ here. > We also note that there are > other types of IPv6 addresses that are allocated in similar manner. > This includes link-local addresses, site-local addresses (currently > being deprecated), multicast addresses, and NSAP addresses. All those blocks have different purposes and much narrower scope. Also, they are not assigned to end users. As the draft says, those addresses are to be treated as global unicast and there is no precedent for allocating such global unicast addresses to end users. I maintain that the legal ramification of the proposal have not been explored enough. > There are > similar blocks of addresses in IPv4. Nothing with the same scope as what is proposed here. > The Unique Local Addresses defined in the draft meet a clearly defined > need that has been discussed at great length in the working group. > The > permanency of these addresses is an important part of the requirements. Another point where we differ. I dispute this requirement. There is no technical rationale for making those allocation absolutely permanent. There is a strong rationale to make sure they can be stable over a reasonably long period of time, but this is very different from permanent. > They are by definition different from how other global IPv6 unicast > addresses are allocated and managed. This is why they were defined > in the first place. > >> - The document does not contain any wording recommending against the >> 'all zero' self allocation. >> It merely say that: >> "Locally assigned global IDs MUST be generated with a pseudo-random >> algorithm consistent with [RANDOM].". However, it should be noted >> that [RANDOM] >> or RFC1750 does not contain any mandate, just provide ideas on how >> to do things. >> An 'all zero' self allocation would create the prefix FD00::/48 >> and will be very tempting >> to use by many. >> This working group just spend more than a year to deprecate the >> site local >> fec0::/10 prefixes, just to reinvent it here. > > When you raised this issue on the mailing list the subsequent > discussion > indicated that the document was very clear on what was required (i.e., > what MUST be done as you quote above) and that there wasn't any reason > to provide a list of exceptions to this. Quoting from Christian > Huitema's email dated Wed, 28 Jan 2004: > > "The draft already says that we MUST assign these numbers exactly > one > way. Why on earth would we need to enumerate the 25 ways that > should > not be used?" You forget my answer to this question: because the wg spend a huge amount of valuable time to deprecate those addresses and I contend that this draft as written today provides a way to re-introduce them. > You logic seems to be that we are reinventing site-local addresses > because we only describe what someone MUST do and do not describe how > to > turn this back into site-local addresses. We believe your suggestion > would have the opposite effect from what you desire. I do not believe in security through obscurity, It is better to clearly articulate the danger of using the specific all zero pattern, IETF wgs have a moral obligation to point to potential issues when they are well known, Again, after so much time spent in the wg discussing the SL issues, I think it is not appropriate to just push the issue under the rug. > Also, if someone > wants to use site-locals, they can just ignore the deprecation > document and keep using them. Why would they need to bother to use > this prefix. Different issue, The responsibility of the wg is to point that there is a potential problem here, See Tim Chown Email a few days ago and you'll find a simple way to address the issue I'm pointing at. > >> As the request to advance this document came from the Ipv6 wg chairs, >> representing the wg, >> it is my opinion that the IPv6 Working Groug has made an incorrect >> technical choice which >> places the quality and/or integrity of the Working Group's product(s) >> in significant >> jeopardy. >> >> As the request to advance this document has already been sent to you, >> ADs, >> this is my appeal to you to reject it and send it back to the working >> group. > > For the reasons stated above, we do not agree that our action was > incorrect and deny your appeal. > > Regards, > Brian Haberman and Bob Hinden > IPv6 Working Group Chairs 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. -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. Let me reassure you that I'm not doing this in a hopeless effort to stall the process, but because I honestly believe that the issues mentioned above must be carefully examined by people outside of this working group. - 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 Feb 27 18:01: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 SAA00962 for ; Fri, 27 Feb 2004 18:01:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwqyM-0006Hl-5X for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 18:00:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RN0kUV024154 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 18:00:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwqyL-0006HO-TI for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 18:00:46 -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 SAA00946 for ; Fri, 27 Feb 2004 18:00:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwqyJ-0004Ok-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 18:00:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwqxS-0004IC-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 17:59:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awqwi-0004Ba-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 17:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awqwg-0005aO-KE; Fri, 27 Feb 2004 17:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwqwX-0005Zr-2E for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 17:58:53 -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 RAA00755 for ; Fri, 27 Feb 2004 17:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwqwU-0004A4-00 for ipv6@ietf.org; Fri, 27 Feb 2004 17:58:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awqvj-00043d-00 for ipv6@ietf.org; Fri, 27 Feb 2004 17:58:04 -0500 Received: from usen-221x249x121x227.ap-us01.usen.ad.jp ([221.249.121.227] helo=coconut.itojun.org) by ietf-mx with esmtp (Exim 4.12) id 1Awquw-0003vJ-00 for ipv6@ietf.org; Fri, 27 Feb 2004 17:57:14 -0500 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id F3FEEAC; Sat, 28 Feb 2004 07:57:10 +0900 (JST) To: Alain Durand Cc: Margaret Wasserman , Thomas Narten , Brian Haberman , IETF IPv6 Mailing List , "'Bob Hinden'" In-reply-to: Alain.Durand's message of Fri, 27 Feb 2004 14:53:09 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" From: itojun@iijlab.net Date: Sat, 28 Feb 2004 07:57:10 +0900 Message-Id: <20040227225711.F3FEEAC@coconut.itojun.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.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 >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. > >-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 support Alain 100%. 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 Feb 27 20:46: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 UAA09792 for ; Fri, 27 Feb 2004 20:46:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwtYN-00052b-BZ for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 20:46:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1S1k7Sp019371 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 20:46:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwtYM-00052H-U6 for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 20:46:07 -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 UAA09641 for ; Fri, 27 Feb 2004 20:46:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwtYK-0000BV-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 20:46:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwtWd-0007WH-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 20:44:21 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AwtUO-00077J-01 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 20:42:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AwtIN-0000nI-3f for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 20:29:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwtHq-000372-Pa; Fri, 27 Feb 2004 20:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwtHD-00034O-S1 for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 20:28:24 -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 UAA08621 for ; Fri, 27 Feb 2004 20:28:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwtHB-0005gN-00 for ipv6@ietf.org; Fri, 27 Feb 2004 20:28:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwtFj-0005Ms-00 for ipv6@ietf.org; Fri, 27 Feb 2004 20:26:52 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1AwtEa-0004z7-00 for ipv6@ietf.org; Fri, 27 Feb 2004 20:25:40 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i1S1P4F4447180; Fri, 27 Feb 2004 20:25:04 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-48-106-173.mts.ibm.com [9.48.106.173]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1S1P1Fw153256; Fri, 27 Feb 2004 18:25:02 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i1S1NGn05628; Fri, 27 Feb 2004 20:23:17 -0500 Message-Id: <200402280123.i1S1NGn05628@cichlid.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: Fri, 27 Feb 2004 20:23:15 -0500 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, > 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. I think I understand your point here. > -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. Let me ask you this then. If the word "permanent" is not appropriate, what word is? To me, "not permanent" means that at some future time an allocation that has been made to an endsite may be revoked. But this begs the question of why an end site would ever want to use such addresses. I.e, this raises such questions as: - under what conditions would an address be reclaimed? - who does the revokation? - what recourse does the end site have? My understanding is that the whole point of these allocations being "permanent" is that once and ends site gets one, it can use it without worry that it will have to give it up at some future time. Also, why do we need to make these allocations "non permantent"? Is there some future scenario we're worried about where it becomes important to be able to reclaim these addresses? I.e., are they ever going to become a scarce resource? Also, would we ever conceive of taking back an end-site's usage of an address block it generated under the non-centrally allocated block? In particular, if your answer no, but yes for those from the centrally allocated block, I'd like to understand the rational behind that thinking. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Feb 28 01:10: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 BAA19236 for ; Sat, 28 Feb 2004 01:10:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awxfn-0004SD-DG for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 01:10:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1S6A3Av017115 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 01:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awxfm-0004Rd-8D for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 01:10: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 BAA19230 for ; Sat, 28 Feb 2004 01:10:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awxfj-0005TV-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 01:09:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awxep-0005Mx-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 01:09:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwxeP-0005GE-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 01:08:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awxdp-00047v-OG; Sat, 28 Feb 2004 01:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awxcr-0003k1-3O for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 01:07: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 BAA19117 for ; Sat, 28 Feb 2004 01:06:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awxco-00058v-00 for ipv6@ietf.org; Sat, 28 Feb 2004 01:06:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awxbu-00052Y-00 for ipv6@ietf.org; Sat, 28 Feb 2004 01:06:02 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AwxbN-0004wH-00 for ipv6@ietf.org; Sat, 28 Feb 2004 01:05:29 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id E99396A908; Sat, 28 Feb 2004 08:05:21 +0200 (EET) Message-ID: <40402E77.6060609@kolumbus.fi> Date: Sat, 28 Feb 2004 08:00:23 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nick 'Sharkey' Moore" , Greg Daley Cc: ipv6@ietf.org, James Kempf Subject: SEND and DIID-compatible DAD rule (was [rfc2462bis issue 275] DAD text inconsistencies) References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040226234049.GA24880@zoic.org> <403E9E2C.3040208@eng.monash.edu.au> <20040227024408.GB24880@zoic.org> In-Reply-To: <20040227024408.GB24880@zoic.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Nick 'Sharkey' Moore wrote: >>> - When configuring a global unicast address, the link-local >>> address with the same suffix as that address MUST be configured >>> and tested for uniqueness in order to maintain interoperability >>> with RFC2462 behaviour. >> >>I think that configuring additional addresses which >>don't match the prefix used to generate the suffix in >>the CGA is going to cause problems. > > > Good point. However, the MN registering A::X only needs to > defend the LL::X against DIID-compatible nodes. > I think we can assume that SEND-CGA nodes will follow the > _new_ DAD standard. So the unsecured defensive NA should be okay, > since it won't be needed against SEND-CGA nodes. > > ... I think. Any SENDites want to comment? Thanks for bringing this issue up. Actually, it seems that if we want SEND nodes to be compatible with DIID-only plain ND nodes, there is indeed a need to defend the link-local address. Doing so is possible, although in my opinion its a bit awkward: - SEND specification has to be amended with a new rule. - SEND nodes have to send plain ND messages (they are unable to secure the LL::X probe because X depends on prefix, and we are not really trying to create the address LL::X but rather A::X). Nevertheless, sending plain ND messages is possible. - The amount of messages for DAD is duplicated. So I guess what I'm asking is whether we really need to do this. Did someone make a poll earlier about how many DIID-only implementations there are? What where the results, are we likely to encounter DIID-only hosts? Or perhaps SEND needs to do defend LL::X only when running in ND-compliant mode? --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Feb 28 01:50: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 BAA20287 for ; Sat, 28 Feb 2004 01:50:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwyIQ-0007LU-MY for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 01:49:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1S6nw6x028230 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 01:49:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwyIQ-0007LF-CL for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 01:49:58 -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 BAA20278 for ; Sat, 28 Feb 2004 01:49:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwyIN-0001mR-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 01:49:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwyHQ-0001gi-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 01:48:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwyGg-0001b7-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 01:48:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwyGX-00072R-QR; Sat, 28 Feb 2004 01:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwyGR-000726-FU for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 01:47:55 -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 BAA20222 for ; Sat, 28 Feb 2004 01:47:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwyGO-0001aZ-00 for ipv6@ietf.org; Sat, 28 Feb 2004 01:47:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwyFW-0001VQ-00 for ipv6@ietf.org; Sat, 28 Feb 2004 01:46:59 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1AwyEq-0001Pu-00 for ipv6@ietf.org; Sat, 28 Feb 2004 01:46:16 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i1S6kHNE019821 for ; Fri, 27 Feb 2004 23:46:17 -0700 (MST) 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 <0HTS00KDH854FP@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Fri, 27 Feb 2004 23:46:16 -0700 (MST) Received: from [67.75.225.181] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HTS00CSH84YRM@mail.sun.net> for ipv6@ietf.org; Fri, 27 Feb 2004 23:46:16 -0700 (MST) Date: Fri, 27 Feb 2004 22:46:33 -0800 From: Alain Durand Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" In-reply-to: <200402280123.i1S1NGn05628@cichlid.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.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200402280123.i1S1NGn05628@cichlid.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 Feb 27, 2004, at 5:23 PM, Thomas Narten wrote: > > Let me ask you this then. If the word "permanent" is not appropriate, > what word is? To me, "not permanent" means that at some future time an > allocation that has been made to an endsite may be revoked. The point I'm arguing is that it is not the IETF business to decide this. So not saying anything is probably the best option. Another one is saying that the entity in charge of the allocation is required to provide those allocation for the long term and not specify anything further. It is a policy decision made by the entity(ies) in charge to decide what long term means. > But this > begs the question of why an end site would ever want to use such > addresses. I.e, this raises such questions as: > > - under what conditions would an address be reclaimed? to be decided by the entity(ies) managing the allocation and their customer by contract. > - who does the revokation? the entity(ies) responsible for the allocations. > - what recourse does the end site have? See the contract between the chosen entity and the customer. Again, this is policy, not protocol. i.e. this is not IETF business. > > My understanding is that the whole point of these allocations being > "permanent" is that once and ends site gets one, it can use it without > worry that it will have to give it up at some future time. > > Also, why do we need to make these allocations "non permantent"? I'm not asking to make them non permanent in the document, but rather not to specify in an IETF document that they are permanent. This is different. If the entity in charge of the allocations decide that permanent allocation is the way they want to run their business, fine. > Is > there some future scenario we're worried about where it becomes > important to be able to reclaim these addresses? I.e., are they ever > going to become a scarce resource? I'm worried about the scenario where IETF does policy and not protocols anymore. > Also, would we ever conceive of taking back an end-site's usage of an > address block it generated under the non-centrally allocated block? > In particular, if your answer no, but yes for those from the centrally > allocated block, I'd like to understand the rational behind that > thinking. The two are different, The self generated addresses are not guaranteed to be unique, so permanent/non permanent or revocation is a meaningless discussion for 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 Sat Feb 28 05:35: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 FAA10962 for ; Sat, 28 Feb 2004 05:35:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1oH-0006NC-Vl for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:35:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAZ54B024494 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1oH-0006Mz-Pc for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:35:05 -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 FAA10942 for ; Sat, 28 Feb 2004 05:35:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1oE-0002aI-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:35:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1nJ-0002TY-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:34:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1me-0002NV-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:33:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1mJ-0005dp-JI; Sat, 28 Feb 2004 05:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1lK-0005bc-NY for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:32: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 FAA10790 for ; Sat, 28 Feb 2004 05:31:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1lH-0002Fe-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:31:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1kN-0002AE-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:31:03 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax1ju-00024i-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:30:34 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax1jv-000C3b-Pc for ipv6@ietf.org; Sat, 28 Feb 2004 10:30:35 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #265 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 #265] Inbound NA processing In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:30:35 +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 The proposed resolution seems to have been agreed. This issue is thus closed. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Feb 28 05:35: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 FAA10980 for ; Sat, 28 Feb 2004 05:35: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 1Ax1oJ-0006NY-96 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:35:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAZ7Na024514 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:35:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1oJ-0006NI-28 for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:35:07 -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 FAA10946 for ; Sat, 28 Feb 2004 05:35:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1oF-0002aS-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:35:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1nJ-0002Tk-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:34:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1mf-0002NW-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:33:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1mH-0005dT-UF; Sat, 28 Feb 2004 05:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1lJ-0005bX-Vl for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:32: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 FAA10787 for ; Sat, 28 Feb 2004 05:31:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1lG-0002FZ-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:31:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1kM-0002A5-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:31:03 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax1jt-00024g-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:30:33 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax1jv-000C3P-5K for ipv6@ietf.org; Sat, 28 Feb 2004 10:30:35 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #265 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 #265] Inbound NA processing In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:30:35 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 The proposed resolution seems to have been agreed. This issue is thus closed. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Feb 28 05:48: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 FAA11820 for ; Sat, 28 Feb 2004 05:48:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax20p-0001YH-TH for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAm3Qc005959 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax20p-0001Y2-Oo for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:48:03 -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 FAA11770 for ; Sat, 28 Feb 2004 05:47:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax20m-0004Mx-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:48:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1zp-0004Ex-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:47:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1yw-00047a-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:46:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1yt-0001E9-IB; Sat, 28 Feb 2004 05:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1yH-00014t-42 for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:45:25 -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 FAA11621 for ; Sat, 28 Feb 2004 05:45:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1y3-00040E-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:45:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1xC-0003su-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:44:18 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax1wX-0003lQ-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:43:37 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax1wY-000DeI-5O for ipv6@ietf.org; Sat, 28 Feb 2004 10:43:38 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #270 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 #270] Semantics of L=0 and A=1 scenario In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:43:38 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 No objection to the resolution (which is just a result of a previous ML discussion we already agreed). This issue is now closed. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Feb 28 05:55: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 FAA12019 for ; Sat, 28 Feb 2004 05:55: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 1Ax27f-0002Dk-AJ for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:55:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAt726008530 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax27f-0002DV-5Y for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:55:07 -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 FAA11970 for ; Sat, 28 Feb 2004 05:55:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax27b-00054U-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:55:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax26b-0004x0-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:54:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax25m-0004rB-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:53:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax25e-0001du-7S; Sat, 28 Feb 2004 05:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax24j-0001dO-AQ for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:52:05 -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 FAA11894 for ; Sat, 28 Feb 2004 05:52:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax24f-0004lS-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:52:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax23i-0004g4-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:51:03 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax23Q-0004am-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:50:44 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax23R-000Elx-O8 for ipv6@ietf.org; Sat, 28 Feb 2004 10:50:45 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #324 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 #324] In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:50:45 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 No objection to the proposed resolution and at least one person agreed on the resolution in ML. The issue is now closed. If you have a different opinion, please revisit the issue. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Feb 28 05:55: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 FAA12036 for ; Sat, 28 Feb 2004 05:55:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax27f-0002E2-UN for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:55:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAt7bI008548 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax27f-0002Dn-Pe for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:55:07 -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 FAA11974 for ; Sat, 28 Feb 2004 05:55:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax27c-00054c-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:55:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax26b-0004x9-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:54:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax25m-0004rD-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:53:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax25g-0001eK-15; Sat, 28 Feb 2004 05:53:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax24j-0001dT-TE for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:52:05 -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 FAA11897 for ; Sat, 28 Feb 2004 05:52:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax24g-0004lX-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:52:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax23j-0004gC-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:51:03 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax23Q-0004ao-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:50:44 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax23S-000Em5-9w for ipv6@ietf.org; Sat, 28 Feb 2004 10:50:46 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #324 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 #324] In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:50:46 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 No objection to the proposed resolution and at least one person agreed on the resolution in ML. The issue is now closed. If you have a different opinion, please revisit the issue. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Feb 28 06:23: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 GAA12858 for ; Sat, 28 Feb 2004 06:23:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax2Yv-0003mJ-7q for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 06:23:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SBNHmO014517 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 06:23:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax2Yv-0003m4-2x for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 06:23:17 -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 GAA12825 for ; Sat, 28 Feb 2004 06:23:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax2Yr-0000B1-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 06:23:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax2Xk-00001O-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 06:22:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax2Ws-0007id-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 06:21:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax2Wl-0003OQ-Ov; Sat, 28 Feb 2004 06:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1yI-00014u-0V for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:45: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 FAA11624 for ; Sat, 28 Feb 2004 05:45:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1y4-00040J-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:45:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1xC-0003t2-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:44:19 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax1wX-0003lR-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:43:37 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax1wY-000DeT-PH for ipv6@ietf.org; Sat, 28 Feb 2004 10:43:38 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #270 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 #270] Semantics of L=0 and A=1 scenario In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:43:38 +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 No objection to the resolution (which is just a result of a previous ML discussion we already agreed). This issue is now closed. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Feb 28 08:59: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 IAA17028 for ; Sat, 28 Feb 2004 08:59:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4zl-0005Ld-05 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 08:59:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SDx8gd020551 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 08:59:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4zk-0005LO-QR for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 08:59:08 -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 IAA17013 for ; Sat, 28 Feb 2004 08:59:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4zj-0000p2-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 08:59:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax4yo-0000jW-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 08:58:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4y9-0000eB-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 08:57:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4xh-00058b-Cg; Sat, 28 Feb 2004 08:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4wo-000582-8C for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 08:56:08 -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 IAA16949 for ; Sat, 28 Feb 2004 08:56:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4wm-0000YN-00 for ipv6@ietf.org; Sat, 28 Feb 2004 08:56:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax4vo-0000TW-00 for ipv6@ietf.org; Sat, 28 Feb 2004 08:55:04 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4ur-0000Kz-00 for ipv6@ietf.org; Sat, 28 Feb 2004 08:54:06 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 714AD15210; Sat, 28 Feb 2004 22:53:58 +0900 (JST) Date: Sat, 28 Feb 2004 22:54:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "S. Daniel Park" Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-Reply-To: <00bc01c3fd01$7ba1c5e0$67cadba8@LocalHost> References: <00bc01c3fd01$7ba1c5e0$67cadba8@LocalHost> 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, 27 Feb 2004 16:15:30 +0900, >>>>> "S. Daniel Park" said: >> > And even with single id and new prefix this is not good: on >> > RA with a new global prefix, every node on the link is going to do >> > DAD based on its ID and new prefix. And, as far as I know, >> > there is no delay requirement here, so everyone is doing it at >> > same time. >> >> Hmm, this is a good point. An obvious workaround is to impose a >> random delay when the node is starting a DAD process for an address >> configured by multicasted RA. >> >> Does this kind of additional requirement make sense? > all >> If so, should we include this in rfc2462bis? > no change in the main sentence but add an appendix (or > something) to discuss the issue on the random delays of > the multiple RAs...but isn't bound for multi6 ? We may be able to address this issue as a future extension in an appendix. But please note that the problematic case can happen even for a single RA (in that sense, there is no direct connection to multi6). p.s. I've registered a separate issue for this on the issue tracker. 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 Feb 29 00:17: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 AAA22205 for ; Sun, 29 Feb 2004 00:17:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJKG-0003qL-Py for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 00:17:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T5HGcR014769 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 00:17:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJKG-0003q8-Lt for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 00:17:16 -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 AAA22083 for ; Sun, 29 Feb 2004 00:17:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJKE-00037p-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 00:17:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJIz-0002st-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 00:15:58 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxJI9-0002kT-02 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 00:15:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxJ87-0004tS-Gt for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 00:04:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJ7S-0002W9-8A; Sun, 29 Feb 2004 00: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 1AxJ6c-0002VD-Mi for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 00:03:10 -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 AAA21731 for ; Sun, 29 Feb 2004 00:03:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJ6a-0001sn-00 for ipv6@ietf.org; Sun, 29 Feb 2004 00:03:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJ5v-0001lO-00 for ipv6@ietf.org; Sun, 29 Feb 2004 00:02:28 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1AxJ4J-0001S2-00 for ipv6@ietf.org; Sun, 29 Feb 2004 00:00:48 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 616655D8 for ; Sun, 29 Feb 2004 00:00:18 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 29 Feb 2004 00:00:18 -0500 Message-Id: <20040229050018.616655D8@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.14% | 14 | 13.26% | 66887 | sharkey@zoic.org 16.16% | 16 | 9.76% | 49201 | rt+ipv6-2462bis@rt.psg.com 9.09% | 9 | 11.72% | 59079 | jinmei@isl.rdc.toshiba.co.jp 8.08% | 8 | 7.67% | 38662 | francis.dupont@enst-bretagne.fr 6.06% | 6 | 7.12% | 35925 | ipng-incoming@danlan.com 6.06% | 6 | 6.10% | 30755 | jari.arkko@kolumbus.fi 4.04% | 4 | 5.64% | 28441 | alain.durand@sun.com 4.04% | 4 | 4.48% | 22613 | greg.daley@eng.monash.edu.au 3.03% | 3 | 4.89% | 24679 | ftemplin@iprg.nokia.com 3.03% | 3 | 3.95% | 19899 | soohong.park@samsung.com 3.03% | 3 | 3.07% | 15501 | kempf@docomolabs-usa.com 3.03% | 3 | 3.01% | 15199 | brian@innovationslab.net 3.03% | 3 | 2.95% | 14860 | jeroen@unfix.org 3.03% | 3 | 2.30% | 11605 | itojun@itojun.org 2.02% | 2 | 3.14% | 15854 | bmanning@isi.edu 2.02% | 2 | 1.82% | 9153 | msa@burp.tkv.asdf.org 2.02% | 2 | 1.73% | 8702 | erik.nordmark@sun.com 1.01% | 1 | 1.14% | 5728 | narten@us.ibm.com 1.01% | 1 | 1.05% | 5277 | tjc@ecs.soton.ac.uk 1.01% | 1 | 0.95% | 4791 | stephen@sprunk.org 1.01% | 1 | 0.89% | 4501 | mika.liljeberg@welho.com 1.01% | 1 | 0.89% | 4480 | sra+ipng@hactrn.net 1.01% | 1 | 0.83% | 4190 | pekka.nikander@nomadiclab.com 1.01% | 1 | 0.83% | 4170 | itojun@iijlab.net 1.01% | 1 | 0.82% | 4144 | pekkas@netcore.fi --------+------+--------+----------+------------------------ 100.00% | 99 |100.00% | 504296 | 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 Feb 29 00:45: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 AAA23593 for ; Sun, 29 Feb 2004 00:45: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 1AxJky-0006fl-89 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 00:44:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T5iqiq025643 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 00:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJky-0006fW-4G for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 00:44: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 AAA23580 for ; Sun, 29 Feb 2004 00:44:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJkv-0006BL-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 00:44:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJk6-00064m-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 00:43:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxJjH-0005xD-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 00:43:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJjB-0006IS-Tw; Sun, 29 Feb 2004 00:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJiw-0006HW-RF for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 00:42:46 -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 AAA23431 for ; Sun, 29 Feb 2004 00:42:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJiu-0005vk-00 for ipv6@ietf.org; Sun, 29 Feb 2004 00:42:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJhv-0005pS-00 for ipv6@ietf.org; Sun, 29 Feb 2004 00:41:44 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJh7-0005eG-00 for ipv6@ietf.org; Sun, 29 Feb 2004 00:40:53 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1T5eHd13311; Sun, 29 Feb 2004 07:40:18 +0200 Date: Sun, 29 Feb 2004 07:40:17 +0200 (EET) From: Pekka Savola To: itojun@itojun.org cc: ipv6@ietf.org Subject: draft-itojun-ipv6-getnameinfo-multiproto-01.txt comments 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 Seems simple enough to me -- no problem from my part. I personally can't see the need for non-Internet service name lookups, but I wasn't sure what you were referring to in any case. So I guess that should be either removed, or expanded to describe the specific scenario better. more or less editorial issues ----------------------------- ==> I'd add IPR boilerplates, copyright sections etc. at the end. Multiple protocol support in getnameinfo API ==> s/protocol support/Protocol Support/ (similar elsewhere) Abstract IPv6 basic API [Gilligan, 2003] defines protocol-independent API for address-to-string conversion, i.e. getnameinfo(3). Current ==> no references in the abstract. ==> I'd probably use "getnameinfo()" rather than "getnameinfo(3)" HAGINO Expires: August 5, 2004 [Page 1] L DRAFT multiprotocol getnameinfo February 2004 ==> "multiprotocol getnameinfo" should probably be reworded to be a bit fancier :) does not hold due to multiple reasons, such as (1) there are other transport protocols coming up like SCTP and DCCP and SOCK_xx and ==> remove "coming up" -- aren't they already there... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 29 00:49: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 AAA23786 for ; Sun, 29 Feb 2004 00:49:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJoh-000748-0q for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 00:48:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T5mgt9027154 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 00:48:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJog-00073t-OH for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 00:48:42 -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 AAA23752 for ; Sun, 29 Feb 2004 00:48:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJoe-0006aB-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 00:48:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJnk-0006Uw-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 00:47:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxJn5-0006PS-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 00:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJn4-0006mH-Ds; Sun, 29 Feb 2004 00:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJmk-0006lI-Kn for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 00:46:42 -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 AAA23675 for ; Sun, 29 Feb 2004 00:46:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJmi-0006OG-00 for ipv6@ietf.org; Sun, 29 Feb 2004 00:46:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJlt-0006JG-00 for ipv6@ietf.org; Sun, 29 Feb 2004 00:45:49 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJlD-00069e-00 for ipv6@ietf.org; Sun, 29 Feb 2004 00:45:07 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1T5icP13387 for ; Sun, 29 Feb 2004 07:44:38 +0200 Date: Sun, 29 Feb 2004 07:44:38 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: draft-ietf-ipv6-host-load-sharing-01 comments 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 I have major, fundamental objection to the premises on which this draft is based on. However, I think we should be able to find consensus on the way forward. Fundamental objection --------------------- The document assumes that it is always desirable to do load-sharing with the equivalent routers. I don't agree with this assumption. If the router's capacity is sufficient so that it can forward all the traffic sent by its nodes, there is actually very little need for load sharing. On the contrary -- sharing load between routers produces difficult-to-debug scenarios when some destinations (which are distributed to some routers) fail in mysterious ways while others work just fine. Due to that, I, as an operator, would not wish to enable load-sharing on hosts except when I specifically require that kind of functionality. So, I'd propose that this document does not describe that the hosts MUST share the load, but rather describes how the hosts MUST behave if they wish to share the load -- and if turned on by default, require that there MUST be a way to toggle load balancing off. A difficult issue to settle might be whether to recommend (and if so, how strongly) to enable load-sharing by default. substantial ----------- [ND] does not require any particular behavior in this respect. It specifies that an implementation may always choose the same router (e.g., the first in the list) or may cycle through the routers in a round-robin manner. Both of these suggestions are problematic. Clearly, always choosing the same router does not provide load sharing. Some problems with naive tie-breaking techniques such as round-robin and random are discussed in [MULTIPATH]. While the destination cache provides some stability since the determination is not per-packet, cache evictions or timeouts can still result in unstable or unpredictable paths over time, lowering the performance and making it harder to diagnose problems. Round- robin selection may also result in synchronization issues among hosts, where in the worst case the load is concentrated on one router at a time. ==> I don't think this document clearly described both of the above suggestion (1st paragraph): but rather how round-robin and random have issues. That is, it does not cleatly describe why choosing the same router is undesirable. As mentioned in [MULTIPATH], when next-hop selection is predictable, an application can synthesize traffic that will all hash the same, making it possible to launch a denial-of-service attack against the load sharing algorithm, and overload a particular router. A special case of this is when the same (single) next-hop is always selected, such as in the algorithm allowed by [ND]. Introducing hashing can make such an attack more difficult; the more unpredictable the hash is, the harder it becomes to conduct a denial-of-service attack against any single router. ==> these threats appear to have no clear threat model. What's the point of such an attack, as you're already on-link, and can already DoS the routers there using a number of means? Introducing hashing doesn't help much here -- you're making an assumption that the attacker is a "friendly" node. A maliscious node will just a) send the packets through raw sockets, DoSing the routers directly, or b) overload both of the routers :). It seems the security considerations needs a rewrite... editorial --------- ==> all the empty lines in the document appear to have been duplicated for some reason. Abstract The original IPv6 conceptual sending algorithm does not require load-sharing among equivalent IPv6 routers, and suggests schemes ==> s/IPv6/IPv6 Neighbor Discovery/ Subsequent traffic to the same destination address continues to use the same router unless there is some reason to change to a different router (e.g., a redirect message is received, or a router is found to be unreachable). ==> s/a router/the router/ 9. Full Copyright Statement ==> IPR boilerplate prior to this document would not hurt. -- 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 Feb 29 01:06: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 BAA24236 for ; Sun, 29 Feb 2004 01:06:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxK57-00083G-8c for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 01:05:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T65fti030944 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 01:05:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxK57-000831-3k for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 01:05:41 -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 BAA24228 for ; Sun, 29 Feb 2004 01:05:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxK54-00007z-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 01:05:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxK45-00002w-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 01:04:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxK3Z-0007mM-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 01:04:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxK3V-0007hV-Gi; Sun, 29 Feb 2004 01:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxK38-0007gk-Rw for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 01:03: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 BAA24167 for ; Sun, 29 Feb 2004 01:03:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxK36-0007lt-00 for ipv6@ietf.org; Sun, 29 Feb 2004 01:03:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxK28-0007hm-00 for ipv6@ietf.org; Sun, 29 Feb 2004 01:02:37 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxK1g-0007db-00 for ipv6@ietf.org; Sun, 29 Feb 2004 01:02:08 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1T61dX13672 for ; Sun, 29 Feb 2004 08:01:39 +0200 Date: Sun, 29 Feb 2004 08:01:39 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: router-selection comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id i1T61dX13672 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 Thanks for the update. I think this is in pretty good shape, protocol-wi= se, and should be shipped ASAP. Especially, please work on getting those ICM= P types reserved, the ones currently used by implementations have been take= n already for other applications! substantial ----------- If there are no routes matching the destination (i.e., no default routes and no more-specific routes), then if a type C host has a single interface then it SHOULD assume the destination is on-link to that interface. If the type C host has multiple interfaces then it SHOULD discard the packet and report a Destination Unreachable / No Route To Destination error to the upper layer. =3D=3D> this "onlink-by-default" rule has big problems, and it has been r= emoved in rfc2461bis -- I think it should be removed from here as well, or at le= ast reworded. Additionally, there doesn't appear to be anything router-selection specific here. 3.5. Router Reachability Probing =3D=3D> as a preface, one should IMHO discuss how this relates to the rou= ter reachability probing of RFC2461. As far as I see, the only difference he= re is that that unreachable, preferable routers are explicitly being probed = to notice when they become reachable again -- while with vanilla RFC2461 thi= s doesn't matter as all the routers are equally preferable. 5.1. Best Router for ::/0 vs Router Least Likely to Redirect=20 =3D=3D> I think these examples show, that if you don't know which type of= nodes (A, B vs C) there exist in the network, the optimal network configuration can be a very delicate process. This should be explicitly called out somewhere. Another approach might b= e "disallowing" type B hosts, requiring full router-selection implementatio= n, which would simplify the types and the configuration quite a bit. 6. Security Considerations A malicious node could send Router Advertisement messages, specifying High Default Router Preference or carrying specific routes, with the effect of pulling traffic away from legitimate routers. However, a malicious node could easily achieve this same effect in other ways. For example, it could fabricate Router Advertisement messages with zero Router Lifetime from the other routers, causing hosts to stop using the other routes. Hence, this document has no new appreciable impact on Internet infrastructure security. =3D=3D> this is inaccurate. There is a significant difference between a=20 blackhole attack, and a redirection attack. Redirection can e.g., be a trivial way to mount MITM attacks. This draft actually makes it even easier. This needs to be explained better in this memo, with appropriate pointers to SEND stuff. editorial --------- A router on one link cannot redirect a host to a router on another link. Hence, Redirect messages do not help multi- homed hosts select an appropriate router.=20 =3D=3D> a host can be multi-homed (at the site level) while still having = only one interface, so proposing to reword: s/multi-homed/multi-homed (through multiple interfaces)/ scenarios can add additional tunnels. For example, hosts may have 6-over-4 [RFC3056] or configured tunnel [RFC1933] network =3D=3D> s/6-over-4/6to4/ =3D=3D> rFC1933 has been obsoleted, soon twice :-) values. If the host has no information about the router=C6s =3D=3D> strange character, should be "'" ? (many other places as well) As one exception to this general rule, the administrator of a router that does not have a connection to the internet, or is connected =20 =3D=3D> s/internet/Internet/ 5.2. Multi-Homed Host and Isolated Network Here's another scenario: a multi-homed host is connected to the 6bone/internet via router X on one link and to an isolated network =3D=3D> s/Here's another scenario:/In another scenario,/ =3D=3D> remove "6bone". Author's Addresses =3D=3D> s/Author's/Authors'/ Full Copyright Statement =3D=3D> one must add an IPR boilerplate before this section. --=20 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 Feb 29 01:19: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 BAA24506 for ; Sun, 29 Feb 2004 01:19:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKHi-0001Hh-Nu for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 01:18:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T6IgOY004931 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 01: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 1AxKHi-0001HS-IW for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 01:18:42 -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 BAA24503 for ; Sun, 29 Feb 2004 01:18:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxKHf-0001BI-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 01:18:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxKGl-00016h-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 01:17:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxKGR-00011m-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 01:17:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKG6-0000yY-2N; Sun, 29 Feb 2004 01:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKFn-0000yG-Kd for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 01:16:43 -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 BAA24451 for ; Sun, 29 Feb 2004 01:16:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxKFk-00011B-00 for ipv6@ietf.org; Sun, 29 Feb 2004 01:16:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxKEs-0000wP-00 for ipv6@ietf.org; Sun, 29 Feb 2004 01:15:47 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxKE5-0000l4-00 for ipv6@ietf.org; Sun, 29 Feb 2004 01:14:57 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1T6ERe13826 for ; Sun, 29 Feb 2004 08:14:27 +0200 Date: Sun, 29 Feb 2004 08:14:27 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: icmpv6-v3 comments 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 Thanks for the update. There are a couple of issues which probably require a bit of discussion; some others should be more straightforward modifications. Comments below. Process issue: Draft Standard may not refer normatively to specifications of lower standardization status. See draft-ymbk-downref-01.txt for a bit of discussion. That is, IPv6-ADDR, PMTU and IPsec documents are unsuitable for normative references. So, some wiggling around will be needed.. ==> should add IPR and copyright boilerplates at the end. 2.2 Message Source Address Determination A node that sends an ICMPv6 message has to determine both the Source and Destination IPv6 Addresses in the IPv6 header before calculating the checksum. If the node has more than one unicast address, it must choose the Source Address of the message as follows: [...] ==> should this "must" (and the following statements) be appropriately uppercased? (c) If the message is a response to a message sent to an address that does not belong to the node, the Source Address should be that unicast address belonging to the node that will be most helpful in diagnosing the error. For example, if the message is a response to a packet forwarding action that cannot complete successfully, the Source Address should be a unicast address belonging to the interface on which the packet forwarding failed. ==> not sure if this has been implemented, so the usability of this generic rule seems questionable. (c) Every ICMPv6 error message (type < 128) includes as much of the IPv6 offending (invoking) packet (the packet that caused the error) as will fit without making the error message packet exceed the minimum IPv6 MTU [IPv6]. ==> s/includes/MUST include/ ? If the reason for the failure to deliver can not be mapped to any of the specific codes listed above, the Code field is set to 3. The example of such cases are inability to resolve the IPv6 destination address into a corresponding link address, or a link-specific problem of some sort. ==> reasons with codes 4, 5, and 6 are below this sentence. Maybe those paragraphs should be moved up, earlier in this section, or the language here reworded? If the reason for the failure to deliver is that packet with this source address is not allowed due to ingress or egress filtering policies, the Code field is set to 5. If the reason for the failure to deliver is that the route to the destination is a reject route, the Code field is set to 6. This may occur if the router has been configured to reject all the traffic for a specific prefix. ==> as has already been mentioned, these two rules are in fact a more specific, more informative subsets of code 1 -- administratively prohibited. I persnally don't see much of an objection for adding these codes, but it would IMHO make useful to spell this out explicitly here. It SHOULD be possible for the system administrator to configure a node to ignore any ICMP messages that are not authenticated using either the Authentication Header or Encapsulating Security Payload. Such a switch SHOULD default to allowing unauthenticated messages. ==> has this even been implemented anywhere? could maybe be deleted? This is completely unpractical, e.g., just consider PMTU packets -- there is no way you'll ever be able to set up security associations with everyone in the Internet to be able to accept the packets :) [IPv6-ADDR] Hinden, R., S. Deering, "IP Version 6 Addressing Architecture", RFC2373, July 1998. ==> update. Note that this is not Draft Standard yet. As there is nothing in IPv6-ADDR that's required by that spec, it could be informative as well. [PMTU] McCann, J., S. Deering, J. Mogul, "Path MTU Discovery for IP version 6", RFC1981, August 1996. [IPv6-SA] Kent, S., R. Atkinson, "Security Architecture for the Internet Protocol", RFC1825, November 1998. ==> These, and IPsec RFCs are PS's at the moment -- can't refer. IPsec ones are being revised though, if that helps any. editorial --------- (f) Finally, in order to limit the bandwidth and forwarding costs incurred sending ICMPv6 error messages, an IPv6 node MUST limit ==> s/incurred/incurred by/ -- 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 Feb 29 01:26: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 BAA24714 for ; Sun, 29 Feb 2004 01:26:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKOZ-0001wL-1W for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 01:25:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T6PlEp007451 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 01:25:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKOY-0001w6-TL for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 01:25:46 -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 BAA24679 for ; Sun, 29 Feb 2004 01:25:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxKOV-0001lp-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 01:25:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxKNX-0001g1-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 01:24:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxKMw-0001aa-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 01:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKMs-0001Vd-SG; Sun, 29 Feb 2004 01:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKMX-0001QH-F3 for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 01:23:44 -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 BAA24609 for ; Sun, 29 Feb 2004 01:23:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxKMU-0001Zz-00 for ipv6@ietf.org; Sun, 29 Feb 2004 01:23:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxKLX-0001Vk-00 for ipv6@ietf.org; Sun, 29 Feb 2004 01:22:40 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxKL2-0001RN-00 for ipv6@ietf.org; Sun, 29 Feb 2004 01:22:08 -0500 Received: from ocean.jinmei.org (unknown [2001:220:101a:224:202:2dff:fe6a:d20]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BAFD715214; Sun, 29 Feb 2004 15:22:01 +0900 (JST) Date: Sun, 29 Feb 2004 15:21:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "S. Daniel Park" Cc: sharkey@zoic.org, ipv6@ietf.org Subject: Re: Optimistic DAD _again!_ In-Reply-To: <002a01c3fa09$a308f9f0$67cadba8@LocalHost> References: <002a01c3fa09$a308f9f0$67cadba8@LocalHost> 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, 23 Feb 2004 21:36:19 +0900, >>>>> "S. Daniel Park" said: >> One fundamental question that I remember is whether optimizing DAD >> really makes much sense while there are other kinds of delays such as >> random delay (up to 1 second) for the first RS and random delay at >> routers before responding to an RS. Without addressing the >> fundamental question(s), we'd simply restart similar divergent >> discussions, waisting lots of energy and time without seeing progress. > So, one draft was proposed to clarify what you indicate and I posted it > on the IPv6 mailing list. > http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt-requirement-02.txt Thanks for the pointer, I've read the draft. Unfortunately, it only covers the delay for the first RS, and not others (e.g., the delay at routers before responding to RSs). I respect the effort of you guys, but I'd rather want to see a comprehensive scenario before introducing additional mechanism to solve a part of the entire issues. 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 Feb 29 03:20: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 DAA12441 for ; Sun, 29 Feb 2004 03:20:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMB0-0002wP-9t for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 03:19:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T8JsE5011299 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 03:19:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMAz-0002wA-Ox for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 03:19:53 -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 DAA12436 for ; Sun, 29 Feb 2004 03:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMAx-0005Dh-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 03:19:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMA5-00058S-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 03:18:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxM9i-00051r-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 03:18:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxM9D-0002b1-Sn; Sun, 29 Feb 2004 03:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxM91-0002VD-Sh for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 03:17:53 -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 DAA12349 for ; Sun, 29 Feb 2004 03:17:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxM8z-00050e-00 for ipv6@ietf.org; Sun, 29 Feb 2004 03:17:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxM85-0004v6-00 for ipv6@ietf.org; Sun, 29 Feb 2004 03:16:53 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxM7X-0004ox-00 for ipv6@ietf.org; Sun, 29 Feb 2004 03:16:19 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C9E1D15210; Sun, 29 Feb 2004 17:16:18 +0900 (JST) Date: Sun, 29 Feb 2004 17:16:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Nick 'Sharkey' Moore" Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-Reply-To: <20040227075924.GA28029@zoic.org> References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.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=AWL autolearn=no version=2.60 >>>>> On Fri, 27 Feb 2004 18:59:25 +1100, >>>>> "Nick 'Sharkey' Moore" said: >> Honestly speaking, I don't see the need for making DAD "compatible" >> with DIID in the first place. Recall that DAD is not "compatible" >> with DIID in this sense, even with the current RFC2462. > There is not currently a true DAD vs. DIID division. > 2462 specifies that nodes SHOULD test all addresses, and they MUST > test the LL. That bit is written on the assumption that all > suffixes will be the same -- otherwise it is meaningless. > All I'm proposing (see my previous post with the very short > bit of suggested text) is to clarify the rules for the post-IID era, > with a check for the link-local to maintain compatibility with > 2462-compliant nodes *whether they check all addresses or just the LL*. I'm now a bit confused (probably I still did not understand your previous scenario correctly)... Suppose that a DIID node has an interface identifier (which is probably derived from the hardware address) "I". The DIID node first tries "DAD" for fe80::I. If the node does not see a duplication, then it will configure a global address P::I without doing DAD. This is the optimization described in RFC2462. Then, also assume the DIID node has some "suffix" which is different from the interface identifier, "I", and even does not have any kind of relationship with I. For example, a suffix prepared for an RFC3041 temporary address might be related to I, since a part of the seed for the suffix might be I. On the other hand, a suffix for a SEND CGA address would probably have no relationship with I. Let's call the former type of suffix "S1" and the latter type of suffix "S2". Are you worried about the case where the DIID node omits DAD for the address P:S1 because fe80::I is proved to be unique but a different node happens to have already used the same address P:S1? Then yes, this may cause a problem. From a practical point of view, however, the only example of this kind of suffix that I know of is a suffix for an RFC3041 temporary address. And, in this case, we have already agreed that each temporary address should be tested for its uniqueness and the specification is updated (though currently expired, unfortunately). So, practically, there should currently no new compatibility issue. And if we take the proposed change in rfc2462bis, we will be able to avoid similar compatibility issues in the future. Now, are you worried about the case where the DIID node omits DAD for the address P:S2 simply because fe80::I is proved to be unique, even though S2 is not related to I at all? If so, I'd say that this is a bug of the specification that specifies the creation and usage of this type of suffix, or a bug of the implementation of the DIID node. In either case, I don't see the need for an additional workaround in rfc2462bis. Or, am I totally missing 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 Sun Feb 29 03:32: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 DAA12761 for ; Sun, 29 Feb 2004 03:32:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMMV-0003pm-FK for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 03:31:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T8VlvD014732 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 03:31:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMMV-0003pX-5w for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 03:31:47 -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 DAA12752 for ; Sun, 29 Feb 2004 03:31:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMMT-0006As-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 03:31:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMLY-00066I-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 03:30:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxML4-00061L-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 03:30:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMKq-0003VN-2A; Sun, 29 Feb 2004 03:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMKX-0003UR-NH for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 03:29: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 DAA12700 for ; Sun, 29 Feb 2004 03:29:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMKV-00060d-00 for ipv6@ietf.org; Sun, 29 Feb 2004 03:29:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMJd-0005wQ-00 for ipv6@ietf.org; Sun, 29 Feb 2004 03:28:49 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxMJL-0005rK-00 for ipv6@ietf.org; Sun, 29 Feb 2004 03:28:31 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id DE59A15210; Sun, 29 Feb 2004 17:28:31 +0900 (JST) Date: Sun, 29 Feb 2004 17:28:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Nick 'Sharkey' Moore" Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-Reply-To: References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.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=AWL autolearn=no version=2.60 >>>>> On Sun, 29 Feb 2004 17:16:30 +0900, >>>>> JINMEI Tatuya said: > Suppose that a DIID node has an interface identifier (which is > probably derived from the hardware address) "I". The DIID node first > tries "DAD" for fe80::I. If the node does not see a duplication, then > it will configure a global address P::I without doing DAD. This is > the optimization described in RFC2462. > Then, also assume the DIID node has some "suffix" which is different > from the interface identifier, "I", and even does not have any kind of > relationship with I. For example, a suffix prepared for an RFC3041 > temporary address might be related to I, since a part of the seed for > the suffix might be I. On the other hand, a suffix for a SEND CGA > address would probably have no relationship with I. Let's call the > former type of suffix "S1" and the latter type of suffix "S2". Oops, I should have been more careful...the suffix for a SEND CGA address also belongs to the former category. > Are you worried about the case where the DIID node omits DAD for the > address P:S1 because fe80::I is proved to be unique but a different > node happens to have already used the same address P:S1? Then yes, > this may cause a problem. From a practical point of view, however, > the only example of this kind of suffix that I know of is a suffix for > an RFC3041 temporary address. So we should also consider the CGA case. Realistically, however, does this really cause a compatibility issue? The compatibility issue only happens when we have a DIID based implementation that supports SEND CGA and it is deployed. Is this really the case in the real world so we need to worry about the compatibility? I not, then the following logic will still apply. > So, practically, there should currently no > new compatibility issue. And if we take the proposed change in > rfc2462bis, we will be able to avoid similar compatibility issues in > the future. 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 Feb 29 03:38: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 DAA12906 for ; Sun, 29 Feb 2004 03:38:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMSH-0004SD-VQ for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 03:37:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T8bjnP017104 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 03:37:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMSF-0004Ri-61 for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 03:37:43 -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 DAA12897 for ; Sun, 29 Feb 2004 03:37:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMSC-0006bt-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 03:37:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMRH-0006XR-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 03:36:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxMQk-0006T9-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 03:36:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMQd-00042b-En; Sun, 29 Feb 2004 03:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMQI-0003ya-He for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 03:35:42 -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 DAA12848 for ; Sun, 29 Feb 2004 03:35:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMQG-0006ST-00 for ipv6@ietf.org; Sun, 29 Feb 2004 03:35:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMPJ-0006Oj-00 for ipv6@ietf.org; Sun, 29 Feb 2004 03:34:41 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxMP8-0006Kt-00 for ipv6@ietf.org; Sun, 29 Feb 2004 03:34:30 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E53DD15214; Sun, 29 Feb 2004 17:34:30 +0900 (JST) Date: Sun, 29 Feb 2004 17:34:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID 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, 27 Feb 2004 13:47:35 -0800 (PST), >>>>> Erik Nordmark said: >> Which one is correct? Is the length of IF IDs determined by the link >> type, or the address format, or both? If the answer is "both", there >> may be inconsistency in future specification. For example, what if a >> future IPv6-over-FOO document specifies like this? >> >> An IPv6 address prefix used for stateless autoconfiguration [ACONF] >> of a FOO interface must have a length of 80 bits. >> >> Will we then have to give up using stateless address autoconfiguration >> with unicast prefixes beginning with "000" in this link? > I think you meant "unless the unicast prefix begins with 000 ..." Oops, that's right. Thanks for the correction. >> Technically, this is not necessary a contradiction. [IPv6-ETHER] only >> requires 64-bit IF IDs for stateless address autoconfiguration, so the >> above (imaginary) IPv6-over-FOO document and the addr-arch document >> can coexist without conflicting each other if we give up stateless >> autoconfiguration in this link. But is this a realistic option? > I personally think we should hard-code the /64 boundary in as few places > as possible to allow for future evolution. Your 80 bit interface ID > on some new links is one example of possible future evolution. > Another example is cases where 20 years from now having less than 64 bit > interface IDs (or addresses allocated with DHCP from a >64 bit subnet prefix) > might fill a useful role. > Hard-coding the /64 address too me sounds like the original Arpanet design > with 8 bit network numbers and 24 bit host numbers; which was revised/relaxed > first with class A/B/C and later with CIDR. > I don't know of a technical reason why /64 needs to be a hard limit. I tend to agree, though I know we have a different opinion. The difficult point here is that this is actually not an RFC2462 issue, but a consistency issue about the definition of interface identifiers in various documents. Currently I don't have a good idea on how to resolve it without affecting other documents much. 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 Feb 29 07:49: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 HAA19585 for ; Sun, 29 Feb 2004 07:49:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQNN-0007Hr-JU for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 07:48:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TCmvbx028010 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 07:48:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQNN-0007Hh-Do for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 07:48: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 HAA19570 for ; Sun, 29 Feb 2004 07:48:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQNM-00060O-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 07:48:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQMP-0005uv-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 07:47:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxQLp-0005qE-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 07:47:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQKZ-0006bU-7X; Sun, 29 Feb 2004 07:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQKO-0006aK-8u for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 07:45:54 -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 HAA19429 for ; Sun, 29 Feb 2004 07:45:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQKN-0005iw-00 for ipv6@ietf.org; Sun, 29 Feb 2004 07:45:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQJV-0005dm-00 for ipv6@ietf.org; Sun, 29 Feb 2004 07:44:58 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx with esmtp (Exim 4.12) id 1AxQIj-0005ZC-00 for ipv6@ietf.org; Sun, 29 Feb 2004 07:44:10 -0500 Received: from localhost ([130.194.13.84]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L76XKFAWTC8WW4KR@vaxc.its.monash.edu.au> for ipv6@ietf.org; Sun, 29 Feb 2004 23:43:54 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 54E4A39C016; Sun, 29 Feb 2004 23:43:54 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 42B742DC012; Sun, 29 Feb 2004 23:43:54 +1100 (EST) Date: Sun, 29 Feb 2004 21:43:54 +0900 From: Gregory Daley Subject: Re: Optimistic DAD _again!_ To: JINMEI Tatuya / GyRCP0BMQEMjOkgbKEI= Cc: "S. Daniel Park" , sharkey@zoic.org, ipv6@ietf.org Message-id: <4f92124fb750.4fb7504f9212@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en 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 Jinmei, There is other work in this area. Some of it is interesting to the new DNA WG. ----- Original Message ----- From: JINMEI Tatuya / GyRCP0BMQEMjOkgbKEI= Date: Sunday, February 29, 2004 3:21 pm Subject: Re: Optimistic DAD _again!_ > >>>>> On Mon, 23 Feb 2004 21:36:19 +0900, > >>>>> "S. Daniel Park" said: > > >> One fundamental question that I remember is whether optimizing DAD > >> really makes much sense while there are other kinds of delays > such as > >> random delay (up to 1 second) for the first RS and random delay at > >> routers before responding to an RS. Without addressing the > >> fundamental question(s), we'd simply restart similar divergent > >> discussions, waisting lots of energy and time without seeing > progress. > > So, one draft was proposed to clarify what you indicate and I > posted it > > on the IPv6 mailing list. > > http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt- > requirement-02.txt > > Thanks for the pointer, I've read the draft. Unfortunately, it only > covers the delay for the first RS, and not others (e.g., the delay at > routers before responding to RSs). I respect the effort of you guys, > but I'd rather want to see a comprehensive scenario before introducing > additional mechanism to solve a part of the entire issues. There are a couple of different ideas for tackling these delays. The RA response delay (0-500ms) is handled in: draft-mkhalil-ipv6-fastra (recently expired, available on watersprings). We've got implementations and papers on this. and can supply further information about this at need. It's a simple idea: just eliminate the delay. It works as expected. The RS delay is currently under study. The main reason this delay was originally included in the spec is to protect the network and other signalling from packet loss and catastrophic delay. I'm currently testing with a simulation of up to 30 wireless hosts changing 802.11 base station at the same time. this is WIP, but I'll see if I have any preliminary results to show before the end of IETF. So the work is being done, but not necessarily in IPv6 WG. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 29 08:10: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 IAA20345 for ; Sun, 29 Feb 2004 08:10:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQhn-0000Ny-3v for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 08:10:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TDA39J001465 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 08:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQhl-0000NW-Lx for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 08:10: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 IAA20328 for ; Sun, 29 Feb 2004 08:10:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQhk-0000CV-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 08:10:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQgt-00006c-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 08:09:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxQg9-0007nW-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 08:08:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQfq-0008T4-GY; Sun, 29 Feb 2004 08:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQew-0008Bv-8q for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 08:07: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 IAA20279 for ; Sun, 29 Feb 2004 08:07:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQev-0007hT-00 for ipv6@ietf.org; Sun, 29 Feb 2004 08:07:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQds-0007bV-00 for ipv6@ietf.org; Sun, 29 Feb 2004 08:06:00 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AxQdO-0007WA-00 for ipv6@ietf.org; Sun, 29 Feb 2004 08:05:30 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 8AD616A908; Sun, 29 Feb 2004 15:05:27 +0200 (EET) Message-ID: <4041E313.6060307@kolumbus.fi> Date: Sun, 29 Feb 2004 15:03:15 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JINMEI Tatuya Cc: ipv6@ietf.org Subject: Re: Optimistic DAD _again!_ References: <002a01c3fa09$a308f9f0$67cadba8@LocalHost> 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 Tatuya wrote: > Thanks for the pointer, I've read the draft. Unfortunately, it only > covers the delay for the first RS, and not others (e.g., the delay at > routers before responding to RSs). I respect the effort of you guys, > but I'd rather want to see a comprehensive scenario before introducing > additional mechanism to solve a part of the entire issues. Overall handover delay consists of, among other factors, link layer search and attachment times, access authentication and access link security setup, router discovery, address assignment and duplicate testing, and mobility signaling. Most or maybe even all of these aspects are being worked by different groups. For instance, - Link layer search and attachment times are being improved in IEEE, to give one example. - Significant efforts are being put in IEEE and elsewhere to reduce the time needed to perform access authentication and set up link layer security. For instance, pre-authentication and fast handoff mechanisms are discussed and specified in 802.11. - As Greg already mentioned, there is ongoing work in DNA WG to improve the RS situation. This relates to the movement detection delays. Is the work finished? I don't know, but is that required? - We have optimistic DAD which is addressing the DAD delay. - We have mobility optimisations such as HMIP in MIPSHOP WG (and bunch of others in research stage) that address delays caused by mobility signaling. Does this count as a "comprehensive scenario" you were looking for? --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 29 08:18: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 IAA20656 for ; Sun, 29 Feb 2004 08:18:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQpT-0000zO-US for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 08:18:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TDHxn7003796 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 08:17:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQpT-0000z9-Nw for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 08:17:59 -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 IAA20625 for ; Sun, 29 Feb 2004 08:17:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQpS-0000yX-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 08:17:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQoZ-0000sV-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 08:17:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxQnm-0000n2-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 08:16:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQnc-0000cX-0U; Sun, 29 Feb 2004 08:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQnQ-0000bA-DG for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 08:15: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 IAA20482 for ; Sun, 29 Feb 2004 08:15:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQnP-0000kQ-00 for ipv6@ietf.org; Sun, 29 Feb 2004 08:15:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQmQ-0000eb-00 for ipv6@ietf.org; Sun, 29 Feb 2004 08:14:51 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1AxQlW-0000WC-00 for ipv6@ietf.org; Sun, 29 Feb 2004 08:13:55 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HTU00101KQB3U@mailout3.samsung.com> for ipv6@ietf.org; Sun, 29 Feb 2004 22:13:23 +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 <0HTU00EXKKQAXH@mailout3.samsung.com> for ipv6@ietf.org; Sun, 29 Feb 2004 22:13:22 +0900 (KST) Received: from ep_spt04 (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 <0HTU009C9KQATF@ms3.samsung.com> for ipv6@ietf.org; Sun, 29 Feb 2004 22:13:22 +0900 (KST) Content-return: prohibited Date: Sun, 29 Feb 2004 13:13:28 +0000 (GMT) From: PARK SOO HONG Subject: Re :Re: Optimistic DAD _again!_ X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2JpbA==?= =?windows-1252?B?ZSBQbGF0Zm9ybSBMYWI/UmVzZWFyY2hlcg==?= To: JINMEI Tatuya / ???? Cc: PARK SOO HONG , "sharkey@zoic.org " , "ipv6@ietf.org " Reply-to: soohong.park@samsung.com Message-id: <0HTU009CAKQATF@ms3.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040229131314566@soohong.park X-MTR: 20040229131314566@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_30_40,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


>Thanks for the pointer, I've read the draft.  Unfortunately, it only
>covers the delay for the first RS, and not others (e.g., the delay at
>routers before responding to RSs).  I respect the effort of you guys,
>but I'd rather want to see a comprehensive scenario before introducing
>additional mechanism to solve a part of the entire issues.

 

 

As Greg pointed out in his response, RA delay is not issue in this thread for

DAD Optimization and I made a "RQ4: Router Modifications" of this consideration

although it is not enough...




Regards

 

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 Sun Feb 29 11:55: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 LAA01172 for ; Sun, 29 Feb 2004 11:55:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxUDd-0007eC-47 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 11:55:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TGt9gl029392 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 11:55:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxUDc-0007dz-Se for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 11:55:08 -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 LAA01165 for ; Sun, 29 Feb 2004 11:55:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxUDb-0001p3-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 11:55:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxUCa-0001jX-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 11:54:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxUC4-0001em-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 11:53:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxUBa-0007Qq-DD; Sun, 29 Feb 2004 11:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxUBW-0007QV-LC for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 11:52:58 -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 LAA01101 for ; Sun, 29 Feb 2004 11:52:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxUBV-0001db-00 for ipv6@ietf.org; Sun, 29 Feb 2004 11:52:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxUAZ-0001Z4-00 for ipv6@ietf.org; Sun, 29 Feb 2004 11:51:59 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxU9f-0001Ui-00 for ipv6@ietf.org; Sun, 29 Feb 2004 11:51:03 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C9C2E15214; Mon, 1 Mar 2004 01:51:00 +0900 (JST) Date: Mon, 01 Mar 2004 01:51:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Jun-ichiro itojun Hagino , Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID In-Reply-To: References: <20040227135847.D3BE3B2@coconut.itojun.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=AWL autolearn=no version=2.60 >>>>> On Fri, 27 Feb 2004 16:25:19 +0200 (EET), >>>>> Pekka Savola said: >> i guess it is either: >> - interface ID is always 64 bit, no matter what. addr-arch should be >> simplified and state that interface ID is 64 bit. >> - stateless addrconf (and maybe ND?) is currently defined only for >> unicast prefixes starting with "001", where interface ID is 64 bit. >> stateless addrconf (and maybe ND) for other unicast prefixes is left >> as a homework for readers. > How about: > - stateless address autoconf is only defined when the prefix > is 64 bits. If the received router advertisement has some other > prefix length, don't use the prefix. As I said in a separate message, I want to avoid introducing hard limits like this as much as possible. We still have a possibility in the future that we have a new link type whose "IPv6 over xx" document requires non 64 bit identifier. And, in this case, we can use stateless autoconfiguration per RFC2462 for a global prefix starting with the bit "000" without conflicting any documents (i.e., RFC2462, addr-arch, and the "IPv6 over foo"). I don't see a valid reason to kill the possibility in rfc2462bis. > I guess this is close to your first assumption -- only, I would > probably not revise addr-arch at all. That's beyond the scope of this > document IMHO. I agree that revising addr-arch is beyond the scope of the 2462bis work. But then we can only make rfc2462bis a little bit clearer, because the possible conflict exists at the border between the addr-arch and the "IPv6 over foo" document. So, assuming we will not change the other documents (soon), what we can do in rfc2462bis, IMO, is: 1. say rfc2462bis adopts the definition of interface identifiers as a per link notion (i.e., based on each "IPv6 over foo" doc), just as currently described in RFC2462 and bis. 2. add a note that this interpretation may conflict with addr-arch because the latter (at least partly) defines the interface identifiers as a per address-format notion. Also note that this does not currently cause a problem, because the two interpretations happen to be synchronized so far (i.e., all known links use 64-bit identifiers). 3. note that the possible conflict may cause a trouble in rfc2462bis in the future but how to solve it is beyond scope of the document. This way, we can make the specification clear under the limitation of the current situation. The possible conflict currently does not cause a problem, and this will probably be the case for the foreseeable future. Someday (hopefully), if the addr-arch and IPv6 over foo documents are aligned, the implicit problem in rfc2462bis will go away, too. Can this be a reasonable compromise? 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 Feb 29 19:35: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 TAA18958 for ; Sun, 29 Feb 2004 19:35:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbOE-0002Oc-Og for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 19:34:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i210YYX2009206 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 19:34:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbOE-0002OP-J9 for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 19:34:34 -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 TAA18950 for ; Sun, 29 Feb 2004 19:34:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbOC-0003Wl-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 19:34:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxbNO-0003Pz-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 19:33:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxbMk-0003IE-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 19:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbLl-0001zM-9j; Sun, 29 Feb 2004 19:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbL2-0001rr-W6 for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 19:31:17 -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 TAA18737 for ; Sun, 29 Feb 2004 19:31:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbL1-0003AP-00 for ipv6@ietf.org; Sun, 29 Feb 2004 19:31:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxbK5-00035S-00 for ipv6@ietf.org; Sun, 29 Feb 2004 19:30:18 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AxbJf-000316-00 for ipv6@ietf.org; Sun, 29 Feb 2004 19:29:51 -0500 Message-ID: <017401c3ff24$628a6b50$3e6015ac@dclkempt40> From: "James Kempf" To: "Nick 'Sharkey' Moore" , "JINMEI Tatuya / ????" Cc: References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> Subject: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Date: Sun, 29 Feb 2004 16:30:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jinmei, > So we should also consider the CGA case. Realistically, however, does > this really cause a compatibility issue? The compatibility issue only > happens when we have a DIID based implementation that supports SEND > CGA and it is deployed. Is this really the case in the real world so > we need to worry about the compatibility? > When an address suffix is formed from a different key or subnet prefix, including link local addresses, SEND will DAD it. This is in conformance with RFC 2462 and has the effect of the SEND node DADing all autoconfigured addresses (LL as well as unicast global). The NS sent by a SEND node will include the SEND ND options. A nonSEND node will receive the NS, ignore the options (as per 2462) and reply with an unsecured NA if it has a duplicate. Section 8, paragraph 9 of the SEND spec describes what the SEND node does in this case. Briefly, it will accept the first unsecured NA, but will reject unsecured NAs after the first. So a node that has DIIDed an address first will have the opportunity to defend it. Conversely, however, there is a problem with a DIID node that just DADs its LL address and assumes from there that the IID can be used for a global address, since the SEND node will just check against its LL address, due to the difference in prefixes. The SEND node's already configured unicast global address might then conflict with the DIID node's. However, this problem would occur between any DIID node and a node that uses different address suffixes for LL and uncast global addresses. So, unless I'm missing something, I don't think there would be any problem between SEND nodes and DIID nodes that would not also occur betwee, say, RFC 3041 nodes and DIID nodes. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 29 20:06: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 UAA19910 for ; Sun, 29 Feb 2004 20:06:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axbt7-0004dK-QK for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 20:06:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2116Tr8017807 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 20:06:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axbt7-0004d8-IQ for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 20:06: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 UAA19898 for ; Sun, 29 Feb 2004 20:06:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axbt5-0006C0-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 20:06:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axbs9-000668-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 20:05:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axbrb-0005zo-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 20:04:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axbqj-0004Ba-Qg; Sun, 29 Feb 2004 20:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axbq1-00049k-TI for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 20:03:21 -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 UAA19758 for ; Sun, 29 Feb 2004 20:03:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axbpz-0005s3-00 for ipv6@ietf.org; Sun, 29 Feb 2004 20:03:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axbp8-0005nd-00 for ipv6@ietf.org; Sun, 29 Feb 2004 20:02:22 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxboR-0005il-00 for ipv6@ietf.org; Sun, 29 Feb 2004 20:01:39 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A485915214; Mon, 1 Mar 2004 10:01:32 +0900 (JST) Date: Mon, 01 Mar 2004 10:01:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Kristine Adamson Cc: ipv6@ietf.org Subject: Re: SIOCGIFaaa ioctls and IPv6 interfaces 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 not responding sooner... >>>>> On Thu, 5 Feb 2004 09:43:00 -0500, >>>>> Kristine Adamson said: >> I know the IETF isn't the most appropriate place to discuss this type >> of thing, but does it help to write a short informational I-D >> describing the specification with some recommendation? > We have received many questions from vendors about what APIs can provide > the same information as the SIOCGIFaaa ioctls, for IPv6 > addresses/interfaces. I thought that this subject may have been discussed > as part of the IPv6 API discussions that produced the basic/advanced > socket RFCs. So, if getifaddrs(3) seems to be the de facto standard for > retrieving this information, then I think it would be great if the IPv6 > working group published something to try to recommend it as the standard > for this function, in order to ensure greater portability of applications. I don't think getifaddrs(3) is a defact standard for now (only a few platforms support it), but I believe we need this kind of high level interface and getifaddrs(3) can be a good candidate for this purpose. > In regards to getifaddrs(3), for IPv6 I assume that the netmask field > contain a 16-octet mask in the sockaddr_in6 structure, correct? There > doesn't appear to be a returned field that contains the prefix length. Yes, that's correct. getifaddrs(3) is designed as a generic, AF-independent library, so it returns a netmask even for an IPv6 address. Applications need to convert the netmask to a prefix length if necessary. 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 Feb 29 20:17: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 UAA20282 for ; Sun, 29 Feb 2004 20:17:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc3b-0005yS-Vq for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 20:17:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i211HJ82022958 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 20:17:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc3b-0005yD-RW for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 20:17: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 UAA20267 for ; Sun, 29 Feb 2004 20:17:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axc3Z-00076A-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 20:17:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axc2i-00071T-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 20:16:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axc2B-0006wC-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 20:15:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc1P-0005Wp-LB; Sun, 29 Feb 2004 20:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc0c-0005Vc-FH for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 20:14:14 -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 UAA20132 for ; Sun, 29 Feb 2004 20:14:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axc0a-0006pK-00 for ipv6@ietf.org; Sun, 29 Feb 2004 20:14:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axbzc-0006kq-00 for ipv6@ietf.org; Sun, 29 Feb 2004 20:13:12 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Axbyv-0006gu-00 for ipv6@ietf.org; Sun, 29 Feb 2004 20:12:29 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E3FB515210; Mon, 1 Mar 2004 10:12:28 +0900 (JST) Date: Mon, 01 Mar 2004 10:12:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bob.hinden@nokia.com, brian@innovationslab.net Cc: ipv6@ietf.org Subject: additional agenda item 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 According to the agenda shown at http://www.ietf.org/ietf/04mar/ipv6.txt, we will be able to have a few more items. If this is the case, may I ask for a short slot about an API extension to get a list of IPv6 addresses (as well as other AF addresses) on a node? This was discussed in the wg list early February and I just made a delayed response. (the subject is "SIOCGIFaaa ioctls and IPv6 interfaces"). I don't have a draft on this, and this may not be suitable for this wg (or even for the IETF), but some people seem to be interested in this topic, I want to have a chance to see if this is worth discussing in this group. If acceptable, I think a five minute slot is enough. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 29 21:09: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 VAA23985 for ; Sun, 29 Feb 2004 21:09:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axcs1-0003eJ-Ol for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 21:09:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2129PmG014021 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 21:09:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axcs1-0003e4-Hq for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:09:25 -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 VAA23913 for ; Sun, 29 Feb 2004 21:09:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axcrz-0005hJ-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 21:09:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axcr0-0005YO-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 21:08:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axcpz-0005Qo-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 21:07:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axcol-0002tL-Bj; Sun, 29 Feb 2004 21:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcoE-0002ot-3v for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 21:05:30 -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 VAA23404 for ; Sun, 29 Feb 2004 21:05:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcoB-0005B1-00 for ipv6@ietf.org; Sun, 29 Feb 2004 21:05:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcnL-0004zu-00 for ipv6@ietf.org; Sun, 29 Feb 2004 21:04:35 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxcmU-0004tG-00 for ipv6@ietf.org; Sun, 29 Feb 2004 21:03:43 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 86CD815214; Mon, 1 Mar 2004 11:03:41 +0900 (JST) Date: Mon, 01 Mar 2004 11:03:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "James Kempf" Cc: "Nick 'Sharkey' Moore" , Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) In-Reply-To: <017401c3ff24$628a6b50$3e6015ac@dclkempt40> References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> 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 Sun, 29 Feb 2004 16:30:19 -0800, >>>>> "James Kempf" said: > Conversely, however, there is a problem with a DIID node that just DADs its > LL address and assumes from there that the IID can be used for a global > address, since the SEND node will just check against its LL address, due to > the difference in prefixes. The SEND node's already configured unicast > global address might then conflict with the DIID node's. However, this > problem would occur between any DIID node and a node that uses different > address suffixes for LL and uncast global addresses. Since I seem to have been failing to understand the point, please let me rephrase that to be sure. Are you talking about a scenario like this? We have two nodes, a "SEND node" and a "DIID node". SEND node: - (for simplicity) do not implement the DIID-style optimization - have an (e.g.,) EUI-64 based interface identifier, I. - configure a SEND (CGA) address P:A (where A is the identifier, A != I) DIID node - implement the DIID-style optimization - (for simplicity) do not implement SEND - happen to have A as an interface identifier The SEND node comes to a link. It perform DAD for both fe80::I and P:A, and confirms that these are unique. Then the DIID node comes to the same link. It performs DAD for fe80::A, and confirms it is unique. So the DIID node start using P:A without doing DAD while P:A is actually duplicate. 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 Feb 29 21:30: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 VAA25107 for ; Sun, 29 Feb 2004 21:30:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdBj-0005su-1D for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 21:29:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i212Tlax022614 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 21:29:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdBi-0005sd-HE for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:29:46 -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 VAA25102 for ; Sun, 29 Feb 2004 21:29:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxdBf-00007G-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 21:29:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxdAn-0007nH-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 21:28:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxdAA-0007eq-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 21:28:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd96-0005H6-4Y; Sun, 29 Feb 2004 21:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd8P-0005Dm-OK for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 21:26:21 -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 VAA24788 for ; Sun, 29 Feb 2004 21:26:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axd8N-0007Rv-00 for ipv6@ietf.org; Sun, 29 Feb 2004 21:26:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axd7W-0007L6-00 for ipv6@ietf.org; Sun, 29 Feb 2004 21:25:27 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1Axd6g-0007Ev-00 for ipv6@ietf.org; Sun, 29 Feb 2004 21:24:34 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i212OWi5021756; Sun, 29 Feb 2004 19:24:32 -0700 (MST) 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 i212OSQ00580; Mon, 1 Mar 2004 03:24:29 +0100 (MET) Date: Sun, 29 Feb 2004 18:24:33 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: additional agenda item To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: bob.hinden@nokia.com, brian@innovationslab.net, 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.0 required=5.0 tests=none autolearn=no version=2.60 It would be good to ask (e.g. on the appsarea list - discuss@apps.ietf.org I think) if there are applications that need other configuration information than the list of interfaces/ifindicies (which we already have) and a list of all IP address (which is what you are proposing). Is that all we need to add to avoid having applications use SIOCGIF ioctls? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 29 23:19: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 XAA00222 for ; Sun, 29 Feb 2004 23:19:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axetu-0006FR-9C for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 23:19:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i214JUmA024014 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 23:19:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axett-0006FF-QS for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:19: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 XAA00186 for ; Sun, 29 Feb 2004 23:19:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axets-000376-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 23:19:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axesy-00030h-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 23:18:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axes8-0002uv-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 23:17:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxerY-0005e0-05; Sun, 29 Feb 2004 23:17:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axeqv-0005c5-HA for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 23:16:25 -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 XAA29992 for ; Sun, 29 Feb 2004 23:16:23 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axeqt-0002nd-00 for ipv6@ietf.org; Sun, 29 Feb 2004 23:16:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axepz-0002il-00 for ipv6@ietf.org; Sun, 29 Feb 2004 23:15:28 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1AxepQ-0002e0-00 for ipv6@ietf.org; Sun, 29 Feb 2004 23:14:52 -0500 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 i214EmL23467; Mon, 1 Mar 2004 06:14:48 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 06:14:40 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i214Eec7004473; Mon, 1 Mar 2004 06:14:40 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00b1mgJQ; Mon, 01 Mar 2004 06:14:38 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i214Ec708110; Mon, 1 Mar 2004 06:14:38 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 06:14:37 +0200 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 issue 277] M/O flags and DHCPv6 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 06:14:36 +0200 Message-ID: Thread-Topic: [rfc2462bis issue 277] M/O flags and DHCPv6 thread-index: AcP9LnL2OPZ3w4eyT9iDQMiCFsPfMACFGyHA To: , X-OriginalArrivalTime: 01 Mar 2004 04:14:37.0513 (UTC) FILETIME=[B5D67B90:01C3FF43] 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 Jinmei, Here are my 2 cents; I'll send comments on the points I have comments, otherwise note any non-comment as a non-objection. > Since this message is lengthy, I'll first summarize the major > (proposed) changes as follows: > > - clarify that the stateful protocol *is* DHCPv6. For example, say in > Section 1 that: > > In this document, Stateful autoconfiguration for IPv6 means DHCPv6 > [7]. > > - change the first part of Section 5.5.2 to: > If a link has no routers, a host MAY attempt to use stateful > autoconfiguration to obtain addresses and other configuration > information. An implementation MAY provide a way to enable the > invocation of stateful autoconfiguration in this case, but the > default SHOULD be disabled. > > (i.e. change MUST in the first sentence to MAY, and modify the second > sentence accordingly) > > - use "SHOULD" instead of "should" in some related sentences of > Section 5.5.3. For example, we'll have the following sentence: > > If the value of ManagedFlag changes from FALSE to > TRUE, and the host is not already running the stateful address > autoconfiguration protocol, the host SHOULD invoke the stateful > address autoconfiguration protocol, ... This is OK with me. > *** regarding question c **** > > I'd first like to answer this question. RFC2462 currently says: > > Stateful autoconfiguration for IPv6 is the subject of future work > [DHCPv6]. > (Section 1) > > And, considering the latest standardization status, the current > revision of rfc2462bis says: > > Stateful autoconfiguration for IPv6 is the subject of DHCPv6 [7]. > > However, I still don't think this is crystal clear. I believe we > should first clarify whether "stateful autoconfiguration" *equals to* > DHCPv6 (as specified in RFC3315), or whether we should still leave the > possibility of (future) other stateful protocols. And then we should > clarify this point in rfc2462bis more explicitly. > > Personally, I would prefer the first option (i.e., the "stateful > protocol" equals to DHCPv6). Flexibility is in general a good thing, > but in this case, I don't see a reasonable practical reason to leave > other possibilities with ambiguous wording, particularly because the > ambiguity has annoyed people and caused similar questions/discussions > again and again. > > If we can agree on this, I'll change the above sentence like: > > In this document, Stateful autoconfiguration for IPv6 means DHCPv6 > [7]. I agree with your text. I don't see the need to keep this as an open issue in the standard. > *** regarding question a **** > > First, I think we can concentrate on Section 5 "PROTOCOL > SPECIFICATION" (and its subsections). For example, someone pointed > out that the following sentence in section 4 is "ambiguous": > > A "managed address > configuration" flag indicates whether hosts should use stateful > autoconfiguration to obtain addresses. > > because it uses "should", not "SHOULD". > > But I don't think we should care about the wording in Section 4, since > it's just an overview of the protocol, not the protocol specification > itself. In fact, there are no RFC2119 keywords throughout Section 4. > Of course, we may have to revisit the wording when we resolve question > b ("which keyword?") though. > > Concentrating on Section 5, I've found the following candidates of > RFC2119 keywords: I don't have a strong opinion on the use of keywords. Either way is OK, in my opinion. > (I interpret "the configuration-only version of DHCPv6" as so called > "stateless DHCPv6" described in > draft-ietf-dhc-dhcpv6-stateless-04.txt.) > > This is not a strong opinion, but I'd currently say "no" for this > question. The reasons are: > > - in my opinion, the stateless DHCPv6 service should be a "ubiquitous" > service, and hosts that need autoconfiguration should try it by > default (that is, without seeing an O flag set, which needs an > explicit configuration in routers). > > - the O bit indicates a "stateful" mechanism for other configuration > information than addresses. If the information actually includes > some real "other" stateful resources (probably in a future > extension), using the stateless version of DHCPv6 may result in an > incomplete service. > > Even if we agree on my opinion, however, it might still be useful to > note that the protocol invoked by the O bit should be the full-spec > DHCPv6 instead of the stateless version. I think noting this would be a good thing. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 29 23:58: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 XAA02458 for ; Sun, 29 Feb 2004 23:58:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfUs-0001sf-9j for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 23:57:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i214vgKM007223 for ipv6-archive@odin.ietf.org; Sun, 29 Feb 2004 23:57:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfUs-0001sQ-36 for ipv6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:57:42 -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 XAA02451 for ; Sun, 29 Feb 2004 23:57:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfUp-0006zb-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 23:57:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfTs-0006t3-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 23:56:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfTT-0006mo-00 for ipv6-web-archive@ietf.org; Sun, 29 Feb 2004 23:56:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfTG-0001UH-Oj; Sun, 29 Feb 2004 23:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfSc-0001S4-AB for ipv6@optimus.ietf.org; Sun, 29 Feb 2004 23:55:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02261 for ; Sun, 29 Feb 2004 23:55:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfSa-0006k8-00 for ipv6@ietf.org; Sun, 29 Feb 2004 23:55:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfRd-0006d2-00 for ipv6@ietf.org; Sun, 29 Feb 2004 23:54:21 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AxfQf-0006VV-00 for ipv6@ietf.org; Sun, 29 Feb 2004 23:53:21 -0500 Message-ID: <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> From: "James Kempf" Cc: "Nick 'Sharkey' Moore" , "IPV6 WG" References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Date: Sun, 29 Feb 2004 20:53:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > We have two nodes, a "SEND node" and a "DIID node". > > SEND node: > - (for simplicity) do not implement the DIID-style optimization > - have an (e.g.,) EUI-64 based interface identifier, I. > - configure a SEND (CGA) address P:A (where A is the identifier, A != I) > > DIID node > - implement the DIID-style optimization > - (for simplicity) do not implement SEND > - happen to have A as an interface identifier > > The SEND node comes to a link. It perform DAD for both fe80::I and > P:A, and confirms that these are unique. > No, the SEND node performs DAD for fe80::C, where C is a function of the key and some other parameters. The prefix on LL addresses is also calculated from the key. > Then the DIID node comes to the same link. It performs DAD for > fe80::A, and confirms it is unique. So the DIID node start using > P:A without doing DAD while P:A is actually duplicate. > Yes, that's the concern. If the DIID node comes on the link second, then it will assume that A is a unique prefix even though it only DADs it for the LL address. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------