From ipv6-bounces@ietf.org Sun Oct 02 00:00:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELv1i-0006KE-Lb; Sun, 02 Oct 2005 00:00:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELv1g-0006Hi-2g for ipv6@megatron.ietf.org; Sun, 02 Oct 2005 00:00:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12126 for ; Sun, 2 Oct 2005 00:00:32 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELv9r-00088r-7e for ipv6@ietf.org; Sun, 02 Oct 2005 00:09:04 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id BEDF947B for ; Sun, 2 Oct 2005 00:00:13 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 02 Oct 2005 00:00:13 -0400 Message-Id: <20051002040013.BEDF947B@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 13.89% | 5 | 12.74% | 27341 | alun@cisco.com 13.89% | 5 | 9.78% | 20982 | francis.dupont@enst-bretagne.fr 11.11% | 4 | 9.46% | 20314 | ronald.pashby.ctr@navy.mil 11.11% | 4 | 6.66% | 14293 | pekkas@netcore.fi 2.78% | 1 | 9.34% | 20054 | jmandin@streetwaves-networks.com 2.78% | 1 | 8.47% | 18188 | kempf@docomolabs-usa.com 5.56% | 2 | 5.05% | 10847 | yukiyo.akisada@jp.yokogawa.com 2.78% | 1 | 4.34% | 9319 | mkshin@pec.etri.re.kr 2.78% | 1 | 4.10% | 8809 | soohong.park@samsung.com 2.78% | 1 | 3.90% | 8363 | heejin.jang@samsung.com 2.78% | 1 | 3.74% | 8022 | john.loughney@nokia.com 2.78% | 1 | 3.49% | 7480 | spencer@mcsr-labs.org 2.78% | 1 | 2.95% | 6326 | dmm@1-4-5.net 2.78% | 1 | 2.58% | 5532 | jpickering@lvl7.com 2.78% | 1 | 2.31% | 4958 | pekka.nikander@nomadiclab.com 2.78% | 1 | 2.16% | 4629 | jspence@native6.com 2.78% | 1 | 2.04% | 4383 | sra+ipng@hactrn.net 2.78% | 1 | 1.90% | 4077 | iljitsch@muada.com 2.78% | 1 | 1.73% | 3711 | jari.arkko@kolumbus.fi 2.78% | 1 | 1.68% | 3615 | mailman-owner@ietf.org 2.78% | 1 | 1.58% | 3390 | erik.nordmark@sun.com --------+------+--------+----------+------------------------ 100.00% | 36 |100.00% | 214633 | 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 ipv6-bounces@ietf.org Tue Oct 04 14:31:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMrZo-0001OZ-O3; Tue, 04 Oct 2005 14:31:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMrFO-0000pg-PC; Tue, 04 Oct 2005 14:10:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14551; Tue, 4 Oct 2005 14:10:37 -0400 (EDT) Received: from haybaler.sackheads.org ([216.27.184.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMrO6-0003TO-O6; Tue, 04 Oct 2005 14:19:40 -0400 Received: from localhost (localhost [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id 792A91AE18; Tue, 4 Oct 2005 11:10:32 -0700 (PDT) Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92382-04; Tue, 4 Oct 2005 11:10:31 -0700 (PDT) Received: from [172.30.106.233] (fw01.cmbrmaks.akamai.com [80.67.64.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by haybaler.sackheads.org (Postfix) with ESMTP id 88B741AE6D; Tue, 4 Oct 2005 11:10:30 -0700 (PDT) In-Reply-To: References: <20050923150609.GA14487@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Payne Date: Tue, 4 Oct 2005 14:10:27 -0400 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.623) X-Virus-Scanned: amavisd-new at sackheads.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 04 Oct 2005 14:31:42 -0400 Cc: David Meyer , iab@ietf.org, ipv6@ietf.org, shim6@psg.com Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Sep 25, 2005, at 12:48 PM, Iljitsch van Beijnum wrote: > NANOG = network operators in the sense of ISPs and the like. The > solution that the shim6 is working on does NOT apply to this > demographic. Whoa there. The NANOG community (as well as other ISP communities) is hugely affected by shim6. They are the ones who will be fielding customer calls about multihoming - "why can't I just setup BGP like I always have done?". Not everyone at NANOG is going to be big enough to get a /32, but most of the ISPs there are at least multihomed today. I for one am looking forward to both the BoF and Jason Schiller's general session topic. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 04 16:34:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMtUX-0002aQ-3l; Tue, 04 Oct 2005 16:34:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMtUW-0002Xv-2y; Tue, 04 Oct 2005 16:34:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01123; Tue, 4 Oct 2005 16:34:21 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMtdG-0001h8-BE; Tue, 04 Oct 2005 16:43:26 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j94KX7L25937; Tue, 4 Oct 2005 13:33:07 -0700 (PDT) Message-Id: <200510042033.j94KX7L25937@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 04 Oct 2005 13:33:07 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4193 on Unique Local IPv6 Unicast Addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4193 Title: Unique Local IPv6 Unicast Addresses Author(s): R. Hinden, B. Haberman Status: Standards Track Date: October 2005 Mailbox: bob.hinden@nokia.com, brian@innovationslab.net Pages: 16 Characters: 35908 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipv6-unique-local-addr-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4193.txt This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. This document is a product of the IP Version 6 Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051004133153.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4193 --OtherAccess Content-Type: Message/External-body; name="rfc4193.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051004133153.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Tue Oct 04 16:42:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMtcn-0005sB-Lk; Tue, 04 Oct 2005 16:42:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMtcl-0005ng-Lr; Tue, 04 Oct 2005 16:42:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03109; Tue, 4 Oct 2005 16:42:53 -0400 (EDT) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMtlU-0002S3-DO; Tue, 04 Oct 2005 16:51:58 -0400 Received: from gihm3.apnic.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id j94KgMXv030543; Wed, 5 Oct 2005 06:42:24 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051005063022.02f1fce0@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 05 Oct 2005 06:42:12 +1000 To: "Jason Schiller (schiller@uu.net)" , John Payne From: Geoff Huston In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: David Meyer , ipv6@ietf.org, Iljitsch van Beijnum , iab@ietf.org, shim6@psg.com Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >Doesn't this apply to any orgization that doesn't have its own /32? In the fullness of time this is the expectation, yes. However its pretty clear that the approach entails some changes to the protocol stack, and its not going to be a completely straightforward task. So its a pretty likely outcome that the 'conventional' practice of advertising more specifics into the routing system will not disappear overnight. >Doesn't this apply to any orgization that has customers that require >multihoming but lack their own /32 as John points out? as above. >Doesn't this apply to any orgization that has it's own IPv6 aggregate, >and wants to advertise something more specific than its aggregate? > >If that is the case, then it won't just apply to ISPs or multi-homed end >sites who can't get a /32, it also applies to ISPs and end sites who have >a /32, but need to split route announcement to share load across multiple >transit providers. I can appreciate the logic here- but in the same way that it strikes me that using routing to perform fine-grained traffic engineering is akin to using a mallet and an axe for a task that normally requires a micro-surgery, this also strikes me as a very round-about way to get to a useful approach to realize localized traffic engineering. regards, Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 05 00:29:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN0uI-0007U3-Kx; Wed, 05 Oct 2005 00:29:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN0uG-0007Ty-QC for ipv6@megatron.ietf.org; Wed, 05 Oct 2005 00:29:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27289 for ; Wed, 5 Oct 2005 00:29:25 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN134-0005nw-77 for ipv6@ietf.org; Wed, 05 Oct 2005 00:38:35 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0INV009RADSZ8M@szxga03-in.huawei.com> for ipv6@ietf.org; Wed, 05 Oct 2005 12:29:23 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0INV00E75DSZ19@szxga03-in.huawei.com> for ipv6@ietf.org; Wed, 05 Oct 2005 12:29:23 +0800 (CST) Received: from huaweimdtsdqe4 ([10.110.102.100]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0INV00GUCE52BM@szxml01-in.huawei.com> for ipv6@ietf.org; Wed, 05 Oct 2005 12:36:39 +0800 (CST) Date: Wed, 05 Oct 2005 12:26:01 +0800 From: Suraj In-reply-to: <20051002040013.BEDF947B@cyteen.hactrn.net> To: ipv6@ietf.org Message-id: <000001c5c964$e461e2a0$64666e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7BIT Subject: effect of deprecated site local addresses on router renumbering (rfc 2894) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi All, RFC 2894 ' Router Renumbering for IPv6'describes the Renumbering of Prefixes using RR commands to multicast addresses. (Site local OR Link local). Since the site local addresses are now deprecated (RFC 3879), we can assume that RR is now supported only for Link local addresses (unicast and multicast). What is the relevance of the 'S'(site specific) flag now in the command message. Should the 'S' flag be evaluated even if the scope of destination address is Link local (unicast or multicast)? Since RFC 2894 says that the 'S' flag should be ignored unless the router treats interfaces as belonging to different "sites", in this case should the RR command messages be limited only to the interfaces on that link OR to all interfaces on the router? Thanks and Regards, Suraj. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 05 03:23:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN3d6-0003jL-Oa; Wed, 05 Oct 2005 03:23:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN3d5-0003jG-Fp for ipv6@megatron.ietf.org; Wed, 05 Oct 2005 03:23:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03028 for ; Wed, 5 Oct 2005 03:23:53 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN3lp-0001S3-Cm for ipv6@ietf.org; Wed, 05 Oct 2005 03:33:03 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EN3cc-0001Fx-So; Wed, 05 Oct 2005 08:23:27 +0100 Message-ID: <43437FC7.6010106@dial.pipex.com> Date: Wed, 05 Oct 2005 08:24:55 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suraj References: <000001c5c964$e461e2a0$64666e0a@china.huawei.com> In-Reply-To: <000001c5c964$e461e2a0$64666e0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: effect of deprecated site local addresses on router renumbering (rfc 2894) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Suraj wrote: >Hi All, > >RFC 2894 ' Router Renumbering for IPv6'describes the Renumbering of >Prefixes using RR commands to multicast addresses. (Site local OR Link >local). > >Since the site local addresses are now deprecated (RFC 3879), we can >assume that RR is now supported only for Link local addresses (unicast >and multicast). > > No: The deprecation only affects site-local unicast addresses. Site-scope multicast is still available. >What is the relevance of the 'S'(site specific) flag now in the command >message. Should the 'S' flag be evaluated even if the scope of >destination address is Link local (unicast or multicast)? > > Yes: The relevance is unchanged. If a router is at a site border and is configured with some interfaces (set A) associated with one site and others (set B) associated with other site(s), then a renumbering message arriving on any interface in set A (whatever the destination address in the base IPv6 header) with the S flag set will be applied exclusively to the interfaces in set A - those in set B will be unaffected. >Since RFC 2894 says that the 'S' flag should be ignored unless the >router treats interfaces as belonging to different "sites", in this case >should the RR command messages be limited only to the interfaces on that >link OR to all interfaces on the router? > > Again the type of the command message destination address has no effect. Combining the words in s1, s3.1 and s4.3, the intention is that any RR command with the S flag clear applies to *all* interfaces apart from those that might be ruled out because they are currently shut down depending on the setting of the A flag - nothing is said about altering the processing depending on the type of destination address. Regards, Elwyn >Thanks and Regards, >Suraj. > > > >-------------------------------------------------------------------- >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 ipv6-bounces@ietf.org Wed Oct 05 04:38:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN4nW-00041f-Op; Wed, 05 Oct 2005 04:38:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN4nU-00040y-2Q; Wed, 05 Oct 2005 04:38:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06501; Wed, 5 Oct 2005 04:38:41 -0400 (EDT) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN4wH-0003d6-DG; Wed, 05 Oct 2005 04:47:53 -0400 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 95B315554; Wed, 5 Oct 2005 10:38:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 935575553; Wed, 5 Oct 2005 10:38:15 +0200 (CEST) Date: Wed, 5 Oct 2005 10:38:15 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: John Payne In-Reply-To: Message-ID: <20051005101940.V68899@mignon.ki.iif.hu> References: <20050923150609.GA14487@1-4-5.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: David Meyer , ipv6@ietf.org, Iljitsch van Beijnum , iab@ietf.org, shim6@psg.com Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Dear all, On Tue, 4 Oct 2005, John Payne wrote: > > On Sep 25, 2005, at 12:48 PM, Iljitsch van Beijnum wrote: > >> NANOG = network operators in the sense of ISPs and the like. The solution >> that the shim6 is working on does NOT apply to this demographic. > > Whoa there. The NANOG community (as well as other ISP communities) is hugely > affected by shim6. > > They are the ones who will be fielding customer calls about multihoming - > "why can't I just setup BGP like I always have done?". Not everyone at NANOG > is going to be big enough to get a /32, but most of the ISPs there are at > least multihomed today. > > I for one am looking forward to both the BoF and Jason Schiller's general > session topic. > I think most of the ISP who are seriously thinking about IPv6 have to have the ability to have a multihoming solution - getting PI-like address (nowadays it is /32). For end-systems/customers/enterprises might agree with upstream providers to accept more specific (and upstream can agree to exchange more specific inside country/region, but announce aggregate to global Internet) or use RFC3178 method (using tunnels) which is quite powerful technique. Any method can be implemented with careful BGP routing policy configuration. The shim6 is attractive method, but requires changes in host and router IPv6 implementations and this requires at least 5 years to be widely accepted.... Shim6 can be a long term solution, but shorter time-frame the operator/provider/user community can use existing methods to support/use multihoming. We can strart using it and if there is some problem we can speak up at NANOG/RIR etc meetings. Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > -------------------------------------------------------------------- > 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 ipv6-bounces@ietf.org Wed Oct 05 05:28:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN5ZK-0006SJ-Av; Wed, 05 Oct 2005 05:28:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN5ZI-0006SE-5D for ipv6@megatron.ietf.org; Wed, 05 Oct 2005 05:28:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09077 for ; Wed, 5 Oct 2005 05:28:05 -0400 (EDT) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN5i9-00055i-Bh for ipv6@ietf.org; Wed, 05 Oct 2005 05:37:17 -0400 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 535BF5553; Wed, 5 Oct 2005 11:27:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 511485519; Wed, 5 Oct 2005 11:27:58 +0200 (CEST) Date: Wed, 5 Oct 2005 11:27:58 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Elwyn Davies In-Reply-To: <4331DB42.6020103@dial.pipex.com> Message-ID: <20050922212656.H55108@mignon.ki.iif.hu> References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> <4331DB42.6020103@dial.pipex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Brian Haberman , Bob Hinden , ipv6@ietf.org Subject: Re: Taking RFC2460 (base IPv6) spec to full standard - issues outstanding X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, 21 Sep 2005, Elwyn Davies wrote: > Dear IPv6 WG Chairs, > I previously sent this mail to the list at the time of the wg meeting in > Paris > but there was no response. Has any decision been taken on how to move > forward > with the IPv6 suite going towards full standard? I believe these items > should > be looked at before RFC2460 goes forward. > > ================================================== > Resent message from 2 August 2005: > > In the course of doing the security overview draft in v6ops, we identified a > number of issues that appear to be errata or issues with the main IPv6 > standard. > These should potentially be fixed up as 2460 goes to full standard: > > Points for full standard; > ? (non-)Processing of Type 0 routing headers in hosts > ? (non-)Processing of Type 2 routing headers in routers This is necessary to be defined. > ? Processing Extension Headers in Middleboxes - > o words about where headers are inspected need to be relaxed > o words about processing headers out of order need to be relaxed > o should intermediate nodes be allowed to discard packets with unknown > extension headers? I think this can be relaxed: Any internmediate system can delete any packet if policy dictates. This should not be very strict, but somehow force the IPv6 conformance. > ? Requiring that new extension headers use TLV format (and maybe > putting > the length into the fragmentation header) - to simplify skipping > headers > in middleboxes This would be a good decision. > ? Constraining new hop-by-hop options both as to number and function - > h-by-h should be designed either for simple fast path processing > (like > jumbo packets) or to explicitly cause a packet to be dumped to the > slow > path (like router alert). It would be good if such a distinction could be done. > ? Fragment reassembly algorithm - should explicitly forbid overlapped > fragments and possibly require that non-final fragments are (say) at > least 1024 bytes. According the RFC2460 the minimal MTU must be 1280. So Each fragments - except the last fragment packet should be at least 1280. - this is implicitly written in RFC2460 spec: "The lengths of the fragments must be chosen such that the resulting fragment packets fit within the MTU of the path to the packets' destination(s)." I understand this, that each fragment packet should be no smaller than MTU, which is at least 1280. I think it is wise to make it more explicit. This my opinion only. Regards, Janos Mohacsi -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 05 09:04:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN8wV-00083G-Uo; Wed, 05 Oct 2005 09:04:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN8wS-00082T-KR for ipv6@megatron.ietf.org; Wed, 05 Oct 2005 09:04:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21577 for ; Wed, 5 Oct 2005 09:04:12 -0400 (EDT) Received: from peewit.ecs.soton.ac.uk ([152.78.68.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN95I-00036z-Dn for ipv6@ietf.org; Wed, 05 Oct 2005 09:13:25 -0400 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id j95D3YhL023370 for ; Wed, 5 Oct 2005 14:03:34 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j95D3Yo13561 for ipv6@ietf.org; Wed, 5 Oct 2005 14:03:34 +0100 Date: Wed, 5 Oct 2005 14:03:34 +0100 From: Tim Chown To: ipv6@ietf.org Message-ID: <20051005130334.GX6413@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <000001c5c964$e461e2a0$64666e0a@china.huawei.com> <43437FC7.6010106@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43437FC7.6010106@dial.pipex.com> User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: Re: effect of deprecated site local addresses on router renumbering (rfc 2894) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Suraj, May I ask if you are implementing this, or are you looking from a theoretical perspective? Tim On Wed, Oct 05, 2005 at 08:24:55AM +0100, Elwyn Davies wrote: > > > Suraj wrote: > > >Hi All, > > > >RFC 2894 ' Router Renumbering for IPv6'describes the Renumbering of > >Prefixes using RR commands to multicast addresses. (Site local OR Link > >local). > > > >Since the site local addresses are now deprecated (RFC 3879), we can > >assume that RR is now supported only for Link local addresses (unicast > >and multicast). > > > > > No: The deprecation only affects site-local unicast addresses. > Site-scope multicast is still available. > > >What is the relevance of the 'S'(site specific) flag now in the command > >message. Should the 'S' flag be evaluated even if the scope of > >destination address is Link local (unicast or multicast)? > > > > > Yes: The relevance is unchanged. If a router is at a site border and > is configured with some interfaces (set A) associated with one site and > others (set B) associated with other site(s), then a renumbering > message arriving on any interface in set A (whatever the destination > address in the base IPv6 header) with the S flag set will be applied > exclusively to the interfaces in set A - those in set B will be unaffected. > > >Since RFC 2894 says that the 'S' flag should be ignored unless the > >router treats interfaces as belonging to different "sites", in this case > >should the RR command messages be limited only to the interfaces on that > >link OR to all interfaces on the router? > > > > > Again the type of the command message destination address has no effect. > Combining the words in s1, s3.1 and s4.3, the intention is that any RR > command with the S flag clear applies to *all* interfaces apart from > those that might be ruled out because they are currently shut down > depending on the setting of the A flag - nothing is said about altering > the processing depending on the type of destination address. > > Regards, > Elwyn > > >Thanks and Regards, > >Suraj. > > > > > > > >-------------------------------------------------------------------- > >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 > -------------------------------------------------------------------- -- Tim/::1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 05 09:24:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9GR-0008Lk-Q0; Wed, 05 Oct 2005 09:24:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMt1E-0005C3-Ac; Tue, 04 Oct 2005 16:04:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23793; Tue, 4 Oct 2005 16:04:06 -0400 (EDT) Received: from pmesmtp04.mci.com ([199.249.20.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMt9u-0007Ku-AT; Tue, 04 Oct 2005 16:13:10 -0400 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0INU00FISPYRED@firewall.mci.com>; Tue, 04 Oct 2005 19:54:28 +0000 (GMT) Received: from imr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQtiup12223; Tue, 04 Oct 2005 19:54:12 +0000 (GMT) Received: from meno.corp.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: meno.corp.us.uu.net [153.39.146.71]) id j94JsBrY023247; Tue, 04 Oct 2005 19:54:11 +0000 (GMT) Received: from localhost by meno.corp.us.uu.net with ESMTP (peer crosschecked as: schiller@localhost) id QQtiup19798; Tue, 04 Oct 2005 15:54:10 -0400 (EDT) Date: Tue, 04 Oct 2005 15:54:10 -0400 (EDT) From: "Jason Schiller (schiller@uu.net)" In-reply-to: X-Sender: schiller@meno.corp.us.uu.net To: John Payne Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 1.6 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Wed, 05 Oct 2005 09:24:54 -0400 Cc: David Meyer , ipv6@ietf.org, Iljitsch van Beijnum , iab@ietf.org, shim6@psg.com Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, 4 Oct 2005, John Payne wrote: > Date: Tue, 04 Oct 2005 14:10:27 -0400 > From: John Payne > To: Iljitsch van Beijnum > Cc: David Meyer , iab@ietf.org, ipv6@ietf.org, shim6@psg.com > Subject: Re: IPv6 Multi-homing BOF at NANOG 35 > > > On Sep 25, 2005, at 12:48 PM, Iljitsch van Beijnum wrote: > > > NANOG = network operators in the sense of ISPs and the like. The > > solution that the shim6 is working on does NOT apply to this > > demographic. > > Whoa there. The NANOG community (as well as other ISP communities) is > hugely affected by shim6. > > They are the ones who will be fielding customer calls about multihoming > - "why can't I just setup BGP like I always have done?". Not everyone > at NANOG is going to be big enough to get a /32, but most of the ISPs > there are at least multihomed today. > > I urge the discussion leaders to make it painfully clear to which > > types of users the shim6 solution space applies and to which type of > > users it doesn't. Doesn't this apply to any orgization that doesn't have its own /32? Doesn't this apply to any orgization that has customers that require multihoming but lack their own /32 as John points out? Doesn't this apply to any orgization that has it's own IPv6 aggregate, and wants to advertise something more specific than its aggregate? If that is the case, then it won't just apply to ISPs or multi-homed end sites who can't get a /32, it also applies to ISPs and end sites who have a /32, but need to split route announcement to share load across multiple transit providers. ___Jason -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 05 09:24:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9GU-0008Mf-9T; Wed, 05 Oct 2005 09:24:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMuYZ-00046D-Nd; Tue, 04 Oct 2005 17:42:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10668; Tue, 4 Oct 2005 17:42:36 -0400 (EDT) Received: from sccrmhc14.comcast.net ([63.240.76.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMuhK-0005fj-8i; Tue, 04 Oct 2005 17:51:43 -0400 Received: from [192.168.0.100] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with SMTP id <2005100421420301400olku5e>; Tue, 4 Oct 2005 21:42:23 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00D1D00E-88CF-45F5-A6F4-1DA90DE4F41B@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Date: Tue, 4 Oct 2005 14:41:59 -0700 To: "Jason Schiller (schiller@uu.net)" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 05 Oct 2005 09:24:54 -0400 Cc: John Payne , Iljitsch van Beijnum , ipv6@ietf.org, David Meyer , iab@ietf.org, shim6@psg.com Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>> NANOG = network operators in the sense of ISPs and the like. The >>> solution that the shim6 is working on does NOT apply to this >>> demographic. >>> The ISP community is the primary direct beneficiary of shim6 and will have to work with their customers to help implement it. If the operational community is interested in the long term scalability of the routing subsystem, then we need to implement the changes to the routing architecture necessary to not advertise per-organization prefixes globally and shim6 is the best way that we have of doing that. Shim6 needs ISP support, plain and simple. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 05 09:24:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9GV-0008N6-HS; Wed, 05 Oct 2005 09:24:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN2Qp-00016i-Bn; Wed, 05 Oct 2005 02:07:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08026; Wed, 5 Oct 2005 02:07:07 -0400 (EDT) Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN2Zb-0007ul-AZ; Wed, 05 Oct 2005 02:16:16 -0400 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Content-Class: urn:content-classes:message Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 Oct 2005 11:36:53 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Oct 2005 11:36:53 +0530 Message-ID: <86094352DBA45B4E8575CE0748C16A6B1B59FB@Haritha.ctd.hcltech.com> From: "Vijayanand C - CTD, Chennai." To: , Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Oct 2005 11:36:52 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 05 Oct 2005 06:06:53.0496 (UTC) FILETIME=[FBA02B80:01C5C972] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 05 Oct 2005 09:24:53 -0400 Cc: Subject: v6 over v4 using igp shortcut X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello all, To transport v6 traffic over v4 only islands , is it feasible to = advertise v4 tunnels between the edges of the v4 island into v6 igp as shortcuts = and use them. This could be an alternative to the 6PE mechanism wherever appropriate.=20 Regards, Vijay DISCLAIMER=20 This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies=20 and its customers. Contents may be privileged or otherwise protected by = law. The information is solely intended for the=20 individual or the entity it is addressed to. If you are not the intended = recipient of this message, you are not authorized to=20 read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error,=20 please notify the sender immediately by return e-mail and delete it from = your computer -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 09 00:00:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOSMd-0002aZ-Et; Sun, 09 Oct 2005 00:00:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOSMb-0002aU-5I for ipv6@megatron.ietf.org; Sun, 09 Oct 2005 00:00:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11020 for ; Sun, 9 Oct 2005 00:00:38 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOSWA-0002kP-Uv for ipv6@ietf.org; Sun, 09 Oct 2005 00:10:38 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 1FE7942D for ; Sun, 9 Oct 2005 00:00:16 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 09 Oct 2005 00:00:16 -0400 Message-Id: <20051009040016.1FE7942D@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.67% | 2 | 18.73% | 10595 | mohacsi@niif.hu 8.33% | 1 | 11.19% | 6333 | rfc-editor@rfc-editor.org 8.33% | 1 | 10.18% | 5760 | tjc@ecs.soton.ac.uk 8.33% | 1 | 8.82% | 4990 | jason.schiller@mci.com 8.33% | 1 | 8.68% | 4914 | elwynd@dial.pipex.com 8.33% | 1 | 7.53% | 4261 | sra+ipng@hactrn.net 8.33% | 1 | 7.53% | 4259 | gih@apnic.net 8.33% | 1 | 7.33% | 4150 | surajs@huawei.com 8.33% | 1 | 6.95% | 3934 | john@sackheads.org 8.33% | 1 | 6.80% | 3850 | vijayc@hcltech.com 8.33% | 1 | 6.25% | 3535 | tony.li@tony.li --------+------+--------+----------+------------------------ 100.00% | 12 |100.00% | 56581 | 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 ipv6-bounces@ietf.org Sun Oct 09 13:32:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOf23-0004vX-5k; Sun, 09 Oct 2005 13:32:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOf21-0004vR-Dr for ipv6@megatron.ietf.org; Sun, 09 Oct 2005 13:32:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28779 for ; Sun, 9 Oct 2005 13:32:14 -0400 (EDT) Received: from xproxy.gmail.com ([66.249.82.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOfBk-00017T-K7 for ipv6@ietf.org; Sun, 09 Oct 2005 13:42:21 -0400 Received: by xproxy.gmail.com with SMTP id s11so142221wxc for ; Sun, 09 Oct 2005 10:32:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=opiP0P8JjBmjFpIEcnaLf/EHKRhkl/pa0lW5TTCIPS8idkz3PS8Ln1YnVES73EAqwjxkFu8Yh1xoab3VcZlfeAGVEgnpGxH1QpVvwr+CH7wIE51YveXhrhiKJ3cVFumo1RVC27xVBbLbBcKebk/bz2gr2w+eba6+F3e0wxlGN1w= Received: by 10.70.59.17 with SMTP id h17mr3075979wxa; Sun, 09 Oct 2005 10:32:02 -0700 (PDT) Received: by 10.70.73.4 with HTTP; Sun, 9 Oct 2005 10:32:02 -0700 (PDT) Message-ID: <9f37d7da0510091032s5e9283a0t3735d27c18b6a7c2@mail.gmail.com> Date: Mon, 10 Oct 2005 02:32:02 +0900 From: Park Sangsu To: ipv6@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: Linux host PC(ipv6) can't ping with embedded board(ipv6) with ping6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Park Sangsu List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0466072542==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0466072542== Content-Type: multipart/alternative; boundary="----=_Part_28955_30030797.1128879122383" ------=_Part_28955_30030797.1128879122383 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, all I have a problem about ping with ipv6. I want to ping between host PC(ipv6) and embedded board(ipv6). When embedded board ping to host PC, ping worked well. But when host PC ping to embedded board, ping didn't work well. Host PC sent a icmp packet(solicitation) to embedded board, but embedded board didn't send a icmp packet(advertisement). I don't know what is worng. please advise me. ------=_Part_28955_30030797.1128879122383 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi, all
 
I have a problem about ping with ipv6.
I want to ping between host PC(ipv6) and embedded board(ipv6).
 
When embedded board ping to host PC, ping worked well.
But when host PC ping to embedded board, ping didn't work well.
Host PC sent a icmp packet(solicitation) to embedded board, but embedd= ed board didn't send a icmp packet(advertisement).
 
I don't know what is worng.
please advise me.
------=_Part_28955_30030797.1128879122383-- --===============0466072542== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0466072542==-- From ipv6-bounces@ietf.org Sun Oct 09 13:45:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOfFA-0007E9-Jl; Sun, 09 Oct 2005 13:45:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOfF9-0007DU-0O for ipv6@megatron.ietf.org; Sun, 09 Oct 2005 13:45:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29481 for ; Sun, 9 Oct 2005 13:45:50 -0400 (EDT) Received: from purgatory.unfix.org ([213.136.24.43] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOfOr-0001TJ-EH for ipv6@ietf.org; Sun, 09 Oct 2005 13:55:55 -0400 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 676DC8F1D; Sun, 9 Oct 2005 19:45:28 +0200 (CEST) From: Jeroen Massar To: Park Sangsu In-Reply-To: <9f37d7da0510091032s5e9283a0t3735d27c18b6a7c2@mail.gmail.com> References: <9f37d7da0510091032s5e9283a0t3735d27c18b6a7c2@mail.gmail.com> Organization: Unfix Date: Sun, 09 Oct 2005 19:45:26 +0200 Message-Id: <1128879926.27616.3.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipv6@ietf.org Subject: Re: Linux host PC(ipv6) can't ping with embedded board(ipv6) with ping6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0344497015==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0344497015== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pXTK14HHb0BWIIvOuW7K" --=-pXTK14HHb0BWIIvOuW7K Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-10-10 at 02:32 +0900, Park Sangsu wrote:=20 > Hi, all > =20 > I have a problem about ping with ipv6. > I want to ping between host PC(ipv6) and embedded board(ipv6). You will most likely find a better answer on a linux specific list: For instance the USAGI users mailing list: http://www.linux-ipv6.org/ml/index.html#usagi-users When mailing them specify the hardware and kernel versions you are using and also the versions of the various tools you are trying. The IETF lists are about the protocol, not for specific OS problems. > When embedded board ping to host PC, ping worked well. > But when host PC ping to embedded board, ping didn't work well. > > Host PC sent a icmp packet(solicitation) to embedded board, but > embedded board didn't send a icmp packet(advertisement). You are most likely mixing this up with ICMP echo requests and ICMP echo responses. One of the few tricks you can try is running tools like ethereal or tcpdump on both sides and determining what is going on. Greets, Jeroen --=-pXTK14HHb0BWIIvOuW7K Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBDSVc2KaooUjM+fCMRAjtiAKCC5EZUit8mVa9EM77lfdWyurliHQCgkzwc hPpB20vX5x6tGt8/jbSEb3U= =3hk+ -----END PGP SIGNATURE----- --=-pXTK14HHb0BWIIvOuW7K-- --===============0344497015== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0344497015==-- From ipv6-bounces@ietf.org Mon Oct 10 08:17:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOwb3-0005az-R1; Mon, 10 Oct 2005 08:17:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOwaz-0005aU-0M; Mon, 10 Oct 2005 08:17:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05180; Mon, 10 Oct 2005 08:17:31 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOwks-00037d-7M; Mon, 10 Oct 2005 08:27:47 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j9ACHMTZ128280; Mon, 10 Oct 2005 12:17:22 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9ACHMkI179300; Mon, 10 Oct 2005 14:17:22 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j9ACHLna007511; Mon, 10 Oct 2005 14:17:21 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j9ACHK7b007505; Mon, 10 Oct 2005 14:17:21 +0200 Received: from zurich.ibm.com (sig-9-145-130-125.de.ibm.com [9.145.130.125]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA30502; Mon, 10 Oct 2005 14:17:18 +0200 Message-ID: <434A5BC7.5030802@zurich.ibm.com> Date: Mon, 10 Oct 2005 14:17:11 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Mohacsi Janos References: <20050923150609.GA14487@1-4-5.net> <20051005101940.V68899@mignon.ki.iif.hu> In-Reply-To: <20051005101940.V68899@mignon.ki.iif.hu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: John Payne , Iljitsch van Beijnum , iab@ietf.org, David Meyer , ipv6@ietf.org, shim6@psg.com Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Mohacsi Janos wrote: > Dear all, > > On Tue, 4 Oct 2005, John Payne wrote: > >> >> On Sep 25, 2005, at 12:48 PM, Iljitsch van Beijnum wrote: >> >>> NANOG = network operators in the sense of ISPs and the like. The >>> solution that the shim6 is working on does NOT apply to this >>> demographic. >> >> >> Whoa there. The NANOG community (as well as other ISP communities) is >> hugely affected by shim6. >> >> They are the ones who will be fielding customer calls about >> multihoming - "why can't I just setup BGP like I always have done?". >> Not everyone at NANOG is going to be big enough to get a /32, but most >> of the ISPs there are at least multihomed today. >> >> I for one am looking forward to both the BoF and Jason Schiller's >> general session topic. >> > > I think most of the ISP who are seriously thinking about IPv6 have to > have the ability to have a multihoming solution - getting PI-like > address (nowadays it is /32). The point of shim6 is to *avoid* the need for PI-like space for multihomed sites, so that we don't do to the IPv6 BGP table what multihoming is doing to the IPv4 BGP table. We need IPv6 to scale vastly more than IPv4, so this is essential. I hope the proposed BOF will make this clearer. I personally think that shim6 will be really cool for ISPs, although as Geoff says it will take a while to deploy and during that time we'll need a PI-like approach. Brian For end-systems/customers/enterprises > might agree with upstream providers to accept more specific (and > upstream can agree to exchange more specific inside country/region, but > announce aggregate to global Internet) or use RFC3178 method (using > tunnels) which is quite powerful technique. Any method can be > implemented with careful BGP routing policy configuration. > The shim6 is attractive method, but requires changes in host and router > IPv6 implementations and this requires at least 5 years to be widely > accepted.... > > Shim6 can be a long term solution, but shorter time-frame the > operator/provider/user community can use existing methods to support/use > multihoming. We can strart using it and if there is some problem we can > speak up at NANOG/RIR etc meetings. > > > Regards, > > > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > >> >> -------------------------------------------------------------------- >> 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 ipv6-bounces@ietf.org Mon Oct 10 17:24:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP58Z-00022S-7p; Mon, 10 Oct 2005 17:24:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP0CA-0001Oh-Gh; Mon, 10 Oct 2005 12:08:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02921; Mon, 10 Oct 2005 12:08:05 -0400 (EDT) Received: from omzesmtp02.mci.com ([199.249.17.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP06s-0007ch-Vq; Mon, 10 Oct 2005 12:02:48 -0400 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0IO500FJQILD5O@firewall.mci.com>; Mon, 10 Oct 2005 15:48:50 +0000 (GMT) Received: from imr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQtjqd14168; Mon, 10 Oct 2005 15:48:34 +0000 (GMT) Received: from meno.corp.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: meno.corp.us.uu.net [153.39.146.71]) id j9AFmXui000253; Mon, 10 Oct 2005 15:48:33 +0000 (GMT) Received: from localhost by meno.corp.us.uu.net with ESMTP (peer crosschecked as: schiller@localhost) id QQtjqd15335; Mon, 10 Oct 2005 11:48:33 -0400 (EDT) Date: Mon, 10 Oct 2005 11:48:32 -0400 (EDT) From: "Jason Schiller (schiller@uu.net)" In-reply-to: <434A5BC7.5030802@zurich.ibm.com> X-Sender: schiller@meno.corp.us.uu.net To: Brian E Carpenter Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 1.6 (+) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 X-Mailman-Approved-At: Mon, 10 Oct 2005 17:24:45 -0400 Cc: John Payne , Iljitsch van Beijnum , ipv6@ietf.org, David Meyer , iab@ietf.org, shim6-wg , Mohacsi Janos Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Mon, 10 Oct 2005, Brian E Carpenter wrote: > Date: Mon, 10 Oct 2005 14:17:11 +0200 > From: Brian E Carpenter > To: Mohacsi Janos > Cc: John Payne , > Iljitsch van Beijnum , iab@ietf.org, > David Meyer , ipv6@ietf.org, shim6@psg.com > Subject: Re: IPv6 Multi-homing BOF at NANOG 35 > > Mohacsi Janos wrote: > > Dear all, > > > > On Tue, 4 Oct 2005, John Payne wrote: > > > > > > I think most of the ISP who are seriously thinking about IPv6 have to > > have the ability to have a multihoming solution - getting PI-like > > address (nowadays it is /32). Some ISPs can get their own aggregate, some are too small and can't. Even having your own aggregate in the global routing table and doing IPv4 style multi-homing doesn't provide you with all of the tools you currently have in IPv4 multi-homing. Distancing all the customers of a given provider is not quite as useful as distancing one customer prefix behind one provider. Having commercial customers who require multi-homing but can't get their own prefix in the global routing table is a barrier to entry, and impacts ISPs who have many such customers. Commercial customers with their own prefix in the global routing table and doing IPv4 style multi-homing doesn't provide them with all of the tools they currently have in IPv4 multi-homing. If they are only allowed to advertise a single aggregate, they can split load across multiple transit providers. > > The point of shim6 is to *avoid* the need for PI-like space > for multihomed sites, so that we don't do to the IPv6 BGP table > what multihoming is doing to the IPv4 BGP table. We need IPv6 > to scale vastly more than IPv4, so this is essential. Yes. We can put all of the IPv6 more specifics into the global routing table, but current hardware won't scale to hold that. Its not clear that the technology to hold the larger RIB and FIB will be available in 5 years, or if it will be cost prohibitive. If we try to solve this in some other way then de-aggregation, then we need to make sure it is at least as functional and easy to operate as what we have now, or no operators will want to adopt it. > > I hope the proposed BOF will make this clearer. I personally > think that shim6 will be really cool for ISPs, although as Geoff > says it will take a while to deploy and during that time we'll > need a PI-like approach. > > Brian There are many content providers who are avoiding IPv6 as they beleive it is not yet ready for "prime time" commerical traffic as it lacks sufficent multi-homing capabilities. Clearly we need a multi-homing solution now. However I am concerned that if we allow PI addresses into the global routing table, then we begin down the path of solving the multi-homing problem by de-aggregating. In 10 years time, there may be many de-aggregates in the global routing table. At that time it will be much harder to tighten the belt and get those prefixes out of the global routing table. Do you think that operators of commercial networks will want to switch to shim6? Consider the current comfort level with the IPv4 style BGP de-aggregate traffic engineering. Consider that the current approach to shim6 is less functional than the current IPv4 style multi-homing. Consider the the shim6 solution may be very different to operate (configuring end hosts instead of Internet facing routers) and may break current operational boundaries. Shim6 as a host multi-homing solution lends itself nicely to consumer networks all operated by few end users with few hosts, but is more problematic to implement it in a large commerical network. Don't miss read me. I'm not bashing shim6. I'm suggesting it needs to be as functional as what operators currently have. I'm also suggesting that there is a barrier to change, and if traditional IPv4 style multi-homing is allowed to be done in IPv6 then comercial networks may never adopt a shim6 solution. ARIN is currently considerig PI IPv6 space. See Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites: http://www.arin.net/policy/proposals/2005_1.html It is my belief that if this policy goes through that commercial sites will be unlikely adopt a shim6 solution. ___Jason > > > > For end-systems/customers/enterprises > > might agree with upstream providers to accept more specific (and > > upstream can agree to exchange more specific inside country/region, but > > announce aggregate to global Internet) or use RFC3178 method (using > > tunnels) which is quite powerful technique. Any method can be > > implemented with careful BGP routing policy configuration. > > The shim6 is attractive method, but requires changes in host and router > > IPv6 implementations and this requires at least 5 years to be widely > > accepted.... > > > > Shim6 can be a long term solution, but shorter time-frame the > > operator/provider/user community can use existing methods to support/use > > multihoming. We can strart using it and if there is some problem we can > > speak up at NANOG/RIR etc meetings. > > > > > > Regards, > > > > > > Janos Mohacsi > > Network Engineer, Research Associate > > NIIF/HUNGARNET, HUNGARY > > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > > > > >> > >> -------------------------------------------------------------------- > >> 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 ipv6-bounces@ietf.org Mon Oct 10 17:24:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP58a-00022w-BA; Mon, 10 Oct 2005 17:24:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP0LW-0004gF-J7; Mon, 10 Oct 2005 12:17:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03882; Mon, 10 Oct 2005 12:17:47 -0400 (EDT) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX192tALPsTF+WGuHMrA+tzGZUU9o+AYBZEY=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP0VQ-0000bI-HE; Mon, 10 Oct 2005 12:28:06 -0400 Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j9AGHSGh032148; Mon, 10 Oct 2005 17:17:31 +0100 Date: Mon, 10 Oct 2005 17:18:42 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Brian E Carpenter In-Reply-To: <434A5BC7.5030802@zurich.ibm.com> Message-ID: References: <20050923150609.GA14487@1-4-5.net> <20051005101940.V68899@mignon.ki.iif.hu> <434A5BC7.5030802@zurich.ibm.com> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Mon, 10 Oct 2005 17:24:45 -0400 Cc: John Payne , Iljitsch van Beijnum , iab@ietf.org, David Meyer , ipv6@ietf.org, shim6@psg.com, Mohacsi Janos Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Mon, 10 Oct 2005, Brian E Carpenter wrote: > The point of shim6 is to *avoid* the need for PI-like space for > multihomed sites, so that we don't do to the IPv6 BGP table what > multihoming is doing to the IPv4 BGP table. We need IPv6 to scale > vastly more than IPv4, so this is essential. The problem isn't PI addressing, it's advertising tiny prefixes in the routing table. PI addressing *without* global-routing-table visibility *would* obviously scale for routing. We just don't have a way to do this. > I hope the proposed BOF will make this clearer. I personally think > that shim6 will be really cool for ISPs, although as Geoff says it > will take a while to deploy and during that time we'll need a > PI-like approach. We'll always need PI. The Independence part of PI is what people /really/ want. They don't want multiple-PA (they can do that already relatively easily). If people can not get globally-unique PI addresses they will use private PI space and use address translation. > Brian regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: The herd instinct among economists makes sheep look like independent thinkers. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 10 19:03:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP6gQ-0000GR-NH; Mon, 10 Oct 2005 19:03:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP6gO-0000FU-0O for ipv6@megatron.ietf.org; Mon, 10 Oct 2005 19:03:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01190 for ; Mon, 10 Oct 2005 19:03:44 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP6qN-0004Qn-9I for ipv6@ietf.org; Mon, 10 Oct 2005 19:14:07 -0400 Received: from impact.jinmei.org (unknown [2001:4f8:3:bb:fdaf:e2ef:7ffe:fbff]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BBF961521A; Tue, 11 Oct 2005 08:03:19 +0900 (JST) Date: Tue, 11 Oct 2005 08:03:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark In-Reply-To: <43135173.7010804@sun.com> References: <430F9EE7.5040901@sun.com> <43135173.7010804@sun.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ipv6@ietf.org, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello, Sorry for the long delay in response...I've been clearly a show-stopper of this document. >>>>> On Mon, 29 Aug 2005 11:18:27 -0700, >>>>> Erik Nordmark said: >> This looks like a reasonable idea. And I see the need for the new >> AI_PREFERENCES flag (i.e., the hint structure is built by the >> application, and the added field passed by an old application can be >> garbage). >> >> One may want to make the new field more generic, rather than the >> specific purpose of preferences, but I don't have a strong opinion on >> this. > Yes, we could call the new field ai_extended_flags or something like > that (ai_eflags?). > Taking your concern about address family specific flags, we could also > explicitly label this (ai_ipv6_flags?). > I don't know how to decide which way to go on this, since I currently > can't imagine what other things might be added to getaddrinfo() over time. After thinking about it again, I now tend to feel AI_PREFERENCE does not sound so ad-hoc. Sine getaddrinfo() is typically expected to return multiple addresses (of multiple families), ordering among them is its inherent concern. So, I think I can live with AI_PREFERENCE (and the corresponding additional field(s) of addrinfo{}). > Also, if we change it to only define a single AI flag, are you still > concerned about having one flag per "feature" (both a PUBLIC and TMP > flag for instance)? I'm not really sure what "to only define a single AI flag", but yes, I'm still concerned about having separate flags for both PUBLIC and TMP (and so on). I've been thinking over it again, and I guess the main concerns are as follows: 1. having separate flags cause invalid cases and make sanity checks in implementations more complex (as I mentioned in the comment message). 2. rephrasing this point differently, these are actually not "flags", but multi(more than 2)-value options. For example, what we are going to define with IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA is the source address selection policy from - prefer home address - prefer care-of-address - (perhaps implicitly) use system (or administrator's) default (I admit this might sound just a "philosophical" argument.) As far as I know, in the traditional API design we have been using a separate socket option type for each optional notion (in this case the address selection policy). Examples include the IPV6_MULTICAST_LOOP option (while it does not have a specific "use default" value) and the IPV6_{UNICAST,MULTICAST}_HOPS options (while these have more than two possible values). I speculate one of the reasons why we've been adhering to the use of "flags" is because we need to do the similar thing for getaddrinfo() and the only available field to pass this information was a "flag" field at that time. If my understanding is correct, and if we agree on some (more flexible) extensions to the addrinfo structure, we may be able to take a different approach. For example, we'd be able to specify each policy as an integer encoding a type-value pair, and specify the set of policies as an array of the pairs. The following describes one possible implementation of this idea. typedef struct { u_int32_t policyname : 30; u_int32_t policyvalue : 2; } ai_selection_t; struct addrinfo { int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, .. */ (snip) ai_selection_t *ai_selection; /* examined only when AI_PREFERENCE is set and ai_selection is non NULL */ }; An application that prefers care-of-address over home-address would do: struct addrinfo hints; ai_selection_t ai_selections[2]; ai_selections[0].policyname = AI_SELECTION_MIP; ai_selections[0].policyvalue = AI_SELECTION_PREFER_COA; /* AI_SELECTION_NULL is a terminating marker */ ai_selections[1].policyname = AI_SELECTION_NULL; ai_selections[1].policyvalue = 0; hints.ai_flags |= AI_PREFERENCE; hints.ai_selection = ai_selections; How about something like this? One may regard this as an overly-generalized solution, but I believe this solves all technical concerns pointed out so far. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 10 20:38:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP8AP-0003vf-FK; Mon, 10 Oct 2005 20:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP8AJ-0003u6-Ok for ipv6@megatron.ietf.org; Mon, 10 Oct 2005 20:38:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04957 for ; Mon, 10 Oct 2005 20:38:46 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP8KI-0006et-Ij for ipv6@ietf.org; Mon, 10 Oct 2005 20:49:08 -0400 Received: from impact.jinmei.org (unknown [2001:4f8:3:bb:c54a:5e24:45c7:ea31]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 772EA1521A; Tue, 11 Oct 2005 09:38:42 +0900 (JST) Date: Tue, 11 Oct 2005 09:38:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark In-Reply-To: <4313621D.7080205@sun.com> References: <4313621D.7080205@sun.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Cc: ipv6@ietf.org, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Mon, 29 Aug 2005 12:29:33 -0700, >>>>> Erik Nordmark said: >> First of all, I must say I'm not particularly fascinated by this API. >> As (I think) I said before, I believe this can be useful in very >> limited situations only (especially because applications need to be >> modified - I generally agree with Francis on this point), and most >> applications (and application writers) wouldn't be bothered with using >> the additional feature. In fact, the only people I've ever seen who >> expressed interest in this API are mobile IP(v6) implementors, >> expecting this API can be used in their mobile IP(v6) specific >> implementations (e.g., ones that negotiate with the home agent). I >> respect that the draft provides one section showing usage examples, >> but these are not convincing enough to me. > FWIW To me, the public/temporary address knob is just as important, if > not more important than the home/coa knob. I'm not saying the public/temporary knob (itself) is not important. I simply suspect application programmers don't bother to use that knob in their implementations, and privacy-conscious users would simply use per-system default (if the system supports that). But anyway, I won't fight on this point to decide whether or not this API should be published, so you don't have to try convince me on this. >> 3. I suspect the necessity of IPV6_PREFER_SRC_{LARGE,SMALL}SCOPE. >> Those might actually be even harmful. The API draft says these >> correspond to Rule 2 of the source address selection defined in >> RFC3484. But the RFC says: (snip) >> At the very least, I'm not even sure how the logic of Rule 2 is >> modified if we specify IPV6_PREFER_SRC_SCOPE. The rule defined in >> RFC3484 is: >> >> Rule 2: Prefer appropriate scope. >> If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB >> and otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If >> Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. >> >> How would this look like with IPV6_PREFER_SRC_SCOPE? > FWIW the semantics of IPV6_PREFER_SRC_SMALLSCOPE would be to invert rule > 2, so that the algorithm instead of prefering the smallest scoped source > which has a scope of at least the destination address, it would prefer > the largest scoped source which has a scope which is at most the same as > the destination address. I'm not sure if this answers my question. Please describe what would happen if IPV6_PREFER_SRC_SMALLSCOPE is specified using the pseudo-algorithm like "If Scope(SA) < Scope(SB)...". But in any event, > But, like you, I question the utility of this. then my primary suggestion is to remove this knob. And, if we can agree on that, I don't need the "pseudo-algorithm". >> SEMI SUBSTANTIAL COMMENTS >> >> 4. Considering the background motivation of the advanced API, I think >> we should also provide an ancillary-data object corresponding to >> the proposed socket option in order to control the address >> selection policy per-packet basis with a single system call (i.e., >> sendmsg()). > We can definitely add that. > Although I sometimes wonder how useful ancillary data options are on the > send side (they are critical on the receive side, so that the > application can see what was "part of" each received datagram). Whether the use of ancillary data makes sense hingly depends on the usage. In general, if a single socket is shared for multiple purposes/destinations with possibly different parameters and switching the parameters per packet using setsockopt is expensive, using ancillary data make sense. For example, BIND9 name server uses the IPV6_PKTINFO option for specifying a particular source address per DNS response. >> 5. (AFAICS) This document does not explicitly define the return value >> of getsockopt(IPV6_ADDR_PREFERENCES). Even though it's pretty >> trivial, I believe an API specification should generally provide >> such 'trivial' things very clearly and explicitly. > Do you mean the actual return value (which is 0/-1 according to the Open > Group standard for getsockopt), or what value is returned in the *optval? The latter (sorry, perhaps I was not clear enough). >> 6. [1st line of page 4 (continued from page 3)] >> >> [...] Since source address selection and destination address >> ordering need to be partially implemented in getaddrinfo() [3] the >> corresponding set of flags are also defined for that routine. >> >> I think this is too strong. Although destination address ordering >> (selection) would typically be implemented through getaddrinfo(), >> the selection rules themselves are quite general and could be >> realized in some other way. > Yes, the point is that the API shouldn't constrain or assume which parts > of address selection is implemented in getaddrinfo() or in the kernel. > We'll make this more clear. > Something along the lines of "should not assume that implementations > implementa particular aspect of RFC 3484 in getaddrinfo" Okay. >> 7. [3rd paragraph of Section 5] >> [...] Thus when >> AI_PREFER_SRC_TMP is set , getaddrinfo() returns DA before DB and SA >> before SB likewise. >> >> I don't understand this sentence. What does 'and SA before SB >> likewise' mean? > Oops. I should say > "Then SA is used when communication to DA, thus the temporary > address gets preferred." Okay. >> 8. [page 12 (Section 5), just after the flag list] >> >> The above flags are ignored for the AF_INET address family as the >> address selection algorithm defined in section 5 of [1] only applies >> to the IPv6 addresses. >> >> This is not really true. RFC3484's destination address selection >> considers both IPv4 and IPv6 addresses (See Section 3.2 of >> RFC3484). > The statement was try when there was no DST flags. > So we can correct it to say "the above SRC flags ... as the source > address selection ..." Okay. >> 9. [first paragraph of Section 6] >> >> An application only needs to call getsockopt() prior calling >> setsockopt() if the application needs to be able to restore the >> socket back to the system default preferences. >> >> This seems odd. Shouldn't the application just be able to reset >> the rules to the default by specifying the all-0 flags? If not, >> why do we need the sets of two flags to begin with? > We need two flags per feature in order handle getaddrinfo() without > casting the default flags in concrete and not introducing some new > getaddrinfo_default_preferences() function. > To me it makes sense to have setsockopt work the same way conceptually > as getaddrinfo, so as long as getaddrinfo has two flags per feature, > then setsockopt should have the same. > With two flags then for any X/not-X pair, the semantics of setting > neither X or not-X is a no-op. > This implies that setting no flag at all must also be a no-op. I'm afraid you misunderstood my point. (Perhaps the additional question obscured the main point...) My main question is: In my understanding, if either of the flags of a particular rule is off, it means the system default should be used for that rule. For example, if 'flags = IPV6_PREFER_SRC_TMP', then the system default will apply for HOME vs COA, CGA vs NONCGA, etc. Is that correct? If so, when an application wants to make the rules revert to system default, it should be able to call setsockopt without setting any flag, shouldn't it? Or in other wise, it does not have to remember the old rule values by calling getsockopt beforehand for this purpose. >> 11. [second to last paragraph of Section 6] >> >> In order to allow different implementations to do different parts of >> address selection in getaddrinfo() and in the protocol stack, this >> specification requires that applications set the same flags when >> calling getaddrinfo() and when calling setsockopt(). For example,if >> the application sets IPV6_PREFER_SRC_COA flag, it must use >> AI_PREFER_SRC_COA flag when calling getaddrinfo(). If applications >> are not setting the same flags the behavior of the implementation is >> undefined. >> >> The phrase of "the same flags" (there are two occurrences) is not >> very accurate, since these are actually different, at least as macro >> names. > Correct. > The same flag at the semantic level, which correspond to different flags > for the two API parts. Okay. > But if we do a ai_preferences type field, then we can actually use the > same flag constants in both places (IPV6_PREFER_...) if we want to. This > would make the document shorter, and might be a simplication for the users. This is a different issue from the original point of comment #11. We may have to revisit that part when we reach a consensus on the ai_preferences (or whatever) thing. >> 12. [second bullet of Section 7] >> >> What would getsockopt() return for preference flags that are not >> supported in the system? (see also comment #5) > I think it makes sense to return the defaults per RFC 3484 and its > future updates. Thus IPV6_PREFER_SRC_PUBLIC would be set even if > temporary addresses are not implemented, and IPV6_PREFER_SRC_HOME set > even if mobile IPv6 is not implemented. > But this is more from a consistency reason than by necessity; returning > 0 for those flags would be ok as well assuming the application just > turns flags on and off. I'm happy as long as the spec is clear on this. >> 13. [third bullet of Section 7] >> >> If an implementation supports both stream and datagram sockets, it >> should implement the address preference mechanism API described in >> this document on types of sockets. >> >> I simply don't understand what this means...could you elaborate? >> (BTW: perhaps 'on types of sockets' should be 'based on types of >> sockets'? Even if so, I still don't understand what this means, >> though) > Oops - should say "on both types of sockets." Okay. >> 14. [second to last paragraph of Section 8] >> >> Other destination rules (#4-prefer home address; #7-prefer native >> interfaces) could have been applicable. But the problem is that the >> local system does not know whether a destination address is a tunnel- >> address for destination rule #7. It can only know for sure if the >> destination address is one of its own. (snip) >> Second, the >> implementation can syntacatically identify 'non-native' destinations >> in some cases (e.g., for 6to4 addresses). > Yes, but we have the preference table to handle that, without any > explicit rules on the nativeness of the transport. > (It might be a defect in 3484 that it has both the "prefer native > transport" and the 6to4 addresses in the table. What happens when they > conflict?) >> Third, at least in >> theory, the local implementation (even an application) could >> identify the outgoing interface for a given destination, and might >> be able to identify it's a tunneling interface. I do not >> necessarily require this API consider destination rule #7, but the >> "excuse" for not doing so should be accurate and convincing. > Sure, at the local end. > But the text in RFC 3484 can be interpreted to mean that by magic the > host can determine whether there is some IPv6 in IPv4 tunnel somewhere > between the host and a particular destination address. It can only do > that if 1) the destination syntactically indicates it does tunneling as > in the case of 6to4, or 2) the tunnel starts on the host itself. That's right. > What do you suggest we clarify to make this more accurate? Maybe we can simply say the sending host cannot *always* detect whether the destination is reached via tunnel. Additional explanation you mentioned above may also help, but I don't have a particular opinion on how much of the details we should provide here. >> 15. [Section 10] >> Do we really need (standardize) a separate function like >> inet6_is_srcaddr()? Perhaps I'm pretty dubious about this >> just because I'm dubious about the usefulness of the entire API in >> the first place, but I'd suggest confirming this point with other >> implementers, particularly with those who are interested in this >> API. > I guess the feedback we've gotten doesn't capture whether or not it is > necessary; only whether or not it is accurately described. > I don't recall anybody else arguing against this function. So I'm > interested in the opinion of others. > And since you're dubious about the entire API, I guess you could argue > we should remove all the other aspects of the API as well ;-) True. Anyway, if others believe this function is useful, then, again, I won't oppose to introducing the feature. >> 16. [last paragraph of page 20] >> The function returns true when srcaddr corresponds to a valid address >> in the node and that address type satisfies the preference flag(s). >> >> I don't think 'that address type satisfies the preference flag' is >> well-defined, although it is intuitively understandable. Please be >> more precise (c.f. comment #5). There may actually be subtle cases: >> e.g., what does it mean if I specify IPV6_PREFER_SRC_SMALLSCOPE as >> 'flags'? That is, 'small' is only meaningful when we are comparing >> multiple things, while this function takes only one address. I >> suspect this indicates we should reconsider the function design. > We tried to make it clear which flags can and can not be tested, but I > see the text is still not clear on this. The SCOPE aspects can not be > tested with inet6_is_srcaddr(), but can be tested with > INET6_IS_LINKLOCAL etc. Yes, and this leads me to think we should rather define other variants of IN6_IS_ADDR_xxx(). That is, in6_is_addr_home() in6_is_addr_careof() in6_is_addr_temporary() in6_is_addr_cga() etc. Or, it's probably better not to adhere to recycling the IPV6_PREFER_xxx "flags" for multiple purposes, and consider something like this: int in6_getaddrattr(struct sockaddr_in6 *addr, uint32_t *attrp); On success, this function returns 0 and sets the "attributes" of the address as bit-wise flags in '*attrp'. The flags are, for example, IN6_ADDRATTR_HOME IN6_ADDRATTR_COA (not sure if we need this in addition to HOME though) IN6_ADDRATTR_TMP IN6_ADDRATTR_CGA Then the following point will also be solved naturally: >> 17. [regarding inet6_is_srcaddr() in general] >> >> If we really need this function (see comment #15), I believe we >> should clearly separate error cases, i.e., we should not overload >> the 'false' return value. This might sound a matter of taste, but I >> believe it's a common and well-known practice. > OK. > There are two different ways to do this and I'd appreciate your opinion > on which one to choose. > 1. A function which returns 3 values: true, false, failure. E.g > int inet6_is_srcaddr(struct sockaddr_in6 *srcaddr, > uint32_t flags); > with 3 defined constans for the 3 possible return values. > A special case is true=1, false=0, fail=-1. > 2. A function which returns 0/-1 for ok/fail (like most library calls), > and has an extra result parameter for the true/false response. For example, > int inet6_is_srcaddr(struct sockaddr_in6 *srcaddr, > uint32_t flags, int *resultp); 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 ipv6-bounces@ietf.org Tue Oct 11 02:26:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPDb5-0000Af-73; Tue, 11 Oct 2005 02:26:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPDaz-0000AJ-SM; Tue, 11 Oct 2005 02:26:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02070; Tue, 11 Oct 2005 02:26:40 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPDl2-0005xA-CZ; Tue, 11 Oct 2005 02:37:05 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 10 Oct 2005 23:26:31 -0700 X-IronPort-AV: i="3.97,196,1125903600"; d="scan'208"; a="664927644:sNHT25638796" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9B6QP4u012752; Mon, 10 Oct 2005 23:26:28 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp234.cisco.com [10.61.64.234]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9B6bGP3005810; Mon, 10 Oct 2005 23:37:17 -0700 Message-ID: <434B5B0B.3070703@cisco.com> Date: Tue, 11 Oct 2005 08:26:19 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: Paul Jakma References: <20050923150609.GA14487@1-4-5.net> <20051005101940.V68899@mignon.ki.iif.hu> <434A5BC7.5030802@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=548; t=1129012642; x=1129444842; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20IPv6=20Multi-homing=20BOF=20at=20NANOG=2035| From:Eliot=20Lear=20| Date:Tue,=2011=20Oct=202005=2008=3A26=3A19=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=jAS7HqJNlJrqdYrLzWYhMWBQH4KB/3PP3+NZEYF5iaAq0VY8NO11hW9PFDJ252p71nuUcaUa woQ2e944vfP8YT8JocfmBJZ3F5ksvC2cIpfAmXJKm1pVcxSRZTVjhMvpmxhv8Cym8sug6th4/ik v2cHRxAU8sbnmM56cOd2WSGs= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: John Payne , Iljitsch van Beijnum , iab@ietf.org, David Meyer , ipv6@ietf.org, Brian E Carpenter , shim6@psg.com, Mohacsi Janos Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Paul, > We'll always need PI. The Independence part of PI is what people > /really/ want. They don't want multiple-PA (they can do that already > relatively easily). If people can not get globally-unique PI addresses > they will use private PI space and use address translation. I think enterprise administrators would be happy to go one level deeper under certain circumstances: - there is a selection algorithm that works properly - there is the ability to switch between the two without loss of L4 connections - it can be administered easily - etc. This was the a large part of why Randy Bush asked for draft-ietf-multi6-things-to-think-about.txt. Eliot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 11 03:46:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPEq5-00076V-S3; Tue, 11 Oct 2005 03:46:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPEq0-00075u-Ck; Tue, 11 Oct 2005 03:46:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05924; Tue, 11 Oct 2005 03:46:14 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPF01-0007y0-KB; Tue, 11 Oct 2005 03:56:40 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j9B7jtlH160972; Tue, 11 Oct 2005 07:45:55 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9B7jtHT171310; Tue, 11 Oct 2005 09:45:55 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j9B7jt6D006360; Tue, 11 Oct 2005 09:45:55 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j9B7jsB1006344; Tue, 11 Oct 2005 09:45:54 +0200 Received: from zurich.ibm.com (sig-9-146-217-189.de.ibm.com [9.146.217.189]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA75582; Tue, 11 Oct 2005 09:45:52 +0200 Message-ID: <434B6DAC.2040103@zurich.ibm.com> Date: Tue, 11 Oct 2005 09:45:48 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Paul Jakma References: <20050923150609.GA14487@1-4-5.net> <20051005101940.V68899@mignon.ki.iif.hu> <434A5BC7.5030802@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: John Payne , Iljitsch van Beijnum , ipv6@ietf.org, David Meyer , iab@ietf.org, shim6@psg.com, Mohacsi Janos Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Paul Jakma wrote: > On Mon, 10 Oct 2005, Brian E Carpenter wrote: > >> The point of shim6 is to *avoid* the need for PI-like space for >> multihomed sites, so that we don't do to the IPv6 BGP table what >> multihoming is doing to the IPv4 BGP table. We need IPv6 to scale >> vastly more than IPv4, so this is essential. > > > The problem isn't PI addressing, it's advertising tiny prefixes in the > routing table. PI addressing *without* global-routing-table visibility > *would* obviously scale for routing. We just don't have a way to do this. > >> I hope the proposed BOF will make this clearer. I personally think >> that shim6 will be really cool for ISPs, although as Geoff says it >> will take a while to deploy and during that time we'll need a PI-like >> approach. > > > We'll always need PI. The Independence part of PI is what people > /really/ want. They don't want multiple-PA (they can do that already > relatively easily). If people can not get globally-unique PI addresses > they will use private PI space and use address translation. Paul, my belief system is different, which is why I've been vigorously supporting ULAs, shim6 and the NAP draft. My belief is that if we provide a solution set that that avoids the need for NAT with its myriad disadvantages, enlightened self-interest will prevail. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 13 03:55:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPxwV-0002qW-0H; Thu, 13 Oct 2005 03:55:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPxwS-0002o9-8L for ipv6@megatron.ietf.org; Thu, 13 Oct 2005 03:55:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00771 for ; Thu, 13 Oct 2005 03:55:52 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPy6v-0002mF-Ar for ipv6@ietf.org; Thu, 13 Oct 2005 04:06:45 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOA00KIXGR90E@szxga03-in.huawei.com> for ipv6@ietf.org; Thu, 13 Oct 2005 15:57:09 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOA00JQCGR95Y@szxga03-in.huawei.com> for ipv6@ietf.org; Thu, 13 Oct 2005 15:57:09 +0800 (CST) Received: from huaweigtausbkb ([10.110.102.85]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOA00EURGXYLN@szxml02-in.huawei.com> for ipv6@ietf.org; Thu, 13 Oct 2005 16:01:11 +0800 (CST) Date: Thu, 13 Oct 2005 15:53:39 +0800 From: Syed Ajim Hussain To: ipv6@ietf.org Message-id: <001c01c5cfcb$3a4d1c90$55666e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Subject: IPV6 AAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1005193397==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1005193397== Content-type: multipart/alternative; boundary="Boundary_(ID_acql/l+TpU5zfez189fduQ)" This is a multi-part message in MIME format. --Boundary_(ID_acql/l+TpU5zfez189fduQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi All I have a question. If you implement RFC 3162 ( RADIUS for IPv6) in NAS , then how IPv6 prefix pools maintained Locally or In a RADIUS server, is useful for providing PPP based services to Clients sitting in access site, when no DHCP6 services are available. Can PPP services provided by NAS use AAA IPv6 prefix list configured locally or in a RADIUS server? Network diagram: RADIUS | | -------------------- ----------- ---------- | User/Host | -----------------| CPE | --------------------ATM/DSLAM--------- | NAS |----------- -------------------- ----------- ---------- ( ppp based Services , No DHCP ) With Regards Syed Ajim Hussain --Boundary_(ID_acql/l+TpU5zfez189fduQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi All

        I have a question.  If you implement RFC 3162 ( RADIUS for IPv6)  in NAS ,   then  how IPv6 prefix pools maintained

        Locally or In a RADIUS server, is useful for providing PPP based services to Clients sitting in access site,   when no

        DHCP6 services are available.   

 

         Can PPP services provided by NAS use AAA IPv6 prefix list configured locally or in a RADIUS server?

 

 

       Network diagram:    

                                                                                                                                      RADIUS

                                                                                                                                         |  

                                                                                                                                         |

                                  --------------------                    -----------                                                  ---------- 

                                  |  User/Host  |  -----------------|   CPE | --------------------ATM/DSLAM--------- | NAS |-----------

                                  --------------------                    -----------                                                   ----------

                                                                                                                                        

                                                                                                                                 ( ppp based Services , No DHCP )  

 

With Regards

Syed Ajim Hussain

 

        

--Boundary_(ID_acql/l+TpU5zfez189fduQ)-- --===============1005193397== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1005193397==-- From ipv6-bounces@ietf.org Thu Oct 13 16:38:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9qQ-0000K6-Kk; Thu, 13 Oct 2005 16:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9qO-0000Ih-9V for ipv6@megatron.ietf.org; Thu, 13 Oct 2005 16:38:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15964 for ; Thu, 13 Oct 2005 16:38:24 -0400 (EDT) Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQA0x-0000K0-2Z for ipv6@ietf.org; Thu, 13 Oct 2005 16:49:24 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id QAA03748; Thu, 13 Oct 2005 16:38:16 -0400 (EDT) Date: Thu, 13 Oct 2005 16:38:16 -0400 (EDT) From: Dan Lanciani Message-Id: <200510132038.QAA03748@ss10.danlan.com> To: ipv6@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Paul Jakma wrote: |On Mon, 10 Oct 2005, Brian E Carpenter wrote: | |> The point of shim6 is to *avoid* the need for PI-like space for |> multihomed sites, so that we don't do to the IPv6 BGP table what |> multihoming is doing to the IPv4 BGP table. We need IPv6 to scale |> vastly more than IPv4, so this is essential. | |The problem isn't PI addressing, it's advertising tiny prefixes in |the routing table. PI addressing *without* global-routing-table |visibility *would* obviously scale for routing. We just don't have a |way to do this. We might have a way to do it by fully separating locators and identifiers, but it would require pervasive changes to existing implementations and a new economic model for address allocation. Shim6 leverages a partial separation of locators and identifiers to provide a solution to a somewhat limited problem space while still requiring pervasive changes to existing implementations, but it does preserve the economic model. My concern is that adoption of shim6 will be an impediment to development of a more general locator/identifier separation solution both because the mapping functions might clash and because many will object to changing existing implementations a *second* time for what might be perceived to be only a marginal gain for users (and possibly even a loss for providers). |> I hope the proposed BOF will make this clearer. I personally think |> that shim6 will be really cool for ISPs, although as Geoff says it |> will take a while to deploy and during that time we'll need a |> PI-like approach. | |We'll always need PI. The Independence part of PI is what people |/really/ want. They don't want multiple-PA (they can do that already |relatively easily). If people can not get globally-unique PI |addresses they will use private PI space and use address translation. Indeed. NAT is simply a response to the economic models of address allocation. Any technical "solutions" that perpetuate those models will also perpetuate the demand for NAT. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 14 07:44:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQNzG-00009C-V3; Fri, 14 Oct 2005 07:44:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQNzF-000097-4n for ipv6@megatron.ietf.org; Fri, 14 Oct 2005 07:44:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04143 for ; Fri, 14 Oct 2005 07:44:26 -0400 (EDT) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQO9u-0000VC-3S for ipv6@ietf.org; Fri, 14 Oct 2005 07:55:35 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j9EBikoj236618 for ; Fri, 14 Oct 2005 12:44:46 +0100 Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9EBiKk6240334 for ; Fri, 14 Oct 2005 12:44:20 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j9EBiJtL017132 for ; Fri, 14 Oct 2005 12:44:19 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j9EBiJeu017121; Fri, 14 Oct 2005 12:44:19 +0100 Received: from zurich.ibm.com (sig-9-145-135-178.de.ibm.com [9.145.135.178]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA30488; Fri, 14 Oct 2005 13:44:18 +0200 Message-ID: <434F9A11.3020700@zurich.ibm.com> Date: Fri, 14 Oct 2005 13:44:17 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Dan Lanciani References: <200510132038.QAA03748@ss10.danlan.com> In-Reply-To: <200510132038.QAA03748@ss10.danlan.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org ... > My concern is that adoption of shim6 will be an impediment to development > of a more general locator/identifier separation solution both because the > mapping functions might clash and because many will object to changing > existing implementations a *second* time for what might be perceived to be > only a marginal gain for users (and possibly even a loss for providers). I believe that a true id/loc split is a much more fundamental change than IPv4 to IPv6 and on a completely different scale of cost and decade. ... > > Indeed. NAT is simply a response to the economic models of address > allocation. Any technical "solutions" that perpetuate those models > will also perpetuate the demand for NAT. The smallest allocation granularity for IPv6 is supposed to be a prefix, not an address, for that reason. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 14 16:55:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWam-0005yU-Tk; Fri, 14 Oct 2005 16:55:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWak-0005xw-K3 for ipv6@megatron.ietf.org; Fri, 14 Oct 2005 16:55:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24161 for ; Fri, 14 Oct 2005 16:55:46 -0400 (EDT) Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWlV-0005xS-76 for ipv6@ietf.org; Fri, 14 Oct 2005 17:07:00 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id QAA14199; Fri, 14 Oct 2005 16:55:39 -0400 (EDT) Date: Fri, 14 Oct 2005 16:55:39 -0400 (EDT) From: Dan Lanciani Message-Id: <200510142055.QAA14199@ss10.danlan.com> To: ipv6@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Brian E Carpenter wrote: | (I wrote) |> My concern is that adoption of shim6 will be an impediment to development |> of a more general locator/identifier separation solution both because the |> mapping functions might clash and because many will object to changing |> existing implementations a *second* time for what might be perceived to be |> only a marginal gain for users (and possibly even a loss for providers). | |I believe that a true id/loc split is a much more fundamental change |than IPv4 to IPv6 and on a completely different scale of cost and decade. That may or may not be true, but it isn't the relevant comparison. The first comparison I would make is between the difficulty of retrofitting a partial separation of identifier and locator in the form of shim6 and the difficulty of doing it right instead. The disruption to existing code would appear to be on a similar scale as either approach would involve a relatively thin mapping layer. That leaves the difficulty of solving the underlying problem. I happen to believe that solving the general problem is not significantly harder than solving the limited one via shim6. I also believe that shim6 (by mixing locator and identifier usage for the same address) may raise some issues of its own that would not exist in the general solution. The second relevant comparison is the difficulty of doing it right at some later time in a world where shim6 has been deployed versus the difficulty of doing it right in a world without shim6. My concern is that the former is far greater than the latter, i.e., we probably get at most one shot at this. At the very least I would like to see the shim6 layer designed to support a more general separation of locator and identifier in the future, even if we decide that we don't yet know how to build the required mapping infrastructure. |> Indeed. NAT is simply a response to the economic models of address |> allocation. Any technical "solutions" that perpetuate those models |> will also perpetuate the demand for NAT. | |The smallest allocation granularity for IPv6 is supposed to be a prefix, |not an address, for that reason. Unfortunately, that does not address most of the problems that drive the demand for NAT. The current economic model is: 1) Pay for addresses 2) Pay more for stable addresses 3) Pay much more for portable stable addresses With more address space available, IPv6 may help with (1) if providers play along. But as we have recently seen, customer prefix lengths are already under attack by perfectly reasonable-sounding conservation arguments. A need to conserve always justifies a need to charge. IPv6 does nothing good for (2). In fact it makes the situation worse by making renumbering "easier" without making it less disruptive. Assuming I understand the protocol correctly, shim6 increases the premium on stable addresses since they will be necessary for its version of PA multi-homing. (Shim6 seems to let you build stable quasi-identifiers on top of two or more stable locators. I would prefer a solution that lets you build stable identifiers on top of one or more unstable locator(s).) IPv6 itself does nothing good for (3). PI allocations may well be available to some set of entities for a while to ease the transition, but that just brings us back to routing table concerns. There is no general PI solution on the horizon, and shim6 may make such a solution less likely to appear. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 14 19:11:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQYiV-0007UK-Iz; Fri, 14 Oct 2005 19:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQYiS-0007RJ-Dg for ipv6@megatron.ietf.org; Fri, 14 Oct 2005 19:11:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02985 for ; Fri, 14 Oct 2005 19:11:51 -0400 (EDT) Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQYtF-0001bd-9N for ipv6@ietf.org; Fri, 14 Oct 2005 19:23:07 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id TAA15015; Fri, 14 Oct 2005 19:11:53 -0400 (EDT) Date: Fri, 14 Oct 2005 19:11:53 -0400 (EDT) From: Dan Lanciani Message-Id: <200510142311.TAA15015@ss10.danlan.com> To: ipv6@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org "Jason Schiller (schiller@uu.net)" wrote: |On Fri, 14 Oct 2005, Dan Lanciani wrote: | |[snip] |> |> IPv6 itself does nothing good for (3). PI allocations may well be available |> to some set of entities for a while to ease the transition, but that just |> brings us back to routing table concerns. There is no general PI solution |> on the horizon, and shim6 may make such a solution less likely to appear. |> |> Dan Lanciani |> ddl@danlan.*com |> |Dan, |You clearly state that PI allocations do not help the concern that |allowing de-aggregates in the IPv6 routing table could easily scale beyond |current hardware limitations. I think PI allocations *create* the scaling concern. |I think this is what you are referring |to when you say "There is no general PI solution on the horizon..." Certainly I'd settle for a PI solution that does not involve putting the PIs in a central routing table. If (as seems to be the case) we can't even discuss distributed routing tables that appears to require identifier/locator separation. |But I want to point out that ARIN does have an IPv6 PI policy proposal on |the table for the end of October. Yes, that's what I meant about PI being available to some entities to ease the transition and preserve the status quo. For a "general solution" I'd expect availability to anyone who wants PI, and at trivial cost. (Cost includes cost of getting the prefix advertised.) |This policy does not provide a solution |to routing table growth (possibly people believe everyone's hardware will |be capable when the time comes that we need it). No, people believe that PI space will be confined to large corporations who can afford the cost. Remember, we've been through this before with IPv4. Provider-allocated aggregated addressing was supposed to be a temporary hack while the hardware caught up with routing table size. The hardware caught up a long time ago but we never went back to generally-available PI addresses. Instead the nature of the problem somehow changed from storage space to computation or bandwidth or something else too nebulous to ever be solved by hardware. |If the ARIN IPv6 PI policy gets accepted and widely implemented that PI |addresses are more likely to be leveraged by large commercial networks who |are currently doing traditional IPv4 multi-homing and traffic engineering |instead of shim6. This may greatly decrease the support for and use of a |shim6 solution. Yes, though it all depends on just how available those PI allocations are. |It seems to me that if PI has wide spread adoption then everyone will have |to commit to solving the large routing table problem in hardware. If we |have already decided to solve the large routing table size in hardware |then why do we need shim6? I'm not at all convinced that we need shim6 (or even that it is desirable), but as far as I know nobody has committed to solving the large routing table problem in hardware or otherwise. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Oct 15 05:35:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQiRb-0008Se-9y; Sat, 15 Oct 2005 05:35:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQiRY-0008Rc-FH for ipv6@megatron.ietf.org; Sat, 15 Oct 2005 05:35:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00502 for ; Sat, 15 Oct 2005 05:35:03 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQicQ-0007Hm-4Y for ipv6@ietf.org; Sat, 15 Oct 2005 05:46:24 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 15 Oct 2005 02:34:57 -0700 X-IronPort-AV: i="3.97,216,1125903600"; d="scan'208"; a="666426084:sNHT25952352" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9F9Ysub003378; Sat, 15 Oct 2005 02:34:55 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4394.cisco.com [10.61.81.41]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9F9jYoP014285; Sat, 15 Oct 2005 02:45:35 -0700 Message-ID: <4350CD3C.9040401@cisco.com> Date: Sat, 15 Oct 2005 11:34:52 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: Dan Lanciani References: <200510142055.QAA14199@ss10.danlan.com> In-Reply-To: <200510142055.QAA14199@ss10.danlan.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1543; t=1129369536; x=1129801736; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20IPv6=20Multi-homing=20BOF=20at=20NANOG=2035| From:Eliot=20Lear=20| Date:Sat,=2015=20Oct=202005=2011=3A34=3A52=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=NtHdhGEMgaHZNXiPjGKUnqNBYjK0IH7sB6PPm5qdMtuvY0cqSNt/eiFjrA4XppKcRtlhAnGW YaSlDj/PUSZ9Ne/rLpToeBEihQVid7h5qk4gLBnxDXZE3A8mXwZA/4fiK3EibcRp6KPGQj3Xrzh BZNXpKO+AGCHtYivJpD5AwQA= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, > Unfortunately, that does not address most of the problems that drive the > demand for NAT. The current economic model is: > > 1) Pay for addresses > 2) Pay more for stable addresses > 3) Pay much more for portable stable addresses > > With more address space available, IPv6 may help with (1) if providers play > along. But as we have recently seen, customer prefix lengths are already > under attack by perfectly reasonable-sounding conservation arguments. A > need to conserve always justifies a need to charge. The IETF cannot legislate prefix lengths, but the argument behind conservation beyond /48 would be utterly silly and demonstrates a "revenue opportunity", plain and simple. > > IPv6 does nothing good for (2). In fact it makes the situation worse by > making renumbering "easier" without making it less disruptive. Assuming I > understand the protocol correctly, shim6 increases the premium on stable > addresses since they will be necessary for its version of PA multi-homing. > (Shim6 seems to let you build stable quasi-identifiers on top of two or > more stable locators. I would prefer a solution that lets you build stable > identifiers on top of one or more unstable locator(s).) This is a matter of timescale. Prefixes should be expected to change. In fact, SHIM6 should be able to provide equivalent of SCTP's ADD-IP to *devalue* prefix stability. > > IPv6 itself does nothing good for (3). PI allocations may well be available > to some set of entities for a while to ease the transition, but that just > brings us back to routing table concerns. There is no general PI solution > on the horizon, and shim6 may make such a solution less likely to appear. The whole point of SHIM6 from my point of view is quite the opposite by providing a means to advertise access via other prefixes. So could you please justify your above statement? Eliot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Oct 15 17:11:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQtJh-0001jj-7d; Sat, 15 Oct 2005 17:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQtJf-0001jY-DX for ipv6@megatron.ietf.org; Sat, 15 Oct 2005 17:11:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27810 for ; Sat, 15 Oct 2005 17:11:36 -0400 (EDT) Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQtUe-00055g-7o for ipv6@ietf.org; Sat, 15 Oct 2005 17:23:05 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id RAA23287; Sat, 15 Oct 2005 17:11:37 -0400 (EDT) Date: Sat, 15 Oct 2005 17:11:37 -0400 (EDT) From: Dan Lanciani Message-Id: <200510152111.RAA23287@ss10.danlan.com> To: ipv6@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Eliot Lear wrote: | (I wrote) |> Unfortunately, that does not address most of the problems that drive the |> demand for NAT. The current economic model is: |> |> 1) Pay for addresses |> 2) Pay more for stable addresses |> 3) Pay much more for portable stable addresses |> |> With more address space available, IPv6 may help with (1) if providers play |> along. But as we have recently seen, customer prefix lengths are already |> under attack by perfectly reasonable-sounding conservation arguments. A |> need to conserve always justifies a need to charge. | |The IETF cannot legislate prefix lengths, but the argument behind |conservation beyond /48 would be utterly silly and demonstrates a |"revenue opportunity", plain and simple. I'm not sure what you mean by ``would be.'' The argument has already been made. See, e.g., http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt In any case, I agree completely that the IETF cannot legislate prefix lengths and that providers can still find "revenue opportunity" in address rental. That was exactly the point I was trying to make in responding to the previous comment which you snipped (and which has nothing to do with shim6 per se): Brian E Carpenter wrote: [...] |The smallest allocation granularity for IPv6 is supposed to be a prefix, |not an address, for that reason. (end quote) |> IPv6 does nothing good for (2). In fact it makes the situation worse by |> making renumbering "easier" without making it less disruptive. Assuming I |> understand the protocol correctly, shim6 increases the premium on stable |> addresses since they will be necessary for its version of PA multi-homing. |> (Shim6 seems to let you build stable quasi-identifiers on top of two or |> more stable locators. I would prefer a solution that lets you build stable |> identifiers on top of one or more unstable locator(s).) | |This is a matter of timescale. Prefixes should be expected to change. Exactly. And thus you have another "revenue opportunity" (I like that phrase): charge more for stable addresses. |In fact, SHIM6 should be able to provide equivalent of SCTP's ADD-IP to |*devalue* prefix stability. Shim6 should be able to do a lot of things. Since it requires insertion of a mapping layer into all existing stacks that are to participate, its deployment already represents a retrofit on the same level as would a more general solution. But shim6 is not (at the moment) a general solution; it's a multi-homing solution with some constraints on the underlying PA addresses. |> IPv6 itself does nothing good for (3). PI allocations may well be available |> to some set of entities for a while to ease the transition, but that just |> brings us back to routing table concerns. There is no general PI solution |> on the horizon, and shim6 may make such a solution less likely to appear. | |The whole point of SHIM6 from my point of view is quite the opposite by |providing a means to advertise access via other prefixes. Except that shim6 is not a general PI solution. It is only a multi-homing quasi-solution. As currently proposed it does nothing to replace the other desirable attributes of PI addresses/identifiers. I would be delighted with a shim6-like solution that allows stable identifiers to be built atop one or more unstable locators. In fact, I've proposed such approaches on several occasions over the years. |So could you |please justify your above statement? I thought I made this pretty clear in the portions of my note which you snipped, but I'll try to run through it one more time. -Scalable PI space without distributed routing tables probably requires a full identifier/locator split. -An identifier/locator split almost certainly requires changes to existing code to accommodate a mapping layer. -Shim6 provides a replacement for one useful attribute of PI space (multi- homing) by leveraging a partial identifier/locator split. -Shim6 requires changes to existing code to accommodate a mapping layer. If shim6 is deployed then one of the problems caused by the lack of a general PI solution will be "solved" thus reducing the impetus to find that general solution. Deployment of shim6 requires changing a lot of existing code. Convincing the world to change all the code a *second* time is going to be a much harder sell. Implementing a general solution in the presense of deployed shim6 would itself be more difficult because of the interaction of two very similar mapping layers. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 16 00:00:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQzhc-0005pF-W5; Sun, 16 Oct 2005 00:00:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQzhb-0005pA-Aw for ipv6@megatron.ietf.org; Sun, 16 Oct 2005 00:00:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09694 for ; Sun, 16 Oct 2005 00:00:44 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQzsd-0003Yy-KJ for ipv6@ietf.org; Sun, 16 Oct 2005 00:12:16 -0400 Received: from localhost (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id A86126DE for ; Sun, 16 Oct 2005 00:00:29 -0400 (EDT) Received: from cyteen.hactrn.net ([127.0.0.1]) by localhost (cyteen.hactrn.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31857-08 for ; Sun, 16 Oct 2005 00:00:23 -0400 (EDT) Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 303FD6DB for ; Sun, 16 Oct 2005 00:00:23 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 16 Oct 2005 00:00:23 -0400 Message-Id: <20051016040023.303FD6DB@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 23.53% | 4 | 20.25% | 24478 | ipng-incoming@danlan.com 11.76% | 2 | 21.29% | 25736 | jinmei@isl.rdc.toshiba.co.jp 17.65% | 3 | 13.66% | 16511 | brc@zurich.ibm.com 11.76% | 2 | 8.84% | 10678 | lear@cisco.com 5.88% | 1 | 12.73% | 15388 | syedah@huawei.com 5.88% | 1 | 7.99% | 9659 | jason.schiller@mci.com 5.88% | 1 | 4.29% | 5179 | jeroen@unfix.org 5.88% | 1 | 4.13% | 4991 | sangsu@gmail.com 5.88% | 1 | 3.83% | 4623 | paul@clubi.ie 5.88% | 1 | 2.99% | 3615 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 17 |100.00% | 120858 | 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 ipv6-bounces@ietf.org Sun Oct 16 02:04:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER1dE-00040n-2z; Sun, 16 Oct 2005 02:04:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER1d7-00040f-Sr for ipv6@megatron.ietf.org; Sun, 16 Oct 2005 02:04:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12971 for ; Sun, 16 Oct 2005 02:04:15 -0400 (EDT) Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ER1o9-0005Tn-4M for ipv6@ietf.org; Sun, 16 Oct 2005 02:15:48 -0400 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id j9G50Bt8007889; Sat, 15 Oct 2005 22:00:16 -0700 (PDT) (envelope-from drc@virtualized.org) In-Reply-To: <4350CD3C.9040401@cisco.com> References: <200510142055.QAA14199@ss10.danlan.com> <4350CD3C.9040401@cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Conrad Date: Sat, 15 Oct 2005 23:03:46 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Dan Lanciani Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Eliot, On Oct 15, 2005, at 2:34 AM, Eliot Lear wrote: > The IETF cannot legislate prefix lengths, but the argument behind > conservation beyond /48 would be utterly silly and demonstrates a > "revenue opportunity", plain and simple. When multiple /19s and /20s have been allocated and there are rumors of much shorter prefixes which can be justified under the current rules, I'm not so sure discussions about conservation can be classified as "utterly silly". > This is a matter of timescale. Prefixes should be expected to > change. In fact, SHIM6 should be able to provide equivalent of > SCTP's ADD-IP to *devalue* prefix stability. Unfortunately, since applications are aware of IP address structures (both v4 and, sadly, v6), you'll need to rewrite all applications, libraries, and kernels to tolerate changes in those addresses at arbitrary times or face broken connections or misdirected packets. An apparent base assumption in IPv4 was that addresses were stable over a "session" (be it connection-oriented or connectionless). This assumption permeates every IP stack. Given DNS root server IP addresses retired over 10 years ago still get 30 queries per second, I doubt prefixes can be expected to change by all applications in our lifetimes. Rgds, -drc -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 16 04:00:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER3Rl-0000KY-Le; Sun, 16 Oct 2005 04:00:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER3Rj-0000JL-Ng for ipv6@megatron.ietf.org; Sun, 16 Oct 2005 04:00:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16882 for ; Sun, 16 Oct 2005 04:00:37 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ER3cl-0007sb-69 for ipv6@ietf.org; Sun, 16 Oct 2005 04:12:08 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 16 Oct 2005 01:00:30 -0700 X-IronPort-AV: i="3.97,218,1125903600"; d="scan'208"; a="352688379:sNHT24473260" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9G80SJh010957; Sun, 16 Oct 2005 01:00:28 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp52.cisco.com [10.61.64.52]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9G8B44e017353; Sun, 16 Oct 2005 01:11:04 -0700 Message-ID: <4352089A.5090404@cisco.com> Date: Sun, 16 Oct 2005 10:00:26 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: David Conrad References: <200510142055.QAA14199@ss10.danlan.com> <4350CD3C.9040401@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1481; t=1129450265; x=1129882465; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20IPv6=20Multi-homing=20BOF=20at=20NANOG=2035| From:Eliot=20Lear=20| Date:Sun,=2016=20Oct=202005=2010=3A00=3A26=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=pUGE0PmQk84+d2wZVjFXXByly/pKopJS6VEOkoBrmxbm1uxvMBEn7JDXLDsXP5Bxd34v5IXk uVOd3aM4xk3VKGsmimWfDcVLD21KMDtl5UhU/tm6n3FIgp7LU3TlMKD6lr6tK2n/qJnPMOaAA4i xS9r3Ycyk38S1/gGfTXV719Q= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Dan Lanciani Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org David Conrad wrote: > On Oct 15, 2005, at 2:34 AM, Eliot Lear wrote: >> The IETF cannot legislate prefix lengths, but the argument behind >> conservation beyond /48 would be utterly silly and demonstrates a >> "revenue opportunity", plain and simple. > > When multiple /19s and /20s have been allocated and there are rumors of > much shorter prefixes which can be justified under the current rules, > I'm not so sure discussions about conservation can be classified as > "utterly silly". Did you see the words "beyond /48" somewhere above, David? I'm not saying we should be blowing allocations like /19s and /20s (although I would be interested in data on that and the ). > >> This is a matter of timescale. Prefixes should be expected to change. >> In fact, SHIM6 should be able to provide equivalent of SCTP's ADD-IP >> to *devalue* prefix stability. > > Unfortunately, since applications are aware of IP address structures > (both v4 and, sadly, v6), you'll need to rewrite all applications, > libraries, and kernels to tolerate changes in those addresses at > arbitrary times or face broken connections or misdirected packets. An > apparent base assumption in IPv4 was that addresses were stable over a > "session" (be it connection-oriented or connectionless). This > assumption permeates every IP stack. Given DNS root server IP addresses > retired over 10 years ago still get 30 queries per second, I doubt > prefixes can be expected to change by all applications in our lifetimes. This is the purpose of SHIM6. It is not something meant to happen overnight. And it is not something that is meant as a forklift upgrade. And I will be you dollars to doughnuts that those 30q/s are not harming any application that anyone cares about (other than generating unnecessary load). Eliot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 16 05:30:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER4qP-0000Rd-Ug; Sun, 16 Oct 2005 05:30:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER4qN-0000RV-RM for ipv6@megatron.ietf.org; Sun, 16 Oct 2005 05:30:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21295 for ; Sun, 16 Oct 2005 05:30:08 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ER51U-0005x4-1x for ipv6@ietf.org; Sun, 16 Oct 2005 05:41:44 -0400 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 j9G9TxT08977; Sun, 16 Oct 2005 11:29:59 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9G9Tr56013786; Sun, 16 Oct 2005 11:29:59 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510160929.j9G9Tr56013786@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Syed Ajim Hussain In-reply-to: Your message of Thu, 13 Oct 2005 15:53:39 +0800. <001c01c5cfcb$3a4d1c90$55666e0a@china.huawei.com> Date: Sun, 16 Oct 2005 11:29:53 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ipv6@ietf.org Subject: Re: IPV6 AAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In RADIUS you have Framed-IPv6-Prefix for the PPP link itself and Delegated-IPv6-Prefix (defined in an I-D) for prefix delegation but PPP can't delegate a prefix, you should use DHCPv6 for this job. Regards Francis.Dupont@enst-bretagne.fr PS: the DHCPv6 Relay RADIUS Attribute Option can bind RADIUS on the NAS with the DHCPv6 services when needed. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 16 07:17:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER6Wa-0001wS-07; Sun, 16 Oct 2005 07:17:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXXC-0004Wr-GS for ipv6@megatron.ietf.org; Fri, 14 Oct 2005 17:56:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29163 for ; Fri, 14 Oct 2005 17:56:09 -0400 (EDT) Received: from pmesmtp02.wcom.com ([199.249.20.2] helo=pmesmtp02.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQXhy-0008CT-PF for ipv6@ietf.org; Fri, 14 Oct 2005 18:07:24 -0400 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0IOD00KH2E99H1@firewall.mci.com> for ipv6@ietf.org; Fri, 14 Oct 2005 21:55:57 +0000 (GMT) Received: from imr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQtkfv18519; Fri, 14 Oct 2005 21:55:56 +0000 (GMT) Received: from meno.corp.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: meno.corp.us.uu.net [153.39.146.71]) id j9ELttiP005719; Fri, 14 Oct 2005 21:55:55 +0000 (GMT) Received: from localhost by meno.corp.us.uu.net with ESMTP (peer crosschecked as: schiller@localhost) id QQtkfv00879; Fri, 14 Oct 2005 17:55:54 -0400 (EDT) Date: Fri, 14 Oct 2005 17:55:54 -0400 (EDT) From: "Jason Schiller (schiller@uu.net)" In-reply-to: <200510142055.QAA14199@ss10.danlan.com> X-Sender: schiller@meno.corp.us.uu.net To: Dan Lanciani Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 1.6 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Sun, 16 Oct 2005 07:17:54 -0400 Cc: ipv6@ietf.org Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Fri, 14 Oct 2005, Dan Lanciani wrote: > Date: Fri, 14 Oct 2005 16:55:39 -0400 (EDT) > From: Dan Lanciani > To: ipv6@ietf.org > Subject: Re: IPv6 Multi-homing BOF at NANOG 35 > [snip] > > IPv6 itself does nothing good for (3). PI allocations may well be available > to some set of entities for a while to ease the transition, but that just > brings us back to routing table concerns. There is no general PI solution > on the horizon, and shim6 may make such a solution less likely to appear. > > Dan Lanciani > ddl@danlan.*com > Dan, You clearly state that PI allocations do not help the concern that allowing de-aggregates in the IPv6 routing table could easily scale beyond current hardware limitations. I think this is what you are referring to when you say "There is no general PI solution on the horizon..." But I want to point out that ARIN does have an IPv6 PI policy proposal on the table for the end of October. This policy does not provide a solution to routing table growth (possibly people believe everyone's hardware will be capable when the time comes that we need it). If the ARIN IPv6 PI policy gets accepted and widely implemented that PI addresses are more likely to be leveraged by large commercial networks who are currently doing traditional IPv4 multi-homing and traffic engineering instead of shim6. This may greatly decrease the support for and use of a shim6 solution. It seems to me that if PI has wide spread adoption then everyone will have to commit to solving the large routing table problem in hardware. If we have already decided to solve the large routing table size in hardware then why do we need shim6? ___Jason -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 16 09:35:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER8fo-0005xS-Am; Sun, 16 Oct 2005 09:35:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER8fm-0005xN-BF for ipv6@megatron.ietf.org; Sun, 16 Oct 2005 09:35:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02188 for ; Sun, 16 Oct 2005 09:35:27 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ER8qt-00032B-ED for ipv6@ietf.org; Sun, 16 Oct 2005 09:47:05 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9GDXQFh022420; Sun, 16 Oct 2005 16:33:27 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Oct 2005 16:35:26 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Oct 2005 16:35:27 +0300 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 16 Oct 2005 16:35:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Message-ID: <1AA39B75171A7144A73216AED1D7478D012892D8@esebe100.NOE.Nokia.com> Thread-Topic: IPV6 AAA Thread-Index: AcXSNJTcdGSVKnWqTaqSRW+EeTCC/AAIdsGg To: , X-OriginalArrivalTime: 16 Oct 2005 13:35:27.0975 (UTC) FILETIME=[7872FF70:01C5D256] X-Spam-Score: 0.9 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: IPV6 AAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I agree with Francis on this. John >In RADIUS you have Framed-IPv6-Prefix for the PPP link itself=20 >and Delegated-IPv6-Prefix (defined in an I-D) for prefix=20 >delegation but PPP can't delegate a prefix, you should use=20 >DHCPv6 for this job. > >Regards > >Francis.Dupont@enst-bretagne.fr > >PS: the DHCPv6 Relay RADIUS Attribute Option can bind RADIUS=20 >on the NAS with the DHCPv6 services when needed. > >-------------------------------------------------------------------- >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 ipv6-bounces@ietf.org Sun Oct 16 09:53:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER8xZ-0002BJ-CQ; Sun, 16 Oct 2005 09:53:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER8xX-00026J-05 for ipv6@megatron.ietf.org; Sun, 16 Oct 2005 09:53:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02894 for ; Sun, 16 Oct 2005 09:53:43 -0400 (EDT) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ER98a-0003Qt-Cc for ipv6@ietf.org; Sun, 16 Oct 2005 10:05:20 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j9GDs6oj185692 for ; Sun, 16 Oct 2005 14:54:06 +0100 Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9GDrdcF210016 for ; Sun, 16 Oct 2005 14:53:39 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j9GDrdFG029982 for ; Sun, 16 Oct 2005 14:53:39 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j9GDrcr1029979; Sun, 16 Oct 2005 14:53:38 +0100 Received: from zurich.ibm.com (sig-9-145-131-210.de.ibm.com [9.145.131.210]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA51598; Sun, 16 Oct 2005 15:53:37 +0200 Message-ID: <43525B5E.3030900@zurich.ibm.com> Date: Sun, 16 Oct 2005 15:53:34 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: David Conrad References: <200510142055.QAA14199@ss10.danlan.com> <4350CD3C.9040401@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Dan Lanciani , Eliot Lear Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org David Conrad wrote: > Eliot, > > On Oct 15, 2005, at 2:34 AM, Eliot Lear wrote: > >> The IETF cannot legislate prefix lengths, but the argument behind >> conservation beyond /48 would be utterly silly and demonstrates a >> "revenue opportunity", plain and simple. > > > When multiple /19s and /20s have been allocated and there are rumors of > much shorter prefixes which can be justified under the current rules, > I'm not so sure discussions about conservation can be classified as > "utterly silly". > >> This is a matter of timescale. Prefixes should be expected to >> change. In fact, SHIM6 should be able to provide equivalent of SCTP's >> ADD-IP to *devalue* prefix stability. > > > Unfortunately, since applications are aware of IP address structures > (both v4 and, sadly, v6), you'll need to rewrite all applications, > libraries, and kernels to tolerate changes in those addresses at > arbitrary times or face broken connections or misdirected packets. An > apparent base assumption in IPv4 was that addresses were stable over a > "session" (be it connection-oriented or connectionless). This > assumption permeates every IP stack. Given DNS root server IP > addresses retired over 10 years ago still get 30 queries per second, I > doubt prefixes can be expected to change by all applications in our > lifetimes. > That is the main driver behind the way shim6 preserves the ULID (i.e., the address as seen by the upper layer). The other main driver is that after 13 years of knowing that a scaleable PI solution would make this problem set go away, we still don't have one. (Defining PI address space that can be used by a few tens of thousands of large companies doesn't have anything to do with IDR scaling to tens of millions of smaller sites.) The multi6 WG did thrash out all these arguments before converging on a direction, by the way. The only new argument I've seen recently is the need for some support of TE functionality in shim6, which is a very valid point but doesn't belong on this list. Instead of predicating the future of the network on a non-existent solution, we're designing one that has a chance of working on the scale of a billion node Internet. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 16 17:25:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERG0t-0003Db-2q; Sun, 16 Oct 2005 17:25:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERG0r-0003DW-M3 for ipv6@megatron.ietf.org; Sun, 16 Oct 2005 17:25:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24999 for ; Sun, 16 Oct 2005 17:25:42 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERGC1-0006Pj-4d for ipv6@ietf.org; Sun, 16 Oct 2005 17:37:24 -0400 Received: from jurassic.eng.sun.com ([129.146.228.50]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9GLPPJE022705; Sun, 16 Oct 2005 15:25:25 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9GLPMqC819113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 16 Oct 2005 14:25:24 -0700 (PDT) Message-ID: <4352C53F.8070708@sun.com> Date: Sun, 16 Oct 2005 14:25:19 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Lanciani References: <200510152111.RAA23287@ss10.danlan.com> In-Reply-To: <200510152111.RAA23287@ss10.danlan.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Dan Lanciani wrote: > I thought I made this pretty clear in the portions of my note which you > snipped, but I'll try to run through it one more time. > > -Scalable PI space without distributed routing tables probably requires > a full identifier/locator split. > > -An identifier/locator split almost certainly requires changes to existing > code to accommodate a mapping layer. > > -Shim6 provides a replacement for one useful attribute of PI space (multi- > homing) by leveraging a partial identifier/locator split. > > -Shim6 requires changes to existing code to accommodate a mapping layer. > > If shim6 is deployed then one of the problems caused by the lack of a general > PI solution will be "solved" thus reducing the impetus to find that general > solution. Deployment of shim6 requires changing a lot of existing code. > Convincing the world to change all the code a *second* time is going to be > a much harder sell. Implementing a general solution in the presense of > deployed shim6 would itself be more difficult because of the interaction > of two very similar mapping layers. Dan, The issue I have with your description is that you assume that the "mapping layers" are actually of similar complexity, and AFAICT they are quite different; the shim uses a "re-mapping" layer (which remaps the ULIDs to alternative locators it has exchanged with the peer). But for a generalized identifier/locator split you need a mechanism to *lookup* an identifier to find some working locators. The complexities of defining such a lookup mechanism is nothing that the shim needs; the complexity is closely tied to what the identifier name space looks like (hierarchical allocation, and HIP-style hashes are two examples). A complete identifier/locator split would also need to redefine what information goes in the DNS (e.g., should we have some form of ID RRs or not?). If and when we have workable solutions for those pieces, we can still reuse the shim as the mechanism for providing failover between different locator pairs. So I don't see how *technically* doing the shim prevents people from working on the above, hard problems. We already have HIP exploring one way to do this (based on a flat ID space). If folks want to explore doing it based on a hierarchical ID name space as well. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 17 00:24:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMYN-00060Z-BG; Mon, 17 Oct 2005 00:24:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMYK-00060J-Q8 for ipv6@megatron.ietf.org; Mon, 17 Oct 2005 00:24:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13890 for ; Mon, 17 Oct 2005 00:24:41 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERMjY-0007bn-SH for ipv6@ietf.org; Mon, 17 Oct 2005 00:36:27 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOH00A8RLYTUG@szxga02-in.huawei.com> for ipv6@ietf.org; Mon, 17 Oct 2005 12:32:53 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOH008JKLYS37@szxga02-in.huawei.com> for ipv6@ietf.org; Mon, 17 Oct 2005 12:32:53 +0800 (CST) Received: from huaweigtausbkb ([10.110.102.85]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOH001FGLYMBU@szxml02-in.huawei.com>; Mon, 17 Oct 2005 12:32:48 +0800 (CST) Date: Mon, 17 Oct 2005 12:25:10 +0800 From: Syed Ajim Hussain In-reply-to: <1AA39B75171A7144A73216AED1D7478D012892D8@esebe100.NOE.Nokia.com> To: john.loughney@nokia.com, Francis.Dupont@enst-bretagne.fr Message-id: <001301c5d2d2$c42ac6b0$55666e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.6 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: RE: IPV6 AAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Francis/Jhon Thanks for your information. Why IPv6 Broadband access service is so dependent on DHCP6. Even if you run DHCP6-Relay on NAS there is some problem in NAS for maintaining Route-information, Since NAS does not know What prefixes are allocated to internal access networks. Since CPE Device Again needs to inform routing information to NAS, CPE device may not support routing protocols like BGP, OSPF. There should be a simple prefix delegation mechanism such that NAS can directly use to advertise prefixes from AAA to its Access clients without using DHCP6 server. If you don't support DHCP6 then IPv6 AAA does not have much use in NAS. With Regards Syed Ajim Hussain Huawei Technologies Co., Ltd. -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Sunday, October 16, 2005 9:35 PM To: Francis.Dupont@enst-bretagne.fr; syedah@huawei.com Cc: ipv6@ietf.org Subject: RE: IPV6 AAA I agree with Francis on this. John >In RADIUS you have Framed-IPv6-Prefix for the PPP link itself >and Delegated-IPv6-Prefix (defined in an I-D) for prefix >delegation but PPP can't delegate a prefix, you should use >DHCPv6 for this job. > >Regards > >Francis.Dupont@enst-bretagne.fr > >PS: the DHCPv6 Relay RADIUS Attribute Option can bind RADIUS >on the NAS with the DHCPv6 services when needed. > >-------------------------------------------------------------------- >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 ipv6-bounces@ietf.org Mon Oct 17 01:44:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERNna-0000gX-0v; Mon, 17 Oct 2005 01:44:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERNnX-0000gP-M7 for ipv6@megatron.ietf.org; Mon, 17 Oct 2005 01:44:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17925 for ; Mon, 17 Oct 2005 01:44:29 -0400 (EDT) Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERNym-000178-DW for ipv6@ietf.org; Mon, 17 Oct 2005 01:56:14 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LUB2GSS9GS9AS4DC@vaxh.its.monash.edu.au> for ipv6@ietf.org; Mon, 17 Oct 2005 15:42:50 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 90B9D80002; Mon, 17 Oct 2005 15:42:49 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 7F1383C009; Mon, 17 Oct 2005 15:42:49 +1000 (EST) Date: Mon, 17 Oct 2005 15:42:44 +1000 From: Greg Daley In-reply-to: <001301c5d2d2$c42ac6b0$55666e0a@china.huawei.com> To: Syed Ajim Hussain Message-id: <435339D4.6060403@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.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 References: <001301c5d2d2$c42ac6b0$55666e0a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7BIT Cc: john.loughney@nokia.com, ipv6@ietf.org, Francis.Dupont@enst-bretagne.fr Subject: Re: IPV6 AAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Syed, Syed Ajim Hussain wrote: > Hi > Francis/Jhon > > Thanks for your information. Why IPv6 Broadband access service is so > dependent on DHCP6. Even if you run DHCP6-Relay on NAS there is some > problem in NAS for maintaining Route-information, Since NAS does not > know > What prefixes are allocated to internal access networks. Since CPE > Device > Again needs to inform routing information to NAS, CPE device may not > support routing protocols like BGP, OSPF. > > There should be a simple prefix delegation mechanism such that NAS can > directly use to advertise prefixes from AAA to its Access clients > without using DHCP6 server. If you don't support DHCP6 then IPv6 AAA > does not have much use in NAS. The point is that there's no specification of addressing assignment for the prefix usign AAA because that address assignment is performed by DHCPv6 if necessary, or by Stateless Address Autoconfiguration (RFC2462) otherwise. Routers Advertise basic routing and addressing configuration for the link using Router Discovery (RFC2461). This contains the addressing prefixes, and whether addresses should be autonomously configured by the host or requested from a DHCPv6 service. This is the same mechanism used to advertise prefixes, and allow address configuration on Ethernet and other networks too. So there's no added reliance on DHCPv6, just the normal one. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 17 04:16:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQ6B-0005pS-7b; Mon, 17 Oct 2005 04:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQ68-0005p3-7l for ipv6@megatron.ietf.org; Mon, 17 Oct 2005 04:11:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23875 for ; Mon, 17 Oct 2005 04:11:49 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERQHO-0004id-VL for ipv6@ietf.org; Mon, 17 Oct 2005 04:23:36 -0400 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 j9H8B8l11430; Mon, 17 Oct 2005 10:11:08 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9H8B7wB021306; Mon, 17 Oct 2005 10:11:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510170811.j9H8B7wB021306@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Syed Ajim Hussain In-reply-to: Your message of Mon, 17 Oct 2005 12:25:10 +0800. <001301c5d2d2$c42ac6b0$55666e0a@china.huawei.com> Date: Mon, 17 Oct 2005 10:11:07 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: john.loughney@nokia.com, ipv6@ietf.org Subject: Re: IPV6 AAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: Thanks for your information. Why IPv6 Broadband access service is so dependent on DHCP6. => it is not so dependent: prefix delegation and service discovery are optional services. Even if you run DHCP6-Relay on NAS there is some problem in NAS for maintaining Route-information, => route for which prefix? Since NAS does not know What prefixes are allocated to internal access networks. => the NAS knows the Framed-IPv6-Prefix and can get the Delegated-IPv6-Prefix when it runs a DHCPv6 relay (note a DHCPv6 relay or server is needed on the NAS to delegate a prefix). Since CPE Device again needs to inform routing information to NAS, CPE device may not support routing protocols like BGP, OSPF. => I don't understand why. In fact on the NAS you have the choice between to put the route directly or to accept the announce of the route by the peer (CPE). There should be a simple prefix delegation mechanism such that NAS can directly use to advertise prefixes from AAA to its Access clients without using DHCP6 server. => you are far too late. There was a discussion about prefix delegation mechanism and the DHCPv6 one wins, so now it *is* *the* prefix delegation mechanism. If you don't support DHCP6 then IPv6 AAA does not have much use in NAS. => I don't understand your argument: the IPv6 AAA in NAS is about access control, its use for IPv6 prefixes is only a convenient side effect. Regards Francis.Dupont@enst-bretagne.fr PS: at the exception of the Delegated-IPv6-Prefix (too recent :-), we have implemented the whole stuff for the server side of the Point6 box. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 17 13:14:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYZD-0004lz-3W; Mon, 17 Oct 2005 13:14:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYZ9-0004ix-Ai for ipv6@megatron.ietf.org; Mon, 17 Oct 2005 13:14:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25341 for ; Mon, 17 Oct 2005 13:14:18 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19zdfphnvmm+O0SRXiRVj+ABDCQkkIe8mE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERYkU-0004UI-Pu for ipv6@ietf.org; Mon, 17 Oct 2005 13:26:12 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ERYYt-0001A1-Br; Mon, 17 Oct 2005 19:14:14 +0200 Received: from [141.3.71.115] (i72ibm03.tm.uni-karlsruhe.de [141.3.71.115]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 05E82B361; Mon, 17 Oct 2005 19:14:11 +0200 (CEST) Message-ID: <4353DBE2.4010601@tm.uka.de> Date: Mon, 17 Oct 2005 19:14:10 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Nick 'Sharkey' Moore" , IPv6 X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -5.9 (-----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: Mark Doll , Roland Bless Subject: Comment on draft-ietf-ipv6-optimistic-dad-06.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Nick, hi everybody. First of all, I take up the cudgels for this draft. It defines an optimization which is going to be a prerequisite for efficient mobility support. The draft is in excellent shape, too. Overall, very good work! One thing, though. Section 3.3 of the draft says: >> * (modifies 5.4) As soon as the initial Neighbor Solicitation is >> sent, the Optimistic Address is configured on the interface and >> available for use immediately. The address MUST be flagged as >> 'Optimistic'. Requiring the initial NS to be transmitted *before* the Optimistic Address (OA) becomes operable can imply delays that defeat the purpose of ODAD. Specifically, if the initial NS would be the Optimistic Node's (ON) first message on that link, the ON would have to send an MLD Report prior to that NS [1]. The MLD Report, in turn, would have to be delayed by up to a second. A similar thing happens when configuration of the OA was triggered by a multicast RA. The MLD Report ensures that ODAD works over links with snooping switches. Its delay serves to avoid collisions when multiple nodes configure simultaneously [1]. Note that these delays apply, e.g., to mobile nodes handing off to a new link and configuring a new Mobile IPv6 care-of address by means of ODAD. We wrote a draft with more details about this issue and also some solutions [2]. The easiest solution seems to be to allow use of the OA already prior to transmission of the inital NS. There has also been a discussion on the this mailing list [3] and the DNA mailing list [4]. Presumably the reason why the draft currently says that the first NS must be sent prior to OA configuration is that you want to get the ODAD process going before the OA is ready for use. This ensures that the OA will be in Optimistic state for a pre-defined time period only. But there are other ways to limit the duration of the Optimistic state. Another reason for having to send the initial NS prior to OA configuration might be that a collision could be revealed before upper-layer communications make use of the OA. But since an application can seize the OA immediately, there is a race condition anyway. Furthermore, the NS might get lost, which is why Optimistic DAD sends multiple NSs. Let me know what you think about this. Best regards, - Christian [1] IPv6 Stateless Address Autoconfiguration, RFC 2462bis, section 5.4.2, http://www.watersprings.org/pub/id/draft-ietf-ipv6-rfc2462bis-08.txt [2] Analysis of IPv6 Relocation Delays, http://www.ietf.org/internet-drafts/draft-vogt-dna-relocation-01.txt [3] "Comment on RFCs 2461bis and 2462bis", Discussion on the IPv6 mailing list, May 27, 2005, http://www1.ietf.org/mail-archive/web/ipv6/current/msg05084.html [4] "DAD and MLD Interaction", Discussion on the DNA mailing list, June 13, 2005, http://webcamserver.eng.monash.edu.au/~warchive/dna/2005-06/msg00098.html -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 18 05:33:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERnqd-0007TY-Jg; Tue, 18 Oct 2005 05:33:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERnqa-0007TK-N3 for ipv6@megatron.ietf.org; Tue, 18 Oct 2005 05:33:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16618 for ; Tue, 18 Oct 2005 05:33:20 -0400 (EDT) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERo20-0007Bt-2a for ipv6@ietf.org; Tue, 18 Oct 2005 05:45:22 -0400 Received: from [192.168.1.105] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 4329511C016D8B83; Tue, 18 Oct 2005 11:33:00 +0200 From: Julien Laganier To: Dan Lanciani User-Agent: KMail/1.8 References: <200510152111.RAA23287@ss10.danlan.com> <4352C53F.8070708@sun.com> In-Reply-To: <4352C53F.8070708@sun.com> MIME-Version: 1.0 Content-Disposition: inline Date: Tue, 18 Oct 2005 11:34:37 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200510181134.37429.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Erik Nordmark , ipv6@ietf.org Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Sunday 16 October 2005 23:25, Erik Nordmark wrote: > > The issue I have with your description is that you assume that the > "mapping layers" are actually of similar complexity, and AFAICT > they are quite different; the shim uses a "re-mapping" layer (which > remaps the ULIDs to alternative locators it has exchanged with the > peer). But for a generalized identifier/locator split you need a > mechanism to *lookup* an identifier to find some working locators. > > The complexities of defining such a lookup mechanism is nothing > that the shim needs; the complexity is closely tied to what the > identifier name space looks like (hierarchical allocation, and > HIP-style hashes are two examples). > > A complete identifier/locator split would also need to redefine > what information goes in the DNS (e.g., should we have some form of > ID RRs or not?). FWIW, there is a HIP WG I-D proposing to define a new RR to store HIP identifiers. > If and when we have workable solutions for those pieces, we can > still reuse the shim as the mechanism for providing failover > between different locator pairs. So I don't see how *technically* > doing the shim prevents people from working on the above, hard > problems. > We already have HIP exploring one way to do this (based on a flat > ID space). If folks want to explore doing it based on a > hierarchical ID name space as well. HIP had, some revisions ago, two types of identifiers: flat (public key hash) and hierarchical (concatenation of prefix and public key hash). We chose to drop the hierarchical flavor because at that time there was no strong support to keep them. If there is now interest one can try to revive them. --julien -- julien -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 19 03:57:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES8p2-0004CL-QG; Wed, 19 Oct 2005 03:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES8p1-0004CF-6R for ipv6@megatron.ietf.org; Wed, 19 Oct 2005 03:57:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28196 for ; Wed, 19 Oct 2005 03:57:07 -0400 (EDT) Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES90g-0002fK-V3 for ipv6@ietf.org; Wed, 19 Oct 2005 04:09:20 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id DAA23875; Wed, 19 Oct 2005 03:57:04 -0400 (EDT) Date: Wed, 19 Oct 2005 03:57:04 -0400 (EDT) From: Dan Lanciani Message-Id: <200510190757.DAA23875@ss10.danlan.com> To: ipv6@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Erik Nordmark wrote: |Dan Lanciani wrote: | |> I thought I made this pretty clear in the portions of my note which you |> snipped, but I'll try to run through it one more time. |> |> -Scalable PI space without distributed routing tables probably requires |> a full identifier/locator split. |> |> -An identifier/locator split almost certainly requires changes to existing |> code to accommodate a mapping layer. |> |> -Shim6 provides a replacement for one useful attribute of PI space (multi- |> homing) by leveraging a partial identifier/locator split. |> |> -Shim6 requires changes to existing code to accommodate a mapping layer. |> |> If shim6 is deployed then one of the problems caused by the lack of a general |> PI solution will be "solved" thus reducing the impetus to find that general |> solution. Deployment of shim6 requires changing a lot of existing code. |> Convincing the world to change all the code a *second* time is going to be |> a much harder sell. Implementing a general solution in the presense of |> deployed shim6 would itself be more difficult because of the interaction |> of two very similar mapping layers. | |Dan, | |The issue I have with your description is that you assume that the |"mapping layers" are actually of similar complexity, I don't think that anything I wrote above relies on such an assumption. I believe that the existence of shim6 will discourage the deployment of a more general PI solution regardless of their relative complexities. The primary reasons are logistical, but the technical issue of two similar mapping layers (similar not in their complexity but in the type of mapping they perform) should not be underestimated. Shim6 need only consider interactions (including referals) between existing vanilla stacks and shim6-enhanced stacks. A general solution that could be deployed in the presense of shim6 would have to deal with interactions among all three of vanilla stacks, shim6-enhanced stacks, and generally-enhanced stacks. That said, I disagree with your apparent assumption that the overall effort of deploying a general solution would be significantly greater than that of deploying shim6. I believe we have a combination of underestimating the complexity of making the current shim6 work in its own limited generality and overestimating the complexity of making a general mapping solution work. The latter has been debated endlessly over the past ~15 years and there is little point in repeating the arguments. (Though in the past it always seemed that solutions that involved extensive retrofits on the level that shim6 requires were not even on the table.) The former may not become apparent until shim6 nears full implementation. In any case, the deployment cost of any similarly pervasive change to the stack has a large fixed component which is independent of the actual complexity of the change. This component may dwarf any difference in complexity. It seems a shame to waste a chance to amortize the fixed cost over the maximum possible functionality gain... Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 19 05:38:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESAPG-0003Dt-Fs; Wed, 19 Oct 2005 05:38:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESAPC-0003At-TY for ipv6@megatron.ietf.org; Wed, 19 Oct 2005 05:38:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02692 for ; Wed, 19 Oct 2005 05:38:34 -0400 (EDT) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESAau-0005F1-7q for ipv6@ietf.org; Wed, 19 Oct 2005 05:50:49 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOL00M2JP7V2Q@usaga01-in.huawei.com> for ipv6@ietf.org; Wed, 19 Oct 2005 02:33:31 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOL00754P7UTX@usaga01-in.huawei.com> for ipv6@ietf.org; Wed, 19 Oct 2005 02:33:31 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [156.106.208.90]) by szxmc01-in.huawei.com (mshttpd); Wed, 19 Oct 2005 17:36:48 +0800 Date: Wed, 19 Oct 2005 17:36:48 +0800 From: zhangjian 24185 To: ipv6@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.4 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT Subject: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Dear all, I have submitted the draft, draft-jian-ipv6-meaheader.The purpose of this document is to introduce a measurement header. Measurement header is a new type of IPv6 extended header used for network measurement. The information needed by measurement carried in measurement header. The parameters can be calculated based on these information. Would you mind give me some comments? Best reagrds, Jian Zhang Huawei Technologies *************************************************************************************** Declaration: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Huawei Technologies Co. Ltd.. Finally, the recipient should check this email and any attachments for the presence of viruses. Huawei Technologies Co. Ltd. accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************** -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 19 07:47:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESCPw-0007oE-SG; Wed, 19 Oct 2005 07:47:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESCPu-0007nQ-Fy for ipv6@megatron.ietf.org; Wed, 19 Oct 2005 07:47:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08976 for ; Wed, 19 Oct 2005 07:47:25 -0400 (EDT) Received: from zorg.st.net.au ([203.16.233.9] helo=borg.st.net.au ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESCba-00008s-Rg for ipv6@ietf.org; Wed, 19 Oct 2005 07:59:42 -0400 Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id E252939477F; Wed, 19 Oct 2005 21:47:18 +1000 (EST) Received: from anchovy.zoic.org (static-2.241.240.220.dsl.comindico.com.au [220.240.241.2]) by borg.st.net.au (Postfix) with ESMTP id 349ED39477A; Wed, 19 Oct 2005 21:47:18 +1000 (EST) Received: by anchovy.zoic.org (Postfix, from userid 1000) id E34D070BCE6; Wed, 19 Oct 2005 21:47:15 +1000 (EST) Date: Wed, 19 Oct 2005 21:47:15 +1000 From: "Nick 'Sharkey' Moore" To: Christian Vogt Message-ID: <20051019114715.GA4074@zoic.org> Mail-Followup-To: Christian Vogt , IPv6 References: <4353DBE2.4010601@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4353DBE2.4010601@tm.uka.de> X-URL: http://zoic.org/sharkey/ User-Agent: Mutt/1.5.9i X-Scanned-By: AMaViS-ng at borg.st.net.au X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IPv6 Subject: Re: Comment on draft-ietf-ipv6-optimistic-dad-06.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 2005-10-17, Christian Vogt wrote: > Hi Nick, hi everybody. > > First of all, I take up the cudgels for this draft. It defines an > optimization which is going to be a prerequisite for efficient mobility > support. The draft is in excellent shape, too. Overall, very good work! Cheers, thanks. It's currently waiting on the IESG's final word ... > One thing, though. Section 3.3 of the draft says: > > >> * (modifies 5.4) As soon as the initial Neighbor Solicitation is > >> sent, the Optimistic Address is configured on the interface and > >> available for use immediately. The address MUST be flagged as > >> 'Optimistic'. > > Requiring the initial NS to be transmitted *before* the Optimistic > Address (OA) becomes operable can imply delays that defeat the purpose > of ODAD. Ah, yes. I see what you mean. Actually, even worse, "as soon as [it] is sent" is somewhat ambiguous given L2 queuing, etc. I'm thinking that: 1) Need to clarify this clause: "* The Optimistic Address is available for use immediately. The address MUST be flagged as 'Optimistic'." would probably be sufficient. 2) Need to add a point to address the MLD clauses mentioned in 2461/2. I'd welcome your suggestions! Note that OptiDAD presents changes to 2461/2, not 2461bis/2462bis, because it's Standards Track and the -bis documents ain't RFCs just yet. This may, of course, change. -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 19 11:47:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESG9s-0002Me-2e; Wed, 19 Oct 2005 11:47:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESG9q-0002M8-HX for ipv6@megatron.ietf.org; Wed, 19 Oct 2005 11:47:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23995 for ; Wed, 19 Oct 2005 11:47:05 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESGLa-0007Ge-Q5 for ipv6@ietf.org; Wed, 19 Oct 2005 11:59:24 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9JFkmW03756; Wed, 19 Oct 2005 18:46:48 +0300 Date: Wed, 19 Oct 2005 18:46:48 +0300 (EEST) From: Pekka Savola To: zhangjian 24185 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipv6@ietf.org Subject: Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, 19 Oct 2005, zhangjian 24185 wrote: > I have submitted the draft, draft-jian-ipv6-meaheader.The purpose of > this document is to introduce a measurement header. Measurement > header is a new type of IPv6 extended header used for network > measurement. The information needed by measurement carried in > measurement header. The parameters can be calculated based on these > information. > > Would you mind give me some comments? You use the standard TLV format, good. As long as you imagine that this is only used between consenting adults in private experiements, this would be an OK approach. (As such it might or might not need to be published in the IETF, but if you'd want to do so, direct submission to the RFC-editor for either informational or experimental RFC might be best.) On the other hand, if you are interested in wider applicability, you should probably seriously evaluate the different tradeoffs where you want to perform the measurements. Using an extension header might be a very awkward place to do that, and might interfere with a lot of other operational things (like firewalls). Just using an upper-layer protocol could possibly do the job. Note that only (certain) hop-by-hop options are expected to be inspected by intermediate nodes. This header type has a subtype "this message header need to be processed hop-by-hop". This has an architectural issue, but again, if you want to use this for very limited measurements only, feel free.. (I didn't really review the spec, I just looked at the parts which are most likely to be problematic.) -- 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 ipv6-bounces@ietf.org Wed Oct 19 16:53:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESKwe-0002kg-Fz; Wed, 19 Oct 2005 16:53:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESKwc-0002kb-Ft for ipv6@megatron.ietf.org; Wed, 19 Oct 2005 16:53:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02797 for ; Wed, 19 Oct 2005 16:53:46 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19Kt08jjK5HZZctmno0NtIZShb/34u9fOc=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESL8O-0007EJ-A5 for ipv6@ietf.org; Wed, 19 Oct 2005 17:06:07 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ESKwV-0004Mt-2v; Wed, 19 Oct 2005 22:53:49 +0200 Received: from [141.3.71.115] (i72ibm03.tm.uni-karlsruhe.de [141.3.71.115]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 2429AB2F2; Wed, 19 Oct 2005 22:53:46 +0200 (CEST) Message-ID: <4356B259.4080701@tm.uka.de> Date: Wed, 19 Oct 2005 22:53:45 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Nick 'Sharkey' Moore" References: <4353DBE2.4010601@tm.uka.de> <20051019114715.GA4074@zoic.org> In-Reply-To: <20051019114715.GA4074@zoic.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -5.2 (-----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: IPv6 Subject: Re: Comment on draft-ietf-ipv6-optimistic-dad-06.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hey Nick. > Ah, yes. I see what you mean. > > Actually, even worse, "as soon as [it] is sent" is somewhat > ambiguous given L2 queuing, etc. True, but you could consider this to be written from the IP layer's perspective, where "sending" a message would mean delivering it to the interface layer. Anyway... > I'm thinking that: > > 1) Need to clarify this clause: "* The Optimistic Address is available > for use immediately. The address MUST be flagged as 'Optimistic'." > would probably be sufficient. Maybe you add the following text to ensure that the inital Neighbor Solicitation cannot be delayed indefinitely. After all, you want to kick-start the verification process as early as possible in order to resolve a potential address conflict quickly. The text below also addresses the MLD clauses which you mention later in your email. "The initial Neighbor Solicitation MUST be transmitted as early as possible after the Optimistic Address has been flagged as 'Optimistic', but it MUST NOT violate any delays or rate limitations set forth by RFC2461 or RFC2462. In particular, if the initial Neighbor Solicitation is the first message to be sent from an interface after interface (re)initialization, the node should delay this message by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [RFC2461] as specified in RFC2461. Furthermore, if sending the initial Neighbor Solicitation requires prior transmission of a Multicast Listener Discovery (MLD) report message [RFC2710] [RFC3810], which then is the first message to be sent from the interface after interface (re)initialization, both the MLD report message and the initial Neighbor Solicitation should be delayed by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [RFC2461]." Note that the reasons for possibly having to delay the initial Neighbor Solicitation are already given in RFC2461. This, in turn, is cited, so you don't need to repeat the reasons in the ODAD draft. > 2) Need to add a point to address the MLD clauses mentioned in 2461/2. > I'd welcome your suggestions! As mentioned before, this is also addressed within the text above. > Note that OptiDAD presents changes to 2461/2, not 2461bis/2462bis, > because it's Standards Track and the -bis documents ain't RFCs just > yet. This may, of course, change. Right. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Nick 'Sharkey' Moore wrote: > On 2005-10-17, Christian Vogt wrote: > >>Hi Nick, hi everybody. >> >>First of all, I take up the cudgels for this draft. It defines an >>optimization which is going to be a prerequisite for efficient mobility >>support. The draft is in excellent shape, too. Overall, very good work! > > > Cheers, thanks. It's currently waiting on the IESG's final word ... > > >>One thing, though. Section 3.3 of the draft says: >> >> >>>>* (modifies 5.4) As soon as the initial Neighbor Solicitation is >>>> sent, the Optimistic Address is configured on the interface and >>>> available for use immediately. The address MUST be flagged as >>>> 'Optimistic'. >> >>Requiring the initial NS to be transmitted *before* the Optimistic >>Address (OA) becomes operable can imply delays that defeat the purpose >>of ODAD. > > > Ah, yes. I see what you mean. > > Actually, even worse, "as soon as [it] is sent" is somewhat > ambiguous given L2 queuing, etc. > > I'm thinking that: > > 1) Need to clarify this clause: "* The Optimistic Address is available > for use immediately. The address MUST be flagged as 'Optimistic'." > would probably be sufficient. > > 2) Need to add a point to address the MLD clauses mentioned in 2461/2. > I'd welcome your suggestions! > > Note that OptiDAD presents changes to 2461/2, not 2461bis/2462bis, > because it's Standards Track and the -bis documents ain't RFCs just > yet. This may, of course, change. > > -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 20 04:39:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESVxa-0002cw-54; Thu, 20 Oct 2005 04:39:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESVxY-0002cE-8G for ipv6@megatron.ietf.org; Thu, 20 Oct 2005 04:39:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24880 for ; Thu, 20 Oct 2005 04:39:23 -0400 (EDT) Received: from salmon.maths.tcd.ie ([134.226.81.11] ident=mmdf) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESW9P-0007tF-1E for ipv6@ietf.org; Thu, 20 Oct 2005 04:51:52 -0400 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 20 Oct 2005 09:39:01 +0100 (BST) Date: Thu, 20 Oct 2005 09:38:57 +0100 From: David Malone To: zhangjian 24185 Message-ID: <20051020083857.GA2210@walton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipv6@ietf.org Subject: Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, Oct 19, 2005 at 05:36:48PM +0800, zhangjian 24185 wrote: > Dear all, > > I have submitted the draft, draft-jian-ipv6-meaheader.The purpose > of this document is to introduce a measurement header. Measurement > header is a new type of IPv6 extended header used for network > measurement. The information needed by measurement carried in > measurement header. The parameters can be calculated based on these > information. It would probably be useful to say how your measurement protocol relates different from other proposals, like: http://watt.nlanr.net/AMP/IPMP/ (there's a draft and other information there). You seem to cover similar ground, though there are some interesting differences. David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 20 11:11:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESc4U-0006jZ-21; Thu, 20 Oct 2005 11:11:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESc4S-0006iC-47 for ipv6@megatron.ietf.org; Thu, 20 Oct 2005 11:11:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22085 for ; Thu, 20 Oct 2005 11:10:57 -0400 (EDT) Received: from qproxy.gmail.com ([72.14.204.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EScGP-00058i-NT for ipv6@ietf.org; Thu, 20 Oct 2005 11:23:29 -0400 Received: by qproxy.gmail.com with SMTP id a39so361171qbd for ; Thu, 20 Oct 2005 08:11:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=D8pKZKaodsb/sV2DHLnndzN4dhWoV4HkNL/eV2EGxxXJRksMp700PfK6I0nPZIhqQv/lDnQgNsrTWwQcyEkDCyJTImjVcbCdl+r++TMIU9F/ishxHM/uN0jfBr4nGGcqlyK3ANwlm0V9iHuPZAWJd66Mb+gSo4kpXSNrrJWIiKY= Received: by 10.65.156.11 with SMTP id i11mr1559879qbo; Thu, 20 Oct 2005 08:11:06 -0700 (PDT) Received: by 10.65.93.15 with HTTP; Thu, 20 Oct 2005 08:11:06 -0700 (PDT) Message-ID: <682af0070510200811y2076e031q216ed048d9c24b91@mail.gmail.com> Date: Thu, 20 Oct 2005 20:41:06 +0530 From: dhawal To: ipv6@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: hi X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0157290000==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0157290000== Content-Type: multipart/alternative; boundary="----=_Part_3693_21171545.1129821066288" ------=_Part_3693_21171545.1129821066288 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hello out there i am new member.... looking forward to inputs from people from all over globe ... i have started project work on topic " BGP4+ implementation over IPv6" ..... we are group of five working on this project... we are doing ou= r post graduation in "Network technology" here in India at SCIT... you people can refer our institute's site at www.scit.edu .... i will keep you people updated with our status and keep asing you people for help whenever possible... if someone wants to know more details please writ= e back in forum or mail me at dhawal_heartz@yahoo.com best regards dhawal sharma SCIT, India. ------=_Part_3693_21171545.1129821066288 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
hello out there
 
i am new member.... looking forward to inputs from people from all ove= r globe ... i have started project work on topic  " BGP4+ im= plementation over IPv6" ..... we are group of five working on this pro= ject... we are doing our post graduation in "Network technology" = here in India at SCIT... you people can refer our institute's site at= =20 www.scit.edu .... i will keep you peopl= e updated with our status and keep asing you people for help when= ever possible... if someone wants to know more details please write back in= forum or mail me at=20 dhawal_heartz@yahoo.com
 
best regards
 
dhawal sharma
SCIT, 
India. 
------=_Part_3693_21171545.1129821066288-- --===============0157290000== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0157290000==-- From ipv6-bounces@ietf.org Thu Oct 20 15:08:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESflw-0001Jz-6V; Thu, 20 Oct 2005 15:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESflt-0001HP-EV for ipv6@megatron.ietf.org; Thu, 20 Oct 2005 15:08:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07308 for ; Thu, 20 Oct 2005 15:08:03 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESfxr-0004sT-W9 for ipv6@ietf.org; Thu, 20 Oct 2005 15:20:37 -0400 Received: from impact.jinmei.org (unknown [2001:4f8:3:bb:dc2f:3feb:bfaf:6fef]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 087691521A; Fri, 21 Oct 2005 04:07:42 +0900 (JST) Date: Fri, 21 Oct 2005 04:07:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: erik.nordmark@sun.com, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net, ipv6@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 12 Aug 2005 00:38:21 +0900, >>>>> JINMEI Tatuya said: > As requested, here are my comments about the addrselect-api draft. One additional comment (I think this has not been pointed out by anyone. sorry if not): Using new flags for ai_flags of getaddrinfo() may have a compatibility issue. RFC3493 says: The ai_flags field to which hints parameter points shall be set to zero or be the bitwise-inclusive OR of one or more of the values AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV, AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG. I personally don't think this prohibits the use of other flags, but some existing implementations seem to interpret this part in the strictest way. Those return an error of EAI_BADFLAGS if an unknown flag is specified in hints.ai_flags. getaddrinfo contained in BSD variants and in the "libbind" library of ISC BIND behave this way. For those implementations, applications that use this API extensions will simply not be working, which is probably what we want to avoid. However, I cannot think of any other solutions than having these implementations change the behavior. So, we should probably first agree on what the implementation should do for unknown flags and describe the clarification 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 ipv6-bounces@ietf.org Thu Oct 20 15:19:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESfx4-0006KP-TE; Thu, 20 Oct 2005 15:19:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESfx3-0006KK-Ba for ipv6@megatron.ietf.org; Thu, 20 Oct 2005 15:19:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07944 for ; Thu, 20 Oct 2005 15:19:35 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESg90-0005FD-Dt for ipv6@ietf.org; Thu, 20 Oct 2005 15:32:09 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Oct 2005 15:19:28 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Oct 2005 15:19:28 -0400 Message-ID: Thread-Topic: MLDv2 and RFC2461bis Thread-Index: AcWGtgzpLlo/OkZtTHS5dNDh8qhoLBO9NtsA From: "Soliman, Hesham" To: "IPv6" X-OriginalArrivalTime: 20 Oct 2005 19:19:28.0502 (UTC) FILETIME=[30D07960:01C5D5AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Subject: 2461bis-05 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Folks,=20 The latest version of 2461bis should appear soon on the web.=20 All issues raised so far were addressed in this draft.=20 I think this concludes the WG LC and hopefully the chairs would initiate IESG LC soon.=20 Thanks, Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 20 18:38:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESj3E-000715-Oa; Thu, 20 Oct 2005 18:38:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESj3C-0006zj-MM for ipv6@megatron.ietf.org; Thu, 20 Oct 2005 18:38:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19405 for ; Thu, 20 Oct 2005 18:38:06 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESjF9-0004GK-Iq for ipv6@ietf.org; Thu, 20 Oct 2005 18:50:42 -0400 Received: from jurassic.eng.sun.com ([129.146.108.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9KMcBZa021355; Thu, 20 Oct 2005 15:38:11 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j9KMcBWx267691; Thu, 20 Oct 2005 15:38:11 -0700 (PDT) Message-Id: <200510202238.j9KMcBWx267691@jurassic.eng.sun.com> Date: Thu, 20 Oct 2005 15:35:51 -0700 (PDT) From: Samita Chakrabarti To: jinmei@isl.rdc.toshiba.co.jp MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KMj8F8JfkBc/DOfaemiTfg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: erik.nordmark@sun.com, ipv6@ietf.org, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Jinmei, Thanks for bringing up this point. Please see my comment below. > > As requested, here are my comments about the addrselect-api draft. > > One additional comment (I think this has not been pointed out by > anyone. sorry if not): > > Using new flags for ai_flags of getaddrinfo() may have a compatibility > issue. RFC3493 says: > > The ai_flags field to which hints parameter points shall be set to > zero or be the bitwise-inclusive OR of one or more of the values > AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV, > AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG. > > I personally don't think this prohibits the use of other flags, but > some existing implementations seem to interpret this part in the > strictest way. Those return an error of EAI_BADFLAGS if an unknown > flag is specified in hints.ai_flags. getaddrinfo contained in BSD > variants and in the "libbind" library of ISC BIND behave this way. > For those implementations, applications that use this API extensions > will simply not be working, which is probably what we want to avoid. > It may vary implementation to implementation. I can't think of any other way than changing the implementation to support the new API. Those implementations that don't support the new AI_* flag will return EAI_BADFLAGS with getaddrinfo(). I'd say that similar could be true for new socket options. > However, I cannot think of any other solutions than having these > implementations change the behavior. So, we should probably first > agree on what the implementation should do for unknown flags and > describe the clarification in this document. As you mentioned that RFC3494 already defines : [EAI_BADFLAGS] The flags parameter had an invalid value. Are you implying that the document (RFC3494) should clarify that the implementation can return EAI_BADFLAGS for unknown flag value? If so, it makes sense to me. However, I'd interpret unknown value as invalid value as well. -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 20 18:58:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjMQ-0000Td-Ok; Thu, 20 Oct 2005 18:58:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjMP-0000TX-7N for ipv6@megatron.ietf.org; Thu, 20 Oct 2005 18:58:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21999 for ; Thu, 20 Oct 2005 18:57:59 -0400 (EDT) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESjYQ-0005N3-Ts for ipv6@ietf.org; Thu, 20 Oct 2005 19:10:35 -0400 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 7CA3F677F6 for ; Thu, 20 Oct 2005 22:57:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id j9KMveEJ040048; Fri, 21 Oct 2005 08:57:40 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200510202257.j9KMveEJ040048@drugs.dv.isc.org> To: Samita Chakrabarti From: Mark Andrews In-reply-to: Your message of "Thu, 20 Oct 2005 15:35:51 MST." <200510202238.j9KMcBWx267691@jurassic.eng.sun.com> Date: Fri, 21 Oct 2005 08:57:39 +1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: julien.ietf@laposte.net, erik.nordmark@sun.com, ipv6@ietf.org, jinmei@isl.rdc.toshiba.co.jp Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > > Hi Jinmei, > > Thanks for bringing up this point. > Please see my comment below. > > > > As requested, here are my comments about the addrselect-api draft. > > > > One additional comment (I think this has not been pointed out by > > anyone. sorry if not): > > > > Using new flags for ai_flags of getaddrinfo() may have a compatibility > > issue. RFC3493 says: > > > > The ai_flags field to which hints parameter points shall be set to > > zero or be the bitwise-inclusive OR of one or more of the values > > AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV, > > AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG. > > > > I personally don't think this prohibits the use of other flags, but > > some existing implementations seem to interpret this part in the > > strictest way. Those return an error of EAI_BADFLAGS if an unknown > > flag is specified in hints.ai_flags. getaddrinfo contained in BSD > > variants and in the "libbind" library of ISC BIND behave this way. > > For those implementations, applications that use this API extensions > > will simply not be working, which is probably what we want to avoid. > > > > It may vary implementation to implementation. I can't think of any other > way than changing the implementation to support the new API. Those > implementations that don't support the new AI_* flag will return > EAI_BADFLAGS with getaddrinfo(). I'd say that similar could be true for > new socket options. > > > However, I cannot think of any other solutions than having these > > implementations change the behavior. So, we should probably first > > agree on what the implementation should do for unknown flags and > > describe the clarification in this document. > > As you mentioned that RFC3494 already defines : > > [EAI_BADFLAGS] The flags parameter had an invalid value. > > Are you implying that the document (RFC3494) should clarify that the > implementation can return EAI_BADFLAGS for unknown flag value? > > If so, it makes sense to me. However, I'd interpret unknown value > as invalid value as well. > > -Samita This really is only a problem when a flag is defined in the header file but the implementation doesn't support it or one of the old flags is now permitted by getaddrinfo(). AI_ADDRCONFIG is a example of such a flag. A little bit of looping addresses this however. Mark #ifdef USE_GETADDRINFO memset(&hints, 0, sizeof(hints)); if (!have_ipv6) hints.ai_family = PF_INET; else if (!have_ipv4) hints.ai_family = PF_INET6; else { hints.ai_family = PF_UNSPEC; #ifdef AI_ADDRCONFIG hints.ai_flags = AI_ADDRCONFIG; #endif } hints.ai_socktype = SOCK_STREAM; #ifdef AI_ADDRCONFIG again: #endif result = getaddrinfo(hostname, NULL, &hints, &ai); switch (result) { case 0: break; case EAI_NONAME: #if defined(EAI_NODATA) && (EAI_NODATA != EAI_NONAME) case EAI_NODATA: #endif return (ISC_R_NOTFOUND); #ifdef AI_ADDRCONFIG case EAI_BADFLAGS: if ((hints.ai_flags & AI_ADDRCONFIG) != 0) { hints.ai_flags &= ~AI_ADDRCONFIG; goto again; } #endif default: return (ISC_R_FAILURE); } > -------------------------------------------------------------------- > 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 ipv6-bounces@ietf.org Thu Oct 20 19:49:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESk6m-0008W4-Nu; Thu, 20 Oct 2005 19:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESk6i-0008VE-VS for ipv6@megatron.ietf.org; Thu, 20 Oct 2005 19:46:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09560 for ; Thu, 20 Oct 2005 19:45:47 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESk7A-0004FV-MA for ipv6@ietf.org; Thu, 20 Oct 2005 19:46:32 -0400 Received: from impact.jinmei.org (unknown [2001:4f8:3:bb:dc2f:3feb:bfaf:6fef]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 007FB1525D; Fri, 21 Oct 2005 08:33:59 +0900 (JST) Date: Fri, 21 Oct 2005 08:33:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Samita Chakrabarti In-Reply-To: <200510202238.j9KMcBWx267691@jurassic.eng.sun.com> References: <200510202238.j9KMcBWx267691@jurassic.eng.sun.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: erik.nordmark@sun.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Thu, 20 Oct 2005 15:35:51 -0700 (PDT), >>>>> Samita Chakrabarti said: >> However, I cannot think of any other solutions than having these >> implementations change the behavior. So, we should probably first >> agree on what the implementation should do for unknown flags and >> describe the clarification in this document. > As you mentioned that RFC3494 already defines : > [EAI_BADFLAGS] The flags parameter had an invalid value. > Are you implying that the document (RFC3494) should clarify that the > implementation can return EAI_BADFLAGS for unknown flag value? Not really. I said some document (3494bis or addrselect doc or whatever) should (1) define "unknown flags" clearly and (2) clarify what getaddrinfo() should do if an "unknown" flag is specified. Regarding (1), RFC3493 specifies explicit flag names: AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV, AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG, which could read that any flags other than those listed are "unknown". But perhaps the real intent is that "under flags" are flags that the system (getaddrinfo implementation) does not support. Regarding (2), it seems to me returning EAI_BADFLAGS is reasonable, but I don't have a strong opinion on this point. As for the relevance to the addrselct API, I was confused about one point. New applications that support this API would probably test the availability of the flag first like this: hints.ai_flags = 0; #ifdef AI_NEWFLAG hints.ai_flags |= AI_NEWFLAG; #endif getaddrinfo(..., &hints, ..); Thus, the problem occurs only when the flag definition and the getaddrinfo() implementation are inconsistent (as Mark pointed out). It would be fair to say such inconsistency is a bug and ignore such a case. I think it's still helpful if the addrselect document assumes the consistency between the supported flag definitions and the getaddrinfo() implementation. 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 ipv6-bounces@ietf.org Fri Oct 21 14:37:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1ly-0008FC-3j; Fri, 21 Oct 2005 14:37:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1lv-0008Ef-VP for ipv6@megatron.ietf.org; Fri, 21 Oct 2005 14:37:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24539 for ; Fri, 21 Oct 2005 14:37:32 -0400 (EDT) Received: from qproxy.gmail.com ([72.14.204.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET1y6-00019c-ON for ipv6@ietf.org; Fri, 21 Oct 2005 14:50:18 -0400 Received: by qproxy.gmail.com with SMTP id o12so100615qba for ; Fri, 21 Oct 2005 11:37:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=h2vGsxYoLYEaXtKRXq3wxwgNWB2OxUpDwd42msJ7n4WsPz3p9/L/JGCm2iDAtCrj+ljn9ynTReizUQqY1fAJP6PF4pfrJk3VwQPolsQ7XfNPszax69G8ne6Qr0nWxELDe0vKUTOcSwOpDaUAkhKP9BSjVshlnU3WETpI4/QQQjk= Received: by 10.65.72.9 with SMTP id z9mr310105qbk; Fri, 21 Oct 2005 11:37:37 -0700 (PDT) Received: by 10.64.156.4 with HTTP; Fri, 21 Oct 2005 11:37:37 -0700 (PDT) Message-ID: <2a86e2e0510211137q11f464f5l452bb79de00d11d2@mail.gmail.com> Date: Sat, 22 Oct 2005 03:37:37 +0900 From: Syed Obaid Amin To: ipv6@ietf.org In-Reply-To: <2a86e2e0510132234i6989f217m1676f8fe72ded2cd@mail.gmail.com> MIME-Version: 1.0 References: <2a86e2e0510132234i6989f217m1676f8fe72ded2cd@mail.gmail.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: Hop-by-Hop options and Intermediate routers. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1564349803==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1564349803== Content-Type: multipart/alternative; boundary="----=_Part_26869_25365953.1129919857251" ------=_Part_26869_25365953.1129919857251 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi I have two inter-related issues which are unclear to me in RFC 2460. Would anyone please clear these ambiguities? 1: If the sending node doesn't include any Hop-by-Hop option header can intermediate router inject Hop-by-hop options? 2: If there is Hop-by-Hop option header present can intermediate router add any new option or modify existing options? Thanks and regards Obaid ------=_Part_26869_25365953.1129919857251 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi

I have two inter-related issues which are unclear to me in= RFC 2460. Would anyone  please clear these ambiguities?

 1: If the sending node doesn't inc= lude any Hop-by-Hop option header can intermediate router inject Hop-by-hop= options?=20

2: If there is Hop-by-Hop option header present can intermediat= e router add any new option or modify existing options?

Thanks and regards
 
Obaid
------=_Part_26869_25365953.1129919857251-- --===============1564349803== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1564349803==-- From ipv6-bounces@ietf.org Fri Oct 21 15:50:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2un-0004Cm-Dr; Fri, 21 Oct 2005 15:50:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2tx-0003pE-Lh; Fri, 21 Oct 2005 15:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29972; Fri, 21 Oct 2005 15:49:54 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET367-0004XW-66; Fri, 21 Oct 2005 16:02:41 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ET2tt-0001Cv-Ie; Fri, 21 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Oct 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-2461bis-05.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --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 : Neighbor Discovery for IP version 6 (IPv6) Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-2461bis-05.txt Pages : 88 Date : 2005-10-21 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-2461bis-05.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-2461bis-05.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: <2005-10-21131201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-2461bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-2461bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21131201.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Sat Oct 22 03:54:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETED5-00007r-TM; Sat, 22 Oct 2005 03:54:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETED2-00006T-W3 for ipv6@megatron.ietf.org; Sat, 22 Oct 2005 03:54:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25015 for ; Sat, 22 Oct 2005 03:54:21 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETEPL-0004ep-0Z for ipv6@ietf.org; Sat, 22 Oct 2005 04:07:16 -0400 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 j9M7s1H23653; Sat, 22 Oct 2005 09:54:01 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9M7s1bp063123; Sat, 22 Oct 2005 09:54:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510220754.j9M7s1bp063123@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Syed Obaid Amin In-reply-to: Your message of Sat, 22 Oct 2005 03:37:37 +0900. <2a86e2e0510211137q11f464f5l452bb79de00d11d2@mail.gmail.com> Date: Sat, 22 Oct 2005 09:54:01 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org Subject: Re: Hop-by-Hop options and Intermediate routers. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: I have two inter-related issues which are unclear to me in RFC 2460. Would anyone please clear these ambiguities? 1: If the sending node doesn't include any Hop-by-Hop option header can intermediate router inject Hop-by-hop options? => no, it MUST NOT. 2: If there is Hop-by-Hop option header present can intermediate router add any new option or modify existing options? => it MUST NOT add any new option but it MAY modify an existing option if the option is marked as mutable en route (there is a bit in the type to recognize such options) and only in the way defined for this option. Note there is no such option registered by IANA today so it is hard to give a real example... Regards Francis.Dupont@enst-bretagne.fr PS: look at the AH specs (RFC 2402 and I-Ds) for mutable fields in headers. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Oct 22 12:23:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETM9a-0002J8-Uj; Sat, 22 Oct 2005 12:23:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETM9A-0001vg-Op for ipv6@megatron.ietf.org; Sat, 22 Oct 2005 12:23:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18904 for ; Sat, 22 Oct 2005 12:22:52 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETMLY-0004fS-BO for ipv6@ietf.org; Sat, 22 Oct 2005 12:35:52 -0400 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 j9MGMmf27940; Sat, 22 Oct 2005 18:22:48 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9MGMmol065785; Sat, 22 Oct 2005 18:22:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510221622.j9MGMmol065785@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: zhangjian 24185 In-reply-to: Your message of Wed, 19 Oct 2005 17:36:48 +0800. Date: Sat, 22 Oct 2005 18:22:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 2.0 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipv6@ietf.org Subject: Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: Would you mind give me some comments? => a new extension header is likely to be problematic today because many boxes on paths look at the contents of packets (even they should not at the exception of the header, the hop-by-hop option header and routing headers where they are intermediate destinations). So in fact the definition of new extension headers is strongly discouraged. BTW I can't see why you need a new extension header: some options, in the hop-by-hop option header for hop-by-hop measurements and in the destination option header for other cases, should do the job and option types encode the behavior for unrecognized options, the mutability, etc. We use here a measurement option without problems (I can give some pointers to our measurement people). 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 ipv6-bounces@ietf.org Sun Oct 23 00:00:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETX2E-0003M2-ME; Sun, 23 Oct 2005 00:00:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETX2C-0003Lx-LL for ipv6@megatron.ietf.org; Sun, 23 Oct 2005 00:00:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12324 for ; Sun, 23 Oct 2005 00:00:24 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETXEf-0006xm-5L for ipv6@ietf.org; Sun, 23 Oct 2005 00:13:30 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id DAC12487 for ; Sun, 23 Oct 2005 00:00:13 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 23 Oct 2005 00:00:13 -0400 Message-Id: <20051023040013.DAC12487@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.29% | 4 | 11.85% | 17029 | francis.dupont@enst-bretagne.fr 7.14% | 2 | 9.46% | 13590 | chvogt@tm.uka.de 7.14% | 2 | 6.88% | 9890 | jinmei@isl.rdc.toshiba.co.jp 3.57% | 1 | 4.95% | 7108 | mark_andrews@isc.org 3.57% | 1 | 4.38% | 6290 | brc@zurich.ibm.com 3.57% | 1 | 4.35% | 6254 | internet-drafts@ietf.org 3.57% | 1 | 4.22% | 6056 | lear@cisco.com 3.57% | 1 | 4.21% | 6051 | obaidasyed@gmail.com 3.57% | 1 | 4.03% | 5797 | ipng-incoming@danlan.com 3.57% | 1 | 3.95% | 5676 | dhawal.hearts@gmail.com 3.57% | 1 | 3.86% | 5551 | erik.nordmark@sun.com 3.57% | 1 | 3.65% | 5239 | syedah@huawei.com 3.57% | 1 | 3.63% | 5218 | samita.chakrabarti@eng.sun.com 3.57% | 1 | 3.44% | 4943 | greg.daley@eng.monash.edu.au 3.57% | 1 | 3.32% | 4774 | sharkey@zoic.org 3.57% | 1 | 3.29% | 4723 | hwzhj@huawei.com 3.57% | 1 | 3.26% | 4691 | julien.ietf@laposte.net 3.57% | 1 | 3.25% | 4667 | pekkas@netcore.fi 3.57% | 1 | 3.04% | 4371 | drc@virtualized.org 3.57% | 1 | 2.88% | 4134 | sra+ipng@hactrn.net 3.57% | 1 | 2.83% | 4062 | john.loughney@nokia.com 3.57% | 1 | 2.70% | 3879 | h.soliman@flarion.com 3.57% | 1 | 2.56% | 3683 | dwmalone=v6lists@maths.tcd.ie --------+------+--------+----------+------------------------ 100.00% | 28 |100.00% | 143676 | 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 ipv6-bounces@ietf.org Mon Oct 24 22:59:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUF1z-0008Mi-EU; Mon, 24 Oct 2005 22:59:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUF1x-0008Jh-Fb for ipv6@megatron.ietf.org; Mon, 24 Oct 2005 22:59:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13088 for ; Mon, 24 Oct 2005 22:59:02 -0400 (EDT) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUFEo-00025Z-83 for ipv6@ietf.org; Mon, 24 Oct 2005 23:12:35 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOW005OSAS7U1@usaga01-in.huawei.com> for ipv6@ietf.org; Mon, 24 Oct 2005 19:55:19 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOW00CR1AS6R7@usaga01-in.huawei.com> for ipv6@ietf.org; Mon, 24 Oct 2005 19:55:19 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [10.110.100.108]) by szxmc01-in.huawei.com (mshttpd); Tue, 25 Oct 2005 10:58:37 +0800 Date: Tue, 25 Oct 2005 10:58:37 +0800 From: zhangjian 24185 To: Francis Dupont Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 2.4 (++) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re:Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org =3E =3D=3E a new extension header is likely to be problematic today becau= se =3E many boxes on paths look at the contents of packets (even they should= =3E not at the exception of the header=2C the hop-by-hop option header an= d =3E routing headers where they are intermediate destinations)=2E So in fa= ct =3E the definition of new extension headers is strongly discouraged=2E In IPv6 specification=2C optional internet-layer information is encoded i= n = separate headers that may be placed between the IPv6 header and the upper= - layer header in a packet=2E So the boxes on paths must look at the extend= ed = header=2C such as hop-by-hop option header and routing headers=2E Yes=2C = it is = strongly discouraged to define new extension=2E But if it is necessary=2C= = it should not be forbidden=2E = =3E BTW I can=27t see why you need a new extension header=3A some options= =2C =3E in the hop-by-hop option header for hop-by-hop measurements and in =3E the destination option header for other cases=2C should do the job an= d =3E option types encode the behavior for unrecognized options=2C the = =3E mutability=2Cetc=2E We use here a measurement option without problems= = =3E (I can give =3E some pointers to our measurement people)=2E Yes=2C it can do the same work=2E But if there are lots of kinds of = information in an extended header=2C it is too complex for program = to identify and process these informations=2E Further more=2C it may be decreased the efficiency of program=2E So it may be better to = organize the informations to an extended header=2C if it is necessary=2E It not only simplify the processing of program=2C but also improve the = efficiency of program=2E Best regards=2C *************************************************************************= ************** Declaration=3A This email and any files transmitted with it are confidential and intende= d solely for = the use of the individual or entity to whom they are addressed=2E If you = have received = this email in error please notify the sender=2E Any offers or quotation o= f service are = subject to formal specification=2E Errors and omissions excepted=2E Plea= se note that any = views or opinions presented in this email are solely those of the author = and do not = necessarily represent those of Huawei Technologies Co=2E Ltd=2E=2E Final= ly=2C the recipient = should check this email and any attachments for the presence of viruses=2E= = Huawei Technologies Co=2E Ltd=2E accepts no liability for any damage caus= ed by any = virus transmitted by this email=2E *************************************************************************= ************* ----- =D4=AD=D3=CA=BC=FE ----- =B4=D3=3A Francis Dupont =3CFrancis=2EDupont=40enst-bretagne=2Efr=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=D5=2C =CA=AE=D4=C2 23=C8=D5=2C 2005 =C9=CF= =CE=E70=3A22 =D6=F7=CC=E2=3A Re=3A =5Bipv6=5D Request for your comments=3A draft-jian-= ipv6-meaheader-00 =3E In your previous mail you wrote=3A =3E = =3E Would you mind give me some comments=3F =3E = =3E =3D=3E a new extension header is likely to be problematic today becau= se =3E many boxes on paths look at the contents of packets (even they should= =3E not at the exception of the header=2C the hop-by-hop option header an= d =3E routing headers where they are intermediate destinations)=2E So in fa= ct =3E the definition of new extension headers is strongly discouraged=2E =3E = =3E BTW I can=27t see why you need a new extension header=3A some options= =2C =3E in the hop-by-hop option header for hop-by-hop measurements and in =3E the destination option header for other cases=2C should do the job an= d =3E option types encode the behavior for unrecognized options=2C the = =3E mutability=2Cetc=2E We use here a measurement option without problems= = =3E (I can give =3E some pointers to our measurement people)=2E =3E = =3E Regards =3E = =3E Francis=2EDupont=40enst-bretagne=2Efr =3E -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 24 23:14:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUFGT-0005R5-2O; Mon, 24 Oct 2005 23:14:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUFGQ-0005Lp-4d for ipv6@megatron.ietf.org; Mon, 24 Oct 2005 23:14:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14503 for ; Mon, 24 Oct 2005 23:13:59 -0400 (EDT) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUFTI-0002f9-Iv for ipv6@ietf.org; Mon, 24 Oct 2005 23:27:32 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOW005GGBHZU1@usaga01-in.huawei.com> for ipv6@ietf.org; Mon, 24 Oct 2005 20:10:47 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOW00C95BHYFG@usaga01-in.huawei.com> for ipv6@ietf.org; Mon, 24 Oct 2005 20:10:47 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [10.110.100.108]) by szxmc01-in.huawei.com (mshttpd); Tue, 25 Oct 2005 11:14:04 +0800 Date: Tue, 25 Oct 2005 11:14:04 +0800 From: zhangjian 24185 To: David Malone Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re:Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Malone=2C Sorry for reply so late=2E IPMP is a measruement protocol that provides measurement methodology for = IPv4 and IPv6=2E Measurement information is carried message body=2E This draft only provides a extended header used to carry on the measureme= nt information=2E It does not define the measurement methodology=2E So everyone can develop= the measurement methodology based on this extended header=2E They can define new measurem= ent options as needed=2E Also=2C IPMP can provides a new IPv6 measurement methodology base on this= extended header=2E *************************************************************************= ************** Declaration=3A This email and any files transmitted with it are confidential and intende= d solely for = the use of the individual or entity to whom they are addressed=2E If you = have received = this email in error please notify the sender=2E Any offers or quotation o= f service are = subject to formal specification=2E Errors and omissions excepted=2E Plea= se note that any = views or opinions presented in this email are solely those of the author = and do not = necessarily represent those of Huawei Technologies Co=2E Ltd=2E=2E Final= ly=2C the recipient = should check this email and any attachments for the presence of viruses=2E= = Huawei Technologies Co=2E Ltd=2E accepts no liability for any damage caus= ed by any = virus transmitted by this email=2E *************************************************************************= ************* ----- =D4=AD=D3=CA=BC=FE ----- =B4=D3=3A David Malone =3Cdwmalone=3Dv6lists=40maths=2Etcd=2Eie=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =CA=AE=D4=C2 20=C8=D5=2C 2005 =CF=C2= =CE=E74=3A38 =D6=F7=CC=E2=3A Re=3A =5Bipv6=5D Request for your comments=3A draft-jian-= ipv6-meaheader-00 =3E On Wed=2C Oct 19=2C 2005 at 05=3A36=3A48PM +0800=2C zhangjian 24185 w= rote=3A =3E =3E Dear all=2C =3E =3E = =3E =3E I have submitted the draft=2C draft-jian-ipv6-meaheader=2EThe pur= pose =3E =3E of this document is to introduce a measurement header=2E Measurem= ent =3E =3E header is a new type of IPv6 extended header used for network =3E =3E measurement=2E The information needed by measurement carried in =3E =3E measurement header=2E The parameters can be calculated based on t= hese =3E =3E information=2E =3E = =3E It would probably be useful to say how your measurement protocol =3E relates different from other proposals=2C like=3A =3E = =3E http=3A//watt=2Enlanr=2Enet/AMP/IPMP/ =3E = =3E (there=27s a draft and other information there)=2E You seem to cover =3E similar ground=2C though there are some interesting differences=2E =3E = =3E David=2E =3E -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 25 02:14:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUI59-0001yB-4F; Tue, 25 Oct 2005 02:14:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUI4v-0001qL-GU for ipv6@megatron.ietf.org; Tue, 25 Oct 2005 02:14:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23024 for ; Tue, 25 Oct 2005 02:14:19 -0400 (EDT) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUIHp-0007NV-2w for ipv6@ietf.org; Tue, 25 Oct 2005 02:27:53 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOW0040BJUAVP@usaga01-in.huawei.com> for ipv6@ietf.org; Mon, 24 Oct 2005 23:10:58 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOW00CGZJU9R7@usaga01-in.huawei.com> for ipv6@ietf.org; Mon, 24 Oct 2005 23:10:58 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [10.110.100.108]) by szxmc01-in.huawei.com (mshttpd); Tue, 25 Oct 2005 14:14:15 +0800 Date: Tue, 25 Oct 2005 14:14:15 +0800 From: zhangjian 24185 To: Pekka Savola Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.4 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re:Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thanks for your comments=2E Sorry for so late to reply=2E =3E As long as you imagine that this is only used between consenting = =3E adults in private experiements=2C this would be an OK approach=2E (As= = =3E such = =3E it might or might not need to be published in the IETF=2C but if = =3E you=27d = =3E want to do so=2C direct submission to the RFC-editor for either = =3E informational or experimental RFC might be best=2E) =3E = =3E On the other hand=2C if you are interested in wider applicability=2C = =3E you = =3E should probably seriously evaluate the different tradeoffs where = =3E you = =3E want to perform the measurements=2E Using an extension header might = =3E be = =3E a very awkward place to do that=2C and might interfere with a lot of = =3E other operational things (like firewalls)=2E Just using an upper- =3E layer = =3E protocol could possibly do the job=2E Yes=2C using an upper-layer protocol could do the job=2E But for extended= = measurement header=2C combined with upper-layer protocol=2C we can finish= the measurement without interrupt the service=2E So we think it is worthy= to wider applicability=2E = =3E Note that only (certain) hop-by-hop options are expected to be = =3E inspected by intermediate nodes=2E This header type has a subtype = =3E =22this = =3E message header need to be processed hop-by-hop=22=2E This has an = =3E architectural issue=2C but again=2C if you want to use this for very = =3E limited measurements only=2C feel free=2E=2E Yes=2C the hop-by-hop option is only used for measurements=2E *************************************************************************= ************** Declaration=3A This email and any files transmitted with it are confidential and intende= d solely for = the use of the individual or entity to whom they are addressed=2E If you = have received = this email in error please notify the sender=2E Any offers or quotation o= f service are = subject to formal specification=2E Errors and omissions excepted=2E Plea= se note that any = views or opinions presented in this email are solely those of the author = and do not = necessarily represent those of Huawei Technologies Co=2E Ltd=2E=2E Final= ly=2C the recipient = should check this email and any attachments for the presence of viruses=2E= = Huawei Technologies Co=2E Ltd=2E accepts no liability for any damage caus= ed by any = virus transmitted by this email=2E *************************************************************************= ************* ----- =D4=AD=D3=CA=BC=FE ----- =B4=D3=3A Pekka Savola =3Cpekkas=40netcore=2Efi=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =CA=AE=D4=C2 19=C8=D5=2C 2005 =CF=C2= =CE=E711=3A46 =D6=F7=CC=E2=3A Re=3A =5Bipv6=5D Request for your comments=3A draft-jian-= ipv6-meaheader-00 =3E On Wed=2C 19 Oct 2005=2C zhangjian 24185 wrote=3A =3E =3E I have submitted the draft=2C draft-jian-ipv6-meaheader=2EThe = =3E purpose of = =3E =3E this document is to introduce a measurement header=2E Measurement= = =3E =3E header is a new type of IPv6 extended header used for network = =3E =3E measurement=2E The information needed by measurement carried in = =3E =3E measurement header=2E The parameters can be calculated based on = =3E these = =3E =3E information=2E =3E =3E =3E =3E Would you mind give me some comments=3F =3E = =3E You use the standard TLV format=2C good=2E =3E = =3E As long as you imagine that this is only used between consenting = =3E adults in private experiements=2C this would be an OK approach=2E (As= = =3E such = =3E it might or might not need to be published in the IETF=2C but if = =3E you=27d = =3E want to do so=2C direct submission to the RFC-editor for either = =3E informational or experimental RFC might be best=2E) =3E = =3E On the other hand=2C if you are interested in wider applicability=2C = =3E you = =3E should probably seriously evaluate the different tradeoffs where = =3E you = =3E want to perform the measurements=2E Using an extension header might = =3E be = =3E a very awkward place to do that=2C and might interfere with a lot of = =3E other operational things (like firewalls)=2E Just using an upper- =3E layer = =3E protocol could possibly do the job=2E =3E = =3E Note that only (certain) hop-by-hop options are expected to be = =3E inspected by intermediate nodes=2E This header type has a subtype = =3E =22this = =3E message header need to be processed hop-by-hop=22=2E This has an = =3E architectural issue=2C but again=2C if you want to use this for very = =3E limited measurements only=2C feel free=2E=2E =3E = =3E (I didn=27t really review the spec=2C I just looked at the parts whic= h = =3E are = =3E most likely to be problematic=2E) =3E = =3E -- = =3E Pekka Savola =22You each name yourselves king=2C yet = the =3E Netcore Oy kingdom bleeds=2E=22 =3E Systems=2E Networks=2E Security=2E -- George R=2ER=2E Martin=3A A Cla= sh of Kings =3E -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 25 09:51:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPDZ-0000Ac-8H; Tue, 25 Oct 2005 09:51:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPDX-00009n-MQ for ipv6@megatron.ietf.org; Tue, 25 Oct 2005 09:51:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18357 for ; Tue, 25 Oct 2005 09:51:41 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUPQU-0003Ky-Oq for ipv6@ietf.org; Tue, 25 Oct 2005 10:05:20 -0400 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 j9PDpXd16972; Tue, 25 Oct 2005 15:51:33 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9PDpUOp002042; Tue, 25 Oct 2005 15:51:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510251351.j9PDpUOp002042@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: zhangjian 24185 In-reply-to: Your message of Tue, 25 Oct 2005 10:58:37 +0800. Date: Tue, 25 Oct 2005 15:51:30 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 2.0 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipv6@ietf.org Subject: Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: Yes, it is strongly discouraged to define new extension. But if it is necessary, it should not be forbidden. => good summary: now you have to prove a new extension header is really necessary! So it may be better to organize the informations to an extended header, if it is necessary. It not only simplify the processing of program, but also improve the efficiency of program. => I don't buy the argument: the processing of an option is not so more expensive than the processing of an extension header. The only real difference between options and extension headers is the length of an option is more limited... I propose to only ask for a (or a few) measurement option types, leaving the internal layout to private experiments... Note a RFC is needed to get an official option type. 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 ipv6-bounces@ietf.org Wed Oct 26 09:15:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUl8A-0007CL-30; Wed, 26 Oct 2005 09:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkcv-0000dq-I1 for ipv6@megatron.ietf.org; Wed, 26 Oct 2005 08:43:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16841 for ; Wed, 26 Oct 2005 08:43:18 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUkq5-0000AV-2n for ipv6@ietf.org; Wed, 26 Oct 2005 08:57:09 -0400 Received: from l1.rennes.enst-bretagne.fr (l1.rennes.enst-bretagne.fr [192.44.77.3]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j9QCh4A01165; Wed, 26 Oct 2005 14:43:04 +0200 Received: from enst-bretagne.fr (dhcp78 [193.52.74.178]) (authenticated bits=0) by l1.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9QCh5sd021867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2005 14:43:05 +0200 Message-ID: <435F7904.1040801@enst-bretagne.fr> Date: Wed, 26 Oct 2005 14:39:32 +0200 From: Geraldine Texier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: hwzhj@huawei.com References: <435F7708.1010303@enst-bretagne.fr> In-Reply-To: <435F7708.1010303@enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by laposte.rennes.enst-bretagne.fr id j9QCh4A01165 X-Spam-Score: 2.0 (++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 26 Oct 2005 09:15:48 -0400 Cc: Subject: Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > In your previous mail you wrote: >=20 > Yes, it is strongly discouraged to define new extension. But if it > is necessary, it should not be forbidden. >=20 > =3D> good summary: now you have to prove a new extension header is real= ly > necessary! >=20 > So it may be better to organize the informations to an extended > header, if it is necessary. It not only simplify the processing of > program, but also improve the efficiency of program. >=20 > =3D> I don't buy the argument: the processing of an option is not so mo= re > expensive than the processing of an extension header. The only real > difference between options and extension headers is the length of an > option is more limited... which is well suited for measurement since it is necessary to limit the=20 interference of the measurement data transported within the packet in=20 order to have a relevent measurement. We developped an IPv6 measurement infrastructure based on the=20 utilization of Destination options. It works well and, since we only=20 transport the sending timestamp, we don't need a special extension. I'll be happy to collaborate. Best Regards, Geraldine Texier > I propose to only ask for a (or a few) measurement option types, > leaving the internal layout to private experiments... Note a RFC > is needed to get an official option type. >=20 > Regards >=20 > Francis.Dupont at enst-bretagne.fr >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6 at ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 --=20 Geraldine TEXIER GET/ENST Bretagne - RSM Department 2 rue de la Ch=E2taigneraie - CS 17607 35576 Cesson Sevign=E9 Cedex- France Tel: +33 299 127 038 - Fax: +33 299 127 030 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 26 15:50:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrHp-0005Kg-Mp; Wed, 26 Oct 2005 15:50:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrHg-0005Ep-3k; Wed, 26 Oct 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17760; Wed, 26 Oct 2005 15:49:48 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUrUs-0007UI-U8; Wed, 26 Oct 2005 16:03:43 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUrHe-00070W-6A; Wed, 26 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-ndproxy-04.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --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 : Neighbor Discovery Proxies (ND Proxy) Author(s) : D. Thaler, et al. Filename : draft-ietf-ipv6-ndproxy-04.txt Pages : 19 Date : 2005-10-26 Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ndproxy-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ndproxy-04.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-ndproxy-04.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: <2005-10-26105929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ndproxy-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ndproxy-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26105929.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Wed Oct 26 22:17:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUxKm-0008TY-Pd; Wed, 26 Oct 2005 22:17:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUxKk-0008PO-0a for ipv6@megatron.ietf.org; Wed, 26 Oct 2005 22:17:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15957 for ; Wed, 26 Oct 2005 22:17:22 -0400 (EDT) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUxXz-0003L6-2Q for ipv6@ietf.org; Wed, 26 Oct 2005 22:31:21 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOZ00M64Y7JBN@usaga01-in.huawei.com> for ipv6@ietf.org; Wed, 26 Oct 2005 19:14:08 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOZ009POY7I51@usaga01-in.huawei.com> for ipv6@ietf.org; Wed, 26 Oct 2005 19:14:07 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [10.110.100.108]) by szxmc01-in.huawei.com (mshttpd); Thu, 27 Oct 2005 10:17:22 +0800 Date: Thu, 27 Oct 2005 10:17:22 +0800 From: zhangjian 24185 To: Francis Dupont Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 2.4 (++) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org =3E In your previous mail you wrote=3A =3E = =3E Yes=2C it is strongly discouraged to define new extension=2E But if= it =3E is necessary=2C it should not be forbidden=2E =3E = =3E =3D=3E good summary=3A now you have to prove a new extension header i= s = =3E reallynecessary! =3D=3D=3EThere are many measurement methodologies=2C each has its own inf= ormation carried on packets=2E So it is necessary to provide a infrastructure for these methodologies based on ipv6=2E Using this extended header=2C we can= = perform the measurement without modify the packet=2E So it is a good idea= =2E = =3E So it may be better to organize the informations to an extended =3E header=2C if it is necessary=2E It not only simplify the = =3E processing of =3E program=2C but also improve the efficiency of program=2E =3E = =3E =3D=3E I don=27t buy the argument=3A the processing of an option is n= ot so = =3E moreexpensive than the processing of an extension header=2E The only = =3E realdifference between options and extension headers is the length = =3E of an =3E option is more limited=2E=2E=2E =3E I propose to only ask for a (or a few) measurement option types=2C =3E leaving the internal layout to private experiments=2E=2E=2E Note a RF= C =3E is needed to get an official option type=2E =3D=3D=3EYes=2C if there are only measurement options in destination head= er=2C it may same as extended header when processing it=2E But if there are lots kinds of options=2C each module should check every option to see whether it should process the option=2E It may exhaust more time=2E I think that we have the same idea=2C but there are some little differenc= es=2E We can collaborate together=2E Regards=2E *************************************************************************= ************** Declaration=3A This email and any files transmitted with it are confidential and intende= d solely for = the use of the individual or entity to whom they are addressed=2E If you = have received = this email in error please notify the sender=2E Any offers or quotation o= f service are = subject to formal specification=2E Errors and omissions excepted=2E Plea= se note that any = views or opinions presented in this email are solely those of the author = and do not = necessarily represent those of Huawei Technologies Co=2E Ltd=2E=2E Final= ly=2C the recipient = should check this email and any attachments for the presence of viruses=2E= = Huawei Technologies Co=2E Ltd=2E accepts no liability for any damage caus= ed by any = virus transmitted by this email=2E *************************************************************************= ************* ----- =D4=AD=D3=CA=BC=FE ----- =B4=D3=3A Francis Dupont =3CFrancis=2EDupont=40enst-bretagne=2Efr=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=D4=C2 25=C8=D5=2C 2005 =CF=C2= =CE=E79=3A51 =D6=F7=CC=E2=3A Re=3A =5Bipv6=5D Request for your comments=3A draft-jian-= ipv6-meaheader-00 =3E In your previous mail you wrote=3A =3E = =3E Yes=2C it is strongly discouraged to define new extension=2E But if= it =3E is necessary=2C it should not be forbidden=2E =3E = =3E =3D=3E good summary=3A now you have to prove a new extension header i= s = =3E reallynecessary! =3E = =3E So it may be better to organize the informations to an extended =3E header=2C if it is necessary=2E It not only simplify the = =3E processing of =3E program=2C but also improve the efficiency of program=2E =3E = =3E =3D=3E I don=27t buy the argument=3A the processing of an option is n= ot so = =3E moreexpensive than the processing of an extension header=2E The only = =3E realdifference between options and extension headers is the length = =3E of an =3E option is more limited=2E=2E=2E =3E I propose to only ask for a (or a few) measurement option types=2C =3E leaving the internal layout to private experiments=2E=2E=2E Note a RF= C =3E is needed to get an official option type=2E =3E = =3E Regards =3E = =3E Francis=2EDupont=40enst-bretagne=2Efr =3E -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 27 00:29:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUzOO-0008MS-JF; Thu, 27 Oct 2005 00:29:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUzOK-0008MN-SJ for ipv6@megatron.ietf.org; Thu, 27 Oct 2005 00:29:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21906 for ; Thu, 27 Oct 2005 00:29:12 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUzbc-0006vg-3V for ipv6@ietf.org; Thu, 27 Oct 2005 00:43:13 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IP000HTO4T484@szxga01-in.huawei.com> for ipv6@ietf.org; Thu, 27 Oct 2005 12:36:41 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IP000LKG4T4PX@szxga01-in.huawei.com> for ipv6@ietf.org; Thu, 27 Oct 2005 12:36:40 +0800 (CST) Received: from syedpc ([10.110.102.110]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IP00092S51FU9@szxml01-in.huawei.com> for ipv6@ietf.org; Thu, 27 Oct 2005 12:41:40 +0800 (CST) Date: Thu, 27 Oct 2005 12:30:32 +0800 From: Syed Ajim Hussain In-reply-to: <0IOZ00K2J6J545@szxga01-in.huawei.com> To: ipv6@ietf.org Message-id: <007e01c5daaf$2b05a790$6e666e0a@china.huawei.com> Organization: HUAWEI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7BIT Subject: Prefix Advertisement to CPE X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syedah@huawei.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi All Suppose I have a network topology shown as below. CPE device have establish One PPPoA connection with NAS. NAS can do authentication for PPP user Using PAP, CHAP protocol, NAS may use RADIUS server to authenticate the PPP user. If NAS supports IPv6 RADIUS attributes, User specific prefix Can be get from RADIUS server for this PPP client at the time of authentication. Now NAS can send prefix get from AAA (RADIUS) in RA message to CPE. NAS can also advertise its own interface prefix to CPE device. What is the benefit of advertising prefix taking from AAA to CPE Device? Does CPE device use this prefix only for auto-configuration its PPPoA Interface? If CPE Device does not support DHCP6 Client, how it should support auto configuration of its internal sub-networks? PPPoA User-------CPE----(ATM)---NAS (IPv6 AAA-with RADIUS Support) With Regards Syed Ajim Hussain -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 27 05:22:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV3xg-0006Re-3k; Thu, 27 Oct 2005 05:22:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV3xd-0006OY-Fl for ipv6@megatron.ietf.org; Thu, 27 Oct 2005 05:22:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17519 for ; Thu, 27 Oct 2005 05:21:57 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV4Ax-0003zU-BK for ipv6@ietf.org; Thu, 27 Oct 2005 05:36:00 -0400 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 j9R9LoI28553; Thu, 27 Oct 2005 11:21:51 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9R9Lo4G019756; Thu, 27 Oct 2005 11:21:51 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510270921.j9R9Lo4G019756@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: zhangjian 24185 In-reply-to: Your message of Thu, 27 Oct 2005 10:17:22 +0800. Date: Thu, 27 Oct 2005 11:21:50 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 2.0 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org Subject: Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: > => good summary: now you have to prove a new extension header is > reallynecessary! ==>There are many measurement methodologies, each has its own information carried on packets. So it is necessary to provide a infrastructure for these methodologies based on ipv6. Using this extended header, we can perform the measurement without modify the packet. So it is a good idea. => I don't understand at all why this argument doesn't apply to options! ==>Yes, if there are only measurement options in destination header, => usually there is no destination header (in fact no extension header at all) so this hypothesis is right (:-). it may same as extended header when processing it. But if there are lots kinds of options, each module should check every option to see whether it should process the option. => be serious please: in all the codes I've seen (including mine) the option processing is vectorized or in a C switch, i.e., the cost is an indirect or direct indexed branch. It may exhaust more time. => for next header it is always vectorized. I think that we have the same idea, but there are some little differences. => the main difference is we are only using options... 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 ipv6-bounces@ietf.org Thu Oct 27 08:25:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6pT-00033M-1L; Thu, 27 Oct 2005 08:25:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6pQ-000333-V5 for ipv6@megatron.ietf.org; Thu, 27 Oct 2005 08:25:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25748 for ; Thu, 27 Oct 2005 08:25:38 -0400 (EDT) Received: from coliposte.enst-bretagne.fr ([192.108.115.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV72l-0000Jw-0g for ipv6@ietf.org; Thu, 27 Oct 2005 08:39:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.10.03) with ESMTP id j9RCPThR019676; Thu, 27 Oct 2005 14:25:29 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.09.01) with ESMTP id j9RCOols019578; Thu, 27 Oct 2005 14:24:50 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9RCOoeY020275; Thu, 27 Oct 2005 14:24:51 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510271224.j9RCOoeY020275@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: syedah@huawei.com In-reply-to: Your message of Thu, 27 Oct 2005 12:30:32 +0800. <007e01c5daaf$2b05a790$6e666e0a@china.huawei.com> Date: Thu, 27 Oct 2005 14:24:50 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipv6@ietf.org Subject: Re: Prefix Advertisement to CPE X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: Suppose I have a network topology shown as below. CPE device have establish One PPPoA connection with NAS. NAS can do authentication for PPP user Using PAP, CHAP protocol, NAS may use RADIUS server to authenticate the PPP user. If NAS supports IPv6 RADIUS attributes, User specific prefix Can be get from RADIUS server for this PPP client at the time of authentication. Now NAS can send prefix get from AAA (RADIUS) in RA message to CPE. => yes, the usual way to propagate the Framed-IPv6-Prefix is by router advertisements. NAS can also advertise its own interface prefix to CPE device. What is the benefit of advertising prefix taking from AAA to CPE Device? => the two ends of the PPP link (NAS and CPE) should agree about the prefix of the link. Does CPE device use this prefix only for auto-configuration its PPPoA Interface? => yes. If CPE Device does not support DHCP6 Client, how it should support auto configuration of its internal sub-networks? => it can't: the CPE should support a DHCPv6 Client, the NAS a DHCPv6 server or relay. The prefix is configured in the DHCPv6 server or in the RADIUS server (Delegated-IPv6-Prefix, cf the new I-D draft-salowey-radext-delegated-prefix-01.txt). 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 ipv6-bounces@ietf.org Thu Oct 27 09:56:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Eu-0003eZ-5l; Thu, 27 Oct 2005 09:56:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Es-0003eA-59 for ipv6@megatron.ietf.org; Thu, 27 Oct 2005 09:56:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00904 for ; Thu, 27 Oct 2005 09:56:02 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8SD-0002qY-CN for ipv6@ietf.org; Thu, 27 Oct 2005 10:10:07 -0400 Received: from l1.rennes.enst-bretagne.fr (l1.rennes.enst-bretagne.fr [192.44.77.3]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j9RDt8822130; Thu, 27 Oct 2005 15:55:08 +0200 Received: from enst-bretagne.fr ([192.168.103.222]) (authenticated bits=0) by l1.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9RDt8TZ024829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2005 15:55:08 +0200 Message-ID: <4360DB5F.50208@enst-bretagne.fr> Date: Thu, 27 Oct 2005 15:51:27 +0200 From: Geraldine Texier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: Francis Dupont References: <200510270921.j9R9Lo4G019756@givry.rennes.enst-bretagne.fr> In-Reply-To: <200510270921.j9R9Lo4G019756@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by laposte.rennes.enst-bretagne.fr id j9RDt8822130 X-Spam-Score: 2.0 (++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I send you a link to a the Thesis document of Joel Corral, a PhD that=20 participated to the development of the measurement platform based on the=20 IPv6 destination option, I think you will find interesting things there. http://www.rennes.enst-bretagne.fr/~jcorral/these/ you will find the PDF at the end of the page. Regards Geraldine texier Francis Dupont a =E9crit: > In your previous mail you wrote: >=20 > > =3D> good summary: now you have to prove a new extension header is= =20 > > reallynecessary! > =3D=3D>There are many measurement methodologies, each has its own in= formation > carried on packets. So it is necessary to provide a infrastructure f= or > these methodologies based on ipv6. Using this extended header, we ca= n=20 > perform the measurement without modify the packet. So it is a good i= dea. > =20 > =3D> I don't understand at all why this argument doesn't apply to optio= ns! >=20 > =3D=3D>Yes, if there are only measurement options in destination hea= der, >=20 > =3D> usually there is no destination header (in fact no extension > header at all) so this hypothesis is right (:-). >=20 > it may same as extended header when processing it. But if there are > lots kinds of options, each module should check every option to see > whether it should process the option. >=20 > =3D> be serious please: in all the codes I've seen (including mine) the > option processing is vectorized or in a C switch, i.e., the cost is > an indirect or direct indexed branch. >=20 > It may exhaust more time. >=20 > =3D> for next header it is always vectorized. >=20 > I think that we have the same idea, but there are some little differ= ences. >=20 > =3D> the main difference is we are only using options... >=20 > Regards >=20 > Francis.Dupont@enst-bretagne.fr >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --=20 Geraldine TEXIER GET/ENST Bretagne - RSM Department 2 rue de la Ch=E2taigneraie - CS 17607 35576 Cesson Sevign=E9 Cedex- France Tel: +33 299 127 038 - Fax: +33 299 127 030 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 27 09:56:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8F1-0003jg-Jb; Thu, 27 Oct 2005 09:56:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Ez-0003hc-K2 for ipv6@megatron.ietf.org; Thu, 27 Oct 2005 09:56:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00921 for ; Thu, 27 Oct 2005 09:56:10 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8SM-0002r6-TM for ipv6@ietf.org; Thu, 27 Oct 2005 10:10:15 -0400 Received: from l1.rennes.enst-bretagne.fr (l1.rennes.enst-bretagne.fr [192.44.77.3]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j9RDtN822171; Thu, 27 Oct 2005 15:55:23 +0200 Received: from enst-bretagne.fr ([192.168.103.222]) (authenticated bits=0) by l1.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9RDtNEQ024835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2005 15:55:23 +0200 Message-ID: <4360DB6F.80505@enst-bretagne.fr> Date: Thu, 27 Oct 2005 15:51:43 +0200 From: Geraldine Texier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: Francis Dupont References: <200510270921.j9R9Lo4G019756@givry.rennes.enst-bretagne.fr> In-Reply-To: <200510270921.j9R9Lo4G019756@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by laposte.rennes.enst-bretagne.fr id j9RDtN822171 X-Spam-Score: 2.0 (++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I send you a link to a the Thesis document of Joel Corral, a PhD that=20 participated to the development of the measurement platform based on the=20 IPv6 destination option, I think you will find interesting things there. http://www.rennes.enst-bretagne.fr/~jcorral/these/ you will find the PDF at the end of the page. Regards Geraldine texier Francis Dupont a =E9crit: > In your previous mail you wrote: >=20 > > =3D> good summary: now you have to prove a new extension header is= =20 > > reallynecessary! > =3D=3D>There are many measurement methodologies, each has its own in= formation > carried on packets. So it is necessary to provide a infrastructure f= or > these methodologies based on ipv6. Using this extended header, we ca= n=20 > perform the measurement without modify the packet. So it is a good i= dea. > =20 > =3D> I don't understand at all why this argument doesn't apply to optio= ns! >=20 > =3D=3D>Yes, if there are only measurement options in destination hea= der, >=20 > =3D> usually there is no destination header (in fact no extension > header at all) so this hypothesis is right (:-). >=20 > it may same as extended header when processing it. But if there are > lots kinds of options, each module should check every option to see > whether it should process the option. >=20 > =3D> be serious please: in all the codes I've seen (including mine) the > option processing is vectorized or in a C switch, i.e., the cost is > an indirect or direct indexed branch. >=20 > It may exhaust more time. >=20 > =3D> for next header it is always vectorized. >=20 > I think that we have the same idea, but there are some little differ= ences. >=20 > =3D> the main difference is we are only using options... >=20 > Regards >=20 > Francis.Dupont@enst-bretagne.fr >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --=20 Geraldine TEXIER GET/ENST Bretagne - RSM Department 2 rue de la Ch=E2taigneraie - CS 17607 35576 Cesson Sevign=E9 Cedex- France Tel: +33 299 127 038 - Fax: +33 299 127 030 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 30 00:00:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW4N5-0007oF-CR; Sun, 30 Oct 2005 00:00:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW4N4-0007oA-AC for ipv6@megatron.ietf.org; Sun, 30 Oct 2005 00:00:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11115 for ; Sun, 30 Oct 2005 00:00:18 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EW4av-0000HD-6Z for ipv6@ietf.org; Sun, 30 Oct 2005 00:15:00 -0400 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 0C6C213E1 for ; Sun, 30 Oct 2005 00:00:15 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 30 Oct 2005 00:00:15 -0400 Message-Id: <20051030040015.0C6C213E1@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 30.77% | 4 | 38.83% | 29518 | hwzhj@huawei.com 23.08% | 3 | 22.66% | 17224 | geraldine.texier@enst-bretagne.fr 23.08% | 3 | 18.08% | 13742 | francis.dupont@enst-bretagne.fr 7.69% | 1 | 8.39% | 6377 | internet-drafts@ietf.org 7.69% | 1 | 6.04% | 4593 | syedah@huawei.com 7.69% | 1 | 6.01% | 4570 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 13 |100.00% | 76024 | 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 ipv6-bounces@ietf.org Sun Oct 30 17:00:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWLDk-0007J2-0S; Sun, 30 Oct 2005 17:00:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWLDh-0007IA-MD for ipv6@megatron.ietf.org; Sun, 30 Oct 2005 17:00:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20694 for ; Sun, 30 Oct 2005 16:59:46 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWLRl-0002np-CO for ipv6@ietf.org; Sun, 30 Oct 2005 17:14:37 -0500 Received: by wproxy.gmail.com with SMTP id i23so424400wra for ; Sun, 30 Oct 2005 14:00:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Blzr7OQiJ6zk6tFll9HMJ7x9Pq5O5t/LALQtEWPPXAJTZPNBHWkw6BYdCk6+lykaXEgtx1fjejHLQNAobtDv7SDoJZvp69ip2JNoFnUf+T5HEUKUWw3HyRMY8bMv+R0q8ZyryaoMMUBGx4VuyPsQvsS2YP9ziW3Ylky3Dt/5qCU= Received: by 10.64.210.16 with SMTP id i16mr1016137qbg; Sun, 30 Oct 2005 14:00:02 -0800 (PST) Received: by 10.64.178.1 with HTTP; Sun, 30 Oct 2005 14:00:02 -0800 (PST) Message-ID: <2a86e2e0510301400r716a256cq365ef62c3a9933fd@mail.gmail.com> Date: Mon, 31 Oct 2005 07:00:02 +0900 From: Syed Obaid Amin To: ipv6@ietf.org In-Reply-To: <200510220754.j9M7s1bp063123@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 References: <2a86e2e0510211137q11f464f5l452bb79de00d11d2@mail.gmail.com> <200510220754.j9M7s1bp063123@givry.rennes.enst-bretagne.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: Re: Hop-by-Hop options and Intermediate routers. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0823146308==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0823146308== Content-Type: multipart/alternative; boundary="----=_Part_1069_11121948.1130709602473" ------=_Part_1069_11121948.1130709602473 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Thanks for your reply. >>1: If the sending node doesn't include any Hop-by-Hop option header can intermediate router inject Hop-by-hop options? >=3D> no, it MUST NOT. It could be a part of specification ( because the problem could occur if the packet size exeeds from the MTU ) but how can you restrict a router in between to not change the IPv6 header. Thanks Again Obaid PS: Would anyone please refer any RFC or standard document where it is mention that intermediate router can't add any option. On 10/22/05, Francis Dupont wrote: > > In your previous mail you wrote: > > I have two inter-related issues which are unclear to me in RFC 2460. Woul= d > anyone please clear these ambiguities? > > 1: If the sending node doesn't include any Hop-by-Hop option header can > intermediate router inject Hop-by-hop options? > > =3D> no, it MUST NOT. > > 2: If there is Hop-by-Hop option header present can intermediate router > add > any new option or modify existing options? > > =3D> it MUST NOT add any new option but it MAY modify an existing option > if the option is marked as mutable en route (there is a bit in the type > to recognize such options) and only in the way defined for this option. > Note there is no such option registered by IANA today so it is hard to > give a real example... > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: look at the AH specs (RFC 2402 and I-Ds) for mutable fields in > headers. > ------=_Part_1069_11121948.1130709602473 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi
 
Thanks for your reply.
 
>>1: If the sending node doesn't include= any Hop-by-Hop option header can
  intermediate router inject Hop-= by-hop options?

>=3D> no, it MUST NOT.
 
It could be a part of specification ( because the problem could occur = if the packet size exeeds from the MTU ) but how can you restrict a&nb= sp;router  in between to not change the IPv6 header. 
 
Thanks Again
 
Obaid
 
PS: Would anyone please refer any RFC or standard document where it is= mention that intermediate router can't add any option.

On 10/22/05, Francis Dupont <= Francis.Dupont@enst-bretagne.fr> wrote:
In your previous mail you wrote:=

  I have two inter-related issues which are unclear to me= in RFC 2460. Would
  anyone please clear these ambiguities?

  1= : If the sending node doesn't include any Hop-by-Hop option header can
&= nbsp; intermediate router inject Hop-by-hop options?

=3D> no= , it MUST NOT.

  2: If there is Hop-by-Hop option header p= resent can intermediate router add
  any new option or modify existing options?

=3D> i= t MUST NOT add any new option but it MAY modify an existing option
if th= e option is marked as mutable en route (there is a bit in the type
to re= cognize such options) and only in the way defined for this option.
Note there is no such option registered by IANA today so it is hard to<= br>give a real example...

Regards

Francis.Dupont@enst-bretagne.fr

PS: look= at the AH specs (RFC 2402 and I-Ds) for mutable fields in headers.

------=_Part_1069_11121948.1130709602473-- --===============0823146308== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0823146308==-- From ipv6-bounces@ietf.org Sun Oct 30 22:12:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWQ5v-00077w-3E; Sun, 30 Oct 2005 22:12:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWQ5s-00077D-HO for ipv6@megatron.ietf.org; Sun, 30 Oct 2005 22:12:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05910 for ; Sun, 30 Oct 2005 22:12:01 -0500 (EST) Received: from zorg.st.net.au ([203.16.233.9] helo=borg.st.net.au ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWQJx-0006Fx-0M for ipv6@ietf.org; Sun, 30 Oct 2005 22:26:55 -0500 Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id 1DDB5394D2D; Mon, 31 Oct 2005 13:12:06 +1000 (EST) Received: from anchovy.zoic.org (static-2.241.240.220.dsl.comindico.com.au [220.240.241.2]) by borg.st.net.au (Postfix) with ESMTP id 524E3394CDE; Mon, 31 Oct 2005 13:12:05 +1000 (EST) Received: by anchovy.zoic.org (Postfix, from userid 1000) id C3942702F0D; Mon, 31 Oct 2005 14:12:02 +1100 (EST) Date: Mon, 31 Oct 2005 14:12:02 +1100 From: "Nick 'Sharkey' Moore" To: Christian Vogt Message-ID: <20051031031201.GA14479@zoic.org> Mail-Followup-To: Christian Vogt , IPv6 References: <4353DBE2.4010601@tm.uka.de> <20051019114715.GA4074@zoic.org> <4356B259.4080701@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4356B259.4080701@tm.uka.de> X-URL: http://zoic.org/sharkey/ User-Agent: Mutt/1.5.9i X-Scanned-By: AMaViS-ng at borg.st.net.au X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IPv6 Subject: Re: Comment on draft-ietf-ipv6-optimistic-dad-06.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 2005-10-19, Christian Vogt wrote: > > "The initial Neighbor Solicitation MUST be transmitted as early as > possible after the Optimistic Address has been flagged as 'Optimistic', > but it MUST NOT violate any delays or rate limitations set forth by > RFC2461 or RFC2462. Actually, I disagree. In order to provide timely address configuration, we MUST violate these delays. As I understand it, until we've performed the MLD report, we can't reliably receive NSes ... and thus we may not be able to send our NA(O=0) and can't respond to communications! Also, the longer we delay the NS, the longer we have to wait to discover a collision. This is a big disadvantage to the arriving node, because in the case of a collision it's not getting any traffic. It's also a small disadvantage to the collidee, because it may get traffic which was meant for the arriving ON. I think L2 collision avoidance is best left to L2 in any case. Elimination of these delays was proposed by some "Fast RS" draft or another at some point, although I don't think I ever wrote up the Soft vs. Hard Handover draft I'd been intending to ... -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 31 07:48:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZ5E-0007Sm-AH; Mon, 31 Oct 2005 07:48:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZ5B-0007SS-8q for ipv6@megatron.ietf.org; Mon, 31 Oct 2005 07:48:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04794 for ; Mon, 31 Oct 2005 07:47:54 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+f+eQm72p/d7tMoRgyZWJ2N8+LOTYnnuc=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWZJM-0000c8-Iy for ipv6@ietf.org; Mon, 31 Oct 2005 08:02:53 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1EWZ51-0003b7-Fh; Mon, 31 Oct 2005 13:48:08 +0100 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1EWZ4z-0006UY-Vg; Mon, 31 Oct 2005 13:48:02 +0100 Message-ID: <43661280.9090108@tm.uka.de> Date: Mon, 31 Oct 2005 13:48:00 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Nick 'Sharkey' Moore" References: <4353DBE2.4010601@tm.uka.de> <20051019114715.GA4074@zoic.org> <4356B259.4080701@tm.uka.de> <20051031031201.GA14479@zoic.org> In-Reply-To: <20051031031201.GA14479@zoic.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -22.5 (----------------------) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -18 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: IPv6 Subject: Re: Comment on draft-ietf-ipv6-optimistic-dad-06.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > Actually, I disagree. In order to provide timely address > configuration, we MUST violate these delays. Nick, my assumption in writing the above text passage was that the delays for MLD Reports should be relaxed elsewhere, e.g. as part of RFC2462bis. On the other hand, thinking more about this... ...there was consensus on the IPv6 mailing list [1] not to include any specific support for mobility into the successors to RFC2461/2462. At least, this was said in the context of delays imposed on MLD Report transmissions. (Note: IMO, this is a bit of a bummer, because RFC2461bis already explicitly allows mobile nodes to forego the delay for Router Solicitations; see section 6.3.7 in RFC2461bis. So it could theoretically include an equivilant passage for the MLD Report, too. Anyway...) Instead, the discussion in [1] yielded that mobility optimizations ought to be specified in separate documents. And thinking about this, draft-ietf-ipv6-optimistic-dad-06.txt is actually one such document. So it could/should allow Optimistic Nodes to forego the delays defined in RFC2461[bis] or RFC2462[bis] where necessary and feasible. This said, the revised text passage for draft-ietf-ipv6-optimistic-dad-06.txt could look like this: "The initial Neighbor Solicitation MUST be transmitted as early as possible after the Optimistic Address has been flagged as 'Optimistic'. Where other standards require the Optimistic Node to delay sending the initial Neighbor Solicitation for the purpose of contention resolution, it is RECOMMENDED that the Optimistic Node omit such delays if sufficient means for de-synchronization are provided otherwise. E.g., a mobile node can omit delaying the first message sent upon arrival at a new link [RFC2461] [RFC2462] because mobility generally serves to de-synchronize signaling to an appropriate extent already. Care must be taken, however, not to confuse an initial link attachment after boot-up with a link attachment after movement." Note that this text implicitly attends to delays on MLD Reports as specified in RFC2462bis. It is also general enough to deal with L2 technologies that have no collision avoidance (even though I agree with you that L2 collision avoidance should be left to L2 in any case). One could argue for changing "it is RECOMMENDED that the Optimistic Node omit such delays if..." to "the Optimistic Node MUST omit such delays if...", but I'd prefer the less strict version. Regards, - Christian [1] "Comment on RFCs 2461bis and 2462bis", Discussion on the IPv6 mailing list, May 27, 2005, . -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Nick 'Sharkey' Moore wrote: > On 2005-10-19, Christian Vogt wrote: > >>"The initial Neighbor Solicitation MUST be transmitted as early as >>possible after the Optimistic Address has been flagged as 'Optimistic', >>but it MUST NOT violate any delays or rate limitations set forth by >>RFC2461 or RFC2462. > > > Actually, I disagree. In order to provide timely address configuration, > we MUST violate these delays. > > As I understand it, until we've performed the MLD report, we can't > reliably receive NSes ... and thus we may not be able to send our > NA(O=0) and can't respond to communications! > > Also, the longer we delay the NS, the longer we have to wait to discover > a collision. This is a big disadvantage to the arriving node, because > in the case of a collision it's not getting any traffic. It's also > a small disadvantage to the collidee, because it may get traffic > which was meant for the arriving ON. > > I think L2 collision avoidance is best left to L2 in any case. > Elimination of these delays was proposed by some "Fast RS" draft > or another at some point, although I don't think I ever wrote up > the Soft vs. Hard Handover draft I'd been intending to ... > > -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 31 14:17:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWf9X-0007HP-KO; Mon, 31 Oct 2005 14:17:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWf9V-0007HA-6d for ipv6@megatron.ietf.org; Mon, 31 Oct 2005 14:17:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00630 for ; Mon, 31 Oct 2005 14:16:46 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWfNj-0000FD-2j for ipv6@ietf.org; Mon, 31 Oct 2005 14:31:48 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2005 11:16:55 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,270,1125903600"; d="scan'208"; a="14251421:sNHT39261676" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9VJGRF8017614 for ; Mon, 31 Oct 2005 14:16:53 -0500 (EST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 14:16:52 -0500 Received: from 161.44.65.150 ([161.44.65.150]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Mon, 31 Oct 2005 19:16:51 +0000 Received: from rdroms.dhcp.org by email.cisco.com; 31 Oct 2005 14:17:17 -0500 From: Ralph Droms To: ipv6@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 31 Oct 2005 14:17:17 -0500 Message-Id: <1130786237.5403.39.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) X-OriginalArrivalTime: 31 Oct 2005 19:16:52.0083 (UTC) FILETIME=[A6201430:01C5DE4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: Question about precluding use of autonomous address-configuration X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Suppose the nodes on a link are to be restricted to the use of addresses assigned through DHCP, and precluded from the use of autonomous address- configuration. It seems there are two ways to accomplish this goal: 1) Don't include any prefixes in router advertisements 2) Include the prefixes assigned to the link in router advertisements, with the A (autonomous address-configuration) flag set to FALSE There may be a subtle problem with (2): the text in RFC 2462 does not include RFC 2119 words absolutely precluding the use of autonomous address-configuration: a) If the Autonomous flag is not set, silently ignore the Prefix Information option. Note the lack of "MUST" before "silently ignore". Is there a reason to prefer one of these two ways of precluding the use of autonomous address-configuration? Is there a problem with using technique (1)? - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 31 14:27:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWfK1-0001Vl-Fs; Mon, 31 Oct 2005 14:27:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWfJw-0001UZ-FE for ipv6@megatron.ietf.org; Mon, 31 Oct 2005 14:27:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01375 for ; Mon, 31 Oct 2005 14:27:33 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWfY8-0000yf-6B for ipv6@ietf.org; Mon, 31 Oct 2005 14:42:35 -0500 Received: from jurassic.eng.sun.com ([129.146.68.36]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9VJRlD7005266; Mon, 31 Oct 2005 12:27:47 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9VJRUgs252433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 31 Oct 2005 11:27:34 -0800 (PST) Message-ID: <436661FD.5010403@sun.com> Date: Mon, 31 Oct 2005 10:27:09 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > After thinking about it again, I now tend to feel AI_PREFERENCE does > not sound so ad-hoc. Sine getaddrinfo() is typically expected to > return multiple addresses (of multiple families), ordering among them > is its inherent concern. So, I think I can live with AI_PREFERENCE > (and the corresponding additional field(s) of addrinfo{}). ok > I'm not really sure what "to only define a single AI flag", but yes, > I'm still concerned about having separate flags for both PUBLIC and > TMP (and so on). FWIW I don't understand the first part of that sentence. Missing "means" before the comma? Or something else? > I've been thinking over it again, and I guess the main concerns are as > follows: >=20 > 1. having separate flags cause invalid cases and make sanity checks in > implementations more complex (as I mentioned in the comment > message). But for getaddrinfo I think is an inherent issue. For instance, I don't see how your proposed list of preferences below (in ai_selections) makes it any easier to detect conflicts; it might actually make it harder for all I can tell. > 2. rephrasing this point differently, these are actually not "flags", > but multi(more than 2)-value options. For example, what we are > going to define with IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA > is the source address selection policy from > - prefer home address > - prefer care-of-address > - (perhaps implicitly) use system (or administrator's) default The 3rd is actually the semantics of "leave unchanged". In the case of getaddrinfo this would always mean the system default. But in the case of setsockopt, it would mean to not change the current setting for that preference on the socket. > (I admit this might sound just a "philosophical" argument.) >=20 > As far as I know, in the traditional API design we have been using a > separate socket option type for each optional notion (in this case the > address selection policy). Examples include the IPV6_MULTICAST_LOOP > option (while it does not have a specific "use default" value) and the > IPV6_{UNICAST,MULTICAST}_HOPS options (while these have more than two > possible values). Yes, one can produce a functional setsockopt setting of preferences by using a separate socket option for each preference. Thus int on =3D 1; setsockopt(s, IPPROTO_IPV6, IPV6_PREFER_COA, &on, sizeof(on)); to prefer CoA over HOA and int off =3D 0; setsockopt(s, IPPROTO_IPV6, IPV6_PREFER_COA, &off, sizeof(off)); to turn it off, and likewise for the separate socket options for IPV6_PREFER_TMP, IPV6_PREFER_CGA, etc. That would imply a large number of separate socket options. But the important thing is that such a change could have no impact on how we specify getaddrinfo(), since there we have to be able to specify everything in a single call. > I speculate one of the reasons why we've been adhering to the use of > "flags" is because we need to do the similar thing for getaddrinfo() > and the only available field to pass this information was a "flag" > field at that time. If my understanding is correct, and if we agree > on some (more flexible) extensions to the addrinfo structure, we may > be able to take a different approach. > For example, we'd be able to specify each policy as an integer > encoding a type-value pair, and specify the set of policies as an > array of the pairs. The following describes one possible > implementation of this idea. >=20 > typedef struct { > u_int32_t policyname : 30; > u_int32_t policyvalue : 2; > } ai_selection_t; >=20 > struct addrinfo { > int ai_flags; /* AI_PASSIVE, AI_CANONNAME, > AI_NUMERICHOST, .. */ > (snip) > ai_selection_t *ai_selection; /* examined only when AI_PREFERENCE is > set and ai_selection is non NULL */ > }; >=20 > An application that prefers care-of-address over home-address would > do: >=20 > struct addrinfo hints; > ai_selection_t ai_selections[2]; >=20 > ai_selections[0].policyname =3D AI_SELECTION_MIP; > ai_selections[0].policyvalue =3D AI_SELECTION_PREFER_COA; >=20 > /* AI_SELECTION_NULL is a terminating marker */ > ai_selections[1].policyname =3D AI_SELECTION_NULL; > ai_selections[1].policyvalue =3D 0; >=20 > hints.ai_flags |=3D AI_PREFERENCE; > hints.ai_selection =3D ai_selections; >=20 > How about something like this? One may regard this as an > overly-generalized solution, but I believe this solves all technical > concerns pointed out so far. I don't see how this is any simpler. The implementation becomes more complex because it needs to handle an array of preferences instead of a single value. And the implementation still need to have checks against specifying different values for the same preference, doesn't it? For example, if the application does ai_selections[0].policyname =3D AI_SELECTION_MIP; ai_selections[0].policyvalue =3D AI_SELECTION_PREFER_COA; ai_selections[1].policyname =3D AI_SELECTION_MIP; ai_selections[1].policyvalue =3D AI_SELECTION_PREFER_HOME; /* AI_SELECTION_NULL is a terminating marker */ ai_selections[2].policyname =3D AI_SELECTION_NULL; ai_selections[2].policyvalue =3D 0; So I don't see the gain in such added generality over a single ai_preference field. And I see a disadvantage in having getaddrinfo preferences and setsockopt preferences working in a different way, since it is the application programmer that needs to deal with that. The simplest approach for the application programmer would be to define a single name space for IPV6_ADDR_PREFER_*, and use that both in ai_preferences and with setsockopt. In such a case the application code would be along the lines of int preferences =3D IPV6_PREFER_COA | IPV6_PREFER_TMP; hints.ai_flags |=3D AI_PREFERENCE; hints.ai_preferences =3D preferences; getaddrinfo(...); /* Loop over all returned addresses */ while (ai !=3D NULL) { s =3D socket(ai->ai_family, ...); setsockopt(s, IPV^_PREFERENCES, &preferences, sizeof (preferences)); if (connect(s, ai->ai_addr, ai->ai_addrlen) =3D=3D -1) continue; break; } =09 Such code would be more complex for all the other approaches we've discussed. And the single preference name space would make it easier to provide a int connect_by_name(char *hostname, int port, int preferences); library function (which would help move the complexity of trying multiple addresses out of the applications). Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 31 14:29:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWfLp-0002H5-Lt; Mon, 31 Oct 2005 14:29:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWfLm-0002GS-Ts for ipv6@megatron.ietf.org; Mon, 31 Oct 2005 14:29:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01782 for ; Mon, 31 Oct 2005 14:29:27 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWfZz-00019m-Um for ipv6@ietf.org; Mon, 31 Oct 2005 14:44:30 -0500 Received: from jurassic.eng.sun.com ([129.146.68.36]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9VJTZ3F017776; Mon, 31 Oct 2005 12:29:35 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9VJTO8x259871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 31 Oct 2005 11:29:28 -0800 (PST) Message-ID: <43666270.5030903@sun.com> Date: Mon, 31 Oct 2005 10:29:04 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I have list of intended edits based on the bulk of your comments. Here are some comments on the non-trivial parts. JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > I'm afraid you misunderstood my point. (Perhaps the additional > question obscured the main point...) My main question is: >=20 > In my understanding, if either of the flags of a particular rule is > off, it means the system default should be used for that rule. For > example, if 'flags =3D IPV6_PREFER_SRC_TMP', then the system default > will apply for HOME vs COA, CGA vs NONCGA, etc. Is that correct? > If so, when an application wants to make the rules revert to system > default, it should be able to call setsockopt without setting any > flag, shouldn't it? Or in other wise, it does not have to remember > the old rule values by calling getsockopt beforehand for this > purpose. No, it isn't "apply system default", it is "leave unchanged". Given that a socket starts with the system default, then subsequent setsockopts of IPV6_PREFERENCES can be used to tweak different preferences; one setsockopt can specify public vs. tmp preferences, and a different setsockopt can specify home vs. coa. > Maybe we can simply say the sending host cannot *always* detect > whether the destination is reached via tunnel. Additional explanation > you mentioned above may also help, but I don't have a particular > opinion on how much of the details we should provide here. ok > Yes, and this leads me to think we should rather define other variants > of IN6_IS_ADDR_xxx(). That is, >=20 > in6_is_addr_home() > in6_is_addr_careof() > in6_is_addr_temporary() > in6_is_addr_cga() You mean that each of those would just take an struct sockaddr * as an argument? And return true/false? What if the address in question isn't even assigned to the host i.e. the host can't determine whether it is of a particular category? > etc. Or, it's probably better not to adhere to recycling the > IPV6_PREFER_xxx "flags" for multiple purposes, and consider something > like this: >=20 > int in6_getaddrattr(struct sockaddr_in6 *addr, uint32_t *attrp); >=20 > On success, this function returns 0 and sets the "attributes" of the > address as bit-wise flags in '*attrp'. The flags are, for example, >=20 > IN6_ADDRATTR_HOME > IN6_ADDRATTR_COA (not sure if we need this in addition to HOME > though) > IN6_ADDRATTR_TMP > IN6_ADDRATTR_CGA This seems like more work than definining a handful of specific in6_is_addr_*() functions. I'm not sure this generality is worth-while. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 31 14:29:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWfLx-0002Li-Kb; Mon, 31 Oct 2005 14:29:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWfLw-0002LW-98 for ipv6@megatron.ietf.org; Mon, 31 Oct 2005 14:29:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01821 for ; Mon, 31 Oct 2005 14:29:36 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWfa6-0001Ab-TX for ipv6@ietf.org; Mon, 31 Oct 2005 14:44:39 -0500 Received: from jurassic.eng.sun.com ([129.146.226.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9VJTodK027759; Mon, 31 Oct 2005 11:29:50 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9VJTgWY261078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 31 Oct 2005 11:29:46 -0800 (PST) Message-ID: <43666282.4050805@sun.com> Date: Mon, 31 Oct 2005 10:29:22 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Samita Chakrabarti , julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org INMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > As for the relevance to the addrselct API, I was confused about one > point. New applications that support this API would probably test the > availability of the flag first like this: >=20 > hints.ai_flags =3D 0; > #ifdef AI_NEWFLAG > hints.ai_flags |=3D AI_NEWFLAG; > #endif > getaddrinfo(..., &hints, ..); >=20 > Thus, the problem occurs only when the flag definition and the > getaddrinfo() implementation are inconsistent (as Mark pointed out). > It would be fair to say such inconsistency is a bug and ignore such a > case. >=20 > I think it's still helpful if the addrselect document assumes the > consistency between the supported flag definitions and the > getaddrinfo() implementation. We can add this to the document. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 31 15:27:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgFp-0007H6-Oc; Mon, 31 Oct 2005 15:27:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgFn-0007FG-GF for ipv6@megatron.ietf.org; Mon, 31 Oct 2005 15:27:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05729 for ; Mon, 31 Oct 2005 15:27:17 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWgTx-00078F-9c for ipv6@ietf.org; Mon, 31 Oct 2005 15:42:20 -0500 Received: from jurassic.eng.sun.com ([129.146.104.45]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9VKRV3F011896; Mon, 31 Oct 2005 13:27:31 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9VKROWO378847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 31 Oct 2005 12:27:28 -0800 (PST) Message-ID: <436614C6.7040408@sun.com> Date: Mon, 31 Oct 2005 04:57:42 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= References: <200510202238.j9KMcBWx267691@jurassic.eng.sun.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.6 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Samita Chakrabarti , julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > As for the relevance to the addrselct API, I was confused about one > point. New applications that support this API would probably test the > availability of the flag first like this: >=20 > hints.ai_flags =3D 0; > #ifdef AI_NEWFLAG > hints.ai_flags |=3D AI_NEWFLAG; > #endif > getaddrinfo(..., &hints, ..); >=20 > Thus, the problem occurs only when the flag definition and the > getaddrinfo() implementation are inconsistent (as Mark pointed out). > It would be fair to say such inconsistency is a bug and ignore such a > case. >=20 > I think it's still helpful if the addrselect document assumes the > consistency between the supported flag definitions and the > getaddrinfo() implementation. We can add this to the document. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 31 16:23:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgwJ-0002ho-4R; Mon, 31 Oct 2005 16:11:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgwG-0002gi-UY for ipv6@megatron.ietf.org; Mon, 31 Oct 2005 16:11:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10172 for ; Mon, 31 Oct 2005 16:11:10 -0500 (EST) Received: from mail2.fluidhosting.com ([204.14.90.62]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWhAQ-0004mA-N4 for ipv6@ietf.org; Mon, 31 Oct 2005 16:26:14 -0500 Received: (qmail 6461 invoked by uid 399); 31 Oct 2005 21:11:05 -0000 Received: from localhost (HELO ?192.168.1.101?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 31 Oct 2005 21:11:05 -0000 Message-ID: <43668867.9050105@dougbarton.us> Date: Mon, 31 Oct 2005 13:11:03 -0800 From: Doug Barton Organization: http://dougbarton.us/ User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms References: <1130786237.5403.39.camel@localhost.localdomain> In-Reply-To: <1130786237.5403.39.camel@localhost.localdomain> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Question about precluding use of autonomous address-configuration X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Ralph Droms wrote: > Suppose the nodes on a link are to be restricted to the use of addresses > assigned through DHCP, and precluded from the use of autonomous address- > configuration. I can also think of a third case, addresses are assigned statically. > It seems there are two ways to accomplish this goal: > > 1) Don't include any prefixes in router advertisements > > 2) Include the prefixes assigned to the link in router advertisements, > with the A (autonomous address-configuration) flag set to FALSE > > There may be a subtle problem with (2): the text in RFC 2462 does not > include RFC 2119 words absolutely precluding the use of autonomous > address-configuration: > > a) If the Autonomous flag is not set, silently ignore the > Prefix Information > option. > > Note the lack of "MUST" before "silently ignore". > > Is there a reason to prefer one of these two ways of precluding the use > of autonomous address-configuration? I think that having a clean way of distinguishing "this is information only" from "use this prefix" in RA is a good thing, so I'd prefer option 2. I can think of several ways in which knowing the prefix would be useful to a host that is not doing autoconf. One off the cuff example would be configuring a host to append some static bits to whatever prefix is announced by the router. hth, Doug -- If you're never wrong, you're not trying hard enough -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 31 17:05:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhme-0007Ik-AR; Mon, 31 Oct 2005 17:05:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhmb-0007IQ-WB for ipv6@megatron.ietf.org; Mon, 31 Oct 2005 17:05:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14878 for ; Mon, 31 Oct 2005 17:05:17 -0500 (EST) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWi0r-00034g-9G for ipv6@ietf.org; Mon, 31 Oct 2005 17:20:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Oct 2005 17:04:17 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73C2F12C@PACDCEXCMB01.cable.comcast.com> Thread-Topic: Question about precluding use of autonomous address-configuration Thread-Index: AcXeT/4jug1O7CUqRNqy7WUMQF5wfQAFwuAR From: "Durand, Alain" To: , X-OriginalArrivalTime: 31 Oct 2005 22:04:17.0269 (UTC) FILETIME=[0985D250:01C5DE67] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: Re: Question about precluding use of autonomous address-configuration X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0868421316==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0868421316== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhlIGZvbGxvdyB1cCBxdWVzdGlvbiBpczoNCkhhdmUgaG9zdCBnZW5lcmFsbHkgaW1wbGVtZW50 ZWQgdGhlIGNoZWNrIG9mIHRoZSBBIGJpdCBpbiBSQSBhbmQgaGFzIHRoaXMgYmVlbiB0ZXN0ZWQg YXQgVU5IL1RBSEkvRVRTSS8uLi4gDQoNCiAgICAgLSBBbGFpbi4NCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogaXB2Ni1ib3VuY2VzQGlldGYub3JnIDxpcHY2LWJvdW5jZXNA aWV0Zi5vcmc+DQpUbzogaXB2NkBpZXRmLm9yZyA8aXB2NkBpZXRmLm9yZz4NClNlbnQ6IE1vbiBP Y3QgMzEgMTQ6MTc6MTcgMjAwNQ0KU3ViamVjdDogUXVlc3Rpb24gYWJvdXQgcHJlY2x1ZGluZyB1 c2Ugb2YgYXV0b25vbW91cyBhZGRyZXNzLWNvbmZpZ3VyYXRpb24NCg0KU3VwcG9zZSB0aGUgbm9k ZXMgb24gYSBsaW5rIGFyZSB0byBiZSByZXN0cmljdGVkIHRvIHRoZSB1c2Ugb2YgYWRkcmVzc2Vz DQphc3NpZ25lZCB0aHJvdWdoIERIQ1AsIGFuZCBwcmVjbHVkZWQgZnJvbSB0aGUgdXNlIG9mIGF1 dG9ub21vdXMgYWRkcmVzcy0NCmNvbmZpZ3VyYXRpb24uDQoNCkl0IHNlZW1zIHRoZXJlIGFyZSB0 d28gd2F5cyB0byBhY2NvbXBsaXNoIHRoaXMgZ29hbDoNCg0KMSkgRG9uJ3QgaW5jbHVkZSBhbnkg cHJlZml4ZXMgaW4gcm91dGVyIGFkdmVydGlzZW1lbnRzDQoNCjIpIEluY2x1ZGUgdGhlIHByZWZp eGVzIGFzc2lnbmVkIHRvIHRoZSBsaW5rIGluIHJvdXRlciBhZHZlcnRpc2VtZW50cywNCiAgIHdp dGggdGhlIEEgKGF1dG9ub21vdXMgYWRkcmVzcy1jb25maWd1cmF0aW9uKSBmbGFnIHNldCB0byBG QUxTRQ0KDQpUaGVyZSBtYXkgYmUgYSBzdWJ0bGUgcHJvYmxlbSB3aXRoICgyKTogdGhlIHRleHQg aW4gUkZDIDI0NjIgZG9lcyBub3QNCmluY2x1ZGUgUkZDIDIxMTkgd29yZHMgYWJzb2x1dGVseSBw cmVjbHVkaW5nIHRoZSB1c2Ugb2YgYXV0b25vbW91cw0KYWRkcmVzcy1jb25maWd1cmF0aW9uOg0K DQogICAgYSkgSWYgdGhlIEF1dG9ub21vdXMgZmxhZyBpcyBub3Qgc2V0LCBzaWxlbnRseSBpZ25v cmUgdGhlDQogICAgICAgUHJlZml4IEluZm9ybWF0aW9uDQogICAgICAgb3B0aW9uLg0KDQpOb3Rl IHRoZSBsYWNrIG9mICJNVVNUIiBiZWZvcmUgInNpbGVudGx5IGlnbm9yZSIuDQoNCklzIHRoZXJl IGEgcmVhc29uIHRvIHByZWZlciBvbmUgb2YgdGhlc2UgdHdvIHdheXMgb2YgcHJlY2x1ZGluZyB0 aGUgdXNlDQpvZiBhdXRvbm9tb3VzIGFkZHJlc3MtY29uZmlndXJhdGlvbj8gIElzIHRoZXJlIGEg cHJvYmxlbSB3aXRoIHVzaW5nDQp0ZWNobmlxdWUgKDEpPw0KDQotIFJhbHBoDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmcN CkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K --===============0868421316== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0868421316==--