From owner-v6ops@ops.ietf.org Thu Jul 1 05:31:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08250 for ; Thu, 1 Jul 2004 05:31:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfxqL-0006Vh-7U for v6ops-data@psg.com; Thu, 01 Jul 2004 09:26:57 +0000 Received: from [63.103.94.23] (helo=ftmailgfi.HQ.Flarion.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfxqJ-0006VE-W4 for v6ops@ops.ietf.org; Thu, 01 Jul 2004 09:26:56 +0000 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Jul 2004 05:26:52 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Moving forward Date: Thu, 1 Jul 2004 05:26:51 -0400 Message-ID: Thread-Topic: Moving forward Thread-Index: AcRfAGWU2grloggoQ5iqAo+xoo0IkgAS0Y1g From: "Soliman Hesham" To: "David Kessens" , X-OriginalArrivalTime: 01 Jul 2004 09:26:52.0791 (UTC) FILETIME=[8B548870:01C45F4D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable David,=20 > it is now getting time that we start to move from the analysis phase > to standarization. As you all know, in general the Operations area > doesn't design new protocols. This means we cannot standarize the > solutions in the v6ops working group. =3D> Does this mean that proposals like Teredo will not be=20 standardised in this Area?=20 Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=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 From owner-v6ops@ops.ietf.org Thu Jul 1 05:44:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09105 for ; Thu, 1 Jul 2004 05:44:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfy50-0007jc-KP for v6ops-data@psg.com; Thu, 01 Jul 2004 09:42:06 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfy4z-0007jH-8r for v6ops@ops.ietf.org; Thu, 01 Jul 2004 09:42:05 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i619g4nE005070 for ; Thu, 1 Jul 2004 10:42:04 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA03817 for ; Thu, 1 Jul 2004 10:42:01 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i619g1h25458 for v6ops@ops.ietf.org; Thu, 1 Jul 2004 10:42:01 +0100 Date: Thu, 1 Jul 2004 10:42:01 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Moving forward Message-ID: <20040701094201.GD24721@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Jul 01, 2004 at 05:26:51AM -0400, Soliman Hesham wrote: > David, > > > > it is now getting time that we start to move from the analysis phase > > to standarization. As you all know, in general the Operations area > > doesn't design new protocols. This means we cannot standarize the > > solutions in the v6ops working group. > > => Does this mean that proposals like Teredo will not be > standardised in this Area? I am confused, why was the transition work moved to Operations Area then if there actually was never any way we could specify new mechanisms or finalise existing ones? And why talk of a temporary ban when it could never have been lifted in the v6ops WG? This seems wrong, we should have made an "IPv6 Transition" WG under the Internet Area. I recall the reasoning for v6ops at the time was to send the message that "IPv6 is operational", which is good, but apparently it was in fact a curse :( It's a shame some of these little IETF rules aren't known by everyone... Tim From owner-v6ops@ops.ietf.org Thu Jul 1 05:45:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09189 for ; Thu, 1 Jul 2004 05:45:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfy62-0007pH-Ax for v6ops-data@psg.com; Thu, 01 Jul 2004 09:43:10 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfy5r-0007o0-TP for v6ops@ops.ietf.org; Thu, 01 Jul 2004 09:43:00 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.1.R) with ESMTP id md50000092816.msg for ; Thu, 01 Jul 2004 11:45:20 +0200 Message-ID: <052a01c45f4f$c5949280$d60b12ac@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20040701000254.GA11822@nokia.com> Subject: Re: Moving forward Date: Thu, 1 Jul 2004 11:42:36 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 01 Jul 2004 11:45:20 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 80.133.106.95 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Thu, 01 Jul 2004 11:45:24 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi David, I will strongly prefer a re-chartering. It will be faster than any other option. We have already the experience of the time needed from ngtrans to v6ops and I don't think we want to move again to another similar experience. Otherwise we will keep deploying IPv6 w/o standards, and this is not good at all. Regards, Jordi ---- Original Message ---- From: "David Kessens" To: Sent: Thursday, July 01, 2004 2:02 AM Subject: Moving forward > The v6ops working group is getting closer to finishing all it's work > items. This obviously means that an old question is rightfully > surfacing again: which proposed solutions do we need for which > scenario, and the follow up question, will we standarize this > solution and where ? >=20 > All this hard work has helped to have a better understanding on which > minimum set of mechanisms need standarization. It is pretty clear that > it is now getting time that we start to move from the analysis phase > to standarization. As you all know, in general the Operations area > doesn't design new protocols. This means we cannot standarize the > solutions in the v6ops working group. However, the ADs would like to > hear officially from the working group what protocols need > standarization for which scenario. After that, the IESG can decide to > accept that work in an existing working group in another area, a new > working group can be formed or the work can proceed without > the need for a working group. >=20 > It is not going to be an easy task to reach consensus on each and > every scenario and which solution(s) is/are most appropriate. In the > interest of making progress it seems best in cases where no quick > consensus can be reached to document the disagreement with pros and > cons and move on. I expect to have results ready fairly soon after the > IETF in San Diego. This process should result in a recommendation from > the working group on which minimum set of protocols need to be > standarized and which proposals didn't reach consensus but could be > useful. Criteria used should involve (among others): simplicity, can > this problem already be solved with a different solution that can be used > in multiple cases?, security and proven to work in practise (running > code).=20 >=20 > Most likely, there will be a group of proposals for solutions that are > not going to be choosen by the working group due to lack of consensus > on the need for standarization or the fact that they are not the > preferred solution. >=20 > In such cases, I would nevertheless like to get them published > through the rfc-editor as an informational or experimental rfc. > However, if there is significant support for the document, it got > quite some review in the IETF and/or multiple implementations exist, > the ADs might decide to propose to the IESG to use a modified > to-be-developed boilerplate that takes the above in consideration. >=20 > I hope this helps, >=20 > David Kessens > --- ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Jul 1 16:25:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29927 for ; Thu, 1 Jul 2004 16:25:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bg840-000MG1-KJ for v6ops-data@psg.com; Thu, 01 Jul 2004 20:21:44 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bg83z-000MFf-3E for v6ops@ops.ietf.org; Thu, 01 Jul 2004 20:21:43 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i61KLf211121; Thu, 1 Jul 2004 23:21:41 +0300 (EET DST) X-Scanned: Thu, 1 Jul 2004 23:20:57 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i61KKvC8032696; Thu, 1 Jul 2004 23:20:57 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00KYE2Bx; Thu, 01 Jul 2004 23:20:57 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i61KKuH00371; Thu, 1 Jul 2004 23:20:56 +0300 (EET DST) Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.140]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Jul 2004 15:20:54 -0500 Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id i61KKsje016561; Thu, 1 Jul 2004 13:20:54 -0700 Received: (from kessens@localhost) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id i61KKsfn016559; Thu, 1 Jul 2004 13:20:54 -0700 Date: Thu, 1 Jul 2004 13:20:54 -0700 From: David Kessens To: Soliman Hesham Cc: v6ops@ops.ietf.org Subject: Re: Moving forward Message-ID: <20040701202053.GA16500@nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 01 Jul 2004 20:20:54.0481 (UTC) FILETIME=[E9333C10:01C45FA8] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hesham, On Thu, Jul 01, 2004 at 05:26:51AM -0400, Soliman Hesham wrote: > > > it is now getting time that we start to move from the analysis phase > > to standarization. As you all know, in general the Operations area > > doesn't design new protocols. This means we cannot standarize the > > solutions in the v6ops working group. > > => Does this mean that proposals like Teredo will not be > standardised in this Area? We first need to officially hear from the working group which ones are going to be needed for the minimum set, than we can decide on the exact logistics for how the work will proceed. I have asked the workinggroup chairpeople to do this in manner that allows us to quickly move forward. In general, protocol work will indeed not happen in the Operations area. However, the careful reader will note that I used 'in general' and there could be circumstances where there is more expertise in this area and where it is more efficient to do the work in this area. David Kessens --- From owner-v6ops@ops.ietf.org Thu Jul 1 16:33:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00392 for ; Thu, 1 Jul 2004 16:33:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bg8Eh-000NTS-OY for v6ops-data@psg.com; Thu, 01 Jul 2004 20:32:47 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bg8Ee-000NSj-8W for v6ops@ops.ietf.org; Thu, 01 Jul 2004 20:32:44 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i61KWfN23467 for ; Thu, 1 Jul 2004 23:32:41 +0300 (EET DST) X-Scanned: Thu, 1 Jul 2004 23:32:28 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i61KWSCp024293 for ; Thu, 1 Jul 2004 23:32:28 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00blH6Y1; Thu, 01 Jul 2004 23:32:28 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i61KWQH07526 for ; Thu, 1 Jul 2004 23:32:27 +0300 (EET DST) Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.140]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Jul 2004 15:31:41 -0500 Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id i61KVfje016628 for ; Thu, 1 Jul 2004 13:31:41 -0700 Received: (from kessens@localhost) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id i61KVfca016626 for v6ops@ops.ietf.org; Thu, 1 Jul 2004 13:31:41 -0700 Date: Thu, 1 Jul 2004 13:31:41 -0700 From: David Kessens To: v6ops@ops.ietf.org Subject: Re: Moving forward Message-ID: <20040701203141.GB16500@nokia.com> References: <20040701094201.GD24721@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040701094201.GD24721@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 01 Jul 2004 20:31:41.0784 (UTC) FILETIME=[6B05D580:01C45FAA] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Tim, On Thu, Jul 01, 2004 at 10:42:01AM +0100, Tim Chown wrote: > > I am confused, why was the transition work moved to Operations Area then if > there actually was never any way we could specify new mechanisms or finalise > existing ones? And why talk of a temporary ban when it could never have > been lifted in the v6ops WG? My message was about 'moving forward'. This process will allow us to finally start moving proposals towards standards track. David Kessens --- From owner-v6ops@ops.ietf.org Thu Jul 1 19:57:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09708 for ; Thu, 1 Jul 2004 19:57:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgBOx-000Mrv-J7 for v6ops-data@psg.com; Thu, 01 Jul 2004 23:55:35 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgBOv-000MrI-1k for v6ops@ops.ietf.org; Thu, 01 Jul 2004 23:55:33 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i61NtWnE021637 for ; Fri, 2 Jul 2004 00:55:32 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id AAA02592 for ; Fri, 2 Jul 2004 00:55:27 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i61NtRD13677 for v6ops@ops.ietf.org; Fri, 2 Jul 2004 00:55:27 +0100 Date: Fri, 2 Jul 2004 00:55:27 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Message-ID: <20040701235527.GH13024@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Jun 30, 2004 at 02:02:39PM -0400, Margaret Wasserman wrote: > > I believe that this scenario is an interesting and important scenario > to explore. How will people who are running highly secure/mobile > networks today transition to IPv6? Margaret, I agree. This should remain in the draft. This example puts IPv6-only network infrastructure, with dual-stack nodes, on the radar for the solution space, and that is important, whether it's a military network or an Asian academic network. I suspect there is some resistance because some people feel IPv6-only infrastructure is too early to consider. I would disagree. For example, the Chinese academic CERNET 2 network is IPv6-only, and is live now (but I don't know whether the sites/universities are IPv6-only infrastructure, but they're probably closer to doing it than any non-Asian academic sites). We have to think global in the scoping and solution space. Tim From owner-v6ops@ops.ietf.org Thu Jul 1 19:57:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09726 for ; Thu, 1 Jul 2004 19:57:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgBQT-000N5w-Pn for v6ops-data@psg.com; Thu, 01 Jul 2004 23:57:09 +0000 Received: from [63.103.94.23] (helo=ftmailgfi.HQ.Flarion.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgBQS-000N5d-Ka for v6ops@ops.ietf.org; Thu, 01 Jul 2004 23:57:08 +0000 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Jul 2004 19:57:06 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Moving forward Date: Thu, 1 Jul 2004 19:57:06 -0400 Message-ID: Thread-Topic: Moving forward Thread-Index: AcRfqQyyqR0NNEXuSd6rVbf652CU0wAG8/qQ From: "Soliman Hesham" To: "David Kessens" CC: X-OriginalArrivalTime: 01 Jul 2004 23:57:06.0533 (UTC) FILETIME=[1D254950:01C45FC7] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > We first need to officially hear from the working group=20 > which ones are > going to be needed for the minimum set, than we can decide on the > exact logistics for how the work will proceed. I have asked the > workinggroup chairpeople to do this in manner that allows us to > quickly move forward. =3D> Understood, but see below. >=20 > In general, protocol work will indeed not happen in the Operations > area. However, the careful reader will note that I used 'in general' > and there could be circumstances where there is more=20 > expertise in this > area and where it is more efficient to do the work in this area. =3D> I certainly noticed 'in general' and it scares me!=20 I know that you're trying to be flexible and not categorically=20 rule things out, however, I hope you can appreciate that this might make things quite blurry and give the wrong=20 impression to people. Given the lack of appreciation of WG members' opinions in this WG, I'm worried that this process will be messy, but I'll wait and see.=20 FWIW, there was unanymous concensus in the Seoul meeting to standardise all mechanisms being considered at the moment Hesham >=20 > David Kessens > --- >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=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 From owner-v6ops@ops.ietf.org Thu Jul 1 20:28:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11049 for ; Thu, 1 Jul 2004 20:28:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgBsd-0001JF-S3 for v6ops-data@psg.com; Fri, 02 Jul 2004 00:26:15 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgBsc-0001J0-F4 for v6ops@ops.ietf.org; Fri, 02 Jul 2004 00:26:14 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i620QDnE022065 for ; Fri, 2 Jul 2004 01:26:13 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id BAA02841 for ; Fri, 2 Jul 2004 01:26:10 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i620QA614324 for v6ops@ops.ietf.org; Fri, 2 Jul 2004 01:26:10 +0100 Date: Fri, 2 Jul 2004 01:26:10 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Message-ID: <20040702002610.GJ13024@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B067CCBD8@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CCBD8@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, It looks good to go. Very minor comment (can be ignored if we want to get the draft published :) Perhaps Section 3.1 could be clearer - is the correct interpretation: Scenario 1: Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable hosts and network infrastructure. Scenario 2: Sparse IPv6 dual-stack deployment in IPv4 network infrastructure. Scenario 3: IPv6-only network infrastructure with some IPv4-capable nodes/applications needing to communicate over the IPv6 infrastructure. If so, then " Scenario 3: Enterprise deploying a new network or re-structuring an existing network, decides IPv6 is the basis for most network communication, to coexist with IPv4." might be better as: " Scenario 3: Enterprise deploying a new network or re-structuring an existing network, decides IPv6 is the basis for most network communication. Some IPv4 capable nodes/applications will need to communicate over that infrastructure. Or is that the wrong intepretation? Finally, how does communication between IPv4-only and IPv6-only nodes or applications fit into the above three scenarios, if any of them? Would that be part of Scenario 3? Perhaps make that clearer? Section 3.1 is actually quite heavily the key in which mechanisms are favoured, so the wording is very important. Tim On Tue, Jun 29, 2004 at 12:30:26AM -0400, Bound, Jim wrote: > WG, > > Chairs asked me to send this note to you. Updated spec below. First > error below I am just the editor see authors in the spec. What we did > and I as editor is took 100% Alain's and Pekka's input as best we could > for additional clarity. But, in section 4 we put additional note that > this section is more of an overview that the reader must look at as > components and all the components would fill up many pages (as all > scenarios) and more of that is analysis as opposed to defining a > scenario, and analysis is the next step. We also added normative > references we felt were applicable to the spec that exist and talk about > the general subject (e.g. DNS, Applications). I as one author may not > be able to respond to mail this week as I am abroad in Europe, but will > do my best. > > Regards, > /jim > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Monday, June 28, 2004 3:31 PM > To: i-d-announce@ietf.org > Cc: v6ops@ops.ietf.org > Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : IPv6 Enterprise Network Scenarios > Author(s) : J. Bound > Filename : draft-ietf-v6ops-ent-scenarios-03.txt > Pages : 16 > Date : 2004-6-28 > > This document describes the scenarios for IPv6 deployment within > Enterprise networks. It will focus upon an Enterprise set of network > base scenarios with assumptions, coexistence with legacy IPv4 nodes, > networks, and applications, and network infrastructure requirements. > These requirements will be used to provide analysis to determine a set > of Enterprise solutions in a later document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-03.tx > t > > 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-v6ops-ent-scenarios-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-v6ops@ops.ietf.org Thu Jul 1 20:29:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11090 for ; Thu, 1 Jul 2004 20:29:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgBuP-0001QG-9m for v6ops-data@psg.com; Fri, 02 Jul 2004 00:28:05 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgBuO-0001Q1-67 for v6ops@ops.ietf.org; Fri, 02 Jul 2004 00:28:04 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i620S3nE022075 for ; Fri, 2 Jul 2004 01:28:03 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id BAA02859 for ; Fri, 2 Jul 2004 01:28:00 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i620S0e14340 for v6ops@ops.ietf.org; Fri, 2 Jul 2004 01:28:00 +0100 Date: Fri, 2 Jul 2004 01:28:00 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Message-ID: <20040702002800.GK13024@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Jun 29, 2004 at 01:44:16PM -0400, Margaret Wasserman wrote: > > How about this? > > This document describes the scenarios for IPv6 deployment within > enterprise networks. It defines a small set of basic enterprise > scenarios and includes pertinent questions to allow enterprise > administrators to further refine their deployment scenarios. Enterprise > deployment requirements are discussed in terms of coexistence with > IPv4 nodes, networks and applications, and in terms of basic network > infrastructure requirements for IPv6 deployment. The scenarios and > requirements described in this document will be the basis for further > analysis to determine what coexistence techniques and mechanisms > are needed for enterprise IPv6 deployment. The results of that analysis > will be published in a separate document. Good. Tim From owner-v6ops@ops.ietf.org Fri Jul 2 00:21:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21463 for ; Fri, 2 Jul 2004 00:21:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgFVe-000P6d-Jv for v6ops-data@psg.com; Fri, 02 Jul 2004 04:18:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgFVc-000P66-VI for v6ops@ops.ietf.org; Fri, 02 Jul 2004 04:18:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i624IcO06956; Fri, 2 Jul 2004 07:18:38 +0300 Date: Fri, 2 Jul 2004 07:18:38 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: David Kessens , Subject: RE: Moving forward In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 1 Jul 2004, Soliman Hesham wrote: > FWIW, there was unanymous concensus in the Seoul meeting > to standardise all mechanisms being considered at the moment Nope -- I don't recall anything like that. Could you elaborate using the minutes when you believe that kind of consensus was achieved or even asked. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jul 2 01:04:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22497 for ; Fri, 2 Jul 2004 01:04:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgGCT-0003Bn-Rc for v6ops-data@psg.com; Fri, 02 Jul 2004 05:03:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgGCS-0003BS-E4 for v6ops@ops.ietf.org; Fri, 02 Jul 2004 05:03:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6252lc07582; Fri, 2 Jul 2004 08:02:47 +0300 Date: Fri, 2 Jul 2004 08:02:47 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: "Soininen Jonne (Nokia-NET/Helsinki)" , "ext Bound, Jim" , Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Wed, 30 Jun 2004, Margaret Wasserman wrote: > At 9:03 AM +0300 6/30/04, Pekka Savola wrote: > >I don't think this addresses my personal comments. The most important > >of them, an applicability statement about a security defence network > >(supported by Richard Graveman at least), hasn't been included. > > I apologize, but I think I missed what you suggested for an > applicability statement for the Security Defense network... Could > you summarize? I did this on May 25, and Richard Graveman agreed. A suggestion was adding a paragraph like: Note that these kind of networks are uncommon and unfit to be a model or example for deployment for enterprises in general. However, due to their importance to the vendor community, their requirements should be considered explicitly. As you see, I'm not arguing that the example needs to be removed (though I wouldn't object :), but that it's made crystal clear that the example might not be a basis for *generalizing* how we would be deploying IPv6 in enterprises because those security defence networks *are* uncommon, and they likely won't share much with 99% of other enterprises (which aren't defence/military networks). Therefore, I'd not like to see a situation where someone could point at the enterprise documents and say, "see, that's how they did it, let's do so ourselves as well!" (even though the actual scenarios and requirements would be entirely different). > I believe that this scenario is an interesting and important scenario > to explore. How will people who are running highly secure/mobile > networks today transition to IPv6? If those networks have special characteristics applicable only for military networks, let's just call them transitioning in military networks, not highly secure (or mobile) networks :). I see no problem having an example describing military networks -- most countries have one, so there should be some aggregation benefit here -- but it should (IMHO) be clearly separated from the other kinds of enterprise examples. [...] > At least within the U.S. Department of Defense there has been some > resistance to deploying IPv6 on "operational" networks, because of > uncertainty about the security implications of doing so. It would be > good for us to explore those implications, dispell any myths, and > close any holes that do exist. This is possibly beyond the scope of the enterprise documents, but hopefully the issues will rise during the process and they are written up and pushed forward (e.g., a separate document about v6 myths or v6 security issues). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jul 2 01:40:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23517 for ; Fri, 2 Jul 2004 01:40:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgGkd-0007S8-Ti for v6ops-data@psg.com; Fri, 02 Jul 2004 05:38:19 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgGkc-0007Rt-68 for v6ops@ops.ietf.org; Fri, 02 Jul 2004 05:38:18 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id BDE4969EC; Fri, 2 Jul 2004 01:38:17 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jul 2004 01:38:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Date: Fri, 2 Jul 2004 01:38:18 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CCDE5@tayexc13.americas.cpqcorp.net> Thread-Topic: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Thread-Index: AcRf8duAcPgKjx0aTxih/xYQnP7NfQAAgTOw From: "Bound, Jim" To: "Pekka Savola" , "Margaret Wasserman" Cc: "Soininen Jonne (Nokia-NET/Helsinki)" , X-OriginalArrivalTime: 02 Jul 2004 05:38:17.0499 (UTC) FILETIME=[C6CACEB0:01C45FF6] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable My responses below.=20 >=20 > I did this on May 25, and Richard Graveman agreed. A=20 > suggestion was adding a paragraph like: >=20 > Note that these kind of networks are uncommon and unfit to be a > model or example for deployment for enterprises in general. =20 > However, due to their importance to the vendor community, their > requirements should be considered explicitly. >=20 > As you see, I'm not arguing that the example needs to be=20 > removed (though I wouldn't object :), but that it's made=20 > crystal clear that the example might not be a basis for=20 > *generalizing* how we would be deploying IPv6 in enterprises=20 > because those security defence networks > *are* uncommon, and they likely won't share much with 99% of=20 > other enterprises (which aren't defence/military networks).=20 The position of the design team and of many on this list is as follows: I will just list a few users: Military, Academic, and Security Surveillance networks today will deploy IPv6 dominant networks on tactitical networks and treat IPv4 totally as legacy operational protocol whereever possible. In addition that is the long term goal of IPv6 transition for any Enterprise. This set of users are very common and the scenario is highly fit to the kind of work that must be done here in v6ops and required. What I suggest as a compromise is as follows to the working group: "Though this is a valid use case for the Enterprise Scenarios depicted, at this time this scenario defines an early adopter of Enterprise networks transitioning to IPv6 as a dominant protocol strategy (e.g. IPv6 Routing, Applications, Security, and Operations), viewing IPv4 as legacy operations immediately in the transition strategy, and not at this time a predominant transition view to deploy IPv6 in the IETF bodies knowledge base." The reason these users do this are as follows: IPv6 operational benefits required immediately. Reduce Transition Cost. >=20 > Therefore, I'd not like to see a situation where someone=20 > could point at the enterprise documents and say, "see, that's=20 > how they did it, let's do so ourselves as well!" (even though=20 > the actual scenarios and requirements would be entirely different). The Scenarios do not do that and that is what the analysis is for and where clarification should be made. >=20 > > I believe that this scenario is an interesting and=20 > important scenario=20 > > to explore. How will people who are running highly secure/mobile=20 > > networks today transition to IPv6? >=20 > If those networks have special characteristics applicable=20 > only for military networks, let's just call them=20 > transitioning in military networks, not highly secure (or=20 > mobile) networks :).=20 These are not just military networks. > I see no problem having an example=20 > describing military networks -- most countries have one, so=20 > there should be some aggregation benefit here -- but it should > (IMHO) be clearly separated from the other kinds of=20 > enterprise examples. I suggest the compromise above. >=20 > [...]=20 > > At least within the U.S. Department of Defense there has been some=20 > > resistance to deploying IPv6 on "operational" networks, because of=20 > > uncertainty about the security implications of doing so. =20 > It would be=20 > > good for us to explore those implications, dispell any myths, and=20 > > close any holes that do exist. >=20 > This is possibly beyond the scope of the enterprise=20 > documents, but hopefully the issues will rise during the=20 > process and they are written up and pushed forward (e.g., a=20 > separate document about v6 myths or v6 security issues). No one can discuss the details and I agree lets not pick on or discuss any specific network user but their properties. But as one who does work with this user as SME the rationale is that IPv6 requires further testing and integration with other components before it is put on a mission critical production network where very bad results can happen from a bug that could be military, medical, or intersection of a graph for a mission critical decision. So I want to clarify Margaret's statement that it is not resistance and IPv6 is mandated and will happen, but that more testing is required. That testing is going on now and one example is Moonv6 (there are others) www.mooonv6.org This same rationale is being used by many Enterprises in the other scenarios too and not just the user described above. It is a smart approach and I support it in industry as a note. First step to transition in my view is to set up pilots before switch to production. This is true of any network software or hardware upgrade to a production network. =20 Regards, /jim >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 From owner-v6ops@ops.ietf.org Fri Jul 2 01:51:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23726 for ; Fri, 2 Jul 2004 01:51:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgGwT-0008g1-4j for v6ops-data@psg.com; Fri, 02 Jul 2004 05:50:33 +0000 Received: from [63.103.94.23] (helo=ftmailgfi.HQ.Flarion.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgGwS-0008fh-8m for v6ops@ops.ietf.org; Fri, 02 Jul 2004 05:50:32 +0000 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Jul 2004 01:50:30 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Moving forward Date: Fri, 2 Jul 2004 01:50:30 -0400 Message-ID: Thread-Topic: Moving forward Thread-Index: AcRf66j8wQPXTPoeTvG16+IdtuB++wACtBcg From: "Soliman Hesham" To: "Pekka Savola" CC: "David Kessens" , X-OriginalArrivalTime: 02 Jul 2004 05:50:30.0943 (UTC) FILETIME=[7BF57AF0:01C45FF8] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > On Thu, 1 Jul 2004, Soliman Hesham wrote: > > FWIW, there was unanymous concensus in the Seoul meeting > > to standardise all mechanisms being considered at the moment >=20 > Nope -- I don't recall anything like that. Could you elaborate using > the minutes when you believe that kind of consensus was achieved or > even asked. =3D> Hmmm, After your presentation which included an analysis of all current proposals (it was divided in some way that=20 I never quite understood), you and Jonne asked the group if there were any objections to moving forward with any of the mechanisms and no one objected. I recall this very clearly. I didn't read the minutes after the meeting but=20 I was there. I believe this was in the first session. 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 From owner-v6ops@ops.ietf.org Fri Jul 2 02:06:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00231 for ; Fri, 2 Jul 2004 02:06:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgHAr-000B1G-0B for v6ops-data@psg.com; Fri, 02 Jul 2004 06:05:25 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgHAp-000B0c-4P for v6ops@ops.ietf.org; Fri, 02 Jul 2004 06:05:23 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id CF982603E; Fri, 2 Jul 2004 02:05:22 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jul 2004 02:05:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Date: Fri, 2 Jul 2004 02:05:24 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CCDEA@tayexc13.americas.cpqcorp.net> Thread-Topic: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Thread-Index: AcRfy5wWYtgvl/5NQRGOH7ATzX8cDgALq4ag From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 02 Jul 2004 06:05:22.0366 (UTC) FILETIME=[8F49D5E0:01C45FFA] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Tim, We have a few edits that we probably need to rev again. When the node needs to communicate with IPv4 it must assume an IPv6 routing protocol not an IPv4 one. So IPv4 capabale nodes would in invalid from the sense that this network states that all nodes are there with IPv6 and IPv4 is only legacy on a specific network. So I think the update is overboard? Do you see my point? Thanks /jim =20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown > Sent: Thursday, July 01, 2004 8:26 PM > To: v6ops@ops.ietf.org > Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt >=20 >=20 > Hi Jim, >=20 > It looks good to go. >=20 > Very minor comment (can be ignored if we want to get the=20 > draft published :) >=20 > Perhaps Section 3.1 could be clearer - is the correct interpretation: >=20 > Scenario 1: Wide-scale/total dual-stack deployment of IPv4=20 > and IPv6 capable hosts and network infrastructure. >=20 > Scenario 2: Sparse IPv6 dual-stack deployment in IPv4=20 > network infrastructure. >=20 > Scenario 3: IPv6-only network infrastructure with some=20 > IPv4-capable nodes/applications needing to communicate over=20 > the IPv6 infrastructure. >=20 > If so, then=20 >=20 > " Scenario 3: Enterprise deploying a new network or=20 > re-structuring an > existing network, decides IPv6 is the basis for > most network communication, to coexist with IPv4." >=20 > might be better as: >=20 > " Scenario 3: Enterprise deploying a new network or=20 > re-structuring an > existing network, decides IPv6 is the basis=20 > for most network=20 > communication. Some IPv4 capable=20 > nodes/applications will > need to communicate over that infrastructure. >=20 > Or is that the wrong intepretation? >=20 > Finally, how does communication between IPv4-only and=20 > IPv6-only nodes or applications fit into the above three=20 > scenarios, if any of them? Would that be part of Scenario 3?=20 > Perhaps make that clearer? >=20 > Section 3.1 is actually quite heavily the key in which=20 > mechanisms are favoured, so the wording is very important. >=20 > Tim >=20 > On Tue, Jun 29, 2004 at 12:30:26AM -0400, Bound, Jim wrote: > > WG, > >=20 > > Chairs asked me to send this note to you. Updated spec below. First=20 > > error below I am just the editor see authors in the spec. =20 > What we did=20 > > and I as editor is took 100% Alain's and Pekka's input as best we=20 > > could for additional clarity. But, in section 4 we put additional=20 > > note that this section is more of an overview that the reader must=20 > > look at as components and all the components would fill up=20 > many pages=20 > > (as all > > scenarios) and more of that is analysis as opposed to defining a=20 > > scenario, and analysis is the next step. We also added normative=20 > > references we felt were applicable to the spec that exist and talk=20 > > about the general subject (e.g. DNS, Applications). I as=20 > one author=20 > > may not be able to respond to mail this week as I am abroad=20 > in Europe,=20 > > but will do my best. > >=20 > > Regards, > > /jim > >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20 > > Behalf Of Internet-Drafts@ietf.org > > Sent: Monday, June 28, 2004 3:31 PM > > To: i-d-announce@ietf.org > > Cc: v6ops@ops.ietf.org > > Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the IPv6 Operations Working=20 > Group of the=20 > > IETF. > >=20 > > Title : IPv6 Enterprise Network Scenarios > > Author(s) : J. Bound > > Filename : draft-ietf-v6ops-ent-scenarios-03.txt > > Pages : 16 > > Date : 2004-6-28 > > =09 > > This document describes the scenarios for IPv6 deployment within=20 > > Enterprise networks. It will focus upon an Enterprise set=20 > of network=20 > > base scenarios with assumptions, coexistence with legacy=20 > IPv4 nodes,=20 > > networks, and applications, and network infrastructure requirements. > > These requirements will be used to provide analysis to=20 > determine a set=20 > > of Enterprise solutions in a later document. > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-03. > > tx > > t > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > > the message. > > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-v6ops-ent-scenarios-03.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-03.txt". > > =09 > > 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=20 > 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. > > =09 > > =09 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri Jul 2 02:07:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01329 for ; Fri, 2 Jul 2004 02:07:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgHCS-000BCq-Ic for v6ops-data@psg.com; Fri, 02 Jul 2004 06:07:04 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgHCR-000BCX-6Y for v6ops@ops.ietf.org; Fri, 02 Jul 2004 06:07:03 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D33451950; Fri, 2 Jul 2004 02:07:02 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jul 2004 02:07:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Moving forward Date: Fri, 2 Jul 2004 02:07:05 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CCDEB@tayexc13.americas.cpqcorp.net> Thread-Topic: Moving forward Thread-Index: AcRf7CGVNn37FUDPRieT7mqgKndDCwADnsLg From: "Bound, Jim" To: "Pekka Savola" , "Soliman Hesham" Cc: "David Kessens" , X-OriginalArrivalTime: 02 Jul 2004 06:07:02.0652 (UTC) FILETIME=[CB1043C0:01C45FFA] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable The mechanisms being deployed right now that require IETF work and forward progress are as follows: Tunnel Broker, 6to4 (mostly done), Teredo, DSTM, ISATAP, and NAT Bypasses. Other exist but these are dominant. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Friday, July 02, 2004 12:19 AM > To: Soliman Hesham > Cc: David Kessens; v6ops@ops.ietf.org > Subject: RE: Moving forward >=20 > On Thu, 1 Jul 2004, Soliman Hesham wrote: > > FWIW, there was unanymous concensus in the Seoul meeting to=20 > > standardise all mechanisms being considered at the moment >=20 > Nope -- I don't recall anything like that. Could you=20 > elaborate using the minutes when you believe that kind of=20 > consensus was achieved or even asked. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri Jul 2 04:58:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17933 for ; Fri, 2 Jul 2004 04:58:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgJr2-0002b1-2I for v6ops-data@psg.com; Fri, 02 Jul 2004 08:57:08 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgJqy-0002aO-Oe for v6ops@ops.ietf.org; Fri, 02 Jul 2004 08:57:05 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i628v3nE000238 for ; Fri, 2 Jul 2004 09:57:04 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA08503 for ; Fri, 2 Jul 2004 09:57:01 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i628v1T23465 for v6ops@ops.ietf.org; Fri, 2 Jul 2004 09:57:01 +0100 Date: Fri, 2 Jul 2004 09:57:01 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Message-ID: <20040702085701.GJ21847@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B067CCDEA@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CCDEA@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Ah, OK. The wording may seem subtle, but the solution space is very different. If Scenario 3 is an IPv6-only infrastructure and IPv6 nodes, that wish to communicate with a separate IPv4-only network, then you're in the NAT-PT, TRT or ALG space (depending which layer you want to translate at). If Scenario 3 is IPv6 infrastructure (routers, and IPv6-only on the wire) but with some dual-stack nodes or legacy applications communicating with each other over IPv4 (e.g. the application is IPv4 only) or to IPv4 nodes outside the network, then you may be in the DSTM solution space. This also applies to the last line of Example Network C (end of Section 3.3). I just think section 3.1 is the real focus of this work in that people will point at it as justification for transition mechanism X being in scope or not for Enterprise. But if you don't think that needs to be clarified, that's also fine by me :) One other quick comment if a quick revision is being made - perhaps the text at the start of Section 3.3 should clarify whether Example A is paired with Scenario 1, B with 2 and C with 3, or whether each Example can apply to any of the scenarios. Tim On Fri, Jul 02, 2004 at 02:05:24AM -0400, Bound, Jim wrote: > Tim, > > We have a few edits that we probably need to rev again. > > When the node needs to communicate with IPv4 it must assume an IPv6 > routing protocol not an IPv4 one. So IPv4 capabale nodes would in > invalid from the sense that this network states that all nodes are there > with IPv6 and IPv4 is only legacy on a specific network. So I think the > update is overboard? > > Do you see my point? > > Thanks > /jim > > > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown > > Sent: Thursday, July 01, 2004 8:26 PM > > To: v6ops@ops.ietf.org > > Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt > > > > > > Hi Jim, > > > > It looks good to go. > > > > Very minor comment (can be ignored if we want to get the > > draft published :) > > > > Perhaps Section 3.1 could be clearer - is the correct interpretation: > > > > Scenario 1: Wide-scale/total dual-stack deployment of IPv4 > > and IPv6 capable hosts and network infrastructure. > > > > Scenario 2: Sparse IPv6 dual-stack deployment in IPv4 > > network infrastructure. > > > > Scenario 3: IPv6-only network infrastructure with some > > IPv4-capable nodes/applications needing to communicate over > > the IPv6 infrastructure. > > > > If so, then > > > > " Scenario 3: Enterprise deploying a new network or > > re-structuring an > > existing network, decides IPv6 is the basis for > > most network communication, to coexist with IPv4." > > > > might be better as: > > > > " Scenario 3: Enterprise deploying a new network or > > re-structuring an > > existing network, decides IPv6 is the basis > > for most network > > communication. Some IPv4 capable > > nodes/applications will > > need to communicate over that infrastructure. > > > > Or is that the wrong intepretation? > > > > Finally, how does communication between IPv4-only and > > IPv6-only nodes or applications fit into the above three > > scenarios, if any of them? Would that be part of Scenario 3? > > Perhaps make that clearer? > > > > Section 3.1 is actually quite heavily the key in which > > mechanisms are favoured, so the wording is very important. > > > > Tim > > > > On Tue, Jun 29, 2004 at 12:30:26AM -0400, Bound, Jim wrote: > > > WG, > > > > > > Chairs asked me to send this note to you. Updated spec below. First > > > error below I am just the editor see authors in the spec. > > What we did > > > and I as editor is took 100% Alain's and Pekka's input as best we > > > could for additional clarity. But, in section 4 we put additional > > > note that this section is more of an overview that the reader must > > > look at as components and all the components would fill up > > many pages > > > (as all > > > scenarios) and more of that is analysis as opposed to defining a > > > scenario, and analysis is the next step. We also added normative > > > references we felt were applicable to the spec that exist and talk > > > about the general subject (e.g. DNS, Applications). I as > > one author > > > may not be able to respond to mail this week as I am abroad > > in Europe, > > > but will do my best. > > > > > > Regards, > > > /jim > > > > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > > > Behalf Of Internet-Drafts@ietf.org > > > Sent: Monday, June 28, 2004 3:31 PM > > > To: i-d-announce@ietf.org > > > Cc: v6ops@ops.ietf.org > > > Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the IPv6 Operations Working > > Group of the > > > IETF. > > > > > > Title : IPv6 Enterprise Network Scenarios > > > Author(s) : J. Bound > > > Filename : draft-ietf-v6ops-ent-scenarios-03.txt > > > Pages : 16 > > > Date : 2004-6-28 > > > > > > This document describes the scenarios for IPv6 deployment within > > > Enterprise networks. It will focus upon an Enterprise set > > of network > > > base scenarios with assumptions, coexistence with legacy > > IPv4 nodes, > > > networks, and applications, and network infrastructure requirements. > > > These requirements will be used to provide analysis to > > determine a set > > > of Enterprise solutions in a later document. > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-03. > > > tx > > > t > > > > > > 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-v6ops-ent-scenarios-03.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-03.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Fri Jul 2 05:36:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20572 for ; Fri, 2 Jul 2004 05:36:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgKRJ-0007hG-LU for v6ops-data@psg.com; Fri, 02 Jul 2004 09:34:37 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgKRH-0007gz-QX for v6ops@ops.ietf.org; Fri, 02 Jul 2004 09:34:36 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.1.R) with ESMTP id md50000098924.msg for ; Fri, 02 Jul 2004 11:36:57 +0200 Message-ID: <04ef01c46017$c1fdda50$d60b12ac@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20040701235527.GH13024@login.ecs.soton.ac.uk> Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Date: Fri, 2 Jul 2004 11:34:17 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 02 Jul 2004 11:36:57 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 80.226.145.89 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Fri, 02 Jul 2004 11:37:01 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I also agree, and have REAL only-IPv6 customer networks NOW. Regards, Jordi ---- Original Message ---- From: "Tim Chown" To: Sent: Friday, July 02, 2004 1:55 AM Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt > On Wed, Jun 30, 2004 at 02:02:39PM -0400, Margaret Wasserman wrote: >>=20 >> I believe that this scenario is an interesting and important scenario >> to explore. How will people who are running highly secure/mobile >> networks today transition to IPv6? >=20 > Margaret, I agree. This should remain in the draft. >=20 > This example puts IPv6-only network infrastructure, with dual-stack nodes, > on the radar for the solution space, and that is important, whether it's > a military network or an Asian academic network. >=20 > I suspect there is some resistance because some people feel IPv6-only > infrastructure is too early to consider. I would disagree. For example, > the Chinese academic CERNET 2 network is IPv6-only, and is live now (but > I don't know whether the sites/universities are IPv6-only infrastructure, > but they're probably closer to doing it than any non-Asian academic > sites).=20 >=20 > We have to think global in the scoping and solution space. >=20 > Tim ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Jul 2 10:20:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08456 for ; Fri, 2 Jul 2004 10:20:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgOs5-000Hfk-U3 for v6ops-data@psg.com; Fri, 02 Jul 2004 14:18:33 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgOs4-000Hf9-2w for v6ops@ops.ietf.org; Fri, 02 Jul 2004 14:18:32 +0000 Received: from [207.31.248.169] (account margaret HELO [10.0.0.41]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 97825; Fri, 02 Jul 2004 10:16:18 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <20040702002610.GJ13024@login.ecs.soton.ac.uk> References: <9C422444DE99BC46B3AD3C6EAFC9711B067CCBD8@tayexc13.americas.cpqcorp.net> <20040702002610.GJ13024@login.ecs.soton.ac.uk> Date: Fri, 2 Jul 2004 10:14:50 -0400 To: Tim Chown , v6ops@ops.ietf.org From: Margaret Wasserman Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Tim, At 1:26 AM +0100 7/2/04, Tim Chown wrote: >Finally, how does communication between IPv4-only and IPv6-only nodes or >applications fit into the above three scenarios, if any of them? Would >that be part of Scenario 3? Perhaps make that clearer? Can you describe a situation where this is necessary? My preferred "solution" to this problem is to avoid the situation. Nodes that need to speak to IPv4-only nodes must implement IPv4, and nodes that need to speak to IPv6-only nodes must implement IPv6. Nodes that need to talk to both IPv4-only and IPv6-only nodes must be dual stack. An IPv4-only node would not be able to communicate directly with an IPv6-only node. In this situation, the question changes from "How does an IPv4-only node talk to an IPv6-only node?" to "How do we get IPv6 connectivity to a node that only has local IPv4 connectivity, and vice versa?". So far, I haven't heard of any situation where IPv4<=>IPv6 translation would be technically superior to dual stack/tunneling. Margaret From owner-v6ops@ops.ietf.org Fri Jul 2 10:31:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08816 for ; Fri, 2 Jul 2004 10:31:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgP4C-000Jcz-1I for v6ops-data@psg.com; Fri, 02 Jul 2004 14:31:04 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgP4A-000JcP-Md for v6ops@ops.ietf.org; Fri, 02 Jul 2004 14:31:02 +0000 Received: from [207.31.248.169] (account margaret HELO [10.0.0.41]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 97871; Fri, 02 Jul 2004 10:28:42 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CCDE5@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B067CCDE5@tayexc13.americas.cpqcorp.net> Date: Fri, 2 Jul 2004 10:29:23 -0400 To: "Bound, Jim" , "Pekka Savola" From: Margaret Wasserman Subject: RE: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Cc: "Soininen Jonne (Nokia-NET/Helsinki)" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, At 1:38 AM -0400 7/2/04, Bound, Jim wrote: > So I want to clarify Margaret's >statement that it is not resistance and IPv6 is mandated and will >happen, but that more testing is required. That testing is going on now >and one example is Moonv6 (there are others) www.mooonv6.org Good clarification. "Resistance" was a poor word choice, "caution" might have been better, and I agree that caution is appropriate. My thinking is that the v6ops group should be informed by early operational experience with IPv6-only networks (like Moonv6) and that during the analysis phase for the secure/defense networks scenario we should consider if any IETF protocol or BCP-type work is needed to resolve technical/protocol issues found in that testing (if any). The biggest issue with secure IPv6 deployment (as I understand it) is not a lack of appropriate standards, but a lack of available, supported, commercial products for information assurance that include good IPv6 integration (things like firewalls and intrusion detection systems). So, some of the issues may not be addressable by the IETF at all. Have things been getting better in this area? Margaret From owner-v6ops@ops.ietf.org Sat Jul 3 02:26:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15837 for ; Sat, 3 Jul 2004 02:26:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bgdvg-000CUQ-H1 for v6ops-data@psg.com; Sat, 03 Jul 2004 06:23:16 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bgdve-000CU6-ST for v6ops@ops.ietf.org; Sat, 03 Jul 2004 06:23:15 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 6D3164F53; Sat, 3 Jul 2004 02:23:14 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Jul 2004 02:23:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Date: Sat, 3 Jul 2004 02:23:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CCE63@tayexc13.americas.cpqcorp.net> Thread-Topic: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Thread-Index: AcRgEt1CsMMh0fwyTr20RfTyWU77FwAss63w From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 03 Jul 2004 06:23:14.0272 (UTC) FILETIME=[389B7600:01C460C6] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > If Scenario 3 is an IPv6-only infrastructure and IPv6 nodes,=20 > that wish to communicate with a separate IPv4-only network,=20 > then you're in the NAT-PT, TRT or ALG space (depending which=20 > layer you want to translate at). If you mean IPv6 only stack yes but not dual stack which adds v4 in v6 tunnels as solution.=20 I don't believe we will see IPv6 ONLY stacks for a very long time. >=20 > If Scenario 3 is IPv6 infrastructure (routers, and IPv6-only=20 > on the wire) but with some dual-stack nodes or legacy=20 > applications communicating with each other over IPv4 (e.g.=20 > the application is IPv4 only) or to IPv4 nodes outside the=20 > network, then you may be in the DSTM solution space. And tunnel broker space too. >=20 > This also applies to the last line of Example Network C (end=20 > of Section 3.3). >=20 > I just think section 3.1 is the real focus of this work in=20 > that people will point at it as justification for transition=20 > mechanism X being in scope or not for Enterprise. But if you=20 > don't think that needs to be clarified, that's also fine by me :) So far only one person thinks that and they are not a god and I do not like to appease such egoes though I did offer a compromise to that ego which goes against my grain quite frankly and intend to speak with that ego in private at San Diego to iron out our consistent battles once and for all. I am sick of speaking to this ego. >=20 > One other quick comment if a quick revision is being made -=20 > perhaps the text at the start of Section 3.3 should clarify=20 > whether Example A is paired with Scenario 1, B with 2 and C=20 > with 3, or whether each Example can apply to any of the scenarios. This is doable yes. Thanks /jim >=20 > Tim >=20 > On Fri, Jul 02, 2004 at 02:05:24AM -0400, Bound, Jim wrote: > > Tim, > >=20 > > We have a few edits that we probably need to rev again. > >=20 > > When the node needs to communicate with IPv4 it must assume an IPv6=20 > > routing protocol not an IPv4 one. So IPv4 capabale nodes would in=20 > > invalid from the sense that this network states that all nodes are=20 > > there with IPv6 and IPv4 is only legacy on a specific=20 > network. So I=20 > > think the update is overboard? > >=20 > > Do you see my point? > >=20 > > Thanks > > /jim > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown > > > Sent: Thursday, July 01, 2004 8:26 PM > > > To: v6ops@ops.ietf.org > > > Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt > > >=20 > > >=20 > > > Hi Jim, > > >=20 > > > It looks good to go. > > >=20 > > > Very minor comment (can be ignored if we want to get the draft=20 > > > published :) > > >=20 > > > Perhaps Section 3.1 could be clearer - is the correct=20 > interpretation: > > >=20 > > > Scenario 1: Wide-scale/total dual-stack deployment of=20 > IPv4 and IPv6=20 > > > capable hosts and network infrastructure. > > >=20 > > > Scenario 2: Sparse IPv6 dual-stack deployment in IPv4 network=20 > > > infrastructure. > > >=20 > > > Scenario 3: IPv6-only network infrastructure with some=20 > IPv4-capable=20 > > > nodes/applications needing to communicate over the IPv6=20 > > > infrastructure. > > >=20 > > > If so, then > > >=20 > > > " Scenario 3: Enterprise deploying a new network or=20 > > > re-structuring an > > > existing network, decides IPv6 is the basis for > > > most network communication, to coexist with IPv4." > > >=20 > > > might be better as: > > >=20 > > > " Scenario 3: Enterprise deploying a new network or=20 > > > re-structuring an > > > existing network, decides IPv6 is the=20 > basis for most=20 > > > network > > > communication. Some IPv4 capable=20 > nodes/applications=20 > > > will > > > need to communicate over that infrastructure. > > >=20 > > > Or is that the wrong intepretation? > > >=20 > > > Finally, how does communication between IPv4-only and IPv6-only=20 > > > nodes or applications fit into the above three scenarios,=20 > if any of=20 > > > them? Would that be part of Scenario 3? > > > Perhaps make that clearer? > > >=20 > > > Section 3.1 is actually quite heavily the key in which mechanisms=20 > > > are favoured, so the wording is very important. > > >=20 > > > Tim > > >=20 > > > On Tue, Jun 29, 2004 at 12:30:26AM -0400, Bound, Jim wrote: > > > > WG, > > > >=20 > > > > Chairs asked me to send this note to you. Updated spec below.=20 > > > > First error below I am just the editor see authors in the spec. > > > What we did > > > > and I as editor is took 100% Alain's and Pekka's input=20 > as best we=20 > > > > could for additional clarity. But, in section 4 we put=20 > additional=20 > > > > note that this section is more of an overview that the=20 > reader must=20 > > > > look at as components and all the components would fill up > > > many pages > > > > (as all > > > > scenarios) and more of that is analysis as opposed to=20 > defining a=20 > > > > scenario, and analysis is the next step. We also added=20 > normative=20 > > > > references we felt were applicable to the spec that=20 > exist and talk=20 > > > > about the general subject (e.g. DNS, Applications). I as > > > one author > > > > may not be able to respond to mail this week as I am abroad > > > in Europe, > > > > but will do my best. > > > >=20 > > > > Regards, > > > > /jim > > > >=20 > > > > -----Original Message----- > > > > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org]=20 > > > > On Behalf Of Internet-Drafts@ietf.org > > > > Sent: Monday, June 28, 2004 3:31 PM > > > > To: i-d-announce@ietf.org > > > > Cc: v6ops@ops.ietf.org > > > > Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt > > > >=20 > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > > > directories. > > > > This draft is a work item of the IPv6 Operations Working > > > Group of the > > > > IETF. > > > >=20 > > > > Title : IPv6 Enterprise Network Scenarios > > > > Author(s) : J. Bound > > > > Filename : draft-ietf-v6ops-ent-scenarios-03.txt > > > > Pages : 16 > > > > Date : 2004-6-28 > > > > =09 > > > > This document describes the scenarios for IPv6=20 > deployment within=20 > > > > Enterprise networks. It will focus upon an Enterprise set > > > of network > > > > base scenarios with assumptions, coexistence with legacy > > > IPv4 nodes, > > > > networks, and applications, and network infrastructure=20 > requirements. > > > > These requirements will be used to provide analysis to > > > determine a set > > > > of Enterprise solutions in a later document. > > > >=20 > > > > A URL for this Internet-Draft is: > > > >=20 > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-03. > > > > tx > > > > t > > > >=20 > > > > 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. > > > >=20 > > > >=20 > > > > Internet-Drafts are also available by anonymous FTP. Login with=20 > > > > the username "anonymous" and a password of your e-mail address.=20 > > > > After logging in, type "cd internet-drafts" and then > > > > "get draft-ietf-v6ops-ent-scenarios-03.txt". > > > >=20 > > > > A list of Internet-Drafts directories can be found in=20 > > > > http://www.ietf.org/shadow.html or=20 > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >=20 > > > >=20 > > > > Internet-Drafts can also be obtained by e-mail. > > > >=20 > > > > Send a message to: > > > > mailserv@ietf.org. > > > > In the body type: > > > > "FILE=20 > /internet-drafts/draft-ietf-v6ops-ent-scenarios-03.txt". > > > > =09 > > > > NOTE: The mail server at ietf.org can return the document in > > > > MIME-encoded form by using the "mpack" utility.=20 > To use this > > > > feature, insert the command "ENCODING mime"=20 > before the "FILE" > > > > command. To decode the response(s), you will=20 > 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=20 > have been split > > > > up into multiple messages), so check your local=20 > documentation on > > > > how to manipulate these messages. > > > > =09 > > > > =09 > > > > Below is the data which will enable a MIME compliant=20 > mail reader=20 > > > > implementation to automatically retrieve the ASCII=20 > version of the=20 > > > > Internet-Draft. > > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sat Jul 3 02:27:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15891 for ; Sat, 3 Jul 2004 02:27:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bgdzi-000DBo-Cm for v6ops-data@psg.com; Sat, 03 Jul 2004 06:27:26 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bgdzh-000DBO-AB for v6ops@ops.ietf.org; Sat, 03 Jul 2004 06:27:25 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 0579B60EA; Sat, 3 Jul 2004 02:27:25 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Jul 2004 02:27:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Date: Sat, 3 Jul 2004 02:27:26 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CCE64@tayexc13.americas.cpqcorp.net> Thread-Topic: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Thread-Index: AcRgQTiJ6AD2Z1LpRmq79Tlhcxfg8AAhTpAg From: "Bound, Jim" To: "Margaret Wasserman" , "Pekka Savola" Cc: "Soininen Jonne (Nokia-NET/Helsinki)" , X-OriginalArrivalTime: 03 Jul 2004 06:27:24.0710 (UTC) FILETIME=[CDE14460:01C460C6] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Margaret, Yes we can do this as data is available. As Chair of NAv6TF and Moonv6 project is under NAv6TF direction I can request such data. Most of the folks doing this will be in San Diego too. On the IPv6 security issue that is totally correct. Note one other big time port is the IDS software for IPv4 simply to be ported to IPv6, and most of this requires certain levels of intel clearance even to understand the requirements in both government and private sector, so complex to parse the requirements for implementation. /jim=20 > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com]=20 > Sent: Friday, July 02, 2004 10:29 AM > To: Bound, Jim; Pekka Savola > Cc: Soininen Jonne (Nokia-NET/Helsinki); v6ops@ops.ietf.org > Subject: RE: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt >=20 >=20 > Hi Jim, >=20 > At 1:38 AM -0400 7/2/04, Bound, Jim wrote: > > So I want to clarify Margaret's > >statement that it is not resistance and IPv6 is mandated and will=20 > >happen, but that more testing is required. That testing is going on=20 > >now and one example is Moonv6 (there are others) www.mooonv6.org >=20 > Good clarification. >=20 > "Resistance" was a poor word choice, "caution" might have=20 > been better, and I agree that caution is appropriate. >=20 > My thinking is that the v6ops group should be informed by=20 > early operational experience with IPv6-only networks (like=20 > Moonv6) and that during the analysis phase for the=20 > secure/defense networks scenario we should consider if any=20 > IETF protocol or BCP-type work is needed to resolve=20 > technical/protocol issues found in that testing (if any). >=20 > The biggest issue with secure IPv6 deployment (as I=20 > understand it) is not a lack of appropriate standards, but a=20 > lack of available, supported, commercial products for=20 > information assurance that include good IPv6 integration=20 > (things like firewalls and intrusion detection systems). So,=20 > some of the issues may not be addressable by the IETF at all.=20 > Have things been getting better in this area? >=20 > Margaret >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sun Jul 4 11:50:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20248 for ; Sun, 4 Jul 2004 11:50:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh9Bx-000BAI-F1 for v6ops-data@psg.com; Sun, 04 Jul 2004 15:46:09 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh9Bv-000B9c-Bp for v6ops@ops.ietf.org; Sun, 04 Jul 2004 15:46:08 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i64Fk6nE007242 for ; Sun, 4 Jul 2004 16:46:06 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA23903 for ; Sun, 4 Jul 2004 16:46:03 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i64Fk3q28626 for v6ops@ops.ietf.org; Sun, 4 Jul 2004 16:46:03 +0100 Date: Sun, 4 Jul 2004 16:46:03 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Message-ID: <20040704154603.GE24811@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B067CCE63@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CCE63@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, Jul 03, 2004 at 02:23:10AM -0400, Bound, Jim wrote: > > If Scenario 3 is an IPv6-only infrastructure and IPv6 nodes, > > that wish to communicate with a separate IPv4-only network, > > then you're in the NAT-PT, TRT or ALG space (depending which > > layer you want to translate at). > > If you mean IPv6 only stack yes but not dual stack which adds v4 in v6 > tunnels as solution. OK, but that needs to be clarified, I think. In the one case you need protocol translation, in the other case you can tunnel. If scenario 3 is both, state it clearly, if it isn't, state it clearly :) > I don't believe we will see IPv6 ONLY stacks for a very long time. Possibly, but hybrid stack nodes with only IPv6 configured is happening now? > > If Scenario 3 is IPv6 infrastructure (routers, and IPv6-only > > on the wire) but with some dual-stack nodes or legacy > > applications communicating with each other over IPv4 (e.g. > > the application is IPv4 only) or to IPv4 nodes outside the > > network, then you may be in the DSTM solution space. > > And tunnel broker space too. Yes, you could run an IPv4-in-IPv6 tunnel broker. I don't think I've seen one yet, but it's possible of course. Since we are having a minor revision, my request is thus just to clarify what Scenario 3 is (or indeed if there is perhaps a Scenario 4). Tim From owner-v6ops@ops.ietf.org Sun Jul 4 12:06:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20751 for ; Sun, 4 Jul 2004 12:06:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh9VW-000DqM-Ay for v6ops-data@psg.com; Sun, 04 Jul 2004 16:06:22 +0000 Received: from [62.189.30.6] (helo=tortoise.webcentre.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh9VU-000Dpp-PV for v6ops@ops.ietf.org; Sun, 04 Jul 2004 16:06:21 +0000 Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by tortoise.webcentre.net (8.9.3/8.9.3) with ESMTP id RAA08246 for ; Sun, 4 Jul 2004 17:05:00 +0100 (BST) Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i64G6HnE007611 for ; Sun, 4 Jul 2004 17:06:17 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA24076 for ; Sun, 4 Jul 2004 17:06:12 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i64G6Cw29016 for v6ops@ops.ietf.org; Sun, 4 Jul 2004 17:06:12 +0100 Date: Sun, 4 Jul 2004 17:06:12 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Message-ID: <20040704160612.GF24811@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B067CCBD8@tayexc13.americas.cpqcorp.net> <20040702002610.GJ13024@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Jul 02, 2004 at 10:14:50AM -0400, Margaret Wasserman wrote: > > Hi Tim, > > My preferred "solution" to this problem is to avoid the situation. Nodes > that need to speak to IPv4-only nodes must implement IPv4, and nodes > that need to speak to IPv6-only nodes must implement IPv6. Nodes > that need to talk to both IPv4-only and IPv6-only nodes must be dual > stack. An IPv4-only node would not be able to communicate directly > with an IPv6-only node. This is the IETF mantra, and I agree with it. The question is how reasonable will it be? In some places, in order to run dual-stack it'll have to be IPv4 private addressing and IPv6 public addressing together. Perhaps some (mainly greenfield) networks will just decide IPv4 isn't worth deploying and will offer translation (probably ALGs) for legacy applications like mail, web and FTP and rely on IPv6 for all new or intranet applications? Do you think this would be unreasonable, especially in less well IPv4-endowed areas? There are actually many academic sites that rely on ALGs, e.g. student dormitory networks, which might only have web ports open outbound, and use private IPv4 addressing. These could be candidates for IPv6 deployment experiments, although in many cases the restriction is of course not because of IPv4 address shortage, but policy decisions. Tim From owner-v6ops@ops.ietf.org Mon Jul 5 23:04:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01243 for ; Mon, 5 Jul 2004 23:04:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhgDK-000HwG-6V for v6ops-data@psg.com; Tue, 06 Jul 2004 03:01:46 +0000 Received: from [4.14.89.246] (helo=tndh.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhgDJ-000Hw0-1l for v6ops@ops.ietf.org; Tue, 06 Jul 2004 03:01:45 +0000 Received: from eaglet (127.0.0.1:3776) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Mon, 5 Jul 2004 19:58:32 -0700 From: "Tony Hain" To: "'Soliman Hesham'" , "'David Kessens'" Cc: Subject: RE: Moving forward Date: Mon, 5 Jul 2004 20:01:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRfqQyyqR0NNEXuSd6rVbf652CU0wAG8/qQAM+7zzA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Lest anyone forget, ngtrans was an OPS area WG. As David pointed out the rule is a generality, not cast in stone. The appropriate step forward is for v6ops to complete the informational documents that recommend specific approaches to the identified environments. It is then up to the IESG to evaluate a recharter vs. close & open specific wgs in other areas. It would not hurt for the members of v6ops to point out that much of the work on these technologies is being done by the same set of people, so splitting into multiple WGs would cause a logistical problem for meeting slots. Other than that it really doesn't matter where the technologies are standardized. It only matters that they get on the standards track now, and not be hung up behind an interminable IESG debate. The IESG must not second guess the extensive deliberations of the WG in terms of identifying which technologies are useful in each environment, and needs to move expeditiously in processing any or all new charters. Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Soliman Hesham > Sent: Thursday, July 01, 2004 4:57 PM > To: David Kessens > Cc: v6ops@ops.ietf.org > Subject: RE: Moving forward > > > > > We first need to officially hear from the working group > > which ones are > > going to be needed for the minimum set, than we can decide on the > > exact logistics for how the work will proceed. I have asked the > > workinggroup chairpeople to do this in manner that allows us to > > quickly move forward. > > => Understood, but see below. > > > > > In general, protocol work will indeed not happen in the Operations > > area. However, the careful reader will note that I used 'in general' > > and there could be circumstances where there is more > > expertise in this > > area and where it is more efficient to do the work in this area. > > => I certainly noticed 'in general' and it scares me! > I know that you're trying to be flexible and not categorically > rule things out, however, I hope you can appreciate that > this might make things quite blurry and give the wrong > impression to people. Given the lack of appreciation > of WG members' opinions in this WG, I'm worried that > this process will be messy, but I'll wait and see. > > FWIW, there was unanymous concensus in the Seoul meeting > to standardise all mechanisms being considered at the moment > > Hesham > > > > > David Kessens > > --- > > > > =========================================================== > 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. > =========================================================== From owner-v6ops@ops.ietf.org Tue Jul 6 06:38:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04520 for ; Tue, 6 Jul 2004 06:38:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhnI9-000F9U-LT for v6ops-data@psg.com; Tue, 06 Jul 2004 10:35:13 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhnI8-000F93-9R for v6ops@ops.ietf.org; Tue, 06 Jul 2004 10:35:12 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D5EFD3F; Tue, 6 Jul 2004 06:35:11 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Jul 2004 06:35:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Date: Tue, 6 Jul 2004 06:35:11 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CCECF@tayexc13.americas.cpqcorp.net> Thread-Topic: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Thread-Index: AcRh3qvCQKz8aBgfRhyQxOZwLsxdegBZYbkg From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 06 Jul 2004 10:35:11.0661 (UTC) FILETIME=[EA8335D0:01C46344] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Tim,=20 > > > If Scenario 3 is an IPv6-only infrastructure and IPv6 nodes, that=20 > > > wish to communicate with a separate IPv4-only network,=20 > then you're=20 > > > in the NAT-PT, TRT or ALG space (depending which layer=20 > you want to=20 > > > translate at). > >=20 > > If you mean IPv6 only stack yes but not dual stack which=20 > adds v4 in v6=20 > > tunnels as solution. >=20 > OK, but that needs to be clarified, I think. In the one=20 > case you need=20 > protocol translation, in the other case you can tunnel. If=20 > scenario 3 > is both, state it clearly, if it isn't, state it clearly :) OK none of the scenarios will address IPv6 ONLY nodes where translation is needed. That will have to be part of the analysis for really long term planning after this spec moves forward. > =20 > > I don't believe we will see IPv6 ONLY stacks for a very long time. >=20 > Possibly, but hybrid stack nodes with only IPv6 configured is=20 > happening now? Yes I know but that is different than an IPv6 ONLY node. As IPv4 can be used if required and avoid translation.=20 > =20 > > > If Scenario 3 is IPv6 infrastructure (routers, and=20 > IPv6-only on the=20 > > > wire) but with some dual-stack nodes or legacy applications=20 > > > communicating with each other over IPv4 (e.g. > > > the application is IPv4 only) or to IPv4 nodes outside=20 > the network,=20 > > > then you may be in the DSTM solution space. > >=20 > > And tunnel broker space too. >=20 > Yes, you could run an IPv4-in-IPv6 tunnel broker. I don't=20 > think I've seen one yet, but it's possible of course. I am hearing of prototypes. > =20 > Since we are having a minor revision, my request is thus just=20 > to clarify what Scenario 3 is (or indeed if there is perhaps=20 > a Scenario 4).=20 I hope to have edit update today submitted or tomorrow Scenario 3 will be clarified and in new applicability section but will not add scenario 4 as that would be a significant change for this last call. Thanks /jim =20 >=20 > Tim >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jul 6 09:48:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14522 for ; Tue, 6 Jul 2004 09:48:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhqFZ-0009YH-2x for v6ops-data@psg.com; Tue, 06 Jul 2004 13:44:45 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhqFX-0009Xr-4L for v6ops@ops.ietf.org; Tue, 06 Jul 2004 13:44:43 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i66DignE012747 for ; Tue, 6 Jul 2004 14:44:42 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA27464 for ; Tue, 6 Jul 2004 14:44:40 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i66Die820576 for v6ops@ops.ietf.org; Tue, 6 Jul 2004 14:44:40 +0100 Date: Tue, 6 Jul 2004 14:44:40 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Message-ID: <20040706134440.GB20291@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B067CCECF@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CCECF@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk OK, that's fine JIm. On Tue, Jul 06, 2004 at 06:35:11AM -0400, Bound, Jim wrote: > Hi Tim, > > > > > If Scenario 3 is an IPv6-only infrastructure and IPv6 nodes, that > > > > wish to communicate with a separate IPv4-only network, > > then you're > > > > in the NAT-PT, TRT or ALG space (depending which layer > > you want to > > > > translate at). > > > > > > If you mean IPv6 only stack yes but not dual stack which > > adds v4 in v6 > > > tunnels as solution. > > > > OK, but that needs to be clarified, I think. In the one > > case you need > > protocol translation, in the other case you can tunnel. If > > scenario 3 > > is both, state it clearly, if it isn't, state it clearly :) > > OK none of the scenarios will address IPv6 ONLY nodes where translation > is needed. That will have to be part of the analysis for really long > term planning after this spec moves forward. > > > > > > I don't believe we will see IPv6 ONLY stacks for a very long time. > > > > Possibly, but hybrid stack nodes with only IPv6 configured is > > happening now? > > Yes I know but that is different than an IPv6 ONLY node. As IPv4 can be > used if required and avoid translation. > > > > > > > If Scenario 3 is IPv6 infrastructure (routers, and > > IPv6-only on the > > > > wire) but with some dual-stack nodes or legacy applications > > > > communicating with each other over IPv4 (e.g. > > > > the application is IPv4 only) or to IPv4 nodes outside > > the network, > > > > then you may be in the DSTM solution space. > > > > > > And tunnel broker space too. > > > > Yes, you could run an IPv4-in-IPv6 tunnel broker. I don't > > think I've seen one yet, but it's possible of course. > > I am hearing of prototypes. > > > > > Since we are having a minor revision, my request is thus just > > to clarify what Scenario 3 is (or indeed if there is perhaps > > a Scenario 4). > > I hope to have edit update today submitted or tomorrow Scenario 3 will > be clarified and in new applicability section but will not add scenario > 4 as that would be a significant change for this last call. > > Thanks > /jim > > > > > Tim > > > > From owner-v6ops@ops.ietf.org Wed Jul 7 00:50:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22878 for ; Wed, 7 Jul 2004 00:50:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bi4KX-0003RE-KM for v6ops-data@psg.com; Wed, 07 Jul 2004 04:46:49 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bi4KT-0003Qi-VB for v6ops@ops.ietf.org; Wed, 07 Jul 2004 04:46:46 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i674kiO28564 for ; Wed, 7 Jul 2004 07:46:44 +0300 Date: Wed, 7 Jul 2004 07:46:44 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 60th IETF Meeting in San Diego, CA (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI -- if you missed this. ---------- Forwarded message ---------- Date: Tue, 06 Jul 2004 12:07:50 -0400 From: Internet-Drafts@ietf.org To: ietf-announce@ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 60th IETF Meeting in San Diego, CA There are two (2) Internet-Draft cutoff dates for the 60th IETF Meeting in San Diego, CA: July 12th: Cutoff Date for Initial Internet-Draft Submissions (new documents) All initial Internet-Drafts (-00) and updates to initial Internet-Drafts must be submitted by Monday, July 12th, at 09:00 ET. As always, all initial submissions (-00) with a filename beginning with "draft-ietf" MUST be approved by the appropriate WG Chair before they can be processed or announced. WG Chair approval MUST be received by Thursday, July 8th, at 09:00 ET. July 19th: Cutoff Date for Revised Internet-Draft Submissions (-01 and higher) All revised Internet-Drafts (-01 and higher) must be submitted by Monday, July 19th, at 09:00 ET. Initial and revised Internet-Drafts received after their respective cutoff dates will NOT be made available in the Internet-Drafts directory OR announced, and will have to be resubmitted. Please do NOT wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, August 9th. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. FYI: The Internet-Draft cutoff dates as well as other significant dates for the 60th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_60.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-v6ops@ops.ietf.org Wed Jul 7 05:27:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06072 for ; Wed, 7 Jul 2004 05:27:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bi8gw-0009yf-So for v6ops-data@psg.com; Wed, 07 Jul 2004 09:26:14 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bi8gv-0009y7-ES for v6ops@ops.ietf.org; Wed, 07 Jul 2004 09:26:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i679Q9J32687; Wed, 7 Jul 2004 12:26:09 +0300 Date: Wed, 7 Jul 2004 12:26:09 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: David Kessens , Subject: RE: Moving forward In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 2 Jul 2004, Soliman Hesham wrote: > > On Thu, 1 Jul 2004, Soliman Hesham wrote: > > > FWIW, there was unanymous concensus in the Seoul meeting > > > to standardise all mechanisms being considered at the moment > > > > Nope -- I don't recall anything like that. Could you elaborate using > > the minutes when you believe that kind of consensus was achieved or > > even asked. > > => Hmmm, After your presentation which included an analysis > of all current proposals (it was divided in some way that > I never quite understood), you and Jonne asked the group > if there were any objections to moving forward with any > of the mechanisms and no one objected. I recall this very > clearly. I didn't read the minutes after the meeting but > I was there. I believe this was in the first session. If this was in the first session, there was an attempt to divide the mechanisms to 'opportunistic' and 'zero-configured'. From the minutes: ==== Consensus call (raising hands): 1) Is opportunistic tunneling needed => many hands; a few hands against. 2) Is zeroconf tunnel needed to be standardized => many hands; nobody against. => Consensus: both are needed and will be standardized. ==== This is was *NOT* consensus that all the mechanisms be standardized as you seem to have understood, but only that there must be a standardized mechanism representing both classes of solutions for which there was consensus. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jul 7 11:17:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25411 for ; Wed, 7 Jul 2004 11:17:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiE8m-000Nrv-K2 for v6ops-data@psg.com; Wed, 07 Jul 2004 15:15:20 +0000 Received: from [206.123.31.135] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiE8c-000Npg-VG for v6ops@ops.ietf.org; Wed, 07 Jul 2004 15:15:11 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (8.12.10+Sun/8.12.10) with ESMTP id i67FFAZa024538; Wed, 7 Jul 2004 11:15:11 -0400 (EDT) Date: Wed, 07 Jul 2004 11:15:10 -0400 From: Florent Parent To: Jeroen Massar , Alain Durand cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-assisted-tunneling-requirements-00.txt Message-ID: <39E5D32D2058C17FCF537E52@blues> In-Reply-To: <1088496993.20311.133.camel@segesta.zurich.ibm.com> References: <200406281931.PAA25593@ietf.org> <1088496993.20311.133.camel@segesta.zurich.ibm.com> X-Mailer: Mulberry/3.1.6 (SunOS/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jeroen, Sorry for long round-trip. Back from vacation. comments inline: -- On Tuesday, June 29, 2004 10:16:34 AM +0200, Jeroen Massar wrote: > On Mon, 2004-06-28 at 21:31, Internet-Drafts@ietf.org wrote: > > >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling- >> requirements-00.txt > > My comments: > > Section 1. > 8<--------- > "Assisted tunneling" is used in this document to described a > transition mechanism where the parameters" > --------->8 > > Should be 'describe'. ok. > > Section 2. > 8<--------- > dual stack UE connecting to IPv6 nodes through a 3GPP network that > --------->8 > What is the definition of a "UE" ? User Endpoint I assume or this > more likely to be some 3GPP term of which I am not familiar with. "User Equipment". From [3GPP] draft. > > Section 4.1 > 8<--------- > Assignment of an IPv6 address (/128) to the end-node must be > supported in both modes. > --------->8 > Shouldn't we suggest assigning a /64 over 'links'? Tunnels are > 'tunnel-links' between the TunnelServer and the TunnelClient. > > Also what if the client moves to a native link. There could be the case > where a ISP only can't provision the last mile, eg because the router > directly facing the customers doesn't support IPv6 yet. In this and some > other cases when the router and the CPE does support IPv6 they can simply > lay the /64 tunnel space on the native link and the user nor the ISP have > to change much. The previous version specifically mentionned that /128 was assigned on the tunnel link. We changed that saying that a /128 must be supported in any mode, but a prefix (/64 and +) is possible in any mode as well. How this prefix is assigned is unspecified in this draft. > > Also mentioning that ISP's can pass out /128's will cause them to do so > and also will have them have a word saying 'see that RFC they say give > out /128's. RFC 3177 already mentions that. > Giving out a /64 for a link doesn't mean one can't filter > everything except ::1 and ::2 of that /64 btw (or just set a /128 only to > the remote side). Read: with /128's IPv6 NAT will happen.... How about adding text relating to RFC3177? I'm not sure forbidding /128 in the protocol is the right direction, but I'd like to hear from others as well on this. > > Section 4.4 > This could refer to draft-palet-v6ops-tun-auto-disc ok. noted. > > Section 4.7 > Isn't this all out of scope for the setup protocol ? > It is good to mention them nevertheless of course but still. That is certainly more related to the implementation (as with other parts of this draft as well). > Also "not _an_ exhaustive list" which it indeed is as many things can > be added. Agreed. > > Section 4.8 > Though no direct solutions are refered to, this could also mention that > proto-41 should not be used as it doesn't get authenticated per packet > and thus can easily be spoofed when the access network (client<->server) > isn't completely under ingress/egress filtering control, aka when the > IPv4 or outer when talking about IPv6-in-IPv6 etc, addresses can be > spoofed. I don't think ip-proto-41 should be forbidden because of possible spoofing (otherwise, we'll have to forbid IPv4 and IPv6 usage ;-) If spoofing is a security risk for an ISP, then security measures are available from other protocols, such as ipsec, no? (or ayiya ;-) > A mention of shaping tunnels, eg ratelimiting per /24 > destination IPv4 could also help in cases where somebody tries to DDoS, > of course these are preventive measures that can be circumvented, by > ddossing the router upstream etc. Noted. Yes, I can help to slow down the DoS. Return routability also helps against attacks based on IP spoofing. ... > Section 5.2 > Like 4.4, this could refer to draft-palet-v6ops-tun-auto-disc > Prolly the 'best' is to have: > - dns prefix search (tunnelsetup.example.net) > - globaly known single anycast address where > the setup protocol connects to and asks for service. > This anycast address could either say 'see > http://www.example.net/ipv6/' or it could say 'no service' or 'get > your setup info from host tunnelsetup.example.net' ok. noted. > > Section 5.3 > This basically boils down to using UDP, as I think it should be a > requirement to demand per-packet authentication of these tunnels packets > to work against spoofing, proto-41 is really a no-go. as stated above, I'm not (yet) convinced of that. I can certainly see a "secured" tunnel mode, but as an optional feature. > This also saves for > the overhead of figuring out 'are you behind a nat' and 'are you behind a > firewall'. > If an administator is filtering certain ports/protocols then > that should never be tried to be circumvented. Agreed and the requirement doesn't propose that. The security policy could allow IPv6 in UDP for example, but not ip-proto-41. In which case the user must be able to select the encapsulation type. > > Section 5.4 > Some NAT boxes will force-timeout mappings or have a very short timeout. > The tunneling or the setup protocol used should be able to recover thus > from both endpoint address and port changes without loosing packets. Yes. But "without loosing packets" need to be defined. e.g. if I have a ping(v6) in a loop going out of my tunnel and the NAT state changes, I will certainly loose ICMPv6 packets. Maybe you are referring to not loosing IPv6 connections instead? > > Section 5.5 > The latency issue for the config protocol basically means that any tunnel > setup protocol employing command/response should be able to support some > mechanism similar to SMTP pipelining. SASL auth defeats the initial setup > of course. As can be learned from TSP the overhead is not that large at > all thus this should be mostly ignorable. Good to note nevertheless. > > Section 5.6 > 8<------- > The tunnel set-up protocol must not introduce any new vulnerability > to the network. > -------->8 > Shouldn't that read: > 8<--------- > The tunnel set-up, nor the tunneling protocol must not introduce > any new vulnerability to the network. > --------->8 > When you only 'secure' the set-up, then people will simply abuse > the tunneling protocol. > > To also mitigate attacks based on 'knowledge' of endpoint information eg > by sniffing setup information packets it should be IMHO that the tunnel > setup protocol is able to use some form of SSL/TLS mode thus making sure > that the interaction between client and server is not readable maybe > disclosing information that can be useful to attack the tunnel. Again as an option that can be enabled/disabled? > > Section 5.8 > Additionally the protocol should have the generic possiblity of returning > a URL. This can be used in many cases: > - signup page > - help page > - explaination page > - 'this service is closed' > - etc. ok. Similar to the registration (4.2) information I guess. > It could also explain the user how to disable the client program. > The client-program might also want to ask the user if it wants to use > native or tunneled connectivity maybe in case where the native > connectivity is misconfigured, and thus not working. > > Section 5.10 > Fortunatly this is a should, typically, from what I have seen at least, > most ISP's don't allow their customers to change reverse DNS entries. > Also, tunnels should be seen as 'transit networks', the /48 routed to the > client should have a means of registering dns servers though. The current requirement has nothing about DNS prefix delegation. Are you saying it should be supported in the protocol? > > Appendix A > "The registered mode:" > "- implementation SHOULD turn it off by default" > Shouldn't asking the client once be a good option? Not following here. > > "- MUST support single address assignment" > /128 or /64 ? > Remember, that when learning people they can give /128's there will be NAT > again for IPv6 and why oh why did all these nice people invent IPv6 ? :) > See also above at section 4.1 > > "- MUST support prefix delegation...." > As there was a mention of not reinventing the wheel, should this be using > DHCPv6 or RA's ? The requirements doesn't go as far as selecting how it's implemented. > Also the client-utility can't know what the network of > the user looks like. Must a prefix also always be a /48? We might want to > suggest that here to make sure ISP's adhere to that (yup trying to > technically enforce a political policy ;) > > > Next to that, as I see a number of items that do not directly relate to > TSP, is there a totally revamped TSP draft or a totally new protocol in > the pipe? The purpose was to state the requirements to have a clean table to work on. TSP is an existing implementation that fulfills most of these requirements, but I'm biased ;-) Florent From owner-v6ops@ops.ietf.org Wed Jul 7 16:45:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16423 for ; Wed, 7 Jul 2004 16:45:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiJFv-000H9o-BX for v6ops-data@psg.com; Wed, 07 Jul 2004 20:43:03 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiJFt-000H96-He; Wed, 07 Jul 2004 20:43:01 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2004 13:43:33 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i67Kgv4N006532; Wed, 7 Jul 2004 13:42:58 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVD72928; Wed, 7 Jul 2004 13:41:46 -0700 (PDT) Message-Id: <6.1.1.1.2.20040707133134.059e6df0@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 07 Jul 2004 13:39:23 -0700 To: Iljitsch van Beijnum From: Fred Baker Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Cc: Pekka Savola , Ralph Droms , v6ops@ops.ietf.org, Eliot Lear , Multi6 In-Reply-To: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk The working group last call has closed, and the only issue that I saw was the issue of ingress filtering affecting a temporarily homed network. Personally, I'm not sure that was not covered in section 3.3: 3.3 Ingress Filtering An important consideration in Section 2.3, in the case where the network being renumbered is connected to an external provider, the network's ingress filtering policy and its provider's ingress filtering policy. Both the network firewall's ingress filter and the provider's ingress filter on the access link to the network should be configured to prevent attacks that use source address spoofing. Ingress filtering is considered in detail in "Ingress Filtering for Multihomed Networks" [RFC3704]. but I have added the following to the introduction: 1.4 Multihoming Issues In addition to the considerations presented, the operational matters of multihoming may need to be addressed. Networks are generally renumbered for one of three reasons: the network itself is changing its addressing policy and must renumber to implement the new policy (for example, a company has been acquired and is changing addresses to those used by its new owner), an upstream provider has changed its prefixes and its customers are forced to do so at the same time, or a company is changing providers and must perforce use addresses assigned by the new provider. The third case is common. When a company changes providers, it is common to institute an overlap period, during which it is served by both providers. By definition, the network is multihomed during such a period. While this document is not about multihoming per se, problems can arise as a result of ingress filtering policies applied by the upstream provider or one of its upstream providers, so the user of this document need also be cognizant of these issues. This is discussed in detail, and approaches to dealing with it are described, in [RFC2827] and [RFC3704]. If this is deemed a sufficient change, I think the documents at ftp://ftpeng.cisco.com/fred/v6ops/renumber.html ftp://ftpeng.cisco.com/fred/v6ops/renumber.txt ftp://ftpeng.cisco.com/fred/v6ops/renumber.xml may be considered responsive to the WG last call. I will put in a note to internet-drafts to post them on Monday barring further comment, and request the chairs to forward them to the IESG. From owner-v6ops@ops.ietf.org Wed Jul 7 17:26:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18312 for ; Wed, 7 Jul 2004 17:26:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiJvk-000Pju-9p for v6ops-data@psg.com; Wed, 07 Jul 2004 21:26:16 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiJvi-000PjI-Mt; Wed, 07 Jul 2004 21:26:15 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i67LP82r006561; Wed, 7 Jul 2004 23:25:08 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <6.1.1.1.2.20040707133134.059e6df0@mira-sjc5-b.cisco.com> References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <6.1.1.1.2.20040707133134.059e6df0@mira-sjc5-b.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Ralph Droms , v6ops@ops.ietf.org, Eliot Lear , Multi6 , Pekka Savola From: Iljitsch van Beijnum Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Date: Wed, 7 Jul 2004 23:23:44 +0200 To: Fred Baker X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 7-jul-04, at 22:39, Fred Baker wrote: > When a company changes providers, it is common to institute an > overlap period, during which it is served by both providers. By > definition, the network is multihomed during such a period. While > this document is not about multihoming per se, problems can arise as > a result of ingress filtering policies applied by the upstream > provider or one of its upstream providers, so the user of this > document need also be cognizant of these issues. This is discussed > in detail, and approaches to dealing with it are described, in > [RFC2827] and [RFC3704]. These references outline ingress filtering, but there is only about half a page in the second one about how to route traffic with certain addresses to a certain provider, and this half page provides very little actual guidance. A few paragraphs along the lines of "ask one ISP to temporarily accept packets with the other's addresses and use that one for outgoing traffic or use policy routing to match ISPs to the source addresses in outgoing packets, or if these approaches aren't possible, implement a flag-day type of transition" would be very helpful, I think. From owner-v6ops@ops.ietf.org Wed Jul 7 18:56:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26052 for ; Wed, 7 Jul 2004 18:56:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiLJM-000G0S-0U for v6ops-data@psg.com; Wed, 07 Jul 2004 22:54:44 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiLJJ-000FzS-Sm; Wed, 07 Jul 2004 22:54:41 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2004 15:55:42 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i67MscgI023629; Wed, 7 Jul 2004 15:54:39 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVD86035; Wed, 7 Jul 2004 15:53:27 -0700 (PDT) Message-Id: <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 07 Jul 2004 15:27:34 -0700 To: Iljitsch van Beijnum From: Fred Baker Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Cc: Ralph Droms , v6ops@ops.ietf.org, Eliot Lear , Multi6 , Pekka Savola In-Reply-To: References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <6.1.1.1.2.20040707133134.059e6df0@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 11:23 PM 07/07/04 +0200, Iljitsch van Beijnum wrote: >On 7-jul-04, at 22:39, Fred Baker wrote: >>When a company changes providers, it is common to institute an overlap >>period, during which it is served by both providers. By definition, the >>network is multihomed during such a period. While this document is not >>about multihoming per se, problems can arise as a result of ingress >>filtering policies applied by the upstream provider or one of its >>upstream providers, so the user of this document need also be cognizant >>of these issues. This is discussed in detail, and approaches to dealing >>with it are described, in [RFC2827] and [RFC3704]. > >These references outline ingress filtering, but there is only about half a >page in the second one about how to route traffic with certain addresses >to a certain provider, and this half page provides very little actual guidance. > >A few paragraphs along the lines of "ask one ISP to temporarily accept >packets with the other's addresses and use that one for outgoing traffic >or use policy routing to match ISPs to the source addresses in outgoing >packets, or if these approaches aren't possible, implement a flag-day type >of transition" would be very helpful, I think. In a word, no. There was a serious attempt last fall to turn this document, which is about "how to renumber a network", into "how to configure ingress filtering and route traffic within multihomed networks". the problem is, there exist a lot of multihomed networks that are not periodically renumbered, and the issues of multihoming apply in them, and (believe it or not) not all networks that get renumbered are multihomed. Yes, a network might be multihomed temporarily while being renumbered, but that doesn't make renumbering==multihoming. They are in fact very different discussions. In the interest of ever getting a chance to actually do anything useful with "how to renumber a network", Pekka and I put the entire BCP 38 discussion into a separate document, which is now RFC 3704. This working group looked at that document, decided it was sufficient to describe those issues, and published it as an RFC. If it is not sufficient, fixing RFC 3704 is the task of the day, and should be part of the recharter effort that is currently under discussion. Alternatively, Multi6 could produce something useful on the topic. May I suggest that, by 12 July, you post an updated version of RFC 3704? From owner-v6ops@ops.ietf.org Wed Jul 7 21:08:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02029 for ; Wed, 7 Jul 2004 21:08:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiNMx-0008Mb-26 for v6ops-data@psg.com; Thu, 08 Jul 2004 01:06:35 +0000 Received: from [61.144.161.40] (helo=huawei.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiNLt-0008Cj-Vh for v6ops@ops.ietf.org; Thu, 08 Jul 2004 01:06:30 +0000 Received: from l04955 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I0I00L61DMZEC@mta0.huawei.com> for v6ops@ops.ietf.org; Thu, 08 Jul 2004 09:04:12 +0800 (CST) Date: Thu, 08 Jul 2004 09:06:22 +0800 From: lidefeng <77cronux.leed0621@huawei.com> Subject: A draft about VPN in IPv4/IPv6 Hybrid Network To: Pekka Savola , jonne.Soininen@nokia.com Cc: internet-drafts@ietf.org, v6ops@ops.ietf.org Message-id: <004801c46487$c939fdc0$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: multipart/mixed; boundary="Boundary_(ID_eEwE2NBGqqXg+DQYxA8s5g)" X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-scores: Clean:76.22930 C:21 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:4 R:4 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_eEwE2NBGqqXg+DQYxA8s5g) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Dear all, Attached is a draft about VPN in IPv4/IPv6 Hybrid Network, I hope this draft can be processed in the v6ops WG as soon as possible, discussions and comments are appreciated. BTW, I hope to discuss it at 60th IETF meeting, I would like to have a chance to make presentation for it, Could you please arrange a time slot for me? I think 10min slot will do. Thanks in advance. Defeng Li Huawei Technologies --Boundary_(ID_eEwE2NBGqqXg+DQYxA8s5g) Content-type: text/plain; name=draft-defeng-v6ops-ipv4-ipv6-hybrid-vpn-00.txt Content-disposition: attachment; filename=draft-defeng-v6ops-ipv4-ipv6-hybrid-vpn-00.txt Content-Transfer-Encoding: 7BIT INTERNET DRAFT Defeng Li Huawei Technologies June 2004 Expires December, 2004 BGP-MPLS VPN extension for IPv4/IPv6 Hybrid Network Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. Abstract This document describes some methods which may be used by Service Providers to provide Virtual Private Networks for some scenarios where the Service Provider's network or Customer's network is comprised of part of IPv4 network and part of IPv6 network.These situations can't be avoided during the process of IPv4 transition to IPv6, e.g. IPv6 backbone network for IPv4-IPv6 hybrid VPN sites,or IPv4 backbone network for IPv4-IPv6 hybrid VPN sites,or IPv4-IPv6 hybrid backbone network for IPv4-IPv6 hybrid VPN sites.This proposal continue to use the concepts described in the Internet draft "BGP/MPLS VPN"[2547bis],such as RD,VRF,Route Target and some mechanisms. In BGP/MPLS VPN, MPLS is used to forward packets over the backbone, and "Multiprotocol BGP" is used for distributing VPN routes over the service provider backbone. This document makes the reference to the current RFC or Internet Draft as to the IPv4 VPN address family and IPv6 VPN address family,In some hybrid scenarios,IPv4/IPv6 dual VPN address family should be supported in backbone, accordingly, some VPN sites should support IPv4/IPv6 dual route table. Defeng Li Expires December 2004 [Page 1] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 This document assumes that the reader is familiar with [2547bis]. Unless explicitly documented herein, [2547bis] applies. 1. Introduction This document adopts the definitions, acronyms and mechanisms described in [2547bis]. Unless otherwise stated, the mechanisms of [2547bis] apply and will not be re-described here. A VPN is said to be an IPv6 hybrid VPN, when one of the following conditions is meeted: (a) Some sites of this VPN is IPv6 capable and is natively connected over an interface or sub-interface to the SP backbone via a Provider Edge device (PE). (b) Backbone network for VPN consists of IPv6 capable network and IPv4 capable network. A site may be both IPv4-capable and IPv6-capable. The logical interface on which packets arrive at the PE may determine the version, or alternatively a per-packet header lookup on the same interface may determine the version. In this document, for those sites having VPN relationship with other IPv4 sites and IPv6 sites in the same VPN, and those sites connected to the different IP version part of backbone (e.g. IPv4 sites connected to IPv6 part of backbone or IPv6 sites connected to IPv4 part of backbone),CE MUST support both IPv4 and IPv6. When PE connects to both IPv4 sites and IPv6 sites(maybe these sites belong to different VPN), or PE connects to CE which must be dual-stacked according to the rules above mentioned, then PE should be dual-stacked too. The PE being dual stack has full IPv4 capabilities, must maintain IPv6 VRFs for its IPv6 sites and must be able to encapsulate IPv6 datagrams in MPLS frames to be sent into the MPLS core network. BGP and its extensions are used to cause routes from IPv4 or IPv6 VPN sites to be distributed over the backbone to each other PE router connected to a site of the same IPv6 hybrid VPN. As it is done for IPv4 VPNs [2547bis], we allow each IPv6 hybrid VPN to have IPv4/IPv6 hybrid address space, i.e. for a VPN with both IPv4 VPN sites and IPv6 VPN sites, both VPN-IPv4 and VPN-IPv6 address family are needed, VPN-IPv4 address family refers to [2547bis], VPN-IPv6 address family is a 24-byte quantity, composed of an 8-byte "Route Distinguisher" (RD) and a 16-byte IPv6 address. MP-BGP allows BGP to carry routes from multiple "address families", so IPv4/IPv6 hybrid address space enables the VPN routes of IPv4 sites and IPv6 sites of the same VPN to be distributed across the backbone. This document first addresses BGP/MPLS VPN mechanism under the situation where VPN sites consist of IPv4 sites and IPv6 sites, and the backbone network consists of one or more IPv4 autonomous system and at least an IPv6 autonomous system, then propose some mechanism for the simple situations. Defeng Li Expires December 2004 [Page 2] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 2. Hybrid Backbone and Hybrid VPN sites In Hybrid Backbone and Hybrid sites situation, VPN backbone network consists of one or more IPv4 autonomous system and at least an IPv6 autonomous system, and VPN sites consist of IPv4 sites and IPv6 sites. Note: This document proposes two methods to address this hybrid VPN scenario, and are detailed in section 2.1 and section 2.2 respectively. 2.1. Method 1 In this method, PEs and ASBR in every AS establish MP-IBGP to distribute the VPN routes between the sites belong to the same AS, and ASBRs of the adjacency AS establish MP-EBGP to distribute VPN routes between the sites belong to the different AS.For the conveniency of discussion, we first consider the situation where backbone network consists only two autonomous system(from Section 2.1.1. to Section 2.1.5.), one is IPv4 AS(AS1) and the other is IPv6 AS2, they connected to each other through some ASBRs, for simplicity, considering the situation where only one ASBR for each AS, ASBR1 for AS1,ASBR2 for AS2, and in some of VPNs accessed to the backbone, some sites are IPv6 sites, others are IPv4 sites. In the following sections, several aspects such as address family, routing distribution, label assignment, data forwarding, VPN topology implementation. In Section 2.1.6., we will discuss how to extend the mechanism to the situation where more than two AS(at least one of them is IPv6 AS). 2.1.1. Address Family In this method, we only consider Unicast communication between VPN sites, and Unicast address(IPv4 or IPv6) should be used. Considering there are still some IPv4 Sites in the VPN and the scarcity of IPv4 address, private IPv4 addresses(defined in RFC 1918) are allowed to be used IN vpn sites, and if two VPNs have no sites in common, they may have overlapping address spaces, this aspect is the same as [RFC 2547bis]. For IPv6 sites, the global unicast address should be used, for the huge IPv6 address space, all the addresses are public addresses. Communications between IPv4 sites use IPv4 address, accordingly, AFI field in MP-BGP can be valued as 1, which is assigned for IPv4 in RFC 1700. Communications between one IPv4 site and one IPv6 site or communications between IPv6 sites use IPv6 address, the IPv4 addresses A.B.C.D/MASK in IPv4 sites can be mapped to IPv6 addresses in the form of 0::A:B:C:D/(96+MASK), accordingly, AFI field in MP-BGP can be valued as 2, which is assigned for IPv6 in RFC 1700. SAFI field in MP-BGP can be valued as 128 to denote the address family for VPN-IPv4 or VPN-IPv6 address. So there will be two VPN address family in this mechanism, MP-BGP will distribute VPN-IPv4 routes and VPN-IPv6 routes at the same time, PEs and ASBRs in this mechanism should support IPv4/IPv6 dual-stack and maintain both VPN-IPv4 routes and VPN-IPv6 routes.If some IPv4 sites have only communications with other IPv4 sites, CEs in these sites can only support IPv4 protocol and maintain IPv4 VPN routes, otherwise CE should support IPv4/IPv6 dual-stack and maintain both IPv4 VPN routes and IPv6 VPN routes of the same VPN. Defeng Li Expires December 2004 [Page 3] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 As stated above, private IPv4 addresses is used in this method, for the same reason as stated in RFC 2547bis, RD continues to serve the purpose of forming the VPN-IPv4 or VPN-IPv6 address, i.e. A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte "Route Distinguisher (RD)" and ending with a 4-byte IPv4 address, and AFI for this address family is 1. A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte "Route Distinguisher (RD)" and ending with a 16-byte IPv6 address(In the case of IPv4 site which has communication with IPv6 site, IPv4 addresses is mapped to IPv6 addresses before forming VPN-IPv6 addresses), and AFI for this address family is 2. 2.1.2. VPN routes distribution VPN sites distribute their routes to PE through routing protocol between CE in the VPN site and PE connected to CE, For the hybrid characteristic of VPN routes, i.e. CE should maintain both IPv4 routes of other IPv4 sites and IPv6 routes of other IPv6 sites, this document proposes to run BGP4+ or IS-ISv6 protocol between CE and PE. It is noted that these two routing protocols can carry both IPv4 routes and IPv6 routes at the same time. When BGP4+ is run between CE and PE, the private AS number should be used in VPN sites. Of course, if OSPFv3 run between CE and PE, IPv4 routes can also be distributed between them through mapping IPv4 routes to IPv6 routes, i.e. when PE learns IPv4 route a.b.c.d/n(where a.b.c.d is subnet address, and n is mask) across backbone, it maps the route to IPv6 route in the form of 0::a:b:c:d/(96+n) and distributes to CE, CE then revert it to a.b.c.d/n and maintain it in IPv4 routing table. After PE learns VPN routes from CE, PE should distribute the VPN routes to the related sites in the same VPN through backbone network before these sites can visit each other, and backbone is composed of IPv4 AS and IPv6 AS, in this section, we only consider the case in which backbone is composed of one IPv4 AS(AS1) and one IPv6 AS(AS2). The distribution process of VPN routes across backbone is as follows: (1) Every two of PEs and ASBR1 in AS1 setting up MP-IBGP based on IPv4; (2) Every two of PEs and ASBR2 in AS2 setting up MP-IBGP based on IPv6; (3) ASBR1 and ASBR2 setting up MP-EBGP based on IPv6; (4) VPN routes from the sites connected to AS1 can be distributed to each other through those MP-IBGP relationships set up in (1), IPv4 routes and IPv6 routes can be piggybacked on the same MP-IBGP; (5) VPN routes from the sites connected to AS2 can be distributed to each other through those MP-IBGP relationships set up in (2), IPv4 routes and IPv6 routes can be piggybacked on the same MP-IBGP; (6) VPN routes need to be distributed to sites connected to neighboring AS can be achieved by MP-EBGP between ASBR1 and ASBR2, according to BGP protocol, routes learned from EBGP PEER should be distributed to IBGP PEER, IPv4 routes and IPv6 routes can be piggybacked on the same MP-EBGP. After the above steps, all the VPN routes can be distributed across backbone network, then PEs maintain the related routes. The difference from RFC 2547bis is that PEs should maintain both IPv4 routes and IPv6 routes in the respective VRFs, IPv4 routes and IPv6 routes can be differentiated by the AFI of the routes received, if AFI is 1, routes will be maintained in IPv4 part of VRF, if AFI is 2, then routes will be maintained in IPv6 part of VRF. Defeng Li Expires December 2004 [Page 4] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 As to the decision whether to accept and advertise the routes received from MP-BGP PEER, PE follows the same rule as stated in RFC 2547bis, where Route Target attribute is used, and this attribute is related to the topology of VPN, it will be detailed in section 2.1.5. Following this mechanism, all the VPN routes can be correctly distributed all over the VPN network, For some sites need to visit IPv4 sites and IPv6 sites, IPv4 routing table in CE can be matched when the destination is IPv4 sites, IPv6 routing table in CE can be matched when the destination is IPv6 sites. If some sites have no relationship with other IPv6 sites, then it is not necessary for these sites to run IPv6 routing protocol with PEs, Even it is enough for these sites to support only IPv4, i.e. IPv4/IPv6 dual-stack is not a must. 2.1.3. Label Distribution Sites belongs to different VPN can connect to the same PE, PE differentiates them by assigning different labels for the sites, this label is called inner label, which will be attached to the VPN routes when PE distributing the VPN routes to MP-BGP PEERs. If backbone network supports MPLS and LDP/RSVP-TE runs in backbone, LDP/RSVP-TE will setup LSPs between PEs and ASBR1 in AS1 and PEs and ASBR2 in AS2 respectively and the label related to these LSPs is called outer label, i.e. the packet received from CE will be label-stacked with two label before IP header. If backbone network doesn't support MPLS, other tunnelling technology can be utilized to setup the tunnel between PE and ASBR,such as GRE, IPsec, and so on. And ASBR1 will establish MP-EBGP with ASBR2, and MP-EBGP will distribute the labels between ASBR1 and ASBR2(refer the mechanism to RFC 3107), these two labels will form a tunnel segment to "stick" the tunnel segments in AS1 and AS2. 2.1.4. Forwarding Data forwarding between VPN sites across backbone consists of following steps: (1) IP Forwarding from source site to Ingress PE; (2) Label or tunneling Forwarding from Ingress PE to Egress PE; (3) IP forwarding from Egress PE to destination site. Where, step (1) follows normal IP forwarding process. As stated in section 2.2.3, if one site has VPN relationship with other IPv4 sites and IPv6 sites simultaniously, CE in this site should maintain both IPv4 route table and IPv6 route table respectively. when the destination is IPv4 site, the IPv4 route table can be queried, otherwise IPv6 route table will be matched. In step (2), ingress PE pushes the inner label to the packet, if backbone supports MPLS, pushes the outer label distributed in the Ingress PE's AS, or encapsulates the tunnel header(when MPLS isn't supported) and forwards packet to ASBR in Ingress PE's AS, where pops the outer label(or penultimate hop poped the outer label) or decapsulates the tunnel header, and pushes the label assigned by MP-EBGP between ASBRs, forwards the packet to the ASBR in the neighboring AS, then VPN packet is forwarded to Egress PE in the neighboring AS following Defeng Li Expires December 2004 [Page 5] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 the same rules as in the previous AS. In step (3),Egress PE receives the packet with inner label(outer label has been popped or the tunnel header has been decapsulated) and distinguishes the destination site by the inner label, then pops the inner label, forwards packet to CE, at last the packet is forwarded to the destination following normal IP forwarding rules. mechanism 2.1.5. VPN topology VPN sites can form different kinds of relationships, such as full mesh, partial mesh, Hub-Spoke, which is called VPN topology. To achieve this, the mechanism of utilizing Route Target as stated in RFC 2547bis can still be used. VPN topology is formed through the routes in VPN sites, if one site have routes to other sites, then it has VPN relationships with those sites, all of VPN relationships among VPN sites form VPN topology. PE can decide whether to accept VPN routes received from other PE carried in MP-BGP UPDATE messages through matching Route Target attributes. When Egress PE distributes VPN routes, the configured Export Route Targets will be attached, and Ingress PE is also configured with Import Route Targets, so Ingress PE can compare the local Import Route Target with the remote Export Route Target attached to the received routes from MP-BGP PEERs, then only those routes with route target attributes matched can be accepted and maintained in VRF by Ingress PE, others will be discarded, After that Ingress PE advertise the accepted VPN routes to the directly connected CE. 2.1.6. IPv4/IPv6 Multi-AS Hybrid Backbone In Section 2.1.1. through to Section 2.1.5. , the case where only two ASes(one is IPv4 AS, the other is IPv6 AS) is addressed in detail. In the case of IPv4/IPv6 multi-AS hybrid backbone, the mechanisms in Address Family, VPN routes distribution, Label Distribution, Forwarding, VPN topology are analogic to the case of two ASes, MP-IBGPs are setup in all the ASes between PEs and ASBR, and MP-EBGPs are established between directly connected ASBRs in adjacent ASes, and this MP-EBGPs will distribute the labels for these ASBRs. VPN routes for IPv4 sites and IPv6 sites can be "relayed" among these MP-IBGP or MP-EBGP. The tunnel used to forward packets between Ingress PE and Egress PE can be "sticked" together from tunnel segments of respective AS and tunnel segments between ASBRs of adjacent ASes. 2.2. Method 2 Similar to Method 1, we first consider the scenario where backbone network consists only two autonomous system(from Section 2.2.1. to Section 2.2.5.), one is IPv4 AS(AS1) and the other is IPv6 AS2, they connected to each other through some ASBRs, for simplicity, considering the case where only one ASBR for each AS, ASBR1 for AS1, ASBR2 for AS2, and in some of VPNs accessed to the backbone, some sites are IPv6 sites, others are IPv4 sites. In this method, PEs and ASBRs in IPv6 AS establish IPv6-based full-mesh MP-IBGP(or MP-BGP Route Reflector) to distribute VPN routes of sites belong to IPv6 AS, and every two PEs in IPv4 AS establish IPv4-based MP-IBGP to distribute VPN routes of sites Defeng Li Expires December 2004 [Page 6] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 belong to IPv4 AS, and every PE in IPv4 AS doesn't establish MP-IBGP with ASBR in its own AS as in Method 1, but establishes IPv4-based multi-hop MP-EBGP with ASBR in the IPv6 AS, so the VPN routes across IPv4 AS and IPv6 AS will be distributed through these multi-hop MP-EBGP, We call IPv6 AS as Primary AS(PAS), and IPv4 AS as Dependent AS(DAS). 2.2.1. Address Family Address scheme in Method 2 is the same as that in Method 1, refer to section 2.1.1. 2.2.2. VPN routes distribution VPN sites distribute their routes to PE through routing protocol between CE in the VPN site and PE connected to CE, For the hybrid characteristic of VPN routes, i.e. CE should maintain both IPv4 routes of other IPv4 sites and IPv6 routes of other IPv6 sites, this document proposes to run BGP4+ or IS-ISv6 protocol between CE and PE. It is noted that these two routing protocols can carry both IPv4 routes and IPv6 routes at the same time. When BGP4+ is run between CE and PE, the private AS number should be used in VPN sites. Of course, if OSPFv3 run between CE and PE, IPv4 routes can also be distributed between them through mapping IPv4 routes to IPv6 routes, i.e. when PE learns IPv4 route a.b.c.d/n(where a.b.c.d is subnet address, and n is mask) across backbone, it maps the route to IPv6 route in the form of 0::a:b:c:d/(96+n) and distributes to CE, CE then revert it to a.b.c.d/n and maintain it in IPv4 routing table. After PE learns VPN routes from CE, PE should distribute the VPN routes to the related sites in the same VPN through backbone network before these sites can visit each other, and backbone is composed of IPv4 AS and IPv6 AS, in this section, we only consider the case in which backbone is composed of one IPv4 AS(AS1) and one IPv6 AS(AS2). The distribution process of VPN routes across backbone is as follows: (1) Every two of PEs in DAS setting up MP-IBGP based on IPv4; (2) Every two of PEs and ASBR2 in PAS setting up MP-IBGP based on IPv6; (3) Every PE and ASBR2 setting up multi-hop MP-EBGP based on IPv4; (4) VPN routes from the sites connected to DAS can be distributed to each other through those MP-IBGP relationships set up in (1), IPv4 routes and IPv6 routes can be piggybacked on the same MP-IBGP; (5) VPN routes from the sites connected to PAS can be distributed to each other through those MP-IBGP relationships set up in (2), IPv4 routes and IPv6 routes can be piggybacked on the same MP-IBGP; (6) VPN routes need to be distributed to sites connected to neighboring AS can be achieved by multi-hop MP-EBGP between PEs in DAS and ASBR2 in PAS,according to BGP protocol, routes learned from EBGP PEER should be distributed to IBGP PEER, IPv4 routes and IPv6 routes can be piggybacked on the same MP-EBGP. After the above steps, all the VPN routes can be distributed across backbone network, then PEs maintain the related routes. The difference from RFC 2547bis is that PEs should maintain both IPv4 routes and IPv6 routes in the respective VRFs, IPv4 routes and IPv6 routes can be differentiated by the AFI of the routes received, if AFI is 1, routes will be maintained in IPv4 part of VRF, if AFI is 2, then routes will be maintained in IPv6 part of VRF. Defeng Li Expires December 2004 [Page 7] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 As to the decision whether to accept and advertise the routes received from MP-BGP PEER, PE follows the same rule as stated in RFC 2547bis, where Route Target attribute is used, and this attribute is related to the topology of VPN, it will be detailed in section 2.2.6. Following the above mechanism, all the VPN routes can be correctly distributed all over the VPN network, For some sites need to visit IPv4 sites and IPv6 sites, IPv4 routing table in CE can be matched when the destination is IPv4 sites, IPv6 routing table in CE can be matched when the destination is IPv6 sites. If some sites have no relationship with other IPv6 sites, then it is not necessary for these sites to run IPv6 routing protocol with PEs, Even it is enough for these sites to support only IPv4, i.e. IPv4/IPv6 dual-stack is not a must. 2.2.3. Label Distribution Egress PE assigns the different labels for different sites, which may be related to different interfaces or sub-interfaces. These labels are attached to VPN routes of the sites when PEs distribute these routes across backbone, these labels are inner labels in label stack during encapsulation before forwarding VPN packets across backbone. To guarantee the isolation of VPN service in backbone, VPN packets are forwarded in tunnels between Ingress PE and Egress PE, if some AS in backbone supports MPLS, the tunnel can be LSP, the labels form the LSP are distributed by LDP/RSVP-TE, and these labels are outer labels in label stack, if MPLS is not supported in some AS, then other types of tunnel, such as IPsec(tunnel mode) or GRE tunnel can be used. ASBR in DAS and ASBR in PAS can distribute labels for each other by MP-EBGP between them, these labels will be encapsulated as outer labels between these two ASBRs. 2.2.4. Segmented Tunnel In this method, The tunnel between Ingress PE and Egress PE is composed of segments of those from PE to ASBR in their respective ASes and those between ASBRs. The segments in the respective ASes can be LSP formed by outer labels distributed LDP run in ASes, or other type of IP tunnel, such as GRE tunnel or IPsec in tunnel mode. Segment between ASes is LSP of label distributed by MP-EBGP between ASBRs. 2.2.5. Forwarding VPN packets forwarding in this method is the same as that in Methos 1, which is addressed in detail in section 2.1.4. 2.2.6. VPN topology This aspect is the same as that in Method 1, which is addressed in section 2.1.5. 2.2.7. Hierarchical IPv4/IPv6 Multi-AS Hybrid Backbone In sections 2.2.1. through to 2.2.6., the case where VPN backbone is composed of one IPv4 AS(DAS) and one IPv6 AS(PAS) is addressed. Defeng Li Expires December 2004 [Page 8] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 In some cases, VPN backbone is composed of three or more ASes, and at least one of them is IPv6 AS, then the IPv6 AS with largest number of PEs than other IPv6 AS is looked upon as PAS, other IPv6 AS and IPv4 AS are looked upon as DAS, in the case of three ASes, the topology can be DAS-PAS-DAS, or DAS-DAS-PAS, it can be looked upon as a new DAS was concatenated to the "DAS-PAS" topology as addressed in section 2.2.1 by the rule that PEs in the new DAS establish MP-IBGP to distribute the VPN routes of sites connected to PEs belong to this new DAS, and PEs establish multi-hop MP-EBGP with ASBR in the adjacent AS of this new DAS, and the ASBR involved should establish multi-hop MP-EBGP with the ASBR in its adjacent AS, until this MP-EBGP relationship reaches the ASBR in PAS. So the MP-EBGP is hierarchical multi-hop MP-EBGP, VPN routes of sites across AS can be distributed by this hierarchical multi-hop MP-EBGP. This architecture is called hierarchy of DAS and PAS. Ths case of IPv4/IPv6 Multi-AS Hybrid Backbone can be addressed by this architecture. 3. IPv4 backbone and IPv4/IPv6 hybrid VPN sites In the scenario where VPN backbone is IPv4 network of one or more AS, and some VPN sites is IPv4 enable, other VPN sites is IPv6 enable, and these VPN sites would like to establish VPN service. In this case, the goal can be achieved by assigning the private IPv4 addresses for these IPv6 sites at PE device, and then run private IPv4 address NAT-PT at the related PE device, an private IPv4 address pool can be maintained at PE for every IPv6 VPN site connected. The address pool is denoted in a private IPv4 subnet prefix, and this subnet prefix can't be duplicated in the VPN this subnet prefix belongs to, and PE assigns different private IPv4 subnet prefix for different IPv6 sites. NAT-PT address pool assigns every private IPv4 address for every IPv6 hosts in IPv6 sites dynamically or statically, so as to every IPv6 host can get unique private IPv4 address. To be compatible with other VPN routes, these private IPv4 subnet prefix are treated as VPN routes of the corresponding IPv6 sites, and will be formed to IPv4-VPN routes by prefixing with RD, these IPv4-VPN routes can be distributed across backbone by MP-BGP in RFC 2858, To identify whether a VPN site is an IPv6 site, we can extend MP-BGP protocol by adding an Extended Community attribute: If-V6-Site, this attribute can be attached to VPN routes when distributing IPv4-VPN among PEs with MP-BGP, for VPN routes of IPv6 sites, both the mapped IPv4 routes(private IPv4 subnet prefix maintained by NAT-PT) at PE device and the true IPv6 routes of the IPv6 sites should be distributed to the MP-BGP Peer, the true IPv6 routes can be attached to UPDATE message in MP-BGP as the "value" field of If-V6-Site extended community attribute. The MP-BGP Peers which receive these UPDATE message can decide whether to accept the IPv4-VPN routes by matching the Route Target attributes as stated in RFC 2547bis, then decide whether to accept the true IPv6 routes by identifying if the IPv6 sites of the same VPN is conneted, if MP-BGP Peer connects IPv6 sites of the same VPN, the true IPv6 routes will be accepted too, otherwise the true IPv6 routes will be discarded. By this mechanism, a IPv6 site can visit other IPv6 sites with these true IPv6 routes directly, and IPv6 packets can be directly encapsulated with MPLS label-stack or GRE tunnel header and forwarded across VPN backbone, so that two-way NAT-PT translation at Ingress PE and Egress can be avoided,which maybe introduce the missing information during NAT-PT. In this way, the integrity of communication between IPv6 sites in the hybrid VPN Defeng Li Expires December 2004 [Page 9] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 can be achieved. As to communication between IPv4 site and IPv6 site, NAT-PT translation at PE where IPv6 site is connected should be performed. Of course, communication among IPv4 sites follows the same rule detailed in RFC 2547bis. 3.1. Address Family and Route Distribution We only consider Unicast communication between VPN sites, and Unicast address(IPv4 or IPv6) should be used. Considering there are still some IPv4 Sites in the VPN and the scarcity of IPv4 address, private IPv4 addresses(defined in RFC 1918) are allowed to be used IN vpn sites, and if two VPNs have no sites in common, they may have overlapping address spaces, this aspect is the same as [RFC 2547bis]. For IPv6 sites, the global unicast address should be used, for the huge IPv6 address space, all the addresses are public addresses. Communications between IPv4 sites or between one IPv4 site and one IPv6 site use IPv4 address, the address for IPv6 site can be the private address assigned by NAT-PT, communications between IPv6 sites use IPv6 address. As the true IPv6 routes for the IPv6 sites and IPv4 routes(including the subnet prefix for IPv6 sites maintained by NAT-PT at PE) are both distributed by IPv4-based MP-BGP across backbone, AFI field in MP-BGP can be valued as 1, which is assigned for IPv4 in RFC 1700. SAFI field in MP-BGP can be valued as 128 to denote the address family for VPN-IPv4 address. PEs connect IPv6 sites should run NAT-PT, these PEs should be dual-stacked, and CEs in those sites having VPN relationships with both IPv4 sites and IPv6 sites should be dual-stacked too, and CEs maintain both IPv4 routes and IPv6 routes for these sites. If some sites have only communications with other sites of the same IP version, such as IPv4 to IPv4, or IPv6 or IPv6, CEs in these sites can only support one IP version protocol and maintain only one IP version routes, in this case, CEs can select only part of the same IP version as the sites in VPN routes when CEs learn VPN routes from PEs. As stated above, private IPv4 addresses is used in this method, for the same reason as stated in RFC 2547bis, RD continues to serve the purpose of forming the VPN-IPv4, i.e. A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte "Route Distinguisher (RD)" and ending with a 4-byte IPv4 address. VRF can also used to maintain VPN-IPv4 routes(including the private IPv4 subnet prefix for IPv6 site at PE maintained by NAT-PT) as stated in RFC 2547bis, as to the true IPv6 routes received as If-V6-Site attribute value in UPDATE message, they can be maintained seperately from VRF, normally, they can be globally unique. Routing protocol runs between PE and CE to distribute VPN routes, Considering the requirement of distributing both IPv4 routes (including Private IPv4 subnet prefix for IPv6 sites at PE maintained by NAT-PT) and true IPv6 routes for IPv6 sites, BGP4+ and IS-ISv6 protocol which can piggybacking IPv4 and IPv6 routes simultaniously are suggested. If local site is IPv4 site, CE distributes aggregated IPv4 routes in the local site to PE, and PE distributes to CE the VPN routes of remote sites of the same VPN, if the remote site is IPv6 site, only the private IPv4 subnet prefix for that IPv6 site maintained by NAT-PT at the remote PE will be distributed to the local IPv4 site, and ignore If-V6-Site attribute attached. Defeng Li Expires December 2004 [Page 10] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 If local site is IPv6 site, CE distributes aggregated IPv4 routes in the local site to PE, and PE distributes to CE the VPN routes of remote sites of the same VPN, if the remote site is IPv6 site, the VPN routes will include the true IPv6 routes for the remote site, and CE can only learn this part and discard the related private IPv4 subnet prefix for the remote IPv6 site, if the remote site is IPv4 site, the VPN routes for the remote IPv4 site(a.b.c.d/mask) can be translated to the form of (NAT-PT Prefix:a:b:c:d:/(96+mask)) and distribute to CE in the local IPv6 site. Note: NAT-PT Prefix in a prefix assigned by IANA. After learning VPN routes from CEs, PEs will distribute VPN routes through IPv4-based MP-BGP across backbone, and the true IPv6 routes can be piggybacked on IPv4-based MP-BGP in If-V6-Site attributes with the mechanism stated above. 3.2. Judgement of IPv4/IPv6 sites Whether the sites is IPv6 or not can be identified by the address of the interface(subinterface) between CE and PE, then PE can set the related fields in If-V6-Site Extended Community attribute when distributing the VPN routes across backbone, and whether the remote site is IPv6 can be identified by If-V6-Site attached to VPN routes received. 3.3. If-V6-Site Attribute If-V6-Site is an Extended Community attribute for MP-BGP defined in this document, it is a triple of (Type,Length,Value), the structure can be denoted temporarily as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | IPv6 Route1 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Routen | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: T: 0 or 1, "0" denotes the site is IPv4 site, "1" denotes the site is IPv6 site. Length: denotes the number of NLRI entries in the value field. If T = 0, then, Length Field should be zero when setting in sender and ignore at receiver. Value: denotes the specific the true IPv6 routes in the related site in the form of concatenated IPv6 route entries. 3.4. Label Distribution and Tunnel In these aspects, the mechanism in RFC 2547bis can be inherited totally. The inner label can be distributed by Egress PE and attached to VPN routes when PE distributing VPN routes to MP-BGP Peers, As to the outer label can be distributed by LDP/RSVP-TE if Defeng Li Expires December 2004 [Page 11] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 backbone support MPLS, otherwise other type of tunnel can be utilized, such as GRE, IPsec(tunnel mode). 3.5. Forwarding (1) For communication between IPv4 sites, the forwarding procedure in RFC 2547bis can be inherited, take the situation where MPLS is supported for example, Egress PE distributes the inner labels for different VPN sites when distributing the VPN routes for these sites through MP-BGP, when Ingress PE receives VPN routes, the inner labels are attached. In addition, LDP/RSVP-TE can run between Ingress PE and Egress PE, they can distribute the outer labels between them, and LSP between Ingress PE and Egress PE can be setup, VPN packets are encapsulated with two-layer labels and forwarded to Egress PE following the LSP, and the outer label will be popped at Egress PE or penultimate hop popped, Egress PE then forwards the VPN packets with inner label to the destination site according the inner packets. (2) For communication from IPv4 site to IPv6 site, IPv4 site has learned the private IPv4 subnet prefix for IPv6 site maintained by NAT-PT at the remote PE, so the destination address in the VPN packet can be the private IPv4 address assigned for IPv6 address of the sink host in the remote IPv6 site(this procedure will involve DNS function, which is out of the scope of this docuent), this packet is forwarded to Egress PE following the normal mechanism stated in RFC 2547bis, at Egress PE, the related NAT-PT will translate the packet to IPv6 packet by translating the source IPv4 address to (NAT-PT Prefix:source IPv4 address), and destination address to the true IPv6 address in the IPv6 site( in some cases, the ALG should be deployed at Egress PE to process the address translation in the application layer, however, this aspect will not be discussed in this document). Then the packet is forwarded to CE and then reaches the sink host following the normal IPv6 forwarding. (3) For communication from IPv6 site to IPv4 site, IPv6 site has learned the IPv6 routes in the form of (NAT-PT Prefix:IPv4 routes), the destination address of the packet will be set (NAT-PT Prefix: destination IPv4 address), the packet is forwarded to Ingress PE, NAT-PT at Ingress PE will translate the source IPv6 address to the private IPv4 address NAT-PT assigned for the IPv6 host, and translate the destination address to the "destination IPv4 address" part in IPv6 address of (NAT-PT Prefix:destination IPv4 address) form, and a IPv4 packet will be encapsulated. This packet is forwarded to Egress PE then forwarded to the sink host following the mechanism stated in RFC 2547bis, DNS and ALG may be required in this case, however, it will not be discussed here. (4) For communication between IPv6 sites, as stated in the above sections, If-V6-Site Extended Community attribute is introduced in this mechanism, and the true IPv6 routes in source and destination IPv6 sites are learned across backbone, so the packet in the site can be forwarded according the true IPv6 routes, when the packet reaches Ingress PE, Ingress PE just encapsulates it with two layered label stack and forwarded to Egress PE, then Egress PE forward the packet to sink host following the normal IPv6 forwarding procedure. In this case, maybe IPv6-DNS is required, however, NAT-PT doesn't participate the translation so as to guarantee the integrity of communication between IPv6 sites. Defeng Li Expires December 2004 [Page 12] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 4. Quality of Service [2547bis] is applicable. 5. Security Considerarion This document extended BGP/MPLS VPN for some scenarios, such as that of IPv4 backbone and IPv4/IPv6 hybrid VPN sites and that of IPv4/IPv6 Hybrid Backbone and Hybrid VPN sites. All the security analysis stated in http://www.ietf.org/internet-drafts/draft-ietf-l3vpn- security-framework-01.txt applys to the mechanisms in this document. 6. References [2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-ppvpn- rfc2547bis-01.txt, January 2004, work in progress [2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547 VPNs", draft-ietf-ppvpn-gre-ip-2547-01.txt, February 2004, work in progress [2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of PE-PE IPsec in RFC2547 VPNs", draft-ietf-ppvpn-ipsec-2547-01.txt, February 2004, work in progress [BGP-TUNNEL] De Clercq, J., et al., "Connecting IPv6 Islands across IPv4 clouds with BGP", draft-ietf-ngtrans-bgp-tunnel-04.txt, work in progress [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext-communities-05.txt, work in progress [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for BGP4", June 2000, RFC2858 [IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460. [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", RFC3031 [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", RFC3107 [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", RFC3032 [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP Specification", RFC3036 [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC2893. [RFC3513] Deering, S., and Hinden, R., "IP Version 6 Addressing Architecture", RFC3513. [RFC2766] G. Tsirtsis, P. Srisuresh, " Network Address Translation - Protocol Translation (NAT-PT)", RFC2766. Defeng Li Expires December 2004 [Page 13] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 7. Authors' Addresses Li Defeng D201 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : 77cronux.leed0621@huawei.com Defeng Li Expires December 2004 [Page 14] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 --Boundary_(ID_eEwE2NBGqqXg+DQYxA8s5g)-- From owner-v6ops@ops.ietf.org Thu Jul 8 00:31:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11592 for ; Thu, 8 Jul 2004 00:31:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiQXr-000EiX-Tv for v6ops-data@psg.com; Thu, 08 Jul 2004 04:30:03 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiQXq-000Eh4-5H; Thu, 08 Jul 2004 04:30:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i684Tiq18246; Thu, 8 Jul 2004 07:29:44 +0300 Date: Thu, 8 Jul 2004 07:29:43 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: Iljitsch van Beijnum , Ralph Droms , , Eliot Lear , Multi6 Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) In-Reply-To: <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 7 Jul 2004, Fred Baker wrote: > >A few paragraphs along the lines of "ask one ISP to temporarily accept > >packets with the other's addresses and use that one for outgoing traffic > >or use policy routing to match ISPs to the source addresses in outgoing > >packets, or if these approaches aren't possible, implement a flag-day type > >of transition" would be very helpful, I think. > > In a word, no. [...] A possible compromise here could be putting RFC3704 in as a *normative* reference (btw, some of those other ones might be as well because they're required for understanding), implying that it's a MUST read.. which could be interpreted as not having to summarize or repeats its contents here. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Jul 8 03:55:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04927 for ; Thu, 8 Jul 2004 03:55:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiThq-00087u-Kd for v6ops-data@psg.com; Thu, 08 Jul 2004 07:52:34 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiThn-00087G-S5; Thu, 08 Jul 2004 07:52:32 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Jul 2004 00:58:54 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i687qSgI027660; Thu, 8 Jul 2004 00:52:29 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVE14751; Thu, 8 Jul 2004 00:51:17 -0700 (PDT) Message-Id: <6.1.1.1.2.20040708004104.0593ddb8@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 08 Jul 2004 00:41:47 -0700 To: Pekka Savola From: Fred Baker Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Cc: Iljitsch van Beijnum , Ralph Droms , , Eliot Lear , Multi6 In-Reply-To: References: <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 07:29 AM 07/08/04 +0300, Pekka Savola wrote: >A possible compromise here could be putting RFC3704 in as a *normative* >reference (btw, some of those other ones might be as well because they're >required for understanding), implying that it's a MUST read.. which could >be interpreted as not having to summarize or repeats its contents here. I'm perfectly willing to do that. Will that address the issues? Glancing through, I at the moment have all references as informational. It occurs to me that this is probably not right. Would you suggest the following, or would you also make others normative? There is probably an argument for making all or almost all of the RFCs normative, but my sense is not to take quite that expansive of a view. [Clausewitz] von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, "On War, Chapter VII, 'Friction in War'", June 1989. [I-D.ietf-dhc-dhcpv6-opt-prefix-delegation] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 (work in progress), October 2003. [I-D.ietf-dnsop-ipv6-dns-issues] Durand, A., Ihren, J. and P. Savola, "Operational Considerations and Issues with IPv6 DNS", draft-ietf-dnsop-ipv6-dns-issues-07 (work in progress), May 2004. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996. [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. From owner-v6ops@ops.ietf.org Thu Jul 8 06:03:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10491 for ; Thu, 8 Jul 2004 06:03:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiViJ-000MBl-6u for v6ops-data@psg.com; Thu, 08 Jul 2004 10:01:11 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiViH-000MA8-Mu for v6ops@ops.ietf.org; Thu, 08 Jul 2004 10:01:10 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i68A0cGP079996; Thu, 8 Jul 2004 10:00:38 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i68A0bMj174178; Thu, 8 Jul 2004 12:00:38 +0200 Received: from zurich.ibm.com (sig-9-145-174-72.de.ibm.com [9.145.174.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA59372; Thu, 8 Jul 2004 12:00:35 +0200 Message-ID: <40ED1B39.5050204@zurich.ibm.com> Date: Thu, 08 Jul 2004 12:00:25 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Fred Baker CC: Pekka Savola , Iljitsch van Beijnum , Ralph Droms , v6ops@ops.ietf.org, Eliot Lear , Multi6 Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) References: <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.com> <6.1.1.1.2.20040708004104.0593ddb8@mira-sjc5-b.cisco.com> In-Reply-To: <6.1.1.1.2.20040708004104.0593ddb8@mira-sjc5-b.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I's suggest that at this point in the discussion you can drop the cross-posting to multi6. While you are tweaking, it might be worth adding a note that the eventual multi6 solution(s) may add new issues to the renumbering recipe, or alternatively may simplify it. Brian Fred Baker wrote: > At 07:29 AM 07/08/04 +0300, Pekka Savola wrote: > >> A possible compromise here could be putting RFC3704 in as a >> *normative* reference (btw, some of those other ones might be as well >> because they're required for understanding), implying that it's a MUST >> read.. which could be interpreted as not having to summarize or >> repeats its contents here. > > > I'm perfectly willing to do that. Will that address the issues? > > Glancing through, I at the moment have all references as informational. > It occurs to me that this is probably not right. Would you suggest the > following, or would you also make others normative? There is probably an > argument for making all or almost all of the RFCs normative, but my > sense is not to take quite that expansive of a view. > > > > > > > > > > > > > > > > > > > > > > > include="reference.I-D.ietf-dhc-dhcpv6-opt-prefix-delegation"?> > include="reference.I-D.ietf-dnsop-ipv6-dns-issues"?> > > > [Clausewitz] > von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, > "On War, Chapter VII, 'Friction in War'", June 1989. > > [I-D.ietf-dhc-dhcpv6-opt-prefix-delegation] > Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 (work in > progress), October 2003. > > [I-D.ietf-dnsop-ipv6-dns-issues] > Durand, A., Ihren, J. and P. Savola, "Operational > Considerations and Issues with IPv6 DNS", > draft-ietf-dnsop-ipv6-dns-issues-07 (work in progress), > May 2004. > > [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", > STD 13, RFC 1034, November 1987. > > [RFC1035] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, November 1987. > > [RFC1305] Mills, D., "Network Time Protocol (Version 3) > Specification, Implementation", RFC 1305, March 1992. > > [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, > August 1996. > > [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone > Changes (DNS NOTIFY)", RFC 1996, August 1996. > > [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, > January 1997. > > [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic > Updates in the Domain Name System (DNS UPDATE)", RFC 2136, > April 1997. > > [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 > (IPv6) Specification", RFC 2460, December 1998. > > [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor > Discovery for IP Version 6 (IPv6)", RFC 2461, December > 1998. > > [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address > Autoconfiguration", RFC 2462, December 1998. > > [RFC2535] Eastlake, D., "Domain Name System Security Extensions", > RFC 2535, March 1999. > > [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: > Defeating Denial of Service Attacks which employ IP Source > Address Spoofing", BCP 38, RFC 2827, May 2000. > > [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. > Wellington, "Secret Key Transaction Authentication for DNS > (TSIG)", RFC 2845, May 2000. > > [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( > SIG(0)s)", RFC 2931, September 2000. > > [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic > Update", RFC 3007, November 2000. > > [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address > Allocations to Sites", RFC 3177, September 2001. > > [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and > M. Carney, "Dynamic Host Configuration Protocol for IPv6 > (DHCPv6)", RFC 3315, July 2003. > > [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed > Networks", BCP 84, RFC 3704, March 2004. > > > From owner-v6ops@ops.ietf.org Thu Jul 8 12:20:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06834 for ; Thu, 8 Jul 2004 12:20:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Biba9-0009Xe-MO for v6ops-data@psg.com; Thu, 08 Jul 2004 16:17:09 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Biba7-0009Wu-Uw; Thu, 08 Jul 2004 16:17:07 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2004 09:17:48 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i68GH44N012782; Thu, 8 Jul 2004 09:17:04 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVE39276; Thu, 8 Jul 2004 09:15:53 -0700 (PDT) Message-Id: <6.1.1.1.2.20040708090646.05a5c408@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 08 Jul 2004 09:15:41 -0700 To: Brian E Carpenter From: Fred Baker Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Cc: Pekka Savola , Iljitsch van Beijnum , Ralph Droms , v6ops@ops.ietf.org, Eliot Lear , Multi6 In-Reply-To: <40ED1B39.5050204@zurich.ibm.com> References: <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.com> <6.1.1.1.2.20040708004104.0593ddb8@mira-sjc5-b.cisco.com> <40ED1B39.5050204@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 12:00 PM 07/08/04 +0200, Brian E Carpenter wrote: >While you are tweaking, it might be worth adding a note that the eventual >multi6 solution(s) may add new issues to the renumbering recipe, or >alternatively may simplify it. Actually, I'm not at all sure that they can. The problems with renumbering without a flag day are not in the technology there to assign new addresses and such. They are first and perhaps foremost in the applications and configuration scripts that forego those tools in favor of static or configuration. More subtly, there are issues with the "who knows what when" operational steps that ensure that a one system knows a given address of another system if and only if the other system is using it and the connecting infrastructure in fact connects them. If you have selected a new address but one of the eleven routers between you and I doesn't know how to route to the prefix, when I use your new address I experience a disruption. If an address is being advertised for you, or was advertised yesterday with a TTL that leaves me with an active record today, and you stop using the address, I experience a disruption. I'm talking about making this work not only in theory in a corner of the world, but operationally supporting applications using them on an end to end basis. But as you ask, I will drop the Multi6 copy after this note. From owner-v6ops@ops.ietf.org Thu Jul 8 17:43:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03827 for ; Thu, 8 Jul 2004 17:43:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bigdv-0005Gm-4V for v6ops-data@psg.com; Thu, 08 Jul 2004 21:41:23 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bigdt-0005GC-Ft for v6ops@ops.ietf.org; Thu, 08 Jul 2004 21:41:21 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i68Lew2r027619; Thu, 8 Jul 2004 23:40:58 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.com> References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <6.1.1.1.2.20040707133134.059e6df0@mira-sjc5-b.cisco.com> <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4E409684-D127-11D8-9113-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Pekka Savola , v6ops@ops.ietf.org, Ralph Droms , Eliot Lear From: Iljitsch van Beijnum Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Date: Thu, 8 Jul 2004 23:39:35 +0200 To: Fred Baker X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 8-jul-04, at 0:27, Fred Baker wrote: >> A few paragraphs along the lines of "ask one ISP to temporarily >> accept packets with the other's addresses and use that one for >> outgoing traffic or use policy routing to match ISPs to the source >> addresses in outgoing packets, or if these approaches aren't >> possible, implement a flag-day type of transition" would be very >> helpful, I think. > In a word, no. > There was a serious attempt last fall to turn this document, which is > about "how to renumber a network", into "how to configure ingress > filtering and route traffic within multihomed networks". Apparently my remark that in many instances, switching ISPs means a network effectively becomes multihomed temporarily made you relive some kind of trauma. My apologies for that. I would very much like to focus on the problem at hand, which is renumbering. As I've said before, a good part of all renumbering operations will be because a network switches ISPs. In that case any ingress filtering that is present becomes a big problem, and the draft doesn't provide sufficient guidance in this area, in my opinion. > In the interest of ever getting a chance to actually do anything > useful with "how to renumber a network", Pekka and I put the entire > BCP 38 discussion into a separate document, which is now RFC 3704. > This working group looked at that document, decided it was sufficient > to describe those issues, and published it as an RFC. If it is not > sufficient, fixing RFC 3704 is the task of the day, I disagree. The renumbering draft is the task at hand, and even though it's possible to see these issues in a larger context, but as this document is supposed to provide operational guidance and this is exactly a problem operators will encounter when renumbering. Some input from the rest of the wg would be beneficial here, btw. I don't think Fred and myself are going to reach rough consensus all on our own here. > May I suggest that, by 12 July, you post an updated version of RFC > 3704? Why before july 12th? And you may remember that I've never been a huge fan of RFC 3704, so I doubt I'm the right person for the job. I'm more interested in fixing the problem rather than fixing the description of the problem, anyway. One thing I've thought about in the past is some kind of "open sesame" protocol that allows customers to instruct ISPs to open up ingress filters in an automated way. From owner-v6ops@ops.ietf.org Thu Jul 8 21:04:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19072 for ; Thu, 8 Jul 2004 21:04:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bijmu-0008n5-Vo for v6ops-data@psg.com; Fri, 09 Jul 2004 01:02:52 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bijmu-0008mp-5d for v6ops@ops.ietf.org; Fri, 09 Jul 2004 01:02:52 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Jul 2004 17:50:48 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i690o3gK028092; Thu, 8 Jul 2004 17:50:06 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVE89981; Thu, 8 Jul 2004 17:48:52 -0700 (PDT) Message-Id: <6.1.1.1.2.20040708172514.05f002d8@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 08 Jul 2004 17:25:28 -0700 To: Iljitsch van Beijnum From: Fred Baker Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Cc: Pekka Savola , v6ops@ops.ietf.org, Ralph Droms , Eliot Lear In-Reply-To: <4E409684-D127-11D8-9113-000A95CD987A@muada.com> References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <6.1.1.1.2.20040707133134.059e6df0@mira-sjc5-b.cisco.com> <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.com> <4E409684-D127-11D8-9113-000A95CD987A@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 11:39 PM 07/08/04 +0200, Iljitsch van Beijnum wrote: >>May I suggest that, by 12 July, you post an updated version of RFC 3704? > >Why before july 12th? -00 cutoff. From owner-v6ops@ops.ietf.org Thu Jul 8 22:28:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07295 for ; Thu, 8 Jul 2004 22:28:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bil5u-000JNJ-Kd for v6ops-data@psg.com; Fri, 09 Jul 2004 02:26:34 +0000 Received: from [61.144.161.40] (helo=huawei.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bil5H-000J9y-37 for v6ops@ops.ietf.org; Fri, 09 Jul 2004 02:26:30 +0000 Received: from l04955 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I0K00KTWBZXTR@mta0.huawei.com> for v6ops@ops.ietf.org; Fri, 09 Jul 2004 10:23:59 +0800 (CST) Date: Fri, 09 Jul 2004 10:26:09 +0800 From: lidefeng <77cronux.leed0621@huawei.com> Subject: A draft about VPN in IPv4/IPv6 Hybrid Network(new version) To: internet-drafts@ietf.org Cc: l3vpn@ietf.org, v6ops@ops.ietf.org Message-id: <004b01c4655c$18d62320$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: multipart/mixed; boundary="Boundary_(ID_9xTF7pTejPbJ32cMyy+8fw)" X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-scores: Clean:50.78753 C:21 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:4 R:4 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_9xTF7pTejPbJ32cMyy+8fw) Content-type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7BIT Dear all, Attached is a draft about VPN in IPv4/IPv6 Hybrid Network, I hope this draft can be processed in the v6ops WG as soon as possible, discussions and comments are appreciated. BTW, I hope to discuss it at 60th IETF meeting, I would like to have a chance to make presentation for it, Could you please arrange a time slot for me? I think 10min slot will do. Thanks in advance. Defeng Li Huawei Technologies --Boundary_(ID_9xTF7pTejPbJ32cMyy+8fw) Content-type: text/plain; name=draft-defeng-v6ops-ipv4-ipv6-hybrid-vpn-01.txt Content-disposition: attachment; filename=draft-defeng-v6ops-ipv4-ipv6-hybrid-vpn-01.txt Content-Transfer-Encoding: 7BIT INTERNET DRAFT Defeng Li Huawei Technologies Expires December, 2004 June 2004 BGP-MPLS VPN extension for IPv4/IPv6 Hybrid Network Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html List of authors/editors Defeng Li Huawei Technologies Abstract This document describes some methods which may be used by Service Providers to provide Virtual Private Networks for some scenarios where the Service Provider's network or Customer's network is comprised of part of IPv4 network and part of IPv6 network.These situations can't be avoided during the process of IPv4 transition to IPv6, e.g. IPv6 backbone network for IPv4-IPv6 hybrid VPN sites,or IPv4 backbone network for IPv4-IPv6 hybrid VPN sites,or IPv4-IPv6 hybrid backbone network for IPv4-IPv6 hybrid VPN sites.This proposal continue to use the concepts described in the Internet draft "BGP/MPLS VPN"[2547bis],such as RD,VRF,Route Target and some mechanisms. In BGP/MPLS VPN, MPLS is used to forward packets over Defeng Li Expires December 2004 [Page 1] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 the backbone, and "Multiprotocol BGP" is used for distributing VPN routes over the service provider backbone. This document makes the reference to the current RFC or Internet Draft as to the IPv4 VPN address family and IPv6 VPN address family,In some hybrid scenarios,IPv4/IPv6 dual VPN address family should be supported in backbone, accordingly, some VPN sites should support IPv4/IPv6 dual route table. 1. Introduction This document assumes that the reader is familiar with [2547bis]. Unless explicitly documented herein, [2547bis] applies. This document adopts the definitions, acronyms and mechanisms described in [2547bis]. Unless otherwise stated, the mechanisms of [2547bis] apply and will not be re-described here. A VPN is said to be an IPv6 hybrid VPN, when one of the following conditions is meeted: (a) Some sites of this VPN is IPv6 capable and is natively connected over an interface or sub-interface to the SP backbone via a Provider Edge device (PE). (b) Backbone network for VPN consists of IPv6 capable network and IPv4 capable network. A site may be both IPv4-capable and IPv6-capable. The logical interface on which packets arrive at the PE may determine the version, or alternatively a per-packet header lookup on the same interface may determine the version. In this document, for those sites having VPN relationship with other IPv4 sites and IPv6 sites in the same VPN, and those sites connected to the different IP version part of backbone (e.g. IPv4 sites connected to IPv6 part of backbone or IPv6 sites connected to IPv4 part of backbone),CE MUST support both IPv4 and IPv6. When PE connects to both IPv4 sites and IPv6 sites(maybe these sites belong to different VPN), or PE connects to CE which must be dual-stacked according to the rules above mentioned, then PE should be dual-stacked too. The PE being dual stack has full IPv4 capabilities, must maintain IPv6 VRFs for its IPv6 sites and must be able to encapsulate IPv6 datagrams in MPLS frames to be sent into the MPLS core network. BGP and its extensions are used to cause routes from IPv4 or IPv6 VPN sites to be distributed over the backbone to each other PE router connected to a site of the same IPv6 hybrid VPN. As it is done for IPv4 VPNs [2547bis], we allow each IPv6 hybrid VPN to have IPv4/IPv6 hybrid address space, i.e. for a VPN with both IPv4 VPN sites and IPv6 VPN sites, both VPN-IPv4 and VPN-IPv6 address family are needed, VPN-IPv4 address family refers to [2547bis], Defeng Li Expires December 2004 [Page 2] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 VPN-IPv6 address family is a 24-byte quantity, composed of an 8-byte "Route Distinguisher" (RD) and a 16-byte IPv6 address. MP-BGP allows BGP to carry routes from multiple "address families", so IPv4/IPv6 hybrid address space enables the VPN routes of IPv4 sites and IPv6 sites of the same VPN to be distributed across the backbone. This document first addresses BGP/MPLS VPN mechanism under the situation where VPN sites consist of IPv4 sites and IPv6 sites, and the backbone network consists of one or more IPv4 autonomous system and at least an IPv6 autonomous system, then propose some mechanism for the simple situations. 2. Hybrid Backbone and Hybrid VPN sites In Hybrid Backbone and Hybrid sites situation, VPN backbone network consists of one or more IPv4 autonomous system and at least an IPv6 autonomous system, and VPN sites consist of IPv4 sites and IPv6 sites. Note: This document proposes two methods to address this hybrid VPN scenario, and are detailed in section 2.1 and section 2.2 respectively. 2.1. Method 1 In this method, PEs and ASBR in every AS establish MP-IBGP to distribute the VPN routes between the sites belong to the same AS, and ASBRs of the adjacency AS establish MP-EBGP to distribute VPN routes between the sites belong to the different AS.For the conveniency of discussion, we first consider the situation where backbone network consists only two autonomous system(from Section 2.1.1. to Section 2.1.5.), one is IPv4 AS(AS1) and the other is IPv6 AS2, they connected to each other through some ASBRs, for simplicity, considering the situation where only one ASBR for each AS, ASBR1 for AS1,ASBR2 for AS2, and in some of VPNs accessed to the backbone, some sites are IPv6 sites, others are IPv4 sites. In the following sections, several aspects such as address family, routing distribution, label assignment, data forwarding, VPN topology implementation. In Section 2.1.6., we will discuss how to extend the mechanism to the situation where more than two AS(at least one of them is IPv6 AS). 2.1.1. Address Family In this method, we only consider Unicast communication between VPN sites, and Unicast address(IPv4 or IPv6) should be used. Considering there are still some IPv4 Sites in the VPN and the scarcity of IPv4 address, private IPv4 addresses(defined in RFC 1918) are allowed to be used IN vpn sites, and if two VPNs have no sites in common, they may have overlapping address spaces, this aspect is the same as [RFC 2547bis]. For IPv6 sites, the global unicast address should be used, for the huge IPv6 address space, all the addresses are public addresses. Defeng Li Expires December 2004 [Page 3] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 Communications between IPv4 sites use IPv4 address, accordingly, AFI field in MP-BGP can be valued as 1, which is assigned for IPv4 in RFC 1700. Communications between one IPv4 site and one IPv6 site or communications between IPv6 sites use IPv6 address, the IPv4 addresses A.B.C.D/MASK in IPv4 sites can be mapped to IPv6 addresses in the form of 0::A:B:C:D/(96+MASK), accordingly, AFI field in MP-BGP can be valued as 2, which is assigned for IPv6 in RFC 1700. SAFI field in MP-BGP can be valued as 128 to denote the address family for VPN-IPv4 or VPN-IPv6 address. So there will be two VPN address family in this mechanism, MP-BGP will distribute VPN-IPv4 routes and VPN-IPv6 routes at the same time, PEs and ASBRs in this mechanism should support IPv4/IPv6 dual-stack and maintain both VPN-IPv4 routes and VPN-IPv6 routes.If some IPv4 sites have only communications with other IPv4 sites, CEs in these sites can only support IPv4 protocol and maintain IPv4 VPN routes, otherwise CE should support IPv4/IPv6 dual-stack and maintain both IPv4 VPN routes and IPv6 VPN routes of the same VPN. As stated above, private IPv4 addresses is used in this method, for the same reason as stated in RFC 2547bis, RD continues to serve the purpose of forming the VPN-IPv4 or VPN-IPv6 address, i.e. A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte "Route Distinguisher (RD)" and ending with a 4-byte IPv4 address, and AFI for this address family is 1. A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte "Route Distinguisher (RD)" and ending with a 16-byte IPv6 address(In the case of IPv4 site which has communication with IPv6 site, IPv4 addresses is mapped to IPv6 addresses before forming VPN-IPv6 addresses), and AFI for this address family is 2. 2.1.2. VPN routes distribution VPN sites distribute their routes to PE through routing protocol between CE in the VPN site and PE connected to CE, For the hybrid characteristic of VPN routes, i.e. CE should maintain both IPv4 routes of other IPv4 sites and IPv6 routes of other IPv6 sites, this document proposes to run BGP4+ or IS-ISv6 protocol between CE and PE. It is noted that these two routing protocols can carry both IPv4 routes and IPv6 routes at the same time. When BGP4+ is run between CE and PE, the private AS number should be used in VPN sites. Of course, if OSPFv3 run between CE and PE, IPv4 routes can also be distributed between them through mapping IPv4 routes to IPv6 routes, i.e. when PE learns IPv4 route a.b.c.d/n(where a.b.c.d is subnet address, and n is mask) across backbone, it maps the route to IPv6 route in the form of 0::a:b:c:d/(96+n) and distributes to CE, CE then revert it to a.b.c.d/n and maintain it in IPv4 routing table. After PE learns VPN routes from CE, PE should distribute the VPN routes to the related sites in the same VPN through backbone network before these sites can visit each other, and backbone is composed of IPv4 AS and IPv6 AS, in this section, we only consider the case in which backbone is composed of one IPv4 AS(AS1) and one IPv6 AS(AS2). The distribution process of VPN routes across backbone is as follows: (1) Every two of PEs and ASBR1 in AS1 setting up MP-IBGP based on IPv4; Defeng Li Expires December 2004 [Page 4] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 (2) Every two of PEs and ASBR2 in AS2 setting up MP-IBGP based on IPv6; (3) ASBR1 and ASBR2 setting up MP-EBGP based on IPv6; (4) VPN routes from the sites connected to AS1 can be distributed to each other through those MP-IBGP relationships set up in (1), IPv4 routes and IPv6 routes can be piggybacked on the same MP-IBGP; (5) VPN routes from the sites connected to AS2 can be distributed to each other through those MP-IBGP relationships set up in (2), IPv4 routes and IPv6 routes can be piggybacked on the same MP-IBGP; (6) VPN routes need to be distributed to sites connected to neighboring AS can be achieved by MP-EBGP between ASBR1 and ASBR2, according to BGP protocol, routes learned from EBGP PEER should be distributed to IBGP PEER, IPv4 routes and IPv6 routes can be piggybacked on the same MP-EBGP. After the above steps, all the VPN routes can be distributed across backbone network, then PEs maintain the related routes. The difference from RFC 2547bis is that PEs should maintain both IPv4 routes and IPv6 routes in the respective VRFs, IPv4 routes and IPv6 routes can be differentiated by the AFI of the routes received, if AFI is 1, routes will be maintained in IPv4 part of VRF, if AFI is 2, then routes will be maintained in IPv6 part of VRF. As to the decision whether to accept and advertise the routes received from MP-BGP PEER, PE follows the same rule as stated in RFC 2547bis, where Route Target attribute is used, and this attribute is related to the topology of VPN, it will be detailed in section 2.1.5. Following this mechanism, all the VPN routes can be correctly distributed all over the VPN network, For some sites need to visit IPv4 sites and IPv6 sites, IPv4 routing table in CE can be matched when the destination is IPv4 sites, IPv6 routing table in CE can be matched when the destination is IPv6 sites. If some sites have no relationship with other IPv6 sites, then it is not necessary for these sites to run IPv6 routing protocol with PEs, Even it is enough for these sites to support only IPv4, i.e. IPv4/IPv6 dual-stack is not a must. 2.1.3. Label Distribution Sites belongs to different VPN can connect to the same PE, PE differentiates them by assigning different labels for the sites, this label is called inner label, which will be attached to the VPN routes when PE distributing the VPN routes to MP-BGP PEERs. If backbone network supports MPLS and LDP/RSVP-TE runs in backbone, LDP/RSVP-TE will setup LSPs between PEs and ASBR1 in AS1 and PEs and ASBR2 in AS2 respectively and the label related to these LSPs is called outer label, i.e. the packet received from CE will be label-stacked with two label before IP header. If backbone network doesn't support MPLS, other tunnelling technology can be utilized to setup the tunnel between PE and ASBR,such as GRE, IPsec, and so on. And ASBR1 will establish MP-EBGP with ASBR2, and MP-EBGP will distribute the labels Defeng Li Expires December 2004 [Page 5] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 between ASBR1 and ASBR2(refer the mechanism to RFC 3107), these two labels will form a tunnel segment to "stick" the tunnel segments in AS1 and AS2. 2.1.4. Forwarding Data forwarding between VPN sites across backbone consists of following steps: (1) IP Forwarding from source site to Ingress PE; (2) Label or tunneling Forwarding from Ingress PE to Egress PE; (3) IP forwarding from Egress PE to destination site. Where, step (1) follows normal IP forwarding process. As stated in section 2.2.3, if one site has VPN relationship with other IPv4 sites and IPv6 sites simultaniously, CE in this site should maintain both IPv4 route table and IPv6 route table respectively. when the destination is IPv4 site, the IPv4 route table can be queried, otherwise IPv6 route table will be matched. In step (2), ingress PE pushes the inner label to the packet, if backbone supports MPLS, pushes the outer label distributed in the Ingress PE's AS, or encapsulates the tunnel header(when MPLS isn't supported) and forwards packet to ASBR in Ingress PE's AS, where pops the outer label(or penultimate hop poped the outer label) or decapsulates the tunnel header, and pushes the label assigned by MP-EBGP between ASBRs, forwards the packet to the ASBR in the neighboring AS, then VPN packet is forwarded to Egress PE in the neighboring AS following the same rules as in the previous AS. In step (3),Egress PE receives the packet with inner label(outer label has been popped or the tunnel header has been decapsulated) and distinguishes the destination site by the inner label, then pops the inner label, forwards packet to CE, at last the packet is forwarded to the destination following normal IP forwarding rules. mechanism 2.1.5. VPN topology VPN sites can form different kinds of relationships, such as full mesh, partial mesh, Hub-Spoke, which is called VPN topology. To achieve this, the mechanism of utilizing Route Target as stated in RFC 2547bis can still be used. VPN topology is formed through the routes in VPN sites, if one site have routes to other sites, then it has VPN relationships with those sites, all of VPN relationships among VPN sites form VPN topology. PE can decide whether to accept VPN routes received from other PE carried in MP-BGP UPDATE messages through matching Route Target attributes. When Egress PE distributes VPN routes, the configured Export Route Targets will be attached, and Ingress PE is also configured with Import Route Targets, so Ingress PE can compare the local Import Route Target with the remote Export Route Target attached to the received routes from MP-BGP PEERs, then only those routes with route target attributes matched can be accepted and maintained in VRF by Ingress PE, others will be discarded, After that Ingress PE advertise the accepted VPN routes to the directly connected CE. Defeng Li Expires December 2004 [Page 6] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 2.1.6. IPv4/IPv6 Multi-AS Hybrid Backbone In Section 2.1.1. through to Section 2.1.5. , the case where only two ASes(one is IPv4 AS, the other is IPv6 AS) is addressed in detail. In the case of IPv4/IPv6 multi-AS hybrid backbone, the mechanisms in Address Family, VPN routes distribution, Label Distribution, Forwarding, VPN topology are analogic to the case of two ASes, MP-IBGPs are setup in all the ASes between PEs and ASBR, and MP-EBGPs are established between directly connected ASBRs in adjacent ASes, and this MP-EBGPs will distribute the labels for these ASBRs. VPN routes for IPv4 sites and IPv6 sites can be "relayed" among these MP-IBGP or MP-EBGP. The tunnel used to forward packets between Ingress PE and Egress PE can be "sticked" together from tunnel segments of respective AS and tunnel segments between ASBRs of adjacent ASes. 2.2. Method 2 Similar to Method 1, we first consider the scenario where backbone network consists only two autonomous system(from Section 2.2.1. to Section 2.2.5.), one is IPv4 AS(AS1) and the other is IPv6 AS2, they connected to each other through some ASBRs, for simplicity, considering the case where only one ASBR for each AS, ASBR1 for AS1, ASBR2 for AS2, and in some of VPNs accessed to the backbone, some sites are IPv6 sites, others are IPv4 sites. In this method, PEs and ASBRs in IPv6 AS establish IPv6-based full-mesh MP-IBGP(or MP-BGP Route Reflector) to distribute VPN routes of sites belong to IPv6 AS, and every two PEs in IPv4 AS establish IPv4-based MP-IBGP to distribute VPN routes of sites belong to IPv4 AS, and every PE in IPv4 AS doesn't establish MP-IBGP with ASBR in its own AS as in Method 1, but establishes IPv4-based multi-hop MP-EBGP with ASBR in the IPv6 AS, so the VPN routes across IPv4 AS and IPv6 AS will be distributed through these multi-hop MP-EBGP, We call IPv6 AS as Primary AS(PAS), and IPv4 AS as Dependent AS(DAS). 2.2.1. Address Family Address scheme in Method 2 is the same as that in Method 1, refer to section 2.1.1. 2.2.2. VPN routes distribution VPN sites distribute their routes to PE through routing protocol between CE in the VPN site and PE connected to CE, For the hybrid characteristic of VPN routes, i.e. CE should maintain both IPv4 routes of other IPv4 sites and IPv6 routes of other IPv6 sites, this document proposes to run BGP4+ or IS-ISv6 protocol between CE and PE. It is noted that these two routing protocols can carry both IPv4 routes and IPv6 routes at the same time. When BGP4+ is run between CE and PE, the private AS number should be used in VPN sites. Of Defeng Li Expires December 2004 [Page 7] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 course, if OSPFv3 run between CE and PE, IPv4 routes can also be distributed between them through mapping IPv4 routes to IPv6 routes, i.e. when PE learns IPv4 route a.b.c.d/n(where a.b.c.d is subnet address, and n is mask) across backbone, it maps the route to IPv6 route in the form of 0::a:b:c:d/(96+n) and distributes to CE, CE then revert it to a.b.c.d/n and maintain it in IPv4 routing table. After PE learns VPN routes from CE, PE should distribute the VPN routes to the related sites in the same VPN through backbone network before these sites can visit each other, and backbone is composed of IPv4 AS and IPv6 AS, in this section, we only consider the case in which backbone is composed of one IPv4 AS(AS1) and one IPv6 AS(AS2). The distribution process of VPN routes across backbone is as follows: (1) Every two of PEs in DAS setting up MP-IBGP based on IPv4; (2) Every two of PEs and ASBR2 in PAS setting up MP-IBGP based on IPv6; (3) Every PE and ASBR2 setting up multi-hop MP-EBGP based on IPv4; (4) VPN routes from the sites connected to DAS can be distributed to each other through those MP-IBGP relationships set up in (1), IPv4 routes and IPv6 routes can be piggybacked on the same MP-IBGP; (5) VPN routes from the sites connected to PAS can be distributed to each other through those MP-IBGP relationships set up in (2), IPv4 routes and IPv6 routes can be piggybacked on the same MP-IBGP; (6) VPN routes need to be distributed to sites connected to neighboring AS can be achieved by multi-hop MP-EBGP between PEs in DAS and ASBR2 in PAS,according to BGP protocol, routes learned from EBGP PEER should be distributed to IBGP PEER, IPv4 routes and IPv6 routes can be piggybacked on the same MP-EBGP. After the above steps, all the VPN routes can be distributed across backbone network, then PEs maintain the related routes. The difference from RFC 2547bis is that PEs should maintain both IPv4 routes and IPv6 routes in the respective VRFs, IPv4 routes and IPv6 routes can be differentiated by the AFI of the routes received, if AFI is 1, routes will be maintained in IPv4 part of VRF, if AFI is 2, then routes will be maintained in IPv6 part of VRF. As to the decision whether to accept and advertise the routes received from MP-BGP PEER, PE follows the same rule as stated in RFC 2547bis, where Route Target attribute is used, and this attribute is related to the topology of VPN, it will be detailed in section 2.2.6. Following the above mechanism, all the VPN routes can be correctly distributed all over the VPN network, For some sites need to visit IPv4 sites and IPv6 sites, IPv4 routing table in CE can be matched when the destination is IPv4 sites, IPv6 routing table in CE can be matched when the destination is IPv6 sites. If some sites have no relationship with other IPv6 sites, then it is not necessary for these sites to run IPv6 routing protocol with PEs, Even it is enough for these sites to support only IPv4, i.e. IPv4/IPv6 dual-stack is not a must. Defeng Li Expires December 2004 [Page 8] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 2.2.3. Label Distribution Egress PE assigns the different labels for different sites, which may be related to different interfaces or sub-interfaces. These labels are attached to VPN routes of the sites when PEs distribute these routes across backbone, these labels are inner labels in label stack during encapsulation before forwarding VPN packets across backbone. To guarantee the isolation of VPN service in backbone, VPN packets are forwarded in tunnels between Ingress PE and Egress PE, if some AS in backbone supports MPLS, the tunnel can be LSP, the labels form the LSP are distributed by LDP/RSVP-TE, and these labels are outer labels in label stack, if MPLS is not supported in some AS, then other types of tunnel, such as IPsec(tunnel mode) or GRE tunnel can be used. ASBR in DAS and ASBR in PAS can distribute labels for each other by MP-EBGP between them, these labels will be encapsulated as outer labels between these two ASBRs. 2.2.4. Segmented Tunnel In this method, The tunnel between Ingress PE and Egress PE is composed of segments of those from PE to ASBR in their respective ASes and those between ASBRs. The segments in the respective ASes can be LSP formed by outer labels distributed LDP run in ASes, or other type of IP tunnel, such as GRE tunnel or IPsec in tunnel mode. Segment between ASes is LSP of label distributed by MP-EBGP between ASBRs. 2.2.5. Forwarding VPN packets forwarding in this method is the same as that in Methos 1, which is addressed in detail in section 2.1.4. 2.2.6. VPN topology This aspect is the same as that in Method 1, which is addressed in section 2.1.5. 2.2.7. Hierarchical IPv4/IPv6 Multi-AS Hybrid Backbone In sections 2.2.1. through to 2.2.6., the case where VPN backbone is composed of one IPv4 AS(DAS) and one IPv6 AS(PAS) is addressed. In some cases, VPN backbone is composed of three or more ASes, and at least one of them is IPv6 AS, then the IPv6 AS with largest number of PEs than other IPv6 AS is looked upon as PAS, other IPv6 AS and IPv4 AS are looked upon as DAS, in the case of three ASes, the topology can be DAS-PAS-DAS, or DAS-DAS-PAS, it can be looked upon as a new DAS was concatenated to the "DAS-PAS" topology as addressed in section 2.2.1 by the rule that PEs in the new DAS establish MP-IBGP to distribute the VPN routes of sites connected to PEs belong to this new DAS, and PEs establish multi-hop MP-EBGP with ASBR in the adjacent AS of this new DAS, and the ASBR involved should establish multi-hop MP-EBGP with the ASBR in its adjacent AS, until this MP-EBGP relationship reaches the ASBR in PAS. So the MP-EBGP is Defeng Li Expires December 2004 [Page 9] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 hierarchical multi-hop MP-EBGP, VPN routes of sites across AS can be distributed by this hierarchical multi-hop MP-EBGP. This architecture is called hierarchy of DAS and PAS. Ths case of IPv4/IPv6 Multi-AS Hybrid Backbone can be addressed by this architecture. 3. IPv4 backbone and IPv4/IPv6 hybrid VPN sites In the scenario where VPN backbone is IPv4 network of one or more AS, and some VPN sites is IPv4 enable, other VPN sites is IPv6 enable, and these VPN sites would like to establish VPN service. In this case, the goal can be achieved by assigning the private IPv4 addresses for these IPv6 sites at PE device, and then run private IPv4 address NAT-PT at the related PE device, an private IPv4 address pool can be maintained at PE for every IPv6 VPN site connected. The address pool is denoted in a private IPv4 subnet prefix, and this subnet prefix can't be duplicated in the VPN this subnet prefix belongs to, and PE assigns different private IPv4 subnet prefix for different IPv6 sites. NAT-PT address pool assigns every private IPv4 address for every IPv6 hosts in IPv6 sites dynamically or statically, so as to every IPv6 host can get unique private IPv4 address. To be compatible with other VPN routes, these private IPv4 subnet prefix are treated as VPN routes of the corresponding IPv6 sites, and will be formed to IPv4-VPN routes by prefixing with RD, these IPv4-VPN routes can be distributed across backbone by MP-BGP in RFC 2858, To identify whether a VPN site is an IPv6 site, we can extend MP-BGP protocol by adding an Extended Community attribute: If-V6-Site, this attribute can be attached to VPN routes when distributing IPv4-VPN among PEs with MP-BGP, for VPN routes of IPv6 sites, both the mapped IPv4 routes(private IPv4 subnet prefix maintained by NAT-PT) at PE device and the true IPv6 routes of the IPv6 sites should be distributed to the MP-BGP Peer, the true IPv6 routes can be attached to UPDATE message in MP-BGP as the "value" field of If-V6-Site extended community attribute. The MP-BGP Peers which receive these UPDATE message can decide whether to accept the IPv4-VPN routes by matching the Route Target attributes as stated in RFC 2547bis, then decide whether to accept the true IPv6 routes by identifying if the IPv6 sites of the same VPN is conneted, if MP-BGP Peer connects IPv6 sites of the same VPN, the true IPv6 routes will be accepted too, otherwise the true IPv6 routes will be discarded. By this mechanism, a IPv6 site can visit other IPv6 sites with these true IPv6 routes directly, and IPv6 packets can be directly encapsulated with MPLS label-stack or GRE tunnel header and forwarded across VPN backbone, so that two-way NAT-PT translation at Ingress PE and Egress can be avoided,which maybe introduce the missing information during NAT-PT. In this way, the integrity of communication between IPv6 sites in the hybrid VPN can be achieved. As to communication between IPv4 site and IPv6 site, NAT-PT translation at PE where IPv6 site is connected should be performed. Of course, communication among IPv4 sites follows the same rule detailed in RFC 2547bis. 3.1. Address Family and Route Distribution Defeng Li Expires December 2004 [Page 10] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 We only consider Unicast communication between VPN sites, and Unicast address(IPv4 or IPv6) should be used. Considering there are still some IPv4 Sites in the VPN and the scarcity of IPv4 address, private IPv4 addresses(defined in RFC 1918) are allowed to be used IN vpn sites, and if two VPNs have no sites in common, they may have overlapping address spaces, this aspect is the same as [RFC 2547bis]. For IPv6 sites, the global unicast address should be used, for the huge IPv6 address space, all the addresses are public addresses. Communications between IPv4 sites or between one IPv4 site and one IPv6 site use IPv4 address, the address for IPv6 site can be the private address assigned by NAT-PT, communications between IPv6 sites use IPv6 address. As the true IPv6 routes for the IPv6 sites and IPv4 routes(including the subnet prefix for IPv6 sites maintained by NAT-PT at PE) are both distributed by IPv4-based MP-BGP across backbone, AFI field in MP-BGP can be valued as 1, which is assigned for IPv4 in RFC 1700. SAFI field in MP-BGP can be valued as 128 to denote the address family for VPN-IPv4 address. PEs connect IPv6 sites should run NAT-PT, these PEs should be dual-stacked, and CEs in those sites having VPN relationships with both IPv4 sites and IPv6 sites should be dual-stacked too, and CEs maintain both IPv4 routes and IPv6 routes for these sites. If some sites have only communications with other sites of the same IP version, such as IPv4 to IPv4, or IPv6 or IPv6, CEs in these sites can only support one IP version protocol and maintain only one IP version routes, in this case, CEs can select only part of the same IP version as the sites in VPN routes when CEs learn VPN routes from PEs. As stated above, private IPv4 addresses is used in this method, for the same reason as stated in RFC 2547bis, RD continues to serve the purpose of forming the VPN-IPv4, i.e. A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte "Route Distinguisher (RD)" and ending with a 4-byte IPv4 address. VRF can also used to maintain VPN-IPv4 routes(including the private IPv4 subnet prefix for IPv6 site at PE maintained by NAT-PT) as stated in RFC 2547bis, as to the true IPv6 routes received as If-V6-Site attribute value in UPDATE message, they can be maintained seperately from VRF, normally, they can be globally unique. Routing protocol runs between PE and CE to distribute VPN routes, Considering the requirement of distributing both IPv4 routes (including Private IPv4 subnet prefix for IPv6 sites at PE maintained by NAT-PT) and true IPv6 routes for IPv6 sites, BGP4+ and IS-ISv6 protocol which can piggybacking IPv4 and IPv6 routes simultaniously are suggested. If local site is IPv4 site, CE distributes aggregated IPv4 routes in the local site to PE, and PE distributes to CE the VPN routes of remote sites of the same VPN, if the remote site is IPv6 site, only the private IPv4 subnet prefix for that IPv6 site maintained by NAT-PT at the remote PE will be distributed to the local IPv4 site, and ignore If-V6-Site attribute attached. Defeng Li Expires December 2004 [Page 11] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 If local site is IPv6 site, CE distributes aggregated IPv4 routes in the local site to PE, and PE distributes to CE the VPN routes of remote sites of the same VPN, if the remote site is IPv6 site, the VPN routes will include the true IPv6 routes for the remote site, and CE can only learn this part and discard the related private IPv4 subnet prefix for the remote IPv6 site, if the remote site is IPv4 site, the VPN routes for the remote IPv4 site(a.b.c.d/mask) can be translated to the form of (NAT-PT Prefix:a:b:c:d:/(96+mask)) and distribute to CE in the local IPv6 site. Note: NAT-PT Prefix in a prefix assigned by IANA. After learning VPN routes from CEs, PEs will distribute VPN routes through IPv4-based MP-BGP across backbone, and the true IPv6 routes can be piggybacked on IPv4-based MP-BGP in If-V6-Site attributes with the mechanism stated above. 3.2. Judgement of IPv4/IPv6 sites Whether the sites is IPv6 or not can be identified by the address of the interface(subinterface) between CE and PE, then PE can set the related fields in If-V6-Site Extended Community attribute when distributing the VPN routes across backbone, and whether the remote site is IPv6 can be identified by If-V6-Site attached to VPN routes received. 3.3. If-V6-Site Attribute If-V6-Site is an Extended Community attribute for MP-BGP defined in this document, it is a triple of (Type,Length,Value), the structure can be denoted temporarily as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | IPv6 Route1 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Routen | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: T: 0 or 1, "0" denotes the site is IPv4 site, "1" denotes the site is IPv6 site. Length: denotes the number of NLRI entries in the value field. If T = 0, then, Length Field should be zero when setting in sender and ignore at receiver. Value: denotes the specific the true IPv6 routes in the related site in the form of concatenated IPv6 route entries. 3.4. Label Distribution and Tunnel Defeng Li Expires December 2004 [Page 12] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 In these aspects, the mechanism in RFC 2547bis can be inherited totally. The inner label can be distributed by Egress PE and attached to VPN routes when PE distributing VPN routes to MP-BGP Peers, As to the outer label can be distributed by LDP/RSVP-TE if backbone support MPLS, otherwise other type of tunnel can be utilized, such as GRE, IPsec(tunnel mode). 3.5. Forwarding (1) For communication between IPv4 sites, the forwarding procedure in RFC 2547bis can be inherited, take the situation where MPLS is supported for example, Egress PE distributes the inner labels for different VPN sites when distributing the VPN routes for these sites through MP-BGP, when Ingress PE receives VPN routes, the inner labels are attached. In addition, LDP/RSVP-TE can run between Ingress PE and Egress PE, they can distribute the outer labels between them, and LSP between Ingress PE and Egress PE can be setup, VPN packets are encapsulated with two-layer labels and forwarded to Egress PE following the LSP, and the outer label will be popped at Egress PE or penultimate hop popped, Egress PE then forwards the VPN packets with inner label to the destination site according the inner packets. (2) For communication from IPv4 site to IPv6 site, IPv4 site has learned the private IPv4 subnet prefix for IPv6 site maintained by NAT-PT at the remote PE, so the destination address in the VPN packet can be the private IPv4 address assigned for IPv6 address of the sink host in the remote IPv6 site(this procedure will involve DNS function, which is out of the scope of this docuent), this packet is forwarded to Egress PE following the normal mechanism stated in RFC 2547bis, at Egress PE, the related NAT-PT will translate the packet to IPv6 packet by translating the source IPv4 address to (NAT-PT Prefix:source IPv4 address), and destination address to the true IPv6 address in the IPv6 site( in some cases, the ALG should be deployed at Egress PE to process the address translation in the application layer, however, this aspect will not be discussed in this document). Then the packet is forwarded to CE and then reaches the sink host following the normal IPv6 forwarding. (3) For communication from IPv6 site to IPv4 site, IPv6 site has learned the IPv6 routes in the form of (NAT-PT Prefix:IPv4 routes), the destination address of the packet will be set (NAT-PT Prefix: destination IPv4 address), the packet is forwarded to Ingress PE, NAT-PT at Ingress PE will translate the source IPv6 address to the private IPv4 address NAT-PT assigned for the IPv6 host, and translate the destination address to the "destination IPv4 address" part in IPv6 address of (NAT-PT Prefix:destination IPv4 address) form, and a IPv4 packet will be encapsulated. This packet is forwarded to Egress PE then forwarded to the sink host following the mechanism stated in RFC 2547bis, DNS and ALG may be required in this case, however, it will not be discussed here. (4) For communication between IPv6 sites, as stated in the above sections, If-V6-Site Extended Community attribute is introduced in this mechanism, and the true IPv6 routes in source and destination Defeng Li Expires December 2004 [Page 13] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 IPv6 sites are learned across backbone, so the packet in the site can be forwarded according the true IPv6 routes, when the packet reaches Ingress PE, Ingress PE just encapsulates it with two layered label stack and forwarded to Egress PE, then Egress PE forward the packet to sink host following the normal IPv6 forwarding procedure. In this case, maybe IPv6-DNS is required, however, NAT-PT doesn't participate the translation so as to guarantee the integrity of communication between IPv6 sites. 4. Quality of Service [2547bis] is applicable. 5. Security Considerarion This document extended BGP/MPLS VPN for some scenarios, such as that of IPv4 backbone and IPv4/IPv6 hybrid VPN sites and that of IPv4/IPv6 Hybrid Backbone and Hybrid VPN sites. All the security analysis stated in http://www.ietf.org/internet-drafts/draft-ietf-l3vpn- security-framework-01.txt applys to the mechanisms in this document. 6. IANA Consideration This document has no actions for IANA. 7. Normative References [2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-ppvpn- rfc2547bis-01.txt, January 2004, work in progress [2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547 VPNs", draft-ietf-ppvpn-gre-ip-2547-01.txt, February 2004, work in progress [2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of PE-PE IPsec in RFC2547 VPNs", draft-ietf-ppvpn-ipsec-2547-01.txt, February 2004, work in progress [BGP-TUNNEL] De Clercq, J., et al., "Connecting IPv6 Islands across IPv4 clouds with BGP", draft-ietf-ngtrans-bgp-tunnel-04.txt, work in progress [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext-communities-05.txt, work in progress [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for BGP4", June 2000, RFC2858 [IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460. [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", RFC3031 Defeng Li Expires December 2004 [Page 14] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", RFC3107 [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", RFC3032 [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP Specification", RFC3036 [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC2893. [RFC3513] Deering, S., and Hinden, R., "IP Version 6 Addressing Architecture", RFC3513. [RFC2766] G. Tsirtsis, P. Srisuresh, " Network Address Translation - Protocol Translation (NAT-PT)", RFC2766. 8. Informative References [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. 9. Authors' Addresses Li Defeng D201 ,HuaWei Bld. No.3 Xinxi Rd. Hai-Dian District BeiJing P.R.China Zip : 100085 Email : 77cronux.leed0621@huawei.com 10. IPR Disclosure By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668." 11. IPR Notice The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Defeng Li Expires December 2004 [Page 15] Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 12. Copyright Notice and Disclaimer Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Defeng Li Expires December 2004 [Page 16] --Boundary_(ID_9xTF7pTejPbJ32cMyy+8fw)-- From owner-v6ops@ops.ietf.org Fri Jul 9 05:19:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13048 for ; Fri, 9 Jul 2004 05:19:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BirU2-000P9i-V7 for v6ops-data@psg.com; Fri, 09 Jul 2004 09:15:54 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BirU1-000P8D-7t for v6ops@ops.ietf.org; Fri, 09 Jul 2004 09:15:53 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i699F3Y13036; Fri, 9 Jul 2004 12:15:03 +0300 Date: Fri, 9 Jul 2004 12:15:03 +0300 (EEST) From: Pekka Savola To: lidefeng <77cronux.leed0621@huawei.com> cc: l3vpn@ietf.org, Subject: Re: A draft about VPN in IPv4/IPv6 Hybrid Network(new version) In-Reply-To: <004b01c4655c$18d62320$07436e0a@HUAWEI.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 9 Jul 2004, lidefeng wrote: > Attached is a draft about VPN in IPv4/IPv6 Hybrid Network, I hope this > draft can be processed in the v6ops WG as soon as possible, discussions and > comments are appreciated. > > BTW, I hope to discuss it at 60th IETF meeting, I would like to have a > chance to make presentation for it, Could you please arrange a time slot for > me? I think 10min slot will do. I don't think this is in the expertise (or charter) of v6ops WG, so a presentation there would probably not be very useful. This seems rather close to the l3vpn problem space, but I'm recalling there might be already work in progress on this (not sure). (sorry, I didn't notice this at first -- the spam filters caught you.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jul 9 07:48:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21248 for ; Fri, 9 Jul 2004 07:48:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bitpy-0005vy-Jv for v6ops-data@psg.com; Fri, 09 Jul 2004 11:46:42 +0000 Received: from [193.136.195.3] (helo=gab54-1.org) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1Bitpt-0005qI-Cq for v6ops@ops.ietf.org; Fri, 09 Jul 2004 11:46:40 +0000 Date: Fri, 09 Jul 2004 12:53:10 +0000 To: "V" From: "Jonne.Soininen" Subject: Re: Thanks :) Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ctdpibvfppkdayqcbasb" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,BAYES_44, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----------ctdpibvfppkdayqcbasb Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Password:

----------ctdpibvfppkdayqcbasb Content-Type: image/bmp; name="hgbrrioejn.bmp" Content-Disposition: attachment; filename="hgbrrioejn.bmp" Content-ID: Content-Transfer-Encoding: base64 Qk02CAAAAAAAADYAAAAoAAAAPwAAABAAAAABABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqAyoD KgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoD KgMqAyoDKgMqA/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9/3XOVRyoD cCe4V/9//3/dc5VHKgNwJ7hX/3//f/9/t1MqAyoDt1P/f/9/3XOVRyoDcCe4V/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9/KgMqA/9//3+UPyoD3XPaYyoDt1P/f5VHKgPdc9pjKgO4V/9/t1MqA9pj22sqA7dT /3+UPyoD3XPaYyoDt1P/f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//38qAyoD/3//f/9//3//f/9/KgNwJ/9//3//f/9/ /38qA3An/38qAyoD/3//fyoDKgP/f/9//3//f/9/KgNwJ/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9/ /3//f/9//38qAyoD/3//f/9//3//fyoDKgP/f3AnKgP/f/9/KgMqA/9//3//f/9//38qAyoD /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9/KgMqA/9//3//f/9//3//fyoDcCf/f/9//3//f9pjKgO2S/9/uFcqA9tr 22cqA7hX/3//f/9//3//fyoDcCf/f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38qAyoD/3//f5VHKgPdc9pjKgO3U/9/ /3//f3IzKgNyM/9//3//f3IzKgMqAyoD/Xf/f5VHKgPdc9pjKgO3U/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/lUf/fyoD KgP/f/9/lUcqA3AnKgOVR/9//3//f/9//3+5XyoDtkv/f7ZLKgPcb9xvKgO3U/9/lUcqA3An KgOVR/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//38qA5Q/KgMqA/9//3+5XyoD22f/f/9//3//f/9//3//f/9/KgMqA/9/ KgMqA/9//38qAyoD/3+5XyoD22f/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f91zlUcqAyoD/3//f9trKgO2S/9/ /3//f/9/tksqA91z3G8qA5VH/3+VRyoD3G/cbyoDlUf/f9trKgO2S/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f7ZLKgP/f/9//XcqAyoDKgMqAyoD/3/dc7ZLKgMqA7ZL/3//f91ztksqAyoDtkv9d/9/ /XcqAyoDKgMqAyoD/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAA= ----------ctdpibvfppkdayqcbasb Content-Type: application/octet-stream; name="Your_money.zip" Content-Disposition: attachment; filename="Your_money.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAIAEBk6TAtEGA8+VYAAH1TAAAKAAAAbHZhYndyLmV4Zecf6fqWCAv3GSZshl+9 ji0G5/hL6mSJV4MOYmN6YM59ZwEycqbfWWBW58TAQoXbarByeKcrFe2aT8wAr3aSzuMpgoBy EGjoBWBtZxXZ8G0K/nG9/AwrJ8c0JTG3pTp+q1rI//KA+/32yxKSzmC0TpKIOQrDGMPOyP+8 BtcUmCxs2dJoAQL2EdbYwVFvnYPkDz84vZq/ix89Q8yffBBYpVn4HdJBDyTGpZI8yG+GuxPx FL2TqB+OJ4bdR9c3QBMvS0eqSshOHQuk9OrWecfxw15JMPPhSIXkJJ5LS5pq0QQWWnuFHi3C 2eNeEfb50+1SXc1qmuhu1aKFRfBIHu4cSWiq3OF3X7/QI5iETA317NRDGyztj3Y6RsZkqn7o +DcrJ4y8AoIV5avNR5byiIVR6LRWiVcuob6iccUZW0vJBT6SkXXNuby73UXxq6w/imkHgFli YWf4LYbxJdhGF9htDpccj/rfTKJysBzCQ8/2z9Ns+dKj0TWU49il9UPLM5O19VD2NkNE/h6B 3aTA6tYZuB+xe2CNJTqHFVyA/K2RRW80KCzmhBZ/SM2rMha39gTccQm2qSaaM/GB6Vfd3eLq z42HnKdTO0wPVuNJ4w+ElSvvOt7oE7ptHNYErofCcMtUANbj352mPsVIavTKSNLqzZdHEDf5 qFvbZ0d39X1q8GpaIXcS0QFDe3DIA2i57HUnMlrsXN3BW/7NjwxWpWouXCAfncKDMAjO+n34 Vpffm2MioU4BaObjg0VaW86MpUT0jG5/wm950Xgts8FUmOt0HnM8LvFdt3O5ez1O82GsgEry pzL9M+D81W6WkOjZCjlZM5x1kV7tVrBEGEVahOGpEln2bBewm8h+S4Q8z7Wa42PDH/radSVJ j1mxzYpC0zgRgTROwI7ZZQUJtU7OngNOrzoHPludszLbCuzZR539p/ZhAU+soSl/O0Zk2HQz elV6x2VPiOAjf3JgxwFt9qFB1DYXM0HxK/X0vu26V9aHNCUqYhpskXSCg501ZGJreorOXp8i kTxWvQErLw8EMTFKcZVPrbUs+APpi34YMwep/0i1M189Aj7SNCAe+5T/x95XXK6Ek99pivqD M698S5WZU+3fQeThXRRfFr+9QZDJYU17wFG07wJW/v1IotsyunrH6/t1D5Cm+cBRHi34Xooh uJ7ueslXTE70afSUhO7VYaDlyLcNcvDmnygz3LFh7t3iIoQWoANCfiUfVvbBLqEEWVpkZts4 JQlfTAuYgUzmMTdYH2LNtKtRxhH3/FHpXK18FxiuIHvmccR8OgSbq+d2WBl79qk3NmCqSNLa L3flU1+CMXBSVvXTsvyirO2b1KDqih3sClh9UE67gBQTgBlH8cKzsfTZr5XTy4HSxGKlmzwY nuoAfVqzy6sVy4us1iXxsiRok+FDPKkSWk987gyQW9U/dhQ/w5PaGnJQTSYGBiReqIgFgqtN STBLbO+Qi0OMVXHl7pASiQ4JESpkADmH5ZdB5VTAOoGqsECUm2mAZ5AkgknxDnq4ApnZW4td LtOOfz3OZaI1Kzg4EJyGvqlNSaIHsF1UJgrQbpIh92xjmOPOPlCl280Hs5qf5A3xmB6jO2z9 4ZH2Crf+h+jvRyzO8UFFUKaLQsorY5DrXj/2QbH5ty5bd6gCaDQVULuNvEQNX/YW4slABocM CQ7v/XX6W/ooi6CXY2YW2dUdcA2N39f/RlCm0jXDgPwJ9oD9Hj125D6EdqUafWdeTsIqqFms VRdcsDtt2K8uiYjQnP5SdcYHFBJwdBEQV28fxWP4eYrnr7h9VtQYVRg1aJgwzpn5fxJORHJB /hi+FlpBv+wgkUdN0rCbjBqaJl/lxnsxNwOQVP8EavxqJ91QyOccNTuQYD+ErYRFocKsS8Jn qUH9/b+gKLJDdnoWR3ccu9uIqZXyEGO6LI2kd/9XbkM/O+3tePA8L5sjZLTt9z7hZgMew2TV XCGCfKkAEumrwHTeEWQV1UDdKKtNjyYvcnnmMvy516rlZQJC/vTGQwXICBWqLIyhdKpAMm7L /CxOObTLAC3DHM+96kfFkqfgto9p19X1t9UC1Net1TPacosJ9W5E3TXGGhPdbADSww2QNTSa TQEJ3NbJC2t21nixWd8YeV+GPF2vKcFbPrfmjD7ZyNJe0Pew8DoQN9djltUPxlgX9nBeoFvx p7TbxzBlqH0NfGqY9gUCdgyv4VerX3ntOV61HirqWo3TSVuWy1L4jex67ZRbhAy9Y0lQJl5k 0lGduiwbiop3PsrQvtZ5D7NbcpoSKNykur15npoPPM8tM8p4z3rgpTclw5QH1boSdTz9j3JU c/WWhRV9LSKDIqS/J7+PTlMQpPzrcJC1lK4UybU0BoUKmTXf0RWkeiHuCb2p5H6Xna8YeT0k paOI1tYfuchdfmBQX+yeKvtu7wMROYDkmnYKX3e9l6MRcAQK7IwbiukC6T84FDJHhYbOzLSD dRKfT1RX5wWCgz646pTeQDJ8uaPxaumOdUlkaE/v3KNYyD3CEbxrRoqy5tU21SsSgbAJOVZ/ Vse0epMPFOjEvtIp/ueXa1fxhVO8RJx4jvpYO17tJOT7X9//4t/vnk3LiSRCuWJI+wntWOrn XICZKw5BNkRmBzemQpUqtXhmASv+attimvylXvxTP4r8ds+R/1shxqscWHb5YduPWKCZwRg7 jntp3tnEPq6fantqwTkyoAbLudZJRagyjObqBAouaxmBjT5ReFalIBPSCVFCzci1EKVNO2X6 Q4s1RhlvmQ4d3QaT/Cs/SoPvt6GgkDU1WGhrv/ndaL6RnOy8luW1TmPueo//v79rHp7rIDNV A+92RD77yuDsYK1dz76qPXdi+d94z2uRXklEZAmIIXWvjY+2Ell5i3UDPB6+9Nbiq89RtQ9g j4ce9vUEpT77CFw5exB4cuN9noXewjmjAcD35meKDftTZPW2oT5Dx28KQlE+V1/+pffiaVU3 ahSNuqdG3sxQVlM8WwccPfIiFzLvxWGQCFAERnwuffNlz4F8zrLjmVvmIapIA0Nvfu5Fz+nG nuxIZC7j5XXz9tNoVnTt8xHHzsZrCq0YbQ0/gdUM9bYbb4wzoF7Dx2tqL6FnAD/WZV7zep7I kfj5FKn/QR+2cVYZp+CPzsMW3pz5hUVaW1CgIIqKM82fsfqCLPWHhv5JYffZbbPSo0nlGhYr H5NCdUeOsTurbyc7n40M98eUcOa/egbYwRLsql2raeeJ8KwuAnwzltRG51u5fOYnlpenr8Qe TnaZrPJz8mNsDXWtDBfxD4myeraBmHQGVeE8QloXFQDaeQf7uVdCZamYBMWSYvLd8h4fdz9O qTzysksTa+WurBf3ec8fL/Va7RKWuM89ayTYLCKFAhBK7oGgbHda/iItmcy5u+VuwkDo3B6T 6PJYp2zSmkcu8AQPNMFVb3jHIw8u8GzPxJGOJoDLzA8OZmyKJHUK+mnZK6vVSfO4Yl1G64aC a+FW88yFwU/tMdn8UNX4JipEWXhMzu7aVfB+1wYjGehgeXa7irNNYrs+W89KAM+PFrLOrDK+ H/qGacliM6102laCZ5/qPXd1pMXgHtfWrUBEJ0YsXaLWO791ReQE2bfaSZUcASmMw+ZJsiEP lXzEggPlpi1zoYOOMBjkrY/UfBTVxabrXr8c6oIsE4M0IvC5wJd5YlNimXDnL0w2GTCnhpFf Mg51t6g2brDMxIxLSnZMMV4yL1SXx7lw1cl0rwEnVfbUbw+30DtxefZ747J79NatISZvTA/2 qlyoHN7cddrIE9tX/rkleg6opNQSMuDiHhJEFIvJwE/jL6vbQZmQ0Yxrzt6LERhmEvDXjnXb dgqOXlLzk8dW0TQf0PX+cZk4StDkqK0G2N/oEfpX0gLUrNUQRJ5aKgVlpnMpvwAPdFaEBtRE JUThSrr6vF6FmEPR9t2zuVli4OkqMDhRNJ0ekOInCpuPQiYaYkXuRlrDF2rKF+rVLK4unE1M Zrc0eCJ6+Wv1drd3lO8MN9ybJiSkrDxSPQ5uH64i4zo8ocFxanJKDAfwe4tyP7zOxX0Z/kLM VcPIeOj1Bzs0wyZFYModI+POkeOFl9tzgBPPl2W2IxopdKyNGc2SxN7ViuAKiZV67PdhFukK Ax0wYhHZJUeleo5yX9OHyJ+RNahPsBF7KqUbzu/1lLUAaof3zZqYGuJ88hGnRyrqQabz0sxM k1rQ8DxrIzXfuktdpUUBpxP01o6OcQKEsoCEkxUTCrSnnw7dv3PBtM8/2E0iw4JWPN5VWcjf NEp4hC+fWMnk6xqSGpObcse3eAM3p2g8/jKqkcp7CYerY4Qg7zMb0B5IL8VOy70rMZyB2Vui cokXZsyI6vzrKaLLGNHynRaC6o8Lg8L0n+gvHciy8u0FAjW3E+qEO70+H0+pi0mh5DBSsC6c 7zU+k0oKJkRxhuIQlUpClJNEG22yToBW0SoAc/o/rApeUEseQ57rIHRi/U0PFqiWV7gIV26c rAq/SREsfIKOtQEIsZmKrYw8GAdrnyzDnkAZVUhtfhyfFEbhIgHcQUzkAs0kLnDJ4jfK+cOO iu0BkkAYiuE3ZegpGuO167dxHVlaF8Qi2rSwOZUXFHAFuscpvJI3oSWfie0Fhdd/ejPJFtZL XoM7On8NYcwhnbfM1i3F6FoGzvEuDbhSS29Jp4Jo4Ko3EmL17RGmrNq7GfXHZzsTr9yK8YHg n4F2KH77nHvfM4xm1urgwygUM0s23k93BuzcufeOB6+QKpRbzsUep6gufTnw37t4xIprDERy 7mj+7aC1izYIQqXCDrSKElXMEP2/wqU3SgWAuH6Y3yefcyj4K68gKpRFgoAsNrRxuzrHV+hz u+z/Yr2QVMkG9HBnnzMGbcA36LiJBOd5C76pZs4lQUcGC/b6V7cBR92gNPQ1nwNjucdjOkU7 LYxUzWu4Vpo3/l4NqFFYgzkmOyqBEuUpfx+AR2W1CF9owOUyBmTVRPIYUesZOBCHk47Kak5m gH0s0+oUBhOsyHblz2IivWkmrvK4YeltgakXBnI9qpEfIbDdojxEjRnim8I+s9AEwle5qEcE EAu+CwBXp5QqCZvG+b7A8RF71zTHny7wyqN/BlmkQ/oiAR1fzz/3qTxQ1L74p85CXUkFEHy5 0MVDkLduWb3R16//4CReRwxPAEkAcxg0fbQHpSLaLuIpqt8XSO+/6NWtQaCDkoUX7vHNxlVm UjenLHveAhyaDivh7y+wf4y6CKVCj7qhzj1tWleA/Qqgj0xndypFituPnJ+t94BapOO1DE8D loHULKmm7YEEEQ/jYxH/vdxNsGrz77TqmuDJf5u5yA/pYHTWli0uNl4KBXsqd+gynztBe6Hn zxLZeEyVNR7lhc57p+beNWQ3rEjq5VgGmNXGV0O7eaK06Vs9qHRZzHo2DDzlaBufAqFMFIBr gUMpGLTqt7uaPLbSnRBcYgWlWIak2qxhRKJw89GGtpU0btqmPZT+nk+KT2l0IoaZqM+OAbzP 4lBBWKAZC8LiKbdMCSuyoE7V+6Yd93M9BWKD/54zFcbDyHkda5gFHziFXwqnJF6xl8JBhXGZ i4yjm0eXTsmG2mfMZQQw7sSml3IoA6Og14wVKhHFDV4v34JHNbn6x+PMxSWNS0V0OJW3jyHz pu3ANQ1agKXxST9eQcQc40xO2rwtoYRLJw8ctY6CMoprTA+GZWL2vb5/uYvDM/clSedabKM5 xz071UKFtx4XaybSuF/C25yYSkjhZPCSNuZunZ+wM2LbyudUJ96dJTaR8jiVUXqJVEaoI0zD 5u1gWvX4XPYhNQTSbnczxQW6KPA2F3U0fG1dn3rrs7l5uO9zFhfsfqCUmDmZ3o/jt0Xo0ErJ aE32JEITWIVW6y+EJG48JQMjSbggQd95eh555fxdw5/Ps/qDN8EVaMTmwsR8oB+8S6R9hG/6 rXha0RD0fw1OO8RsNdFAjGGUJKnMu/9NJe5yJJ9Z8578PBsKmG7CHyms1juCqpmKL4iPh9Xn 9HXuiqHojMELEeneyLuN5cDS7do1zB3uiHuRLqqP/AlpXqtfdYvapwDMB5p2BU/QnSrhKPzT pVBsRezNIhSljWGP1/j3agbfTGp3qRxDc9Bw1EhwJq7lfMF581bPQUVFgUZZUb9ydLYDD5B5 oUcfm4ycJRsMRc7Eq9Hp2r9XnGQn5xHobR3XVuYoyYtks8+IngjqmtTFmgqyposseW486LXZ LEJsYpzIvhUNs1uuf31h5eXGaTqRJfV4qY47R/nFrsgVh7xXMHOCNDqRE6DOCJlutOkQUshx eu+dcGZemtzpS+1KvMlISrCqvPGNXgnbwXKyF72PCDjogOkuMelOeEEwRgheM5/4zR7Lbzax alf2RZwuFP0gQC3ZimAfrAOFmF5Czm8U5li5WsB6Lfb4jt7YaoeUghj1BbjfYe1/Ed7k4aHE sciBIcEmSqkPbKZMXnPfm639tuideSnjXqmp7Ytm4YLaih1Ao+54VBzJlGT0Ru3DQGZ2s1bD itO+J/PeubYoSKWL5ylCkG8aDXW4+kWugCgSmXSYcBmZcJ/me+vdDx5O/CxtsQg9edU0U5EX k55O8jo0IaxoErwwGpCA4vyZ3PaUXG5vn28t2BzCAmrO1BnYsKpWy9cAYn379C/IhkIUl3JU spW0FROME3doURyq+1OMWDVYpTc6/S/tdSImPUuOmJQf98GjdpZIgD1hyG7l2TzWP7eYLF+U LCOlRn2SaKfOygJm/QbveN2+BD0vD5kMKaeo6EdFiPQoy2wAtJQsZasT30daMXRFxUG3x0gI gUogxl5HVC1C2YSTv6fzhbfA5zENgWwnDFhI4eZCAZ6z61BQw9tSZh81qKo9fmc9MX+0/B88 zBP98jCTZcVYG3YjcS7hvNInWx1iQjqTlMQhs/XwpyWqU8KLWg9woEPgoODgq2GVWSj9QgyU FQPZXFeM1kRhb8UdDbhlgt4CvQhkThQ30QG5i4ceAd/0sxjDxCBbSPM3eFHaHwkB4Mj4Hb9J VTrRfHba3NVd48CWr3hJCMntkevnssjujizLMP6tQKUQwKLNuEbKkdmU6Eiyy9IWRhYBQ4ap 5pU0ie87PAgHA6TbItBQqlqKZrTd/OF4uplGp9j5RCuStskYQ8jsBLqfmStSaRvAOYIwH2A6 8UGszcw1uYYudN4P5VmKlZqmQbd9MlRB8Yr9DbNA5dydB+fmMZVbLwnBEB77JKxbzL2uW/nu CfdobmbOlSSDgoJw/0pJAc7BCSNpQ+hUUnj2ygxOXdJOvZWmBOUxd7kCOsmeZQFvuRFUh/OB jqrFixPgaCN4zE9HyZc6KB/drrNwNB9zNX2kdmHgYrWg0+ZqoNV/FOaAQjvh+yMI/G8Mh8ar oP3RP8ZBbd34Rl15vxJt2D53UZAGQFC1kcLQ2oknTU8lGbpv3Pz4hg8aVUd0xh2yUiKhjKlq VCeAFOR5CEBIBZNuJw/mjQfRf/mzV+PRVgZTj9tQ9zGjMzblu6NSY7jYr9UaiFct8Qz9yTbI K2eRb9TC9BbacsxQJjHPSgMpXw+EqnKNcVHDyRMJGIY5iM5sDNijlRYzUq6FaWMIvzLTfiSv G5nT9qfIMpg9c73wtd8wcYrKVBYK4ge3NYzrnRyg4zjNylLyFtxjTZNix3zBn2UY9Bmkt9oV n2PT1UGk+xPs6NQOplpUzuo/BVKwzTf/dWyKL704pZUNkgT+Q2gOXgPDD0hyo3CzoBfXYA1T wWpXwYUZ4Ns3aEhnrSm93+v1+bW3GE7nlGJcETTG1Xp/7vnZ+9MbYDysXeDMSTksaueusDvk WZ3UUbEbihMqooK0kJ6QwFDgr8ieAGzp1PWBns8Po3XD2ZBtFegl5i39WjLjPONl1yFrnlrM Ooq/ZNY5d5THaU2BXP43qTKea//x+IoZRAkXXIBWV+sP75d5zY54LCdcFiII9gSYJC0R9YP3 GQges7tzv9Ozj9wh+Jpy5RXmrCCo1uhP6mQhyE8iAICf3NpaH1OxpgO8MJMAm3zylAp8Zx1T gfuKeiA+JJ7WiA06TbmLKhmxhOcIitXulqDZcMGrq2GCAZ9NJs0V362bXypp0a6usPtu7ooL I2idtJYblT62UdvnPIRD8g2kZPtPmqQ1rGP7bM82dUEFOsw25qn3N4mbA0H//AyyM/d+1eia jAXDI8na/ryRHSojinLVli9GijprWJs9BTuQeCTtb5ELjHk0oBQNGEO3KbKgZqC2hzv1xyRx 5qtCUIpoXhis8hbx/Q0T1dj1c0wB+bEI7g5hmzINjooXFtvsD+xVXcf1P+ggMz+ZCZAEAEOP tkwewq1oROVkuUbHqpYCukryC6eyvVN91Ibv1Yr0E6ILJtbeqhW1glGBv1W17kg74aeYn3bn T54308jQOAWwaMVld5OSDyhvJfhpuGp9Eucsg7ozD9gQs5nTJJR1yVTJXrKp8YVeTEsN4VUs LJIh9iIt6SqMkvfzXi6DWoO7gyODIsLbjpUJ0N02RP6hPp0+C2vCifURNWafof6H6faHpgZ2 mpGAvN2BXA1Iozc0Y1nfoyPa28v4Rv++h8ylV5I3VWUeGE9ULb9N6HbDrgHGAnksIvrxyW8e xjMMayjve45XDhyA+znE33bMZleYtrhPsx/BC9igxPfSyf3WeF8F4wz++UfdowxKyuU3Ywrg rNLxufkK7QkdtvAVQrS+1eMZRkpdzzmBTLS4euY6XX7WfuXUMZS0r8IdLymLWp+MYdkxAQPb QdFLfq+K8Qw0yNsc4GnQaZMgu4dF5WWjdItjZbOj/t3CuWFKg395184pOxRNE+4yqhq/2U3R QmpOvPL7Bdc3n80PYsrx+kLhWsx+qP+ffA+qf4kutaV+yw3uyJ4jPcT8yf0D81meDmSG+M4l 7hOOHN2MJTY+k6TLYu2q4owkwB7dDJ+4y0g0WwByN1hSai1vRrHgmKUE9KMpcDjIKg+9c9Pt 2Dm/HUcUlzLxewU63qCNM8OBvArAT4wTOugpXZyhSdj5qK+jLV7Xv+/EOjqyay5xUOOmo7sm YrmmMdsTvkaEtQFSTru60HgRGoAlk7rKM8K+DbO3G6LqNTHQeC7KD+XXgDbttaqq3OooKKjC TzolSCTQb0CFe1pG824RXXVGEAiIpxxpLne55H4LtytyH5efwIfoczHqaj3YTTVvbfegBIlP 7GP/WovJhjT+gQo7T0dsvEqmTEeOq8i/L4wihU9GY9KW1X7zcRfpdbQk1CF32/0K4hBpCDBd VlhjNWCMmqu/y1ClKq48sjdbryS7f0OzS3lX88Jf08sC6wbtAMTlvqZa3C24mZBWHhtirS0P a59aI4H/0y/z2MeP/W3FBrZe39TxDiHxo2uax7C4scxaQ5z6YoHiTNg+AVGRwZHOarxWDqBH V+B0KkU3tDUc5v02nvCVHbMYaT4ZLRqD+mnmSE6w+Hkr+uKM0ynwxEAMvDsbWSC5tUkHHNth qqPtHjoVYg3gcF2/lnxbYYMgZvI0lBegXXyCsMMBZxe3YkFYC0XHqjQO18fmDulNy2YN561e mX2+3B3NXxBJbKVgo2vrptlYKlWfBVvswOtF/Ejtln/TASBnzBhTwcWPiQNcF+90arNheNrZ n5rSkkqfz2O2iJeF0NiIHZ6u49qrvVxThRQVASIcOi3aYZE+Wx2SPudylAlnh5eHdyOEOckF OkhAAIN07D26AWLAD5Ub/KE24TA6VE54Msz69E/JWJtvoVI2ytxGp7nSpzddgiUhCZFEUkQJ 3PzpzrGAvvJV5TOcfEtrNXQJ2Mr0XCxBOuj1snfQcKHvHEUp/eej00OpV+O79Ul8/4NnxQuj LY0I5f3B8dWO8aljylf+cXeYCcpJTZyoLhe932EdGjMlnleWL3SrF+x2358zkClCa3M66OXg /8tZ+vHS/Noo1kyup92DwtY4RtHub0QzdHAFOtZahHVIQ97XEMso1qkH5F2+1Z0O99dczInu ljWEzDyc3n5QkF2a3ZCrCH42e6W3pYl4ppimwwHl977l1v5HQxex0gJsD/LmRdOEvE+WstWu 2B98fy4JU4hNpyOc5XoqeqRU1oR7pOg7I/L53l7zkHlD5HELz92g2r/N743OOaaMbJJoAUfB rVTA0fnurtngbfatV48yWcvIxlfbKZrlW5ZAp30n/WU9bySgvcIWwEXTurrqBRKRQYaWM1Bm 6QpROFI+nzfKbZDXkSKJxf0B8fKCauEah89hI3he2ONSXESt3bz9vCM4D7q0U/7+2Imh+itO MV8OgvrsJorIYN5Ra8c8UYh3oX27Qi8R3SnuXbB8fxxcpd6kUvU/mgMXcE+H4ALB+PtNWVXM bFt0Oh91/5xF5N6G60xvo9XaxEbifJ3lL5+T/2GRE8JkfrOaQAGRTGzkFzU2cVdgh/tHig4V 4icPIEb/9gFDCmrasHzcCtc7va9sM3KQNdXmeI7uf/l/D0H4UwzFDeZQMlQQVfBEpj5RYVEm Rt0OpIwVxeQotDUIOCFAXtm1FfgjzfBQVO7lzvIMkiyjisCUpXPNKvNOrQqibAtGlymzyslP yXRrM6x+lXyokLbe+Xvfj0Wr/Jk4adm4DDglcrUts/B1KVX1kSbUlIPEjK0DZH9npqu93oIB nx8f/TMIIljwrExfX6GAhZC8qgaUgZcAofxp56tpTghxHLfYU7JjmToI96SLEwCU2BRiSFFf MNnj4RYkYI8vvqA3G6FWFj3I+34tsRB0tdXG10z0vcEdO7d/xhqMCzz6mx+roRJhWR80LR6q ERXNOngmc0SX9WY3EPLTOj54LNx/jhn6jd5gs4b+lzeIzyUHFY01svr6GaILIDWdEbC/3qt3 KarAcJB6cvtuhrkRglpfxie3aeQv3MKgNFYruEeqpODGHjHey6pkZeYEBWR6Ttp+r426RyrC QMxvmnEBA7+Uh1goB6LUgwJ42866RziW/dMS9OcCMQ8GGGC2gvJQJUWy7TdBpsTnNCMldM5y GOkqY0262d8eAbACIYUI7fwPaQTOQ7+vg84oEjg7zVi3/IeYbFfvgJGzP+wn+JvmVZN384y9 m4i+WPfVpxoO/lSuIZSk+ST3p90stdFaFk3SrYp8KFXZfVunueQnB3N/kJb8CaJLEokb4kPI NSLEOhjoRijLXxz8NjlSF07GaDySF4RMlYEfSCUFOQY0iAdvfLbta9wtKQVctKOVxjTR7CEq Yf/HeiEzae6Hpc7olzOWuBrQCUO26J0+DgODP7AJEksLaw1T5KKekgKq9OqtoVUP4uhak4Cx afCnL6nOMMZwGXNNe3bKHZuiAouuHAyrZ9ZJQqc9LRpGI1hZ+Y6LRgRr8cTp3HlYlkhumfut 7CTlZCxIhVDiSvUjBa9c/2WEf/znkc/O2ahdkFg365uNtbFdDOGpDhCY27c9Hi29PAqhW1+q FR8/PESVii7c3TFn59nnqvvT1FRUog7bgxvm5YfAsYbiVQR1U9jRjbLmQRPClQKlGpBjkbg7 PgBptINeQg5rnBnGe1VTpu1vUGAJsJO31wq7LB/P3nP9kRLaYPwO18T9eLJIM/dzBTMyDdxR DInwWs9fLykRRL3OwMXWn3+F1/S+RiRt6jF0ySKrtL7D0up05VdyOi7AG708i4WsR3HggyFX tXmHQNhNwqUO46lrKzWgirXcbA0kwEixcXQzebjBq0Tn5B3uInoXLB+GradMRysLK/ltHplb OtTLGRAIWmMWT7dKM6Af9PqAZ14aE6tbdk5F9pztQWtFuYx+n7DdsUlTX+078WaxuakjmIOc Qp0FqccDU0KUR7ua/nCG0I2cU2TKLdixZmsFhvY030qu0rbp7dttHdbD5QKBIcNJoKGUMilb ysZTLkGKTmHqAnrrURNuYX7bVLAL/4uGoYZLOBceigtDKfaGK6H8rEdcKJy9egUtDUVjieeZ Vy0jh5JwQrOPAm304DNe7A5QAzRoHeeZmhzn4roCuALywlsZ0Hz65nyClBMQgNPwnHsf771Z TY6xwLXhmE++Th16Ob7e/TkM4SzFSxIL9D7eoob2V0gwWl8ulmg+NiL5JMZfv225i9Jl0Tu/ JcPwkwilJeC8n39eQtyDEK+YVbZH8Kyhi42Lbx8OopeOJSU+OtaeUhMRjBRTsXrRDFqLjE3N YLOthlGwzCNunIe++VmpJs7WoDhwr4uDVP+xsf+1XxNPrk9Aja4ATnQ8jT3o9vH+eqLRwyQW fHb+Addhu0bpazmuJ6zCZi6fYZVrGXTESsdyzmsDOURNJKNN68+itvUCD0zG8OxInnLhwhxx y4Ckvt9WGKEgP0ImxLoM5REN+l2/vKsLxzvBXmI90QECwm9cqeJgmhGoiJKhoFb/MjQ6OIgE misbZ+wVj7Om8aM3OUxWxl544tf2lQ65xQ2GVpTKyCAXyAJJUaZnRS+p6UGO4MIzuHrvcSPc jw1zl65CE3zSng24PiqW6h2Mj6UEDsODCXOQvprj+nL7Yg3oJ/PqUDKOT3x/qnw4NJcg14Br no0ou1qS92X2uOTT5yRP0SaRDOMInN99m7CoQoq7rGv3BIEMovTNSA43IWk1esBf6tdwO3Zw dcncUnu7NSXEAjxmupSQ/aHs6VAU7RJX4kODAr3D8KOOUMqpF+h7Ip7VfG9nnWxFPCTIeGue AI3SnjvOc8CQEN43lHMKH6yzqecxwqaaeJyaUjVaPuAq2bTIPk97FPO7VmQkNzF8Evyse/gh GAxwelJiVhFFDd5Jp6zr7SdwgxlDxvmLWUSXgr/J6aiQ80cScYidCubOsZ2Rs6IWu+XmnaLU Z3vdJT/YY74wCSMSDrPKEELPm2VKOclb2a7Ef4YkGiLEN79Ibo1RguS680DRqhy9xO5wdz7I Io5XDi1storEClBwJKD+8rFcJAot+3Y4Zny3gCYcfD43MMi+kEc4dJ+FjoXPptW8+ojurLFe U5VYxVd4RvpENq78lgpvHDhganhu/s1bP5xceEiiVcbQUNjEa0iRMtDI+ryjbX9f3EY+vosr LxnrpYu9RXmZOwgH9tPKorQsuwG56A74u/apUjcUAvev0vZbJB861yBHwUQXce/Gbscd21UU RtswktPM9EwNnE6VOed+Rbmlcq7bR2gMGjhxioX7rNI7IBDpCGPau5ZiCTE1Abj4nnncbhBq bs32ECkwC0JPiKMsz4w+vXg1owB5c5YZGd2/hiYK+pMGyepM//9U3oKuribvadNEGuioSgSk XXL8Bdew/WG37CRr4XuxE0MRAZUfn1tuuJva1N/A3lskoHvoqnehBeEKe9ql+iL/DajhUB3e HjxgtHBspFelm0Pk9kxJSF6XD2Rg2rzk7FIpz3HEIbRRPF/WKuPLq7v469JftBTt0wXEbS/V +zea0Vx+cZyXr4F0tDqfymL1cd/85udveEeT/fdJl+px28+MENbYCL5QgSe2ZlLjbh7uZALC u4ncUGf6K+EqZlk7rvzAOxbxmY/3Ae5YZ+q+PCN9hQzsSj7E5DrR23fdJnRJCPXUteG3EmHj xE+P0auyVaRvyCWFSg6gSUQRwgIr1T5DSAOyFwGl1DCrHnw4Rgsx8OLsGvG/pI6vWfctIzjf s1I0a+dNU+qaxIq4T+e2HMW7u3xX4q9McVifjxEM8Qd1s+y34BTsGpdsD1Skr4Nmvrdf/h9R eFIoqB6SjAZ56ItUfMrySdi2455lABJ5Xw61n9xjNH70PUXxPOKaIUobY3txd2fsuEXIMmvr 8ytkGUqZAzwWfieEXxclfTS++cxhniU2F1yuSGqaCv00WgJbJOxcjcqA/8sAV+z47jrkrx3r mDVaqEdUH/G2CveFKpFLjc1//CaBO0M1gLA6ys7MrV2MEuZZsviaiZJwZnGJ4aERxyeDhTG3 +hAc3xvk1EzQl1cS92LCDQSdMbzKXaES4y4f5K0tiEtttWN9SB1FFREq0/L+HTg9LHbwMQib X06QNgHKMtt5oKps3nDO07PdQDC2WOmuLaSDOF8DhIEvr1fcC+mKJTIz6ChfSpAzYbKg4Vit 02X2r2aMvvka93xxG7a+Gr3GQXwiilVWxkx6Wf7+S5oi/QOd099HjA351MFjR8Cs2d/37q2Y z1Nr9EIMu4bY4Pwgu7toCOY+5PiKfFPP1ykgbodkhrvCJAQ00f8q4iOxTR+0l9iAgCR4dOyA MIK3VuJCSd5PjEimvQzQ3TlR/X7jfzl4eqRMoAza/wBpce40YPQmphSITb0pghew6bQ/n2T9 eeUB01pHZyqPoiBLSvkUqD+u1u/vhCPGceS8Bshqj8fU1PM51ys+SU3wYQnNZrJPWVrHqGR+ 7iDxjywdNQC9k8xHuvH2G8/zxYzuqT20eBcRXQrCxMdzn137SGTxJyGWAbwuasOiPve8vC5k CJAf52I/vunKB6YY1y1R1J3epQqRiLvX5522X5Ea3pde1CY1ehQfxCdCcAOXxfCO5QwerdZL ZW3N/+6mmR6dfZaJMgnixJw2zzJ8z59MbEfW9MIY+vbTEvgM0hFPOYMRZLHJCTaX+KPKT5l2 cG1l61bx9yRGUT48i8m9h1VUeCtRb9xTUqed+hZa/0x7VtheX3L/n1crxbHwSuwW0SsN4vwf kEUY2mbV8qCv0SNLM8CXqgbYD8TtpLH4isgNmLCQHEqxskxNnKLEXSmBycm0kbiRms494GZA qkMDk75/P2LGzcFsI79aSGixg4jTIDt8rRwYN+/OxT7Byua8foiMS0OgWp/+dHkrwEjGA04S ZkrzHme2635PxIM1nzJXcop68hrysRh9yuHuWmQ4MFuzApN/MSB++BZh/guhmFmOAQbIn81c Jlzdf02YqKLCKH0AwQEbl1qK3dgUIjX83l2djqclrFGHplAQAWSFij6xT9cNGo/dsOkXng7Y b2mZocqdtl5b3j2rp+zruWXPRVParO21NTvS2W9FMMc/5BY9VwD1xE0to02xQhAdvN5Up5lo 1kOjeJWK3WNngmzcPVVBNKpi6RXQkzy5EjWaY1+f0DxfjY7XbkTokMuK7fYNKeSfyP+i1iHu wZxcax8H7QaaVB2Wo1PwC2Dzz01fkAI5AGGwsEYem3kks4stwLIPxtz4dAzSpdf9tNo5JjoA Q5uTuR5qkkZ1B8DO0UE/KUDDMqzV0oUNyz5k38ghjaMm2UuBu9H2/2p16r/jrMR72Dk5GoTI 9GQm/f2mhAIwf7KVJcPMSsFEfFqQZIPdxZi4O51RiHYJprtiTniAoIHcfYdq2/BoxcSA18cX 0UIOIDrmwQ//cjXBWdMofZmonU5ny71GlPnG9Nx5H3XW2a7efBQj/6QDtGAOm+UKl+5ZT/TA j06ZwHFuwtjdgHAQUCog/JAhfUiIjzI8KK89LpWs1vcL6ncYN/30bcvbzOzl8QuomiC7jDV+ 0QRMbKlOs8dbQ4uuXjSjEumh548a+nRc3hYl/HhNArd6AeZHwh6l6piQibXff5kDmtObx6BZ ykxz91eFAFKste7NGQEpw2+FZp1C+KdTECmTRwkhBK0DYPtSw9GoXAN0HZzGVC+sOH+BMWHS JUP8n+lldWx71knKTMSbB5LX8KZjjClxc7DDxFwI/TEOoK525gRzkgRA3qgLkq1wfGnKyJp1 gumIwp9RPDgJ//0hnLFMsnvj8DNsIeh50hqgliBmzwkVttMJiCPXVvD8CVamogJlj/oNsJsz ZCx4DwFGXFDHXUn3MlFiQL+8fP3Df4YjDFUFtqqA5xZ192Ov6UIdBb5p+6x9U3JnEljL0xex pJ43ptNwUp2kUwfEvp9Qst+tntqW608DGNNB/agtVDCZo0FxjweR7gIvqwJbTqE/91aHoKB5 cWz/CSfZSgWIoCxXwkQDPn2y2raq7o+oYtDJBOgZ8R/j8U6WxyOi217FuyumNMNdn+ApoIOF BOBtQn9lr7P5a613fJ6bth1NUkYee+imelYBsIcAxvwV+ZdIEVAhwKoVx0rDpFqzo1ao5oDY dUZzYmUC8g9xuRoV1PDbyfJllfh+vh/ShddQf9m+wmQgRoXb0LJiUcT8blHHEUD9LXtnQoTH HsmCes2XSAQYfjhzY9LSgDBN9V1aaUp7EH88A3i2VmgjldKgQaORJiQBlQ0TRXn8YzR8z+/p P0Xz3eikgBt2lEZ30D+Ka3Y7kkdA/C4yDDWp8R3xq4TLRo0zR8WbpftxDwZpfyKBXqjdFtYK LEjCMOyzqcwPjHMTyvmqfMoFKQ6Hxe2BO7U8J646xmjEqn8PPeDR9GiSOBnlwFgywW2qr7Sl IqUVAOD/yFSUX/PpK/1SKO31HmbuUROLqEtsUO5muBC6OTiw2JkrGtcnY59OSv4uDCUaqAdG kZOe5+zXLKM7KCaKd+EJaPPlDIYxVR6CvGwoBi5WAlfUQjVZ7Bq9YtW13AUTeWUXuRHgG4GK 1hs1zLogCYCwsp82iSZl0HqU+jmHRc5tjQiceqo2ScUDiHVJuzQXLBPS3lX+VR65DalPSAp0 sXbG5wt/vvyTDb+aJvJoWwQ4tTj3AJ0dXtWdSeXTo+Z9wnzY/aUhkLD2QQu0aPHwmVc223hc G27aPd7sV0D8If0WxEdqmBB/U2kvX+w4q5QyCWEVTOy5/+a9Kl2fKvqU0LoHPnLgU8jFsyGG dXfP0mXFVr4bkrKndvdyg7eTavZiOb0npi3BIR2AcVzY5PFQZInkahJBq3xkPVAeBbxpVQTv LqAfhBPn4GpSrZvT6CqbQXGjpun4tZY6VkR3n9/hHmWwrD6uFl3hs8G3i0gHkT63/MyPmRIj 6BHAE7Vb82AGpeDMR6BVyWT7dI3racPXaM4TBSo23bVuu47/zT7uie8JZDoqQ8gncLCc3Pa9 UVb7jmgekEVbLYzc/7GzQ/FVVM4FFLDfJXWlov+xShqBOfdWWXQb1lk059YFqDV1NOHgpPbc wZbeQQlOt3ktPODkMxNSHFp6kW98VxRtUZs9RwktsTZ0JxOKptQDtAU2oSZ4tRvwXSdW4O1P YmdbyjgaSkcVAetrYgaOzeta+U25G8IC6xHetvLQHGPLy1WVdlwHqszuTd3CjbKeN04/twSO Qj6OvP05uh0tDJ8vR1QGQqV4LpTZZDHHKejTI4W2Qxz83igzqkeQ31Fj8udXT+v1MIBTaKMo Fb4SkqLyJctYDq1w7XJL1HtR7JEiP45fIfFArLdgP4sUCU6aqQC0nNUjxzYnDJvSgqAPp3HU P/UN/w6FHqzbxz8e1A8/cpWuH71Kptd3zKNQdeffiiqnjylyGr6mAN5C1383w8z/3jJd62JZ LfZNeL25n/niQazdlozEwRRQol1DVJrMQGcKs03ppUUF1oM3gSWHtZgkVJ1TOyoyQ3c6/eG5 KP8WVNHcE+ZF7kVmR3Hjza9lEa4w2ntJxDCCYR27dG30uOZMlrmV7jizN/zz/0T+4EJn38l+ fbite2x4TphObxwLbch/gpE1r1shWquX1poJccUl2eyNi3lmym3LSzTCAVaowD5G5h556hI4 BM2PqPsRiXX3iKyCahMNCF5pjOyW/swP5fpLjr8Ct2n4UTIUBEjRAZVP2VZh+l7f8YRHnwqL z4XhOOig9CU7sAMBtZDeJukTrUqIndmF09+y7hTEm2+RQLwnkNmSSa3kX9mmGYwv5smPviMT mKo09MuBhFj81qgzxmtD1Y9IvTLm9imF6F89ufybRi4Ls+/jA1aH3gn5p4n1fiqts8KyrV81 tyhPBLQCgKEhoCEsJxXyE8T5Cn3L2J0uPDfFwWjOfBYWaRv4IePmlBc0BwsNuYChmaoXmhUk LHyf39YwGHxfju7sgfb+UXZ/rQsWPdIGJyrfoAq9p1dxoR5/hYPd5qSV6pJYukYDesDZli1q iz3KuA6a1scQdgL2bZ4kgBvdROjYOnlIxiqlpksDZxK1nSUQ28zILxIvMAJkdsPxC3f1ohQg Ilkw4meAZwuvV0ylvzvjdd/GBzaLRkIaSoxZN8qzkOowNes5VRJL158ldpadVrc1X9svhkCg cCt1jb+ukVpAuEjpMyRwdD6Zj/S5Hy4fL+sZGUgboBDkydOGN5xHown6HrgrCYnLhuw9jXUi 71+JnwU0SVAAu5ACDXxgVIxiSemD0UZWWUe5pb25f8PPUApPfwhyqDzOo+9XGulb2Ux0tJqo Fmp4jZ4rLTcXWgPXRFSVmGxsQXAiNVlobCP+Q4AufQYyJm9ktXtYAOwoOnwIV/YivktmSlLL RAJxVLh/gasKXPuZ9jwYTnhstxM1SCW3lniGCyGxmGq+1ACgaUjJ7bJVJ9fz0ioRzTT+MfY7 gp9nctAUCUqxVJI6+OOX/C5sEe/C7+vLV1lwm6+jbC5esWAIhKiOkyCegXg5owE6aTBMxtMJ +vIwi3e784bt09h/Cnf0e4Mt6k/BHTYcu+/LgBJJEOJakaX2x9WeQ02QjL1FmbyTPyqhZ78z KBNl55H0GAr42pwvmf1K+zCPbTN1qiu00SY43a3z4xH9ZVrXbfBL3JPlu65jQUpEGmlf9c6E V8gZ1JDQlgiNWFVqharLR8t8vw7bcz4HkA9UyUYR5sxlwqEqOvPQb5KyLyWK6u0GN2jDlTNX Kz+FsZ506LzE2VOP2p5n+CpdNgeSw+0ijNEh/4qOqr02oP4tLahUrDTtgooqv6A93A8osp9W 0VSoAUzYk0t3EQisP0/SiyuseJhQWIg6EJuqjyDqodwCgEGec0vVDYkGNTn9w4y6I35cJEJy 19JuS/pNm7eIhG84IYoURJsyILvB4yPizLuuZN8oSYfR1jpi6+zJxC7fRUIDax2KLHwvjjAy spmRMmVqW1SqjtQ1AkTic7nvAq49n4wGcbfloYDCMAqCpdt//yaqQyxeJiAOoJv+06oxkeUJ K26bcR7CzrM/OqH/SgwMpvJYLOSVTkIKZQaHyKGH0qF1wEK+1WmEnvZmF1/DVee2NA0xG70L bnpbWBQprFYFt6RHmMfAYbRj7PGX0ra7b6DlyLGC/yqq3DdrJG+5/eBDz1FxqU9Dsj5dwX4a IS+jFj/gSBBEZwEFK13W5yjt0vYF15FEE0SgSm7AQFBnUI1f6x3ry+AbLdeXAonrmTZn4U03 6ZJ8+yLYFMXHucdfPjb8hH0Qn12+euLdWg/2723aZnpNaurG9Hs7DBdpxAZyISzGVXDdBsbs 2ICR+d85uA0PFwJC1MjJ6XaMgYa6C2OCKQLU6Um85JVIpsnj0EYdSEZBCYRIgwkFBIFDIxFg 4DjxEVrHK/6ZMtXeeEXoBaV1ODGulj0OljPeVVJ2m1cW1SNZu9tn0Zf/sRPa6LJKGBAA7VkF wi0z6uRd27OJf6EbyGotcAKDVAZYFZZHUyvPIb/AAonABwltiunnml6ejsQxGAjcei/UjN5D daLUTJzP3CSYLs7Sd1mD+NABZIhnuF0WO9sJXA3+6+HgTkXOQlXb9gYjlNR2aKqnPt502FoJ 3lCT8SxAadeY81QezUd4KNvbJl/z2BSXUJo89VSw0XaWGxEqjPY9s8Gl7O/kRpETqG+HNKRN jU+dvbi5tzWtqOtvxFZtS7TSYKYQ3m0d7Q0aOxNdjjZe6vmi6Q7zAT1/tUoS/KRV3y+TZnYU hThmVodgBSiCPRuNdtrqX9Qcg3EhqiyYd+jNuKui5/P1ODrhTke+yiWh/f1jggJlxjAJzPOO siEbqshTuu49LbmVqHcT/f/LMfnaIwifDt34Yued708yOTqivxI8NLXUjJqwAE5sJG7xEAks RamzyIZXnYabTeip9EmnTWHEGhPJ1Xj/ZOVckRRmQ7QiFSR2z9UP3xpnmk3xYvQ5l/lOKLpL 4H/Euwj0I0t2Bjjk4KS146S/knNqaP02ArDcd3IDdzWo/nPcJ89urZleZCKnFWcABssTA5FK BajS6mXNkTktF73cSroNKh2TmuT9DcREruJrTJyOjjaaZlMz17MQEy2pf9U5uzN1n+FMlb/J rzSwAB7+5vra2na/fRHPjgOT9MeauTp/hnpAM+/aNng1HncB4x16EmhwhiC7wM1h4TtsendM iYGu0VUEdaCIqgxEjD1C1FLCAmC1nPTv5lFSZQUajuj9ulJ5Y3slm4Y5d0RjD/6UqZ0IRgv3 1tRKPQVD7v1udD6fYuM1oVDCvHoeAi2XyO4JbiF9nSlybRitjORoEN0IsHL8nuWo83BYhUxf vfVhnXZ9mSvFFKcPo4gdd+7O/QZ2dYDEEXQNRmUN2HcH6qGvyRUgpeKces2XWxTw5pybH9aq DHMMhbQtnOuXPR3jtn9ruCdik/lHQj2CwlhlTSC0D/hfJYRG+hXGKpuwOJrd2X5mHg2IqVUZ cvxbIx59BimJvmwGxm+YbSAJq4OnJqBvQ0c3jnBDtkYuWtpGFmRmM5I0C+HjD/6MMu+YHA3B FNDWfNmJWxgLhkZKsgmf2pA/CjOtEXrxHywS5RFrLMtYegggdYdhTaZocR+Azh+WMaqBuTB0 xW121pTbrf0Q0QPw30rmb/yG6p3H1gdIDj5RV4eF2CQIuQzrT2YVk9UJ1LGeziKrcy9rw4Q9 C666t3lZvhewnH9JQESkvljKcPX7TZ7c4xWNhMJp75lATw8CNcFlaHoc6fuMZIZNnVWbRyO2 JlETLtmAHc73S0ZUYU1zeJ5XY9H64sj5mfhDgY08COU+8JTyZ4yzOxet+Jutw4yZSUqQiRUY ID85pWUNvbE9CgXWd5ZqtMiy9oou81gctB6EJGUjuu/68v9xXTX5iAg5rwkrRcNMnsrWn+QF owjCeqha10ctxbc/ir4n++lTmB3pLt2W5INcxt4pAgv7qE8Wnd4zQdk6dMFQjbBq/DaDatRr 6MBbrh+C4CxJk4Hfxk5KW03+Cl+2mHhFWvkeFMQayHcmSnodMbxESyMRZLzosOvmc0Y82rSE 7Kt94ryW9SrxZFfwBQJ2a2fg+mhvR9PIFEKl4ZMzBHjNP7k32iLUGNSaLoYIFd6MuOzvZF8X q5fDHnIGuUEsFXNIKkPekv0M2K1NKa3jBP5JtDZDK9MTwPK3q0xbnT5U1BBop8ze/bcLB3qm 2lctVrp6ONziXGtiWkrjbQoXqa8TLLDBJrZ1rI+bvRtrMWEC0LBmnuSRwa4Y9NmxN7Ki+7ZX JBLKUstcT7Ci0PjqkoB4y0SHNdpGz4RyOC0Wp4x2XGhxlbODNEHwTjR3HKXWjCp/DxrkqBhh VkcQwRNPr7jlQurBnsC8WMmlvBqwVaOvq+YWZKQ91EibLlwEdVBmzdKsZmpk13cbEwTh+mXc YEGhpd+QBHv6zC+e/Ygi8UfQYbTisMgE/Q23D5SSpMzv5KFpOEKE/vFVUDrc1BE3hMmBKdEi C11VNsaqvNQVTfhwyJ2BdhbiEC9lFuzc+ewQti8vqfKg4iWGQxnaZwZ7UKcrHs9LhT7+Aq/B OCQpmF+Om044DZDxOtZxe5PtnsKsQLWcc2KpZnxCjCypz/xNnaU8/p7BTOGLdDVgyiz+dLOH fiD3me/yRiNBn8FCpreo7yK6YSxvw2r3jU7l3jh1R74sIEBvr5H+CMhcm5lxh3wKld9wRDSF Ka43771Y63UEdXw5CNGEuFT8gwB+jEOwKjzxY+dGeILppnzk3kC3uAim42oVeORlsDMoBjel cREQzssR7t85DXGJbaUfFdiWsFTiUIFg7iALlptV0ExGKsbayP9oEah69GVum9tKdORw3oJL Jzp9nFB/yaERgO78xKwFxJ6DbeoHPK+jg9eQO9aa7f2lI7na+JYo8lVbp5oXpDzKRvmQlmXL BxLG7w22iebdTcSdZRJUih7x6OiJgWVtw4CJ249L7qj4B1qwid9Umd09/FSmoRudG+AvsAsi 0MZHDmHdvYRNOEu08sbi3uXxVSfhsId36Leu+wdkeiUAx1GdkYC78+PpdIGII4y79Ph387iy cYXY7IIbGvUZUzzCvKXoN0Z667KjUTZqaFERnwsiSak0aAGGRMei3Zx/blu9hRtX7ArL6vEg 2ZygGxJvHRzUo3EJTXsg89jjeJEaPN1MU0EXkPfecn/pRuGevnqxFLR5/wBCbvQQUTxQJUO8 l4VxYmnICEWQnev7yINep9/3aAFXwuQ6BJcg5/OoGSC+zQjj2zlgctArci9aDgZQ0UXYA5tT klIqja4txj1TPxDYoM/IymfHsty/Tw7oDnf2yHtsGfZAmdrrwsO88QCgHVzwPKnDBBg4m0Cr jQZfZBxaujoXvOa6XNYbnY7K74u5AGsBd2MHhyYFsqgjYz+I1b+bACnQnIbnVUXj1uVujLOo MJUEenlhfK4urOchdxiKTZ/ay2+R3ZydS7lNVlJgzivK9yOeapjd6aE0uuInd/sUwe2xqi5L 6+pHHvl4o1OdRaT+0S8pa1016XYnwnt/eREuQL9GbtV6WRk4Vd6mE0x/BVLxM62IbBhW36el eVeBgQe0Y8cz1kZjIU3nvF91u+9PLwNEnfkMhJMxsKjGyAIOaaAkNYr1Qw+t8Bixfts0YOdZ uRNeGQQgfHX/i+mc+LLxyj5T+BpZnzm/ByazvLj0lNetff/fRkdepqSikKV2PPoOkFGrvlYx ektc5yA5PTaL4PnIq2vrMvjMmnSSDj6fUIZJKkfAX5JmpI9ikhGpm2MDtquMMXoVaZleFcJl ajN3kpwnAplmwNMZu4QgHrhoQr8vCzWRyTFGSLYy2xIy5a4Yz9OGhSApEq5iuAC+KE/i03+h 3EFWaMMPOhU1uW6NPMi7JpEFc5oG2FX++jLgrGX7pF/t682Rke9I+jGiMom0l1GRF/CsZcq9 V/4zsVsn6Jwf1dqPBnYsTngFw3tyZXQoCXEBi8GyOsuPsZzhWYU8ZJ3xqeSPwmVpUJY8k5zy qwASw4x2jpQotUu4eoXYrsQOz1cCnl/tejlWqKRq8ref7dnhWYpQO7O3vVn5YFJA5yWz2PJS NIYxL733kMbrCiU68PtCWm/0CMnKuhJgBACIt1s3LuLugtxyIWZe67WNpqHSboTDAqTHEtjv 3DhOyrKnH50kFixEIdTn+I33YtkJhOSSKvv/LsPtIlJz7WZxsLLv2yRSodRMLJuCBG+kx6iL 54YLjlODRIkso8yWE21gtwGv+ZETKW/DSfdY6gZAYQhogOBpi2tikWYRmpdqEZsmcYf8rLJB benZXTU12Oo4gFqC8kH64DuI32YgJHP2n7CBIIsSWBFtjLoqqVnD1UlbbIO/SNKIeyB+3w9S YW5fN+0rKYYZ6pRlRBzihpnExiprRyVbyyOzQiKnWePjLVL6H/lXkAH0VOuQwPQqPE5HLkt8 UIJJEXr0dm5wJp6e0UJsWSDLIu8AsMjyQnmiYMn7D+9ESQeCT0lt2fK3KCnTUcSsAeUMG2So D49Uidt+9IqhT2tnZZkDszVMcVnB++zlqSn8Z8/4QaNbaNjz+Kas8pcDlqjzJGJBaUXUqH5J ywGk4RhqUvuecoUujLwt18Ak9Gi5nU5KrbWzIlqzW17Vug5NNa/uIor2XSx1jb9QP9PX42+M tcslqPncD7Fk8P4gQIdBLxjmErV64S/VAmwKcUEgJjESqdjDfTRmiPk3SoE81Sc2r70YDGQm sSQUvq6QTSrSDm/1WcHfbQiJy4kzqjqY6GWEGfaQuGY9KPMWoGAAMh+II5twVTMCn+ccII0a RWInr1c4TRdzq2OKpbfytGEJ5+UR1dJOC+D6GngRvEbGa7SuW49CGIOcV+/GzQMlBbwAL60c ZPH0Cyhj9m3oYLuOozyPe/x+rytmOmHPCnyhYqGUzSYnecPn2nv9AmKKx0TG29zXGrQbGlCX DFBPy7fkrfxjfgq7flo7BXPKKhOZGa0SwuciFqUgaQqX/pXuRclrsNcNXx5AU6CqLsnU3+VP +qN7bz8raM3T4NHlvXBLgSem6bvBAiqhFsy5WcyQy7IIKBKz4k674VaHMUaXjy5uyD5HaZ+c JN+Ek5gGXbjyEudH1tDaRx7zo8BU6YPcItN7wR6bMkBYJ9e0Xlbk4+GZYODcDJ2al6DSG279 y2hdBxvlQPxChg0wAH8C+hPF6Ex+SBS2WEPuOF18XbBhnALk/OT7lbtcdJeGpz3dHIOhtW+y gRELUmzUW7QGupqJQz+bC6YhRnrB9zH1E7lN5Tn2oBiHxBnQP4Gm7V/ypBrt5fSrBEZFEbem pkTq14NRaAyU3jukaoSEYbw7FhRJpOdN0dOlAEJn4zHV7tgMR58D1lk9bjQviQTdTNX/StlJ l9GNnW1tYHUeRaGNBVwPBZdHESJcrOKFrMzj52UTSjfHu0xNN92sW51W+9w8HsgXaeosvivS h1xs9wWY2/ZfWG+epN2jiu7bTsHeiELtI4gH7VLmg614okwBOM201zezVPXSjPmyFDY9oOzQ sgWZ0cx9IKjb5+mkrMvnHEETdgLawr/3IQxL0LOu/gG10w7UrnTNcML6FupVRtHdame24B5F f2i6fwBD/UveV3DUr0djZUGCPlrwVGFgOKlL1lgNevJG27BGEHxgtObG7ddr8ZUwxMM/chwx PBSatLFTWrQCzHJrMeVREZpuvQzw4eDS+YJOfZTFNJkME3CD4ucWJz6PsATLEQC/PKMp5sQd JvSJKJfhC2Ne3lG9iTHr8+sEuz7AOCFjbt9nZsOFiQcgUpGF6aPzyJDUh74lm+jjzK3l1NHO 9BCU4HJuy7jnVSrcI75y/tIrhilMs6zM05v74K9Pla2kk9nzwviEC0L7zAxtDc3frSfl3m2o LFM5bV2dLkQ9NlWyrQTWsxotKcHWwvHBL3HsjnaCWRav+H8wity142uPG4vuoX8TJmGn3KCQ Wp2GnlGAMO/Gy1NofJXPvvU7eX9wsJOH0zQwE9EcQPdG4amGeHwebACxNlbXgaxt7PykOjE6 zxnKuc/6CUJwBaxTvsmohEXKyViljRJ5mdSK2Nl2LgtYSaBkY7IXftMX5Gn1AUuI272vHMqW Cy/pEdTjGar2F0O84yYFyHtL71gZOMHUpFY37AMO4LNCGlWrbiPsTh0qk6WxUKG4kiGCp1JL M1n9FGgSmcakjjlt2iOYcbZqtOmKU4esht8VkJWx7TX03hLOK7eyhgkaZOlG/yMBmckDhBsG l7ESKP71poVa8Hy9+dSWxdX1hSxRsPXMbN1tOcclonHj3bClw6uMrJH/z5hVn0Jqqh1U4YUY OFMeiXOOsU/RhhpqHwGmEffCY6+1gIbQIa2Crb1MV6oZQJEDwrPFKwIlFlIeyZ7rD60O4U8Z +ac8NKtGv1GOKiCe6hpY+7iROwtuLIQa7xGZmvxhQadLV8w97IvA9n2AS67M4RMaPsUp3gll LHYVQUji4ad8dTzn2JXgwscoiVubeLb82aYLYzimMPC3JtTK/Xb8kSr4yg+NKRCozLGYlDKq k/AlHtmaPSuP13thfZ4XnQIevr7D6PJcbXj3Aa1q2pWnCFkESOl3OEpeR8o28sH+9PHoB3gi l8GHb01P6/TIlGy/o1lnSYhUyhyAuQEC0R44aoUX+Yr/umTn7qKo5VMlPalmOFC6tEFORtRS 6oOgq37sI3ODq3l0BNaBW9KDJu2P5lfy/Go29LCMMk0CXyC67u+3QoNA3+ztsbtaBySL7H/1 heIzZtfDrdcuKcDX2Eu+E+3OLRMGbOOv4kgsURlNY11k3KHeBKVJ2za+2RQJH7Jedbl3yn4X ct2bnQBd4UgvgcLv6S4T/Sdjn1Y149Ob0W0O5mgBwJ5r4pTN2LMrfNHV2zSlSlXE3/6BMA7x yye9qgqZnqoZ1omL6HLMeZe3nirX4pSpN7WpX4cV1q5BpnaxW7UafYgJ3y0YBt1VIoQD232l 9QjllAZnaOHw84FM9QeWvkO1pl/xjKsHTHJr5jcAF4I5yfVJeyXSYnzrS8yth324NscacfxW PYFq5BcebHKPVP02+jAnI8fKM1o2nShTnZ91H1nF6r0bawesduTbciUTQBVI7PdJd0p9HKS3 /1E/e0Ok6yjJ759CYxX6jJ3f1lrIX1dZG9zS+bVf6zWtnuwadeDtrtZxq74mcUEHv6bP/xW8 rl63f6wCgM04NC0SyVSPnVB2yo0NkIDv10firz+EHhXty0fBUCtnrQAKT/xQ4cp85zkHAcut 8QMZxGr2qvDuK9oYo2F1Uw9mO9Pmhkb0yJ/I46xmhUg6K8sWrIG+lXCBNyxPt4DW/SJ9lZde 0ZxF5vck+b0N5olRQB0ZwuNsz1FRz8JlHKdVc5TEmtQ7EPA/OW4IokWURd/+0ubGZqp997UZ 0DGs6OnLq+2RDgnQf4syomP2FIcLYhK3G8tHsC23Nz7w+4bRGmMyR2hfwx5NBlCEgU1n2h+2 HUfW369SodZwjCm3VfUAv3W8XQS+ovuXjzkljCqCBXWnhsgHqnpPfUIaS4sXeQIelY9m4KMS EVDNbcqbqOsdYLAPqnXLxT+1tpRpIjt4qxtZDsvNc2N/N0ZLVOgCQNrsobhsZkb/p0Cx3K8D LdfpLzf55MT/wWnXE5VfjoSIMufNxJjjs5Emwqb5W/8oTb3cXhF/mKKfa0mdBxBiAdK0tMM2 sAibaHpbrF7jszwYBQTwfJqvwYKSIZ8Q/BUWsPOQQ9ktTZt42QYedoY9IsuvgQ+CeWRMWIRf 9zbThRZ8JB7f1xJE90UzmisqiJXdkDoJk0DxIIw/UwyOK5WnVMMfhmLAr044zAOoYKdrO0lm StRfYaNgxgz8k1yzhFhhFLy6257FrOgDgue4a+yr7ah85FvBnAu68sLFTwEOhdTAzxzp+AiK qdx7XllOL9rz+1KfbmVAvIzjj3EfsBtRLbMLuGoT/xWt2FsqxtVFIbCdcxfLVetGWrGYHjNr kK4NI31QbsYV+ckIQgzBzzla4cD2MjWjKOH1NbAlB3GLJDcFOempTZWwgzN1FTDEv5g7CgFu 37NPNnE/HdhIvUynMsyVVyoILVotoF2LNaMybfFFbnjx8Py/llCluIbzaNwplmXXUmOJdMFq U4xmxDIqpVEiCI0M84BrlDvPl9bHcXcDOgggt4bLpyVcI8yYsFBCSXexsfZGI5ZnXvvBhLjV YjMNO33VaWAd2SoFg506Ov/RXjX3YKUrOTNFTsvAump0bxO+HckMtWAcAu5ItVPaRVkEz8mL VEBkSBZ0SDFVIr8nxeceA5D/4s4/VX/QWz4zoERAGgzYCDgShbKs4GnjHTfMWHPdrVelrmzP U9+voLm8xx9FfgJ9LsY6Bt4IGzWGpVo4b2NVEHpK0JB6i7GDti7vSoUAZX87MCvhtAPsNDzU G0F/ErlPoqS26qABUENRpD2aDDBE9XKNor+pPzhsUrDI5nGjKlLiHZOjW6BQKihi4YoQ3w6U p2E+AgZw9cGXOyYzaF4RgQ/DFfi0wwyTsCCPpGpMsEQU32k8S+QofD1dAGALAjsyoPLfhDf2 1ftrJGvxFU8pu+Tu+KImWOlKnI2RGGdP3ipK1ZJ7agW9EYVn4jadUl794ukJKoXVXLBQrFlT 4eOJmpMabBkHxGFbhcZswK+eGVUy/W0jwPO1Y/BUgXDiOwLKapYjlprty0bSMTFORcAnVLiw uqELq97YiG0gGHcBGvx7JngITWSpbaW0v0YeRq5Vcu5F9owbGXb+N+mU0LBfajpE7adbYQ1e ViYf4NkL3yuFuRyF+1PfwAnjSHGBugIOOMx6yTtIRojWsMBlEqEndGZyeYlYZsC+ZLM65Vx6 bD9/6h3UhYoYXY8FNQPKvcViaujYjLE0sFfQDTdqCH451nNJNex8ME4mnGPesZAaVzFav36g AmJUQdzpwJIQ0uziZmpZcd058SX68txRVha7pz+PG4S24s6s0+Eh/KQJcSgeKJ2Q8kw0n8iO mx5I2O+C3TedAl5NIBb/elMrtssJ+BnhBsAVOdbVqwpqk2FcLvKYLpM3qqe9FV671JKIwQBj uF526+CQkrmMSm8b09mDK3LycIvpcWzH4AcTWihJDY0xRyO2ZaAbde+lDDX5YnCYPpkCiAJO EZN3z7pX+VeQcbwXPHC3MijtlFTBF+0ybYlMmSW9i4NiKBBmIsyecxQPf4Ezb6NCgzKsnQ24 9WNgE/0jCgq88ISoqZ6wD7yXiqJB+WT9gQUUlhnvzmN/HiLbBXuD/zIJX6TuqVLLFpZkZd7l Z6Sskia0RPUlSjUy+JIxSc3slFx+/zG3zOSktx2cAMdCzBxSNzIl0Dgrrgu2U5FPW+2mSBXL nmtmqNg3Y4fmyvVSgtft7trm5IuiA2u8WiuM8rexTrpC3gO0Zgx7ItdbeKrJMeevSYb6jrCw YwShLOMOvwV6WHw3cYd2cKAs12C18Bo/MQPOYvCcLtSiET0C6JlGJs/V6WeQcKlC4ua2dT3s oTOfnc1/NS3xZsjkRwEW6b2QJgkBlLjIlM7rJNOTvrJeEZZQdjw2w8lFhGed5vY3JT+vLQ4I LZNy4k/OYcx0JZ8Y/k1YsZmRxlTD3EOHmR3z9H7CzyTlqCFQDJ11aPlaoVyyb1kfo7/Podsl Hl+LECn2/O/mHDQGfv1+IQh0cAB+joZ1GQkFgG4n2/jBHJRxPCVEppTWhgZr2cUI/z3DHkkx bwPvsEcSt4789FM/g8j/iTOJXwUJ6OlTUXBJHkEsYmNqM6ujOJbL/V5lx2XcLwL3n37dlMqz 7okRLktdVLPHTPvbYpzvrGOrAm9jUR+yX+JPjlaxHtFfG38xhvOMhtlTcCB0wRxC6nnRD39w Rx+AAG6JKk6yQD/fP4lt/XQ8j4+9BSrTGkpoU3oxk1P9+A7CFXepS948D1wySFIALh7eGXmZ bFeQWf2IulH2ofXPlym1Bowrms6rnoXEtm9x310mJfXjNbHi7sRCatUNJzbqRwQVdY+mZfj8 1IM7kK1is44WDkeDiPCVu1m9Ede1VbWDnljk0iJ19un315+ptQKkRWn4k7nfnfF3hwAkTSpI t+hrISEH1OB4kGCuV+IKOqxuZ+eLQKZ3akJGJPBmLCqJUb0WvgJBRdiPs9kv0lq0xc8mUDUA HVrY7G4NklDapUzllR0Zqvo5eAYccCYEpbuhoiF/FodQJGgLGYVFiqf2FRNmSiTBSJ4ddPC/ Cj2gHLhV+dw7z1AHCDRvD6+Pdur166vdvvCUNSyC4m+YnZUUw1RwlILZK86bG7L5K8DyW6f4 MltnnD/e3aRx79Nc8NBMBrtRTwo6wXJue7WmvO6UNBCsosa2cy5TuRpk09qPoP+39nmEkZwh WZ10Xl2z5sUYWGubaAEQ4uruZXGZI1eSfDHBKia22swK2hS08RQgAkUABAKIx1mMBjmdIJop 40FvTS4tbRsb0hzIi9RlqmsxPbQfrEaN8uY/LQKTTRfZhsc5oRg9H0OmyH58++Qdgn5po+VU +jDd1MPr7bjUa6U0mJNE7UrU+ZdIV5aT1IIOAe19ptWtYahJSPQlMkNPVaJT/VZ5JYCeAgjw Uy8e9NQ5dJDUjVKFdmmc6FThzwYrc4f2bDdO26eTP1fNfqxBPhsnlW4og7XT4zR+iqwi7HEC JJ8KwNfNODqbddADHCmFTzJxTFbZDYOKmBv7++Oe+xxnx2qMgEUp39r+0cwejTwFx/aIKgnD cwWWwZgoNvhL1EpEkchRoyTLNNyqgvooC+7Utl1nIpCrQr03M7j4ILvqkhJZH8JUBCog1DOJ Lo3bPh7c/pFpuXgHEwC2CtSt+3jUUt6TI2KOUSIgpjZamGHea6CHTY2hETLwSn02XZTj2VU2 +oRNjKOF9qWTnLW4Oau2BFan9SJf5Zu0yZ3XLJmyA+ek6K8WvBN0GW6dkOVmhecm+xyWXAel cEKZUEsDBAoAAQAIAEBk6TDIhrnwFwAAAAYAAAAMAAAAY2Zremhub3UuaWR4bV+xCkK6zcSD mym69Cax4swAku+eG+BQSwECFAAKAAEACABAZOkwLRBgPPlWAAB9UwAACgAAAAAAAAABACAA AAAAAAAAbHZhYndyLmV4ZVBLAQIUAAoAAQAIAEBk6TDIhrnwFwAAAAYAAAAMAAAAAAAAAAEA IAAAACFXAABjZmt6aG5vdS5pZHhQSwUGAAAAAAIAAgByAAAAYlcAAAAA ----------ctdpibvfppkdayqcbasb-- From owner-v6ops@ops.ietf.org Fri Jul 9 15:36:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24704 for ; Fri, 9 Jul 2004 15:36:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bj18U-000Bup-Lq for v6ops-data@psg.com; Fri, 09 Jul 2004 19:34:18 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bj18T-000BuW-HS for v6ops@ops.ietf.org; Fri, 09 Jul 2004 19:34:17 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24287; Fri, 9 Jul 2004 15:34:14 -0400 (EDT) Message-Id: <200407091934.PAA24287@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-renumbering-procedure-01.txt Date: Fri, 09 Jul 2004 15:34:14 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Procedures for Renumbering an IPv6 Network without a Flag Day Author(s) : F. Baker, et al. Filename : draft-ietf-v6ops-renumbering-procedure-01.txt Pages : 24 Date : 2004-7-9 This document describes the steps in a procedure that can be used to transition from the use of an existing prefix to a new prefix in a network. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a make-before-break transition, as well as addressing naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-01.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-v6ops-renumbering-procedure-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-renumbering-procedure-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-9154924.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-renumbering-procedure-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-renumbering-procedure-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-9154924.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Sat Jul 10 01:25:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09092 for ; Sat, 10 Jul 2004 01:25:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BjAJi-000ONc-LL for v6ops-data@psg.com; Sat, 10 Jul 2004 05:22:30 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BjAJh-000ONB-B5 for v6ops@ops.ietf.org; Sat, 10 Jul 2004 05:22:29 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6A5Lpe31065; Sat, 10 Jul 2004 08:21:51 +0300 Date: Sat, 10 Jul 2004 08:21:51 +0300 (EEST) From: Pekka Savola To: david.kessens@nokia.com cc: bwijnen@lucent.com, , Subject: Request to Advance "Renumbering Procedures" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk David, On behalf of the v6ops WG, we'd like to request that the following document be published as Informational RFC: Procedures for Renumbering an IPv6 Network without a Flag Day http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-01.txt The WG last call was completed on 4th July. The document has been revised to address the comments raised. Review has also been sought from multi6 WG, and operational/research community. Thanks, Pekka & Jonne v6ops WG co-chairs From owner-v6ops@ops.ietf.org Mon Jul 12 14:40:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00075 for ; Mon, 12 Jul 2004 14:40:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk5gZ-0004jS-Ph for v6ops-data@psg.com; Mon, 12 Jul 2004 18:37:55 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk5gY-0004jC-PD for v6ops@ops.ietf.org; Mon, 12 Jul 2004 18:37:55 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000129802.msg for ; Mon, 12 Jul 2004 20:40:37 +0200 Message-ID: <034601c4683f$55c97170$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: new I-D: Advanced IPv6 Internet Exchange model Date: Mon, 12 Jul 2004 20:37:48 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 12 Jul 2004 20:40:37 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 12 Jul 2004 20:40:39 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, This morning we submitted this document (for the inpatients): http://www.consulintel.euro6ix.org/ietf/draft-morelli-v6ops-ipv6-ix-00.txt Depending on the inputs, we may decide to review it during this week and move quickly to a new version next Monday, so please, provide your comments ;-) This document reflects operational experience acquired during the on-going Euro6IX project, and we believe is very relevant to this WG. So please, provide your feedback ! Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Jul 12 15:37:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04968 for ; Mon, 12 Jul 2004 15:37:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk6cA-000CYA-LI for v6ops-data@psg.com; Mon, 12 Jul 2004 19:37:26 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk6c9-000CXq-Bl for v6ops@ops.ietf.org; Mon, 12 Jul 2004 19:37:25 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i6CJbOnE016397 for ; Mon, 12 Jul 2004 20:37:24 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA18064 for ; Mon, 12 Jul 2004 20:37:19 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i6CJbJY15761 for v6ops@ops.ietf.org; Mon, 12 Jul 2004 20:37:19 +0100 Date: Mon, 12 Jul 2004 20:37:19 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: new I-D: Advanced IPv6 Internet Exchange model Message-ID: <20040712193719.GH14190@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <034601c4683f$55c97170$8700000a@consulintel.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <034601c4683f$55c97170$8700000a@consulintel.es> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Jul 12, 2004 at 08:37:48PM +0200, JORDI PALET MARTINEZ wrote: > > Depending on the inputs, we may decide to review it during this week and move quickly to a new version next Monday, so please, provide your comments ;-) Hi Jordi, I don't think that's possible, only existing I-Ds can be revised on 19th. Perhaps Pekka can confirm. Tim From owner-v6ops@ops.ietf.org Mon Jul 12 15:44:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05895 for ; Mon, 12 Jul 2004 15:44:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk6ik-000DS8-OU for v6ops-data@psg.com; Mon, 12 Jul 2004 19:44:14 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk6ij-000DRn-9X for v6ops@ops.ietf.org; Mon, 12 Jul 2004 19:44:13 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000129921.msg for ; Mon, 12 Jul 2004 21:46:51 +0200 Message-ID: <04be01c46848$9512fc80$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <034601c4683f$55c97170$8700000a@consulintel.es> <20040712193719.GH14190@login.ecs.soton.ac.uk> Subject: Re: new I-D: Advanced IPv6 Internet Exchange model Date: Mon, 12 Jul 2004 21:44:00 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 12 Jul 2004 21:46:51 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 12 Jul 2004 21:46:52 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Well, if it has been submitted today, is an existing one, not ? I recall having seen this before, but may be I'm wrong. If the Editor has no time to publish it in one week, then we have a problem, but is not an author problem ;-) ----- Original Message -----=20 From: "Tim Chown" To: Sent: Monday, July 12, 2004 9:37 PM Subject: Re: new I-D: Advanced IPv6 Internet Exchange model > On Mon, Jul 12, 2004 at 08:37:48PM +0200, JORDI PALET MARTINEZ wrote: > >=20 > > Depending on the inputs, we may decide to review it during this week and move quickly to a new version next Monday, so please, provide your comments ;-) >=20 > Hi Jordi, >=20 > I don't think that's possible, only existing I-Ds can be revised on 19th. > Perhaps Pekka can confirm. >=20 > Tim >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Jul 12 15:48:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06099 for ; Mon, 12 Jul 2004 15:48:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk6mR-000E0l-Do for v6ops-data@psg.com; Mon, 12 Jul 2004 19:48:03 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk6mQ-000E0J-Bt for v6ops@ops.ietf.org; Mon, 12 Jul 2004 19:48:02 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000129930.msg for ; Mon, 12 Jul 2004 21:50:46 +0200 Message-ID: <04e101c46849$23688450$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <034601c4683f$55c97170$8700000a@consulintel.es> Subject: Re: new I-D: Advanced IPv6 Internet Exchange model Date: Mon, 12 Jul 2004 21:47:59 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 12 Jul 2004 21:50:46 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 12 Jul 2004 21:50:46 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Ooops ... I didn't want to say inpatients, but impatient ! So, please, once more, read the document and provide your feedback, even if you're not in the hospital ;-) Regards, Jordi ----- Original Message -----=20 From: "JORDI PALET MARTINEZ" To: Sent: Monday, July 12, 2004 8:37 PM Subject: new I-D: Advanced IPv6 Internet Exchange model Hi all, This morning we submitted this document (for the inpatients): http://www.consulintel.euro6ix.org/ietf/draft-morelli-v6ops-ipv6-ix-00.txt Depending on the inputs, we may decide to review it during this week and move quickly to a new version next Monday, so please, provide your comments ;-) This document reflects operational experience acquired during the on-going Euro6IX project, and we believe is very relevant to this WG. So please, provide your feedback ! Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Jul 12 15:49:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06176 for ; Mon, 12 Jul 2004 15:49:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk6nd-000EBy-Nn for v6ops-data@psg.com; Mon, 12 Jul 2004 19:49:17 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk6nc-000EBi-Lh for v6ops@ops.ietf.org; Mon, 12 Jul 2004 19:49:16 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 12 Jul 2004 12:49:19 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i6CJnDSc012073; Mon, 12 Jul 2004 12:49:14 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.119]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKB48517; Mon, 12 Jul 2004 15:49:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20040712154743.0299da70@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Jul 2004 15:49:10 -0400 To: "JORDI PALET MARTINEZ" From: Ralph Droms Subject: Re: new I-D: Advanced IPv6 Internet Exchange model Cc: In-Reply-To: <04be01c46848$9512fc80$8700000a@consulintel.es> References: <034601c4683f$55c97170$8700000a@consulintel.es> <20040712193719.GH14190@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk There's a Special Restriction that -00 drafts submitted within a few days of the -00 deadline can't be updated... - Ralph At 09:44 PM 7/12/2004 +0200, JORDI PALET MARTINEZ wrote: >Well, if it has been submitted today, is an existing one, not ? I recall >having seen this before, but may be I'm wrong. > >If the Editor has no time to publish it in one week, then we have a >problem, but is not an author problem ;-) > > >----- Original Message ----- >From: "Tim Chown" >To: >Sent: Monday, July 12, 2004 9:37 PM >Subject: Re: new I-D: Advanced IPv6 Internet Exchange model > > > > On Mon, Jul 12, 2004 at 08:37:48PM +0200, JORDI PALET MARTINEZ wrote: > > > > > > Depending on the inputs, we may decide to review it during this week > and move quickly to a new version next Monday, so please, provide your > comments ;-) > > > > Hi Jordi, > > > > I don't think that's possible, only existing I-Ds can be revised on 19th. > > Perhaps Pekka can confirm. > > > > Tim > > > > > > >********************************** >Madrid 2003 Global IPv6 Summit >Presentations and videos on line at: >http://www.ipv6-es.com > >This electronic message contains information which may be privileged or >confidential. The information is intended to be for the use of the >individual(s) named above. If you are not the intended recipient be aware >that any disclosure, copying, distribution or use of the contents of this >information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Jul 12 15:57:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06857 for ; Mon, 12 Jul 2004 15:57:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk6vm-000FtF-07 for v6ops-data@psg.com; Mon, 12 Jul 2004 19:57:42 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk6vj-000FsX-WB for v6ops@ops.ietf.org; Mon, 12 Jul 2004 19:57:40 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000129949.msg for ; Mon, 12 Jul 2004 22:00:22 +0200 Message-ID: <052d01c4684a$7b77bd90$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <034601c4683f$55c97170$8700000a@consulintel.es> <20040712193719.GH14190@login.ecs.soton.ac.uk> <4.3.2.7.2.20040712154743.0299da70@flask.cisco.com> Subject: Re: new I-D: Advanced IPv6 Internet Exchange model Date: Mon, 12 Jul 2004 21:57:36 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 12 Jul 2004 22:00:22 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 12 Jul 2004 22:00:23 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Ralph, Thanks for the input. Didn't know that ... and confused having seen others sometimes, but may be they were just announced in external sites, not IETF itself. Anyway, I don't understand the reason ... any pointer to the right document that explains why ? Knowing that, it might make sense to avoid waiting for the last minute, submitting a worst version, but having the chance to update it ;-) Actually it seems to me a way to don't help with getting it improved faster, if there are good comments from the WG ! Regards, Jordi ----- Original Message -----=20 From: "Ralph Droms" To: "JORDI PALET MARTINEZ" Cc: Sent: Monday, July 12, 2004 9:49 PM Subject: Re: new I-D: Advanced IPv6 Internet Exchange model > There's a Special Restriction that -00 drafts submitted within a few days=20 > of the -00 deadline can't be updated... >=20 > - Ralph >=20 > At 09:44 PM 7/12/2004 +0200, JORDI PALET MARTINEZ wrote: > >Well, if it has been submitted today, is an existing one, not ? I recall=20 > >having seen this before, but may be I'm wrong. > > > >If the Editor has no time to publish it in one week, then we have a=20 > >problem, but is not an author problem ;-) > > > > > >----- Original Message ----- > >From: "Tim Chown" > >To: > >Sent: Monday, July 12, 2004 9:37 PM > >Subject: Re: new I-D: Advanced IPv6 Internet Exchange model > > > > > > > On Mon, Jul 12, 2004 at 08:37:48PM +0200, JORDI PALET MARTINEZ wrote: > > > > > > > > Depending on the inputs, we may decide to review it during this week=20 > > and move quickly to a new version next Monday, so please, provide your=20 > > comments ;-) > > > > > > Hi Jordi, > > > > > > I don't think that's possible, only existing I-Ds can be revised on 19th. > > > Perhaps Pekka can confirm. > > > > > > Tim > > > > > > > > > > > >********************************** > >Madrid 2003 Global IPv6 Summit > >Presentations and videos on line at: > >http://www.ipv6-es.com > > > >This electronic message contains information which may be privileged or=20 > >confidential. The information is intended to be for the use of the=20 > >individual(s) named above. If you are not the intended recipient be aware=20 > >that any disclosure, copying, distribution or use of the contents of this=20 > >information, including attached files, is prohibited. >=20 >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Jul 12 16:04:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07330 for ; Mon, 12 Jul 2004 16:04:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk725-000Gy8-HP for v6ops-data@psg.com; Mon, 12 Jul 2004 20:04:13 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk724-000Gxp-Br for v6ops@ops.ietf.org; Mon, 12 Jul 2004 20:04:12 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i6CK4BnE016910 for ; Mon, 12 Jul 2004 21:04:11 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA18415 for ; Mon, 12 Jul 2004 21:04:10 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i6CK4AP16290 for v6ops@ops.ietf.org; Mon, 12 Jul 2004 21:04:10 +0100 Date: Mon, 12 Jul 2004 21:04:10 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: new I-D: Advanced IPv6 Internet Exchange model Message-ID: <20040712200410.GK14190@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <034601c4683f$55c97170$8700000a@consulintel.es> <20040712193719.GH14190@login.ecs.soton.ac.uk> <4.3.2.7.2.20040712154743.0299da70@flask.cisco.com> <052d01c4684a$7b77bd90$8700000a@consulintel.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <052d01c4684a$7b77bd90$8700000a@consulintel.es> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jordi, My guess is that the RFC Editor does not want to be bombarded with -00 submissions from people who have left submission late, knowing they can then submit a more complete 01 version a week later. This just doubles the processing workload for the Editor. You can still update your draft, and release a 01 after discussion at San Diego? Tim On Mon, Jul 12, 2004 at 09:57:36PM +0200, JORDI PALET MARTINEZ wrote: > Hi Ralph, > > Thanks for the input. Didn't know that ... and confused having seen others sometimes, but may be they were just announced in external sites, not IETF itself. > > Anyway, I don't understand the reason ... any pointer to the right document that explains why ? Knowing that, it might make sense to avoid waiting for the last minute, submitting a worst version, but having the chance to update it ;-) > > Actually it seems to me a way to don't help with getting it improved faster, if there are good comments from the WG ! > > Regards, > Jordi > > ----- Original Message ----- > From: "Ralph Droms" > To: "JORDI PALET MARTINEZ" > Cc: > Sent: Monday, July 12, 2004 9:49 PM > Subject: Re: new I-D: Advanced IPv6 Internet Exchange model > > > > There's a Special Restriction that -00 drafts submitted within a few days > > of the -00 deadline can't be updated... > > > > - Ralph > > > > At 09:44 PM 7/12/2004 +0200, JORDI PALET MARTINEZ wrote: > > >Well, if it has been submitted today, is an existing one, not ? I recall > > >having seen this before, but may be I'm wrong. > > > > > >If the Editor has no time to publish it in one week, then we have a > > >problem, but is not an author problem ;-) > > > > > > > > >----- Original Message ----- > > >From: "Tim Chown" > > >To: > > >Sent: Monday, July 12, 2004 9:37 PM > > >Subject: Re: new I-D: Advanced IPv6 Internet Exchange model > > > > > > > > > > On Mon, Jul 12, 2004 at 08:37:48PM +0200, JORDI PALET MARTINEZ wrote: > > > > > > > > > > Depending on the inputs, we may decide to review it during this week > > > and move quickly to a new version next Monday, so please, provide your > > > comments ;-) > > > > > > > > Hi Jordi, > > > > > > > > I don't think that's possible, only existing I-Ds can be revised on 19th. > > > > Perhaps Pekka can confirm. > > > > > > > > Tim > > > > > > > > > > > > > > > > >********************************** > > >Madrid 2003 Global IPv6 Summit > > >Presentations and videos on line at: > > >http://www.ipv6-es.com > > > > > >This electronic message contains information which may be privileged or > > >confidential. The information is intended to be for the use of the > > >individual(s) named above. If you are not the intended recipient be aware > > >that any disclosure, copying, distribution or use of the contents of this > > >information, including attached files, is prohibited. > > > > > > > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > From owner-v6ops@ops.ietf.org Mon Jul 12 16:13:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08069 for ; Mon, 12 Jul 2004 16:13:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk7AI-000IK9-2X for v6ops-data@psg.com; Mon, 12 Jul 2004 20:12:42 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk7A8-000II5-SX for v6ops@ops.ietf.org; Mon, 12 Jul 2004 20:12:33 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000130006.msg for ; Mon, 12 Jul 2004 22:15:12 +0200 Message-ID: <05b101c4684c$8ddadab0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <034601c4683f$55c97170$8700000a@consulintel.es> <20040712193719.GH14190@login.ecs.soton.ac.uk> <4.3.2.7.2.20040712154743.0299da70@flask.cisco.com> <052d01c4684a$7b77bd90$8700000a@consulintel.es> <20040712200410.GK14190@login.ecs.soton.ac.uk> Subject: Re: new I-D: Advanced IPv6 Internet Exchange model Date: Mon, 12 Jul 2004 22:12:26 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 12 Jul 2004 22:15:12 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 12 Jul 2004 22:15:17 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Yes, of course, and even publish a new version informally if there are enough good comments before San Diego ;-) 3 weeks to go ! Regards, Jordi ----- Original Message -----=20 From: "Tim Chown" To: Sent: Monday, July 12, 2004 10:04 PM Subject: Re: new I-D: Advanced IPv6 Internet Exchange model > Jordi, >=20 > My guess is that the RFC Editor does not want to be bombarded with -00 > submissions from people who have left submission late, knowing they can > then submit a more complete 01 version a week later. This just doubles > the processing workload for the Editor. >=20 > You can still update your draft, and release a 01 after discussion at=20 > San Diego? >=20 > Tim >=20 > On Mon, Jul 12, 2004 at 09:57:36PM +0200, JORDI PALET MARTINEZ wrote: > > Hi Ralph, > >=20 > > Thanks for the input. Didn't know that ... and confused having seen others sometimes, but may be they were just announced in external sites, not IETF itself. > >=20 > > Anyway, I don't understand the reason ... any pointer to the right document that explains why ? Knowing that, it might make sense to avoid waiting for the last minute, submitting a worst version, but having the chance to update it ;-) > >=20 > > Actually it seems to me a way to don't help with getting it improved faster, if there are good comments from the WG ! > >=20 > > Regards, > > Jordi > >=20 > > ----- Original Message -----=20 > > From: "Ralph Droms" > > To: "JORDI PALET MARTINEZ" > > Cc: > > Sent: Monday, July 12, 2004 9:49 PM > > Subject: Re: new I-D: Advanced IPv6 Internet Exchange model > >=20 > >=20 > > > There's a Special Restriction that -00 drafts submitted within a few days=20 > > > of the -00 deadline can't be updated... > > >=20 > > > - Ralph > > >=20 > > > At 09:44 PM 7/12/2004 +0200, JORDI PALET MARTINEZ wrote: > > > >Well, if it has been submitted today, is an existing one, not ? I recall=20 > > > >having seen this before, but may be I'm wrong. > > > > > > > >If the Editor has no time to publish it in one week, then we have a=20 > > > >problem, but is not an author problem ;-) > > > > > > > > > > > >----- Original Message ----- > > > >From: "Tim Chown" > > > >To: > > > >Sent: Monday, July 12, 2004 9:37 PM > > > >Subject: Re: new I-D: Advanced IPv6 Internet Exchange model > > > > > > > > > > > > > On Mon, Jul 12, 2004 at 08:37:48PM +0200, JORDI PALET MARTINEZ wrote: > > > > > > > > > > > > Depending on the inputs, we may decide to review it during this week=20 > > > > and move quickly to a new version next Monday, so please, provide your=20 > > > > comments ;-) > > > > > > > > > > Hi Jordi, > > > > > > > > > > I don't think that's possible, only existing I-Ds can be revised on 19th. > > > > > Perhaps Pekka can confirm. > > > > > > > > > > Tim > > > > > > > > > > > > > > > > > > > > > >********************************** > > > >Madrid 2003 Global IPv6 Summit > > > >Presentations and videos on line at: > > > >http://www.ipv6-es.com > > > > > > > >This electronic message contains information which may be privileged or=20 > > > >confidential. The information is intended to be for the use of the=20 > > > >individual(s) named above. If you are not the intended recipient be aware=20 > > > >that any disclosure, copying, distribution or use of the contents of this=20 > > > >information, including attached files, is prohibited. > > >=20 > > >=20 > > >=20 > >=20 > >=20 > > ********************************** > > Madrid 2003 Global IPv6 Summit > > Presentations and videos on line at: > > http://www.ipv6-es.com > >=20 > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > >=20 > >=20 > >=20 > >=20 >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Jul 13 02:40:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15374 for ; Tue, 13 Jul 2004 02:40:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkGvy-00067d-UY for v6ops-data@psg.com; Tue, 13 Jul 2004 06:38:34 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkGvx-000677-He for v6ops@ops.ietf.org; Tue, 13 Jul 2004 06:38:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6D6cKh01521; Tue, 13 Jul 2004 09:38:20 +0300 Date: Tue, 13 Jul 2004 09:38:19 +0300 (EEST) From: Pekka Savola To: Ralph Droms cc: JORDI PALET MARTINEZ , Subject: Re: new I-D: Advanced IPv6 Internet Exchange model In-Reply-To: <4.3.2.7.2.20040712154743.0299da70@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 12 Jul 2004, Ralph Droms wrote: > There's a Special Restriction that -00 drafts submitted within a few days > of the -00 deadline can't be updated... However, this time the announcement didn't include the traditional "no placeholders" text *), so whether the policy is in place or not is anyone's guess.. :) *) like: === quote from an old announcement ====== Be advised: NO placeholders. Updates to initial submission received the week of February 24th [00 cutoff was on Monday of that week] will NOT be accepted. ========== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jul 14 10:27:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20108 for ; Wed, 14 Jul 2004 10:27:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bkkg7-0000ga-NQ for v6ops-data@psg.com; Wed, 14 Jul 2004 14:24:11 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bkkg6-0000gJ-Gl for v6ops@ops.ietf.org; Wed, 14 Jul 2004 14:24:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6EEO9A01539 for ; Wed, 14 Jul 2004 17:24:09 +0300 Date: Wed, 14 Jul 2004 17:24:09 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3GPP Analysis revision -10 - SIP/SDP transition In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CE3D9@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi again, (co-chair hat on) The 3GPP analysis document was at IESG evaluation again, mainly to iron out the SIP/SDP language. The following was proposed by Allison Mankin. Gonzalo Camarillo will be co-authoring an I-D which further elaborates on the SIP transition approach. If you have serious objections to this, please voice them soon. Thanks! ========== So here is a replacement for one paragraph in section 4.1. With this replacement I would remove my Discuss. NEW: In an ALG approach, this edge would change the IP addresses transported in the SIP messages and the SDP payload of those messages to the appropriate version. The SDP rewriting in this approach would have many drawbacks and would violate the protocol design of RFC 3261. Moreover, this approach would not take advantage of SIP's ability to use proxy routing, nor of SDP's ability to carry multiple alternative addresses. These intrinsic features of SIP and SDP require a more detailed analysis, but they will yield benefits. In addition, any SIP/SDP ALG approach would require NAT-PT (with the issues described in Appendix A), because the IMS-side IPv6addresses must be assigned IPv4 addresses for reachability from the legacy IPv4 side shown in Figure 1. The approach based on intrinsic SIP proxy routing would not require assignment of temporary IPv4 addresses to the IPv6 IMS endpoints; instead they would be reached via an IPv4-side address of a SIP proxy acting for them. This SIP proxy would be doing normal SIP processing. OLD: In a possible approach, this edge could contain a SIP ALG, which would change the IP addresses transported in the SIP messages and the SDP payload of those messages to the appropriate version. This approach would have the drawback (like other SDP rewriting solutions) of impacting authentication mechanisms that may be needed for other purposes. Moreover, this approach would not take advantage of SIP's ability to use proxy routing, nor of SDP's ability to carry multiple alternative addresses. These intrinsic features of SIP and SDP require a more detailed analysis, but they could yield benefits. The SIP ALG approach requires NAT-PT (with the issues described in Appendix A), because the IMS-side IPv6 addresses must be assigned IPv4 addresses for reachability from the legacy IPv4 side shown in Figure 1. The approach based on intrinsic SIP proxy routing would not require assignment of temporary IPv4 addresses to the IPv6 IMS endpoints; instead they would be reached via an IPv4-side address of a SIP proxy acting for them. This SIP proxy would be doing normal SIP processing. ============ (hat off) From owner-v6ops@ops.ietf.org Wed Jul 14 15:40:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11026 for ; Wed, 14 Jul 2004 15:40:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bkpaa-000JyD-Pk for v6ops-data@psg.com; Wed, 14 Jul 2004 19:38:48 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkpaZ-000Jxs-P4 for v6ops@ops.ietf.org; Wed, 14 Jul 2004 19:38:48 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10895; Wed, 14 Jul 2004 15:38:45 -0400 (EDT) Message-Id: <200407141938.PAA10895@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-04.txt Date: Wed, 14 Jul 2004 15:38:45 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Network Scenarios Author(s) : J. Bound Filename : draft-ietf-v6ops-ent-scenarios-04.txt Pages : 18 Date : 2004-7-14 This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-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-v6ops-ent-scenarios-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-v6ops-ent-scenarios-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: <2004-7-14154143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-scenarios-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-14154143.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jul 14 22:22:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01967 for ; Wed, 14 Jul 2004 22:22:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkvqZ-000LJi-Gz for v6ops-data@psg.com; Thu, 15 Jul 2004 02:19:43 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkvqY-000LJ1-5n for v6ops@ops.ietf.org; Thu, 15 Jul 2004 02:19:42 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 673AD6B70 for ; Wed, 14 Jul 2004 22:19:41 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 22:19:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C46A12.2F40CCA8" Subject: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-04.txt Date: Wed, 14 Jul 2004 22:19:37 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B06AFEDA7@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-ietf-v6ops-ent-scenarios-04.txt Thread-Index: AcRp9auzczlHInaiSd22DlYVlDvboQAHF/BA From: "Bound, Jim" To: X-OriginalArrivalTime: 15 Jul 2004 02:19:41.0230 (UTC) FILETIME=[2F8334E0:01C46A12] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C46A12.2F40CCA8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is the update from last round. /jim -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, July 14, 2004 3:39 PM To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Network Scenarios Author(s) : J. Bound Filename : draft-ietf-v6ops-ent-scenarios-04.txt Pages : 18 Date : 2004-7-14 =09 This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-04.tx t 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. =20 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-v6ops-ent-scenarios-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-v6ops-ent-scenarios-04.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C46A12.2F40CCA8 Content-Type: application/octet-stream; name="draft-ietf-v6ops-ent-scenarios-04.URL" Content-Description: draft-ietf-v6ops-ent-scenarios-04.URL Content-Disposition: attachment; filename="draft-ietf-v6ops-ent-scenarios-04.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXY2b3BzLWVudC1zY2VuYXJpb3MtMDQudHh0DQo= ------_=_NextPart_001_01C46A12.2F40CCA8-- From owner-v6ops@ops.ietf.org Thu Jul 15 00:09:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06470 for ; Thu, 15 Jul 2004 00:09:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkxXp-0007hM-NL for v6ops-data@psg.com; Thu, 15 Jul 2004 04:08:29 +0000 Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bkx7a-0004Mn-FW for v6ops@ops.ietf.org; Thu, 15 Jul 2004 03:41:22 +0000 Received: from [131.179.232.51] (Mass.CS.UCLA.EDU [131.179.232.51]) by kiwi.cs.ucla.edu (8.11.7p1+Sun/8.11.7/UCLACS-5.2) with ESMTP id i6F3egF16025; Wed, 14 Jul 2004 20:40:42 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <38B07406-D611-11D8-A54E-000A95A6D9BC@cs.ucla.edu> Content-Transfer-Encoding: 7bit Cc: dccp@ietf.org, Pekka Savola , v6ops@ops.ietf.org, "" From: Eddie Kohler Subject: Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt Date: Wed, 14 Jul 2004 20:44:06 -0700 To: Aaron Falk X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, responding to a longago mail: First off, I think that DCCP is more like TCP than UDP. Second off, I disagree with the draft's approach for TCP. Maybe this discussion has already been had. The -02 draft suggests, basically, that IPv6 Destination Unreachable is a hard error during connection setup, so that the application can cycle through different addresses. It notes also that "TCP MUST NOT abort connections when receiving ICMP Destination Unreachable messages that indicate "soft errors"," according to RFC 1122. These are in conflict. But RFC 1122 also says that TCP "SHOULD make the information [about the soft error] available to the application". This shows a way out of the conflict. We can leave IPv6 Dest Unreach a soft error, like IPv4 Dest Unreach, while still supporting address cycling. Simply specify that TCPv6 stacks SHOULD provide an API by which the application can request that soft errors end the connection right away (one form of 'making the information available'). This change is more incremental than the change currently proposed, and less invasive to the stack (no worries about SYN-SENT/SYN-RECEIVED state and so forth). The text I've suggested for DCCP below takes this approach. Also, an editing comment: the draft seems quite verbose. Thanks for your solicitation, Eddie 2.3.4 DCCP Implications DCCP implementations should let applications request that "soft errors", including ICMP Destination Unreachable errors, be reported immediately. Applications that can try multiple addresses to reach a given host SHOULD use this API to reduce potential transport-associated delay during connection setup. Applications should generally turn off this API once a connection has been successfully initiated. On Apr 23, 2004, at 1:14 PM, Aaron Falk wrote: > I didn't see a response to this note. Would someone like to draft > some text and circulate it by the list? > > THanks, > > --aaron > > > On Mar 31, 2004, at 8:39 PM, Pekka Savola wrote: > >> Hi, >> >> draft-ietf-v6ops-v6onbydefault-01.txt has brought up some issues wrt. >> handling of ICMP messages in transport protocols, in section 2.3. The >> document is in v6ops WG last call for Informational at the moment. >> >> I believe the situation with DCCP is quite similar to UDP: >> >> -------------- >> 2.3 Transport Protocol Robustness >> >> Making the same set of assumptions as Section 2.2, regardless of >> how >> long the network layer takes to determine that the IPv6 destination >> is unreachable, the delay associated with a connection attempt to >> an >> unreachable destination can be compounded by the transport layer. >> When the unreachability of a destination is obviated by the >> reception >> of an ICMPv6 destination unreachable message, the transport layer >> should make it possible for the application to deal with this by >> failing the connection attempt, passing ICMPv6 errors up to the >> application, etc... Such messages would be received in the cases >> mentioned in Section 2 in which a node has no default routers and >> NUD >> fails for destinations assumed to be on-link, and when firewalls or >> other systems that enforce scope boundaries send such ICMPv6 errors >> as described in Section 3.1 and Section 3.3. >> [...] >> >> 2.3.2 UDP Implications >> >> As noted in [HOSTREQS] section 4.1.3.3, UDP implementations MUST >> pass >> to the application layer all ICMP error messages that it receives >> from the IP layer. As a result, proper handling destination >> unreachability by UDP applications is the responsibility of the >> applications themselves. >> ------------- >> >> 1) is this being handled differently in DCCP? >> >> 2) would you like to propose text to describe the situation with DCCP? >> >> On behalf of v6ops WG, >> Pekka >> >> -- >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> From owner-v6ops@ops.ietf.org Thu Jul 15 00:09:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06488 for ; Thu, 15 Jul 2004 00:09:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkxX6-0007bN-1i for v6ops-data@psg.com; Thu, 15 Jul 2004 04:07:44 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkxX2-0007aL-Ns for v6ops@ops.ietf.org; Thu, 15 Jul 2004 04:07:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6F47dX17428 for ; Thu, 15 Jul 2004 07:07:39 +0300 Date: Thu, 15 Jul 2004 07:07:39 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 6PE for Standards Track in ISP scenarios? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, (co-chair hat on) (There was already rough consensus in March 2004, but at the request of the ADs, and since we will handle the other proposals the same way, let's do this in a slightly more formal manner.) In draft-ietf-v6ops-isp-scenarios-analysis-03.txt we found that we need draft-ooms-v6ops-bgp-tunnel-03.txt ("6PE/BGP-tunnel") to provide easier transition for IPv4 MPLS networks. Let me try to summarize the consensus: 1. Problem: to deploy IPv6 over an MPLS network, you'll have to either use manually configured tunnels, deploy IPv6 natively, or upgrade the whole signalling plane to support IPv6. The MPLS operators haven't been enthusiastic about the last option, and in many cases, the others aren't suitable either (if the network is extensive, or using vendors without sufficient native IPv6 capabilities). Therefore an automatic encapsulation in IPv4 MPLS network is needed. 2. Why this solution: there haven't been other proposed solutions to this problem (in v6ops). However, one should note that the generic provider-provisioned VPN framework provides a slightly more extensive means to solve this problem, but is overly complex to those who do not need to provide IPv6 VPN services (but just want to support IPv6 over their MPLS core). Further, draft-ooms-v6ops-bgp-tunnel-03.txt has been implemented, is interoperable, and has been already extensively deployed. 3. Is this ready: the document is ready to be progressed by the routing area for Standards Track -- it has recently been revised a couple of times to remove unneeded functionality that was present earlier on, and is now a very simple and compact specification. If you disagree with these conclusions, please respond within a week, by 22nd July. Thanks! (co-chair hat off) From owner-v6ops@ops.ietf.org Thu Jul 15 03:59:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01567 for ; Thu, 15 Jul 2004 03:59:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bl17e-0008Ri-KK for v6ops-data@psg.com; Thu, 15 Jul 2004 07:57:42 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bl17a-0008Qv-KY for v6ops@ops.ietf.org; Thu, 15 Jul 2004 07:57:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6F7van20759; Thu, 15 Jul 2004 10:57:36 +0300 Date: Thu, 15 Jul 2004 10:57:36 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: Margaret Wasserman Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, (co-chair hat on) I'd like to move forward with this by submitting a revised I-D before the revision cutoff on Monday. There was just one comment to this thread, and some off-list discussion between Margaret and the authors/editors. I see three kinds of potential resolutions: 1) Just remove a bit of text and refer normatively to RFC3484. This makes it impossible to go for Draft Standard soon. If this is done, IPv6 WG must be rechartered to add revising RFC3484 to Draft Standard in its deliverables. 2) Keep the text basically as is. The draft can't go forward unless Margaret changes her opinion though. 3) Remove a bit of text, refer informatively to RFC3484, and basically say "DNS result ordering is out of scope of this specification". (This is a new compromise proposal.) That way, we don't propose the "simple" ordering rules, but don't require implementation of RFC3484 (in this spec) either. Thoughts? (co-chair hat off) If my own opinion is worth anything.. 1) would be inappropriate because RFC3484 revision isn't even on the IPv6 WG radar yet, and even if it was, it would probably take a year at least; 3) might be a reasonable compromise; obviously, I'd prefer 2).. :) ---------- Forwarded message ---------- Date: Mon, 14 Jun 2004 08:53:13 -0400 From: Margaret Wasserman To: v6ops@ops.ietf.org Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt Hi All, A few weeks ago, Pekka Savola sent a summary of IESG comments to the list that included: > 1) section 2.2 on DNS result ordering/filtering seems to > be considered inappropriately short, and it would be better > to just refer to the default address selection RFC3484. > (Margaret Wasserman). Filtering is inappropriate (Ted Hardie > and Scott Hollenbeck). The length of the section doesn't bother me. In fact, following my suggestion would make it shorter :-). My objection to this section is that it contains a simple set of address selection rules, including a simple preference for IPv4 or IPv6, that has several well-understood problems. Those problems were identified and addressed in RFC 3484. So, I believe that we should remove the address selection rules specified in this section and replace them with a normative reference to RFC 3484. > ==> possibilities include at least: > a) keeping the current tense of specifying a "simple" address > selection, and referring to RFC3484 for more details, but reword > the text appropriately. Remove filtering but keep ordering. It > might require some convincing to make the IESG accept this > approach. (In other words, a simple dual-stack implementation > would not necessarily have to implement RFC3484 to be > compliant/interoperable with this spec.) There are several reasons why I do not believe that this is a good choice. We know that the simple address selection (flag to prefer IPv4 or IPv6) does not work properly. For instance, it causes situations where global communication will be initiated using a local source address, even when a global source address is available. It also causes situations where hosts will prefer tunnelled communication over non-tunnelled communication. These problems were identified and fixed in RFC 3484, which is a mandatory part of IPv6. > b) remove most of the text, referring to RFC3484. Note that RFC3484 > is PS, and we could not advance to DS if we did that. (In other > words, all the dual-stack implementations compliant with this spec > would also have to implement RFC3484.) This is my suggestion. IMO, the concern that adding a normative reference to RFC 3484 will prevent promotion to draft standard is misplaced. Before moving to DS, a draft must have two interoperable implementations and "successful operational experience". The whole purpose of the multi-tiered standards process is to identify problems (such as the address selection problems in this draft) and correct them before documents move to higher levels of the standards track. Margaret From owner-v6ops@ops.ietf.org Thu Jul 15 21:26:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25100 for ; Thu, 15 Jul 2004 21:26:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlHRi-000BP3-Hu for v6ops-data@psg.com; Fri, 16 Jul 2004 01:23:30 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlHRg-000BOo-OP for v6ops@ops.ietf.org; Fri, 16 Jul 2004 01:23:29 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6G1NRil009208 for ; Thu, 15 Jul 2004 19:23:28 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I0X00M8H7V398@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 15 Jul 2004 19:23:27 -0600 (MDT) Received: from [192.168.1.2] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I0X003B97V2L2@mail.sun.net> for v6ops@ops.ietf.org; Thu, 15 Jul 2004 19:23:27 -0600 (MDT) Date: Thu, 15 Jul 2004 18:23:26 -0700 From: Alain Durand Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt (fwd) In-reply-to: To: Pekka Savola Cc: Margaret Wasserman , v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT There is a perception (at least from Margaret) that RFC3484 solves the IPv4/IPv6 selection problem. I do not share that point of view. The issue is much more complex, as hinted in draft-ietf-v6ops-v6onbydefault. Today, in the current state of IPv6 deployment, a single switch on/off would not really be any worse than implementing RFC3484; however, this is not something you want to say in a DS document. My opinion is that we should delete section 2.2 DNS all together, as out of scope. - Alain. On Jul 15, 2004, at 12:57 AM, Pekka Savola wrote: > Hello all, > > (co-chair hat on) > > I'd like to move forward with this by submitting a revised I-D before > the revision cutoff on Monday. > > There was just one comment to this thread, and some off-list > discussion between Margaret and the authors/editors. > > I see three kinds of potential resolutions: > > 1) Just remove a bit of text and refer normatively to RFC3484. > This makes it impossible to go for Draft Standard soon. > > If this is done, IPv6 WG must be rechartered to add revising > RFC3484 to Draft Standard in its deliverables. > > 2) Keep the text basically as is. The draft can't go forward unless > Margaret changes her opinion though. > > 3) Remove a bit of text, refer informatively to RFC3484, and > basically say "DNS result ordering is out of scope of this > specification". (This is a new compromise proposal.) That way, we > don't propose the "simple" ordering rules, but don't require > implementation of RFC3484 (in this spec) either. > > Thoughts? > > (co-chair hat off) > > If my own opinion is worth anything.. 1) would be inappropriate > because RFC3484 revision isn't even on the IPv6 WG radar yet, and even > if it was, it would probably take a year at least; 3) might be a > reasonable compromise; obviously, I'd prefer 2).. :) > > ---------- Forwarded message ---------- > Date: Mon, 14 Jun 2004 08:53:13 -0400 > From: Margaret Wasserman > To: v6ops@ops.ietf.org > Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt > > > Hi All, > > A few weeks ago, Pekka Savola sent a summary of IESG > comments to the list that included: > >> 1) section 2.2 on DNS result ordering/filtering seems to >> be considered inappropriately short, and it would be better >> to just refer to the default address selection RFC3484. >> (Margaret Wasserman). Filtering is inappropriate (Ted Hardie >> and Scott Hollenbeck). > > The length of the section doesn't bother me. In fact, > following my suggestion would make it shorter :-). > > My objection to this section is that it contains a > simple set of address selection rules, including a > simple preference for IPv4 or IPv6, that has several > well-understood problems. Those problems were > identified and addressed in RFC 3484. So, I believe > that we should remove the address selection rules > specified in this section and replace them with a > normative reference to RFC 3484. > >> ==> possibilities include at least: >> a) keeping the current tense of specifying a "simple" address >> selection, and referring to RFC3484 for more details, but reword >> the text appropriately. Remove filtering but keep ordering. It >> might require some convincing to make the IESG accept this >> approach. (In other words, a simple dual-stack implementation >> would not necessarily have to implement RFC3484 to be >> compliant/interoperable with this spec.) > > There are several reasons why I do not believe > that this is a good choice. We know that the simple > address selection (flag to prefer IPv4 or IPv6) does > not work properly. For instance, it causes situations > where global communication will be initiated using a > local source address, even when a global source address > is available. It also causes situations where hosts > will prefer tunnelled communication over non-tunnelled > communication. > > These problems were identified and fixed in RFC 3484, > which is a mandatory part of IPv6. > >> b) remove most of the text, referring to RFC3484. Note that RFC3484 >> is PS, and we could not advance to DS if we did that. (In other >> words, all the dual-stack implementations compliant with this spec >> would also have to implement RFC3484.) > > This is my suggestion. > > IMO, the concern that adding a normative reference > to RFC 3484 will prevent promotion to draft standard > is misplaced. Before moving to DS, a draft must have > two interoperable implementations and "successful > operational experience". The whole purpose of the > multi-tiered standards process is to identify problems > (such as the address selection problems in this draft) > and correct them before documents move to higher > levels of the standards track. > > Margaret > > > > > > > From owner-v6ops@ops.ietf.org Fri Jul 16 08:46:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27137 for ; Fri, 16 Jul 2004 08:46:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlS2b-000CFb-36 for v6ops-data@psg.com; Fri, 16 Jul 2004 12:42:17 +0000 Received: from [164.164.31.6] (helo=wiproecmx2.wipro.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlS2N-000CEa-OQ for v6ops@ops.ietf.org; Fri, 16 Jul 2004 12:42:15 +0000 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i6GCfhpg023481 for ; Fri, 16 Jul 2004 18:11:50 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 16 Jul 2004 18:11:43 +0530 Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Jul 2004 18:11:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46B32.3EF35CBA" Subject: Need info regarding status of some items Date: Fri, 16 Jul 2004 18:11:42 +0530 Message-ID: <2BB7146B38D9CA40B215AB3DAAE24C0876E8E7@blr-m2-msg.wipro.com> Thread-Topic: Need info regarding status of some items Thread-Index: AcRrMj5YrVncBjQKT+qlCptZQvF5XA== From: To: X-OriginalArrivalTime: 16 Jul 2004 12:41:42.0360 (UTC) FILETIME=[3F0D7580:01C46B32] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=BAYES_44, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C46B32.3EF35CBA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I need some info on the status of following things - =20 1. IPv4 mapped IPv6 address 2. Site local address 3. IPv4 compatible IPv6 tunnels 4. 6over4 tunnels 5. BIS =20 I wanted to know whether the above concepts are deprecated. Can anybody please throw some light on the same? =20 Thanks a lot! =20 Regards, Savitha Wipro Technologies, Bommanahalli, Bangalore, INDIA *: +91-80-25732293 Extn: 3126 *: savitha.kumar@wipro.com http://www.wipro.com The world's first SEI CMM level 5 software services company. =20 =20 ------_=_NextPart_001_01C46B32.3EF35CBA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I need some info on the status of following things = –

 

  1. IPv4 mapped IPv6 address
  2. Site local address
  3. IPv4 compatible IPv6 tunnels
  4. 6over4 tunnels
  5. BIS=

 

I wanted to know whether the above concepts are = deprecated. Can anybody please throw some light on the = same?

 

Thanks a lot!

 

Regards,

=

Savitha

Wipro = Technologies,

Bommanahalli, Bangalore, = INDIA

(: = +91-80-25732293 Extn: 3126

+: savitha.kumar@wipro.com<= /o:p>

http://www.wipro.com<= /p>

The world's first SEI CMM level 5 = software services company.

 

 

------_=_NextPart_001_01C46B32.3EF35CBA-- From owner-v6ops@ops.ietf.org Sat Jul 17 04:37:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01848 for ; Sat, 17 Jul 2004 04:37:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Blkd0-0004mI-7i for v6ops-data@psg.com; Sat, 17 Jul 2004 08:33:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Blkcw-0004lY-Mr for v6ops@ops.ietf.org; Sat, 17 Jul 2004 08:33:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6H8WGU31903; Sat, 17 Jul 2004 11:32:17 +0300 Date: Sat, 17 Jul 2004 11:32:16 +0300 (EEST) From: Pekka Savola To: Eddie Kohler cc: Aaron Falk , , , "" , Subject: Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt In-Reply-To: <38B07406-D611-11D8-A54E-000A95A6D9BC@cs.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I also added tcpm WG to Cc: (as you already forwarded this on that list later). As a status update, the TCP part has been put in a separate draft -- draft-gont-tcpm-tcp-soft-errors-00.txt. What is the status wrt. the modification you propose in DCCP? That is, in the IESG evaluation we received feedback that we cannot publish this document with "solutions" unless the solutions have been specified in the respective specification (e.g., DCCP drafts, etc.) -- and we'd have to reference them normatively (I think). More inline on TCP and the genegic approach... On Wed, 14 Jul 2004, Eddie Kohler wrote: > Hi all, responding to a longago mail: > > First off, I think that DCCP is more like TCP than UDP. > > Second off, I disagree with the draft's approach for TCP. Maybe this > discussion has already been had. > > The -02 draft suggests, basically, that IPv6 Destination Unreachable is > a hard error during connection setup, so that the application can cycle > through different addresses. It notes also that "TCP MUST NOT abort > connections when receiving ICMP Destination Unreachable messages that > indicate "soft errors"," according to RFC 1122. These are in conflict. > > But RFC 1122 also says that TCP "SHOULD make the information [about the > soft error] available to the application". This shows a way out of the > conflict. We can leave IPv6 Dest Unreach a soft error, like IPv4 Dest > Unreach, while still supporting address cycling. Simply specify that > TCPv6 stacks SHOULD provide an API by which the application can request > that soft errors end the connection right away (one form of 'making the > information available'). This change is more incremental than the > change currently proposed, and less invasive to the stack (no worries > about SYN-SENT/SYN-RECEIVED state and so forth). It would indeed be possible to provide an API for the application to act on the soft error information. However, I think the application still cannot ignore the SYN-SENT/SYN-RECEIVED state issues due to security reasons (otherwise anyone could start aborting the ongoing connections for those who use the API). In other words, it would be possible to provide an API (e.g., a socket option that could be set) which would abort the connection if it receives a soft error in SYN-SENT/RECEIVED states. Another alternative is to make the change by default, but provide the identical API (e.g., a socket option) which would prevent the address cycling -- because one could argue that address cycling is in most cases a desirable thing to do, and this would be a better "by default" behaviour. Most applications would want to set it in any case, and doing it by default would achieve a better and easier "application penetration". All the approaches have their tradeoffs, of course. This discussion needs to be had, possibly in TCPM WG. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sat Jul 17 10:03:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16454 for ; Sat, 17 Jul 2004 10:03:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlpjT-000Lx2-6i for v6ops-data@psg.com; Sat, 17 Jul 2004 14:00:07 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlpjL-000LuV-Lg for v6ops@ops.ietf.org; Sat, 17 Jul 2004 13:59:59 +0000 Received: from [24.61.30.237] (account margaret HELO [10.0.0.78]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 113944; Sat, 17 Jul 2004 09:57:21 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: References: Date: Sat, 17 Jul 2004 09:59:51 -0400 To: Alain Durand , Pekka Savola From: Margaret Wasserman Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt (fwd) Cc: v6ops@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Alain, At 6:23 PM -0700 7/15/04, Alain Durand wrote: >There is a perception (at least from Margaret) that RFC3484 solves >the IPv4/IPv6 selection >problem. I do not share that point of view. The issue is much more complex, >as hinted in draft-ietf-v6ops-v6onbydefault. It is likely that RFC 3484 doesn't resolve every address selection issue. Also, RFC 3484 is complex, and I think that we would all be happier with a simpler solution to the address selection problem, but we haven't been able to find a simpler solution that actually works. Also RFC 3484 solves some serious issues that were identified with the single switch mechanism currently described in draft-ietf-v6ops-mech-v2. Also, further progress in this area should be made in updates to RFC 3484. If the v6ops WG believes that there are operational problems with RFC 3484, we should clearly document them for consideration by the IPv6 WG. Or, better yet, we could just go to the IPv6 WG and propose solutions. >Today, in the current state of IPv6 deployment, a single switch >on/off would not really be any worse >than implementing RFC3484; however, this is not something you want >to say in a DS document. > >My opinion is that we should delete section 2.2 DNS all together, as >out of scope. I am concerned about this option, because it seems to duck the problem... Do you really think it would be okay to publish a specification for dual-stack nodes that is silent on the subject of address selection? Without even including a reference to a separate specification that covers this topic? IMO, RFC 3484 is better in many ways (and no worse in others) than the single on/off switch described in draft-ietf-v6ops-mech-v2. So, we should be encouraging people to implement RFC 3484, not the single switch mechanism. I believe rather strongly that it would be a mistake to re-publish the single switch address selection mechanism and advance it to DS when we know that a more complex mechanism is required. I fear that this would cause confusion in the industry about what level of address selection support is required for a full IPv6 implementation. The arguments for publishing this document without a normative reference to RFC 3484 seem to be motivated by the goal of publishing draft-ietf-v6ops-mech-v2 as a DS by somehow side-stepping the fact that it has known technical omissions in the area of address selection that we have attempted to address in RFC 3484. This goal seems to be based on some assumptions that I don't necessarily agree with, most notably: - The assumption that there is some large value to moving draft-ietf-v6ops-mech-v2 despite its technical flaws in the area of address selection, and/or - The assumption that RFC 3484 can't (or won't?) be moved to DS any time soon. Right now, we are not even talking about whether or not to publish draft-ietf-v6ops-mech-v2 at DS! The requested publication status for this document is PS, RFC 3484 is already at PS, and normatively referencing RFC 3484 in draft-ietf-v6ops-mech-v2 will not block publication of this document. Also, we're all really the same group of people... So, if we (as a group) consider publishing draft-ietf-v6ops-mech-v2 as a Draft Standard to be a high priority, we can do the work to move RFC 3484 to DS as well. I've worked with everyone involved here long enough to respect you and consider you to be reasonable people, so I feel like I may be missing something here... So, what am I missing? I don't want to assert my beliefs above those of the entire v6ops WG. At this point, though, too few people have weighed in on this issue for the opinion of the v6ops WG to be clear (to me, anyway), one way or the other. What do other people think? Margaret From owner-v6ops@ops.ietf.org Sat Jul 17 12:11:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23189 for ; Sat, 17 Jul 2004 12:11:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Blrku-000Hnc-F1 for v6ops-data@psg.com; Sat, 17 Jul 2004 16:09:44 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Blrkt-000Hn7-5g for v6ops@ops.ietf.org; Sat, 17 Jul 2004 16:09:43 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6HG9gil010292 for ; Sat, 17 Jul 2004 10:09:42 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1000BGL7K6T1@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Sat, 17 Jul 2004 10:09:42 -0600 (MDT) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1000CBP7K4D8@mail.sun.net> for v6ops@ops.ietf.org; Sat, 17 Jul 2004 10:09:42 -0600 (MDT) Date: Sat, 17 Jul 2004 09:09:41 -0700 From: Alain Durand Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt (fwd) In-reply-to: To: Margaret Wasserman Cc: Pekka Savola , v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Jul 17, 2004, at 6:59 AM, Margaret Wasserman wrote: >> My opinion is that we should delete section 2.2 DNS all together, as >> out of scope. > > I am concerned about this option, because it seems to duck the > problem... Do you really think it would be okay to publish a > specification for dual-stack nodes that is silent on the subject of > address selection? Without even including a reference to a separate > specification that covers this topic? Look at the table of content of the draft: 2. Dual IP Layer Operation.................................. 5 2.1. Address Configuration............................... 5 2.2. DNS................................................. 5 3. Configured Tunneling Mechanisms.......................... 7 3.1. Encapsulation....................................... 8 3.2. Tunnel MTU and Fragmentation........................ 9 3.2.1. Static Tunnel MTU.............................. 9 3.2.2. Dynamic Tunnel MTU............................. 10 3.3. Hop Limit........................................... 11 3.4. Handling ICMPv4 errors.............................. 12 3.5. IPv4 Header Construction............................ 14 3.6. Decapsulation....................................... 15 3.7. Link-Local Addresses................................ 18 3.8. Neighbor Discovery over Tunnels..................... 19 4. Threat Related to Source Address Spoofing................ 20 5. Security Considerations.................................. 21 6. Acknowledgments............... The essence of this draft is really about dual stack and tunneling IPv6 over IPv4 as _the_ basic transition mechanisms. There is much more than DNS in the operation of a dual stack node, however the draft only mention DNS, and, as you mention, is not complete as it does not actually provide a satisfactory answer to the overall problem. This is the reason why I think we might as well declare the DNS issues out of scope. - Alain. From owner-v6ops@ops.ietf.org Sat Jul 17 14:22:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28786 for ; Sat, 17 Jul 2004 14:22:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bltmg-000CBO-1h for v6ops-data@psg.com; Sat, 17 Jul 2004 18:19:42 +0000 Received: from [169.232.46.138] (helo=smtp.ucla.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bltme-000CAz-Iq for v6ops@ops.ietf.org; Sat, 17 Jul 2004 18:19:40 +0000 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.135]) by smtp.ucla.edu (8.12.11/8.12.11) with ESMTP id i6HIJZwj003896; Sat, 17 Jul 2004 11:19:35 -0700 Received: from [192.168.1.101] (adsl-63-207-102-46.dsl.snfc21.pacbell.net [63.207.102.46]) (authenticated bits=0) by mail.ucla.edu (8.12.11/8.12.11) with ESMTP id i6HIJXjP026285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Jul 2004 11:19:34 -0700 Message-ID: <40F96DD5.1070401@cs.ucla.edu> Date: Sat, 17 Jul 2004 11:20:05 -0700 From: Eddie Kohler User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: dccp@ietf.org, v6ops@ops.ietf.org, tcpm@ietf.org Subject: Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Probable-Spam: no X-Spam-Hits: -4.901 X-Scanned-By: smtp.ucla.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Long cc: list... :( > As a status update, the TCP part has been put in a separate draft -- > draft-gont-tcpm-tcp-soft-errors-00.txt. What is the status wrt. the > modification you propose in DCCP? The DCCP specs do not talk about network layer interactions like ICMP. That is probably a new draft we'll eventually have to work on. > It would indeed be possible to provide an API for the application to > act on the soft error information. However, I think the application > still cannot ignore the SYN-SENT/SYN-RECEIVED state issues due to > security reasons (otherwise anyone could start aborting the ongoing > connections for those who use the API). > > In other words, it would be possible to provide an API (e.g., a socket > option that could be set) which would abort the connection if it > receives a soft error in SYN-SENT/RECEIVED states. This is trivial at the application level: simply turn off the "soft errors are hard" API once connect() has completed. I think embedding SYN-SENT/RECEIVED knowledge in any kernel/user API is a bad idea. > Another alternative is to make the change by default, but provide the > identical API (e.g., a socket option) which would prevent the address > cycling -- This assumes that all address cycling will happen below the application, which is doubtful. Eddie From owner-v6ops@ops.ietf.org Sat Jul 17 15:00:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00976 for ; Sat, 17 Jul 2004 15:00:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BluPe-000KRH-9r for v6ops-data@psg.com; Sat, 17 Jul 2004 18:59:58 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BluPa-000KQH-UC for v6ops@ops.ietf.org; Sat, 17 Jul 2004 18:59:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6HIxo108211; Sat, 17 Jul 2004 21:59:50 +0300 Date: Sat, 17 Jul 2004 21:59:50 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: alain.durand@sun.com, Subject: WG Last Call: draft-ietf-v6ops-assisted-tunneling-requirements-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, (co-chair hat on) This is the WG Last Call for comments on sending draft-ietf-v6ops-assisted-tunneling-requirements-00.txt, "Requirements for assisted tunneling" to the IESG for consideration as Informational RFC: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt This document will be used as a basis for possible (re-)design of appropriate transition mechanisms. Please review the document carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. The last call will end in about 3.5 weeks, on 9th August. The large WGLC time is due to the IETF meeting. It is recommended that participants read and comment prior to the IETF as the topic will be discussed there. Thanks! From owner-v6ops@ops.ietf.org Sat Jul 17 16:02:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04421 for ; Sat, 17 Jul 2004 16:02:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlvMs-000692-EQ for v6ops-data@psg.com; Sat, 17 Jul 2004 20:01:10 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlvMp-00067x-Hw for v6ops@ops.ietf.org; Sat, 17 Jul 2004 20:01:08 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000140313.msg for ; Sat, 17 Jul 2004 22:03:58 +0200 Message-ID: <0b3001c46c38$c4f8bae0$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: WG Last Call: draft-ietf-v6ops-assisted-tunneling-requirements-00.txt Date: Sat, 17 Jul 2004 22:00:53 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sat, 17 Jul 2004 22:03:58 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Sat, 17 Jul 2004 22:04:01 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, May be is worth to make 2 sub-sections in 4.1 to make more evident which text belong to each mode. Alternatively: Replace The tunnel established is "anonymous" in a sense as the end-user does not register explicitly to the server ... With In the non-registered mode, The tunnel established is "anonymous" in a sense as the end-user does not register explicitly to the server ... Or In this mode, the tunnel established is "anonymous" in a sense as the end-user does not register explicitly to the server ... Other suggestions follow. Replace In non-registered mode, the IPv6 address is "transient" and may change, but the protocol SHOULD offer a mechanism to provide IPv6 address stability in this mode (e.g. cookie mechanism). The implementation of this mechanism MUST allow this feature to be turned off. In registered mode, the protocol MUST be able to support servers willing to offer stable IPv6 prefixes to the authenticated customers. With In non-registered mode, the IPv6 address is "transient" and may change, but the protocol SHOULD offer a mechanism to provide IPv6 address stability, by default, in this mode (e.g. cookie mechanism). The implementation of this mechanism MUST allow this feature to be turned off, being on by default. In registered mode, the protocol MUST be able to support servers willing to offer stable IPv6 prefixes to the authenticated customers, by default. In my opinion, we should prefer stable addresses, right ? Replace The protocol MAY send information about registration procedure when a non-registered client requests registered mode (ex: URL to provider registration web page). With The protocol MAY send information about registration procedure when a non-registered client requests registered or non-registered mode (ex: URL to provider registration web page). If a non-registered client request non-registered usage, he can also receive the URL. He will decide then if he want to register or not. Service Discovery. Should a reference to http://www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-01.txt, be included here ? I think is very negative for deployment to say "Non registered service should be limited to the provider network". I think it should be clarified that this is desired to avoid security threats, but not as a general recommendation, which seems to be the actual read (even if within the thread section). "A then can, for example ..."??? I guess it should be "Then can, for example ..." Replace "a customer A ..." with "a customer ..." There are several mentions of ISP in the document that should be probably ISPs ? Replace customers a message explaining that no service is available. With customers a message explaining that no service is available in that ISP. In that case, if alternative ISPs offer the service it could also be signaled to the customer. Replace "to to turn on ..." with "to turn on/off..." Regarding the keep-alive messages, I suggest to change the example of the ISDN type links to something more generic to cover two cases: - A low bandwidth link (ISDN, modem, etc.) - A link which the user pay for traffic (GPRS, 3GPP, ...) I will also add something to provide the option to negotiate the timing among keep-alive messages, for example, a default configuration depending on the bandwidth/cost available and then configured by the user/server. In 6.2, a way to achieve the client to be able to choose one of them, a reference to http://www.ietf.org/internet-drafts/draft-palet-v6ops-auto-trans-00.txt can be useful. I also wonder if in case of the NAT supports proto-41-forwarding, a reference to this must also be added, probably a section 6.4 ? Regards, Jordi PS: There are several "nits" but I guess they will be addressed also in the next step- ----- Original Message -----=20 From: "Pekka Savola" To: Cc: ; Sent: Saturday, July 17, 2004 8:59 PM Subject: WG Last Call: draft-ietf-v6ops-assisted-tunneling-requirements-00.txt > Hi all, >=20 > (co-chair hat on) >=20 > This is the WG Last Call for comments on sending > draft-ietf-v6ops-assisted-tunneling-requirements-00.txt, "Requirements > for assisted tunneling" to the IESG for consideration as Informational > RFC: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt >=20 > This document will be used as a basis for possible (re-)design of > appropriate transition mechanisms. >=20 > Please review the document carefully, and send your feedback to the > list. Please also indicate whether or not you believe that this > document is ready to go to the IESG. >=20 > The last call will end in about 3.5 weeks, on 9th August. The large > WGLC time is due to the IETF meeting. It is recommended that > participants read and comment prior to the IETF as the topic will be > discussed there. >=20 > Thanks! >=20 >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sat Jul 17 16:24:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05428 for ; Sat, 17 Jul 2004 16:24:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlviQ-000AYL-Jj for v6ops-data@psg.com; Sat, 17 Jul 2004 20:23:26 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlviP-000AXp-87 for v6ops@ops.ietf.org; Sat, 17 Jul 2004 20:23:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6HKNOa09755; Sat, 17 Jul 2004 23:23:24 +0300 Date: Sat, 17 Jul 2004 23:23:23 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: draft agenda for v6ops at IETF60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, See below the current draft agenda for v6ops sessions at IETF60. The sessions are currently scheduled for Monday night and Friday morning. Let's hope that the latter one, at least, changes. Updates or changes are very likely still. Please send in your thoughts, further agenda requests, comments, etc. ========= First session ============= (Tentatively scheduled for Monday night) Introduction and agenda bashing - 5 mins, Chairs/Savola - Scribes! (Jabber also?) Document status - 15 mins, Chairs/Savola - What has happened with WG documents lately - GOAL: show the status of WG documents Moving forward with Mechanisms - 45 mins, Chairs/ADs - [placeholder as of yet, plans still forming] - GOAL: discuss the procedure of how to move forward VLAN Usage for IPv6 transition - 5 mins, Chown? - draft-chown-v6ops-vlan-usage-01.txt [expired, to be revised] - GOAL: describe the procedure, discuss whether to go for Informational RFC Enterprise solution case study: Campus Transition - 20 mins, Chown - draft-chown-v6ops-campus-transition-00.txt - examine a case study of applying the enterprise scenarios document, discuss the issues. - GOAL: give input to the Enterprise solutions work and the necessity of transition tools. IPv6 Security Overview - 10 mins, Savola - draft-savola-v6ops-security-overview-02.txt - introduce the approach and justify the need; discuss changes. - GOAL: take as a WG item, solicit an editor. Assisted Tunneling Requirements - 15 mins, Durand - draft-ietf-v6ops-assisted-tunneling-requirements-00.txt - go through open issues, discuss - GOAL: resolve issues, revise and advance after IETF60 Tunnel-endpoint Discovery, 10 mins, Palet? - draft-palet-v6ops-tun-auto-disc-01.txt - discuss different approaches to discover the v6-in-v4 endpoint (to be used with assisted tunneling and maybe others) - GOAL: get more feedback, adopt as WG item? Secure IPv6 Tunneling - 10 mins, Graveman - draft-tschofenig-v6ops-secure-tunnels-00.txt - discuss the method of using IPsec to create secure v6-in-v4 tunnels - GOAL: get more input, adopt as WG item? Protocol-41 Forwarding in NAT boxes - 10 mins, Palet - [to be: draft-palet-v6ops-proto41-nat-05.txt] - GOAL: discuss changes and approach, adopt as WG item for Informational Measurement of Misbehaving DNS Servers - 5 mins, Savola channeling Malone - (based on draft-ietf-dnsop-misbehavior-against-aaaa-01.txt) - GOAL: show relative numbers of misbehaving servers vs IPv6 records Second session ============== (Tentatively scheduled for Friday morning, hopefully will change) [If good discussion is generated on the discussion items on the first session, add time to discuss those here] IPv6 replacement for NAT boxes etc. - 10 mins, van de Welde? - [no draft] - GOAL: present early work on an Informational draft on how to deploy v6 in environments where NATs and/or private addressing were used. Moving forward, take two, 30 mins, Chairs/ADs - [placeholder] - GOAL: continue tuning the process as necessary IPv6 Mobility Scenarios/Requirements update, 10 mins, Williams - [follow-up on draft-yamamoto-mipv6node-v4trav-00.txt] - GOAL: follow up from where we left off with in the last meeting "Auto-transition": picking the right mechanism - 10 mins, Palet - draft-palet-v6ops-auto-trans-00.txt - GOAL: discuss the concepts, whether useful for the WG. Distributed v6 security requirements/problem statement - 10 mins, Palet - draft-palet-v6ops-ipv6security-00.txt - draft-vives-v6ops-ipv6-security-ps-00.txt - GOAL: get input from the WG [These might at least might drop off from the agenda if there are no significant updates or interest:] Transition mechanisms update, 5 mins, Chairs/Savola - draft-ietf-v6ops-mech-v2-03.txt - GOAL: discuss how to address the DNS lookup ordering issue IPv6-on-by-Default - 5 mins, ? - draft-ietf-v6ops-v6onbydefault-01.txt - GOAL: discuss what has been happening with this work IPv6 Renumbering Procedures - 5 mins, Baker? - draft-ietf-v6ops-ipv6-renumber-procedure-01.txt - GOAL: discuss major issues, if raised during the IESG evaluation Advanced L3 IPv6 Exchange Model - 10 mins, Palet - draft-morelli-v6ops-ipv6-ix-00.txt - GOAL: get input from the WG ============= From owner-v6ops@ops.ietf.org Sat Jul 17 22:47:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24521 for ; Sat, 17 Jul 2004 22:47:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bm1ee-000IOx-4O for v6ops-data@psg.com; Sun, 18 Jul 2004 02:43:56 +0000 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bm1eZ-000IOZ-TP for v6ops@ops.ietf.org; Sun, 18 Jul 2004 02:43:52 +0000 Received: from fernando.gont.com.ar ([200.68.210.84]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id AAA14633; Sun, 18 Jul 2004 00:17:01 -0400 Message-Id: <4.3.2.7.2.20040717230639.00be4250@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 17 Jul 2004 23:12:15 -0300 To: Eddie Kohler , Pekka Savola From: Fernando Gont Subject: Re: [tcpm] Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt Cc: v6ops@ops.ietf.org, tcpm@ietf.org, dccp@ietf.org In-Reply-To: <40F96DD5.1070401@cs.ucla.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 11:20 17/07/2004 -0700, Eddie Kohler wrote: >>In other words, it would be possible to provide an API (e.g., a socket >>option that could be set) which would abort the connection if it receives >>a soft error in SYN-SENT/RECEIVED states. > >This is trivial at the application level: simply turn off the "soft errors >are hard" API once connect() has completed. I think embedding >SYN-SENT/RECEIVED knowledge in any kernel/user API is a bad idea. IMHO, requiring an application programmer more knowledge about networking and protocol specifics (soft and hard errors, etc.) is not a good idea. I'd either ease his life, and provide him with a more abstract, higher-level API, or would fix things without bothering him. >>Another alternative is to make the change by default, but provide the >>identical API (e.g., a socket option) which would prevent the address >>cycling -- >This assumes that all address cycling will happen below the application, >which is doubtful. Not sure what you mean. As far as I can understand, Pekka is just discussing whether it'd be best for the "change" to kick in by default, or not. He's still thinking about address-cycling being performed by the application. Of course, if you provided application programmers with a higher-level API, all the soft errors and address cycling issues could be handled bellow the application. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-v6ops@ops.ietf.org Sat Jul 17 22:47:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24541 for ; Sat, 17 Jul 2004 22:47:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bm1gW-000IdJ-V2 for v6ops-data@psg.com; Sun, 18 Jul 2004 02:45:52 +0000 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bm1gU-000Ict-M4 for v6ops@ops.ietf.org; Sun, 18 Jul 2004 02:45:51 +0000 Received: from fernando.gont.com.ar ([200.68.210.84]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id AAA14630; Sun, 18 Jul 2004 00:16:56 -0400 Message-Id: <4.3.2.7.2.20040717230134.00b9f7c0@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 17 Jul 2004 23:05:43 -0300 To: Pekka Savola , Eddie Kohler From: Fernando Gont Subject: Re: [tcpm] Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt Cc: v6ops@ops.ietf.org, "" , Aaron Falk , dccp@ietf.org, tcpm@ietf.org In-Reply-To: References: <38B07406-D611-11D8-A54E-000A95A6D9BC@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 11:32 17/07/2004 +0300, Pekka Savola wrote: >In other words, it would be possible to provide an API (e.g., a socket >option that could be set) which would abort the connection if it >receives a soft error in SYN-SENT/RECEIVED states. > >Another alternative is to make the change by default, but provide the >identical API (e.g., a socket option) which would prevent the address >cycling -- because one could argue that address cycling is in most >cases a desirable thing to do, and this would be a better "by default" >behaviour. Most applications would want to set it in any case, and >doing it by default would achieve a better and easier "application >penetration". And would not require changes in existing applications to achieve what is likely to be what most applications want to do. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-v6ops@ops.ietf.org Sun Jul 18 00:03:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28098 for ; Sun, 18 Jul 2004 00:03:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bm2sc-0007cA-Ew for v6ops-data@psg.com; Sun, 18 Jul 2004 04:02:26 +0000 Received: from [169.232.46.137] (helo=smtp.ucla.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bm2sb-0007br-FR for v6ops@ops.ietf.org; Sun, 18 Jul 2004 04:02:25 +0000 Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.135]) by smtp.ucla.edu (8.12.11/8.12.11) with ESMTP id i6I42LgB031234; Sat, 17 Jul 2004 21:02:21 -0700 Received: from [192.168.1.101] (adsl-63-207-102-46.dsl.snfc21.pacbell.net [63.207.102.46]) (authenticated bits=0) by mail.ucla.edu (8.12.11/8.12.11) with ESMTP id i6I42K9D017636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Jul 2004 21:02:20 -0700 Message-ID: <40F9F667.7030408@cs.ucla.edu> Date: Sat, 17 Jul 2004 21:02:47 -0700 From: Eddie Kohler User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont CC: v6ops@ops.ietf.org, tcpm@ietf.org Subject: Re: [tcpm] Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt References: <4.3.2.7.2.20040717230639.00be4250@mail.daleclick.com> In-Reply-To: <4.3.2.7.2.20040717230639.00be4250@mail.daleclick.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Probable-Spam: no X-Spam-Hits: -4.901 X-Scanned-By: smtp.ucla.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Seems like these two comments are in conflict: > IMHO, requiring an application programmer more knowledge about > networking and protocol specifics (soft and hard errors, etc.) is not a > good idea. and: > He's still thinking about address-cycling being performed by the > application. If the app cycles between addresses, then the app needs more knowledge about networking than most currently do. The TCP option is incremental on top of address cycling. > Of course, if you provided application programmers with a higher-level > API, all the soft errors and address cycling issues could be handled > bellow the application. We agree! Here's my proposal. 1. "Kernel" socket APIs for TCP are extended with an option that allows the app to specify whether "soft" errors should be treated as "hard". 2. A higher-level API is designed that handles multi-protocol DNS resolution and address cycling, and that calls the "kernel" socket API as appropriate to turn "soft" errors into "hard" ones during connection setup (_iff_ there are multiple addresses to try). In pseudocode: open_socket_from_name(DNS_name) ::= get list of addresses; create socket; if (more than one address) { // Address cycling: first time through, treat soft errors as hard, // so cycling happens faster. make soft errors hard on socket; for (each address) { try connecting to current address; if (connect succeeded) { make soft errors soft on socket; return socket; } make soft errors soft on socket; } // Second time through, treat soft errors as soft, to avoid failing. // Alternately might cycle through addresses a number of times until // some timeout occurs. for (each address) { try connecting to current address; if (connect succeeded) return socket; } destroy socket; return connection failure; This type of structure seems like the right thing for many apps, but not all. But there are a lot of potential parameters, and experience is required. So you should only specify it in a library API. Eddie From owner-v6ops@ops.ietf.org Sun Jul 18 00:56:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00686 for ; Sun, 18 Jul 2004 00:56:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bm3hx-000HVI-4L for v6ops-data@psg.com; Sun, 18 Jul 2004 04:55:29 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1Bm3gV-000HB5-1Q for v6ops@ops.ietf.org; Sun, 18 Jul 2004 04:53:59 +0000 Received: (qmail 28138 invoked by uid 417); 18 Jul 2004 04:53:58 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 18 Jul 2004 04:53:58 -0000 Received: from fernando.softhome.net ([200.70.173.160]) (AUTH: LOGIN fgont@softhome.net) by softhome.net with esmtp; Sat, 17 Jul 2004 22:53:54 -0600 Message-Id: <4.3.2.7.2.20040718002405.00d9ff00@mail.daleclick.com> X-Sender: fgont@pop.softhome.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 18 Jul 2004 02:04:41 -0300 To: v6ops@ops.ietf.org From: Fernando Gont Subject: Re: [tcpm] TCP, DCCP, v6, and ICMP soft errors [draft-ietf-v6ops-v6onbydefault-01] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 12:07 15/07/2004 -0700, you wrote: >>The -02 draft suggests, basically, that IPv6 Destination Unreachable is a >>hard error during connection setup, so that the application can cycle >>through different addresses. Note that while while the proposal *is* to make TCP react to soft errors, conceptually we're *not* saying that destination unreacheables are now considered "hard errors". Please have a look at draft-gont-tcpm-tcp-soft-errors-00.txt, which contains a somehow expanded discussion of the TCP stuff. It says: ---- cut here ---- 4.1 Changing TCP's reaction to soft errors As discussed in Section 1, it may make sense for the fault recovery action to depend not only on the type of error being reported, but also on the time the error is reported. For example, one could infer that when an error arrives in response to opening a new connection, it is probably caused by opening the connection improperly, rather than by a transient network failure. [8] ---- cut here ---- That means, we modify TCP fault isolation policy on the connection establishment phase, rather than changing the "meaning" of the error itself. >>But RFC 1122 also says that TCP "SHOULD make the information [about the >>soft error] available to the application". This shows a way out of the >>conflict. IMHO, this was okay when applciation programmers were more knowledgeable about networking and protocol specifics. Should we *nowadays* bother an *application* programmer with TCP soft/hard errors? I don't think so. The proposed solution provides a work around without having to bother the application programmer. Furthermore, the fix would kick in without adding any extra logic to existing applications. >>We can leave IPv6 Dest Unreach a soft error, like IPv4 Dest Unreach, >>while still supporting address cycling. Simply specify that TCPv6 stacks >>SHOULD provide an API by which the application can request that soft >>errors end the connection right away (one form of 'making the information >>available'). I don't think this soultion would be quite acceptable nowadays.If application programmers were to learn more stuff on an API, then it should probably be about a brand-new higher level API, that would hide all these details from them. And from then on, we could "fix" this sort of "problem" without any impact on applications. >> This change is more incremental than the change currently proposed, and >> less invasive to the stack (no worries about SYN-SENT/SYN-RECEIVED state >> and so forth). Not sure what you mean. BTW, Thanks so much for your comments! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-v6ops@ops.ietf.org Sun Jul 18 04:49:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24906 for ; Sun, 18 Jul 2004 04:49:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bm7If-0004q9-T2 for v6ops-data@psg.com; Sun, 18 Jul 2004 08:45:37 +0000 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bm7Ic-0004pE-Qw for v6ops@ops.ietf.org; Sun, 18 Jul 2004 08:45:35 +0000 Received: from fernando.gont.com.ar ([200.68.222.31]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id GAA18385; Sun, 18 Jul 2004 06:20:45 -0400 Message-Id: <4.3.2.7.2.20040718053133.00d40100@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 18 Jul 2004 05:47:52 -0300 To: Eddie Kohler From: Fernando Gont Subject: Re: [tcpm] Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt Cc: v6ops@ops.ietf.org, tcpm@ietf.org In-Reply-To: <40F9F667.7030408@cs.ucla.edu> References: <4.3.2.7.2.20040717230639.00be4250@mail.daleclick.com> <4.3.2.7.2.20040717230639.00be4250@mail.daleclick.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 21:02 17/07/2004 -0700, Eddie Kohler wrote: >>IMHO, requiring an application programmer more knowledge about networking >>and protocol specifics (soft and hard errors, etc.) is not a good idea. >and: >>He's still thinking about address-cycling being performed by the application. > >If the app cycles between addresses, then the app needs more knowledge >about networking than most currently do. That's part of what I meant in my other post: Don't have applications do all these things, or they'll be working close to the network. Then whenever you want to change some protocol behaviour, it will likely affect the applications (which it shouldn't!). >>Of course, if you provided application programmers with a higher-level >>API, all the soft errors and address cycling issues could be handled >>bellow the application. >We agree! > >Here's my proposal. > >1. "Kernel" socket APIs for TCP are extended with an option that allows >the app to specify whether "soft" errors should be treated as "hard". > >2. A higher-level API is designed that handles multi-protocol DNS >resolution and address cycling, and that calls the "kernel" socket API as >appropriate to turn "soft" errors into "hard" ones during connection setup >(_iff_ there are multiple addresses to try). In pseudocode: > > open_socket_from_name(DNS_name) ::= > get list of addresses; > create socket; > if (more than one address) { > // Address cycling: first time through, treat soft errors as > hard, > // so cycling happens faster. > make soft errors hard on socket; > for (each address) { > try connecting to current address; > if (connect succeeded) { > make soft errors soft on socket; > return socket; > } > make soft errors soft on socket; > } > // Second time through, treat soft errors as soft, to avoid failing. > // Alternately might cycle through addresses a number of times until > // some timeout occurs. > for (each address) { > try connecting to current address; > if (connect succeeded) > return socket; > } > destroy socket; > return connection failure; That's one of the ways it could be implemented. And I think indeed proposed this in March, when Pekka triggered discussion on this in the TCPM WG list. (As a refinement, in case all connection attempts are aborted due to soft errors, the last for() loop could cycle several times, imposing an API-defined delay between each connection attempt). >This type of structure seems like the right thing for many apps, but not all. Are you thinking about any specific application? >But there are a lot of potential parameters, Correct. That's why I said "just because it's more abstract it doesn't mean it will be less powerful" in my previous post. >and experience is required. So you should only specify it in a library API. Now, back to the current scenario: We have one problem, only one API, and do not want all existing apps to have to be modified. The long term solution (which would probably avoid future posible problems) would be that of having applications use a High-Level API. But there has to be some work-around before there's such a High-Level API. The proposed solution tries to solve the problem without bothering application programmers. Thanks for your comments! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-v6ops@ops.ietf.org Sun Jul 18 04:49:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24926 for ; Sun, 18 Jul 2004 04:49:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bm7K2-000556-0Q for v6ops-data@psg.com; Sun, 18 Jul 2004 08:47:02 +0000 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bm7Jz-00054X-71 for v6ops@ops.ietf.org; Sun, 18 Jul 2004 08:47:00 +0000 Received: from fernando.gont.com.ar ([200.68.222.31]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id GAA18382; Sun, 18 Jul 2004 06:20:38 -0400 Message-Id: <4.3.2.7.2.20040718042456.00d3dbf0@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 18 Jul 2004 05:30:42 -0300 To: Eddie Kohler From: Fernando Gont Subject: Re: [tcpm] TCP, DCCP, v6, and ICMP soft errors [draft-ietf-v6ops-v6onbydefault-01] Cc: tcpm@ietf.org, v6ops@ops.ietf.org In-Reply-To: <40F9F0DA.7000001@cs.ucla.edu> References: <4.3.2.7.2.20040717223022.00b9a7d0@mail.daleclick.com> <4.3.2.7.2.20040717223022.00b9a7d0@mail.daleclick.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 20:39 17/07/2004 -0700, Eddie Kohler wrote: >>It says: >>---- cut here ---- >>4.1 Changing TCP's reaction to soft errors >> As discussed in Section 1, it may make sense for the fault recovery >> action to depend not only on the type of error being reported, but >> also on the time the error is reported. For example, one could infer >> that when an error arrives in response to opening a new connection, >> it is probably caused by opening the connection improperly, rather >> than by a transient network failure. [8] >>---- cut here ---- >>That means, we modify TCP fault isolation policy on the connection >>establishment phase, rather than changing the "meaning" of the error itself. > >The Host Requirements RFC codifies years of experience about whether or >not particular errors are "soft" or "hard". I'd disagree a bit here. The Host Requirements dates back to 1989. It considers, for example, "Fragmentation needed but DF bit set" as a hard error. However, this was letter considered a soft error, and used for the Path MTU Discovery Mechanism. That doesn't mean it's not a great source of experience, but that you should not consider it as "religion". >That experience is still valid, so shifting an error from "soft" to "hard" >(in terms of the response to that error) is problematic. Limiting the >shift to two connection states doesn't conceptually change this. I don't think implementing the proposed solution would lead to interoperability problems. The only scenario in which you could get an undesired "effect" would be that in which you tried to connect to a destination host (which had only one IP address) while there was transient network problem (that would elicit ICMP unreacheables) that was short enough that some later TCP retransmission would succeed. OTOH, this work-around could be enabled by default only when the destination port is that of an interactive service, such as the web. This is not discussed in the current draft, but I could include it if any of the WG participants thinks it would be convenient. For interactive services the delays in connection establishment attempts would be unacceptable. And in the event there was an scenario as the one I described above (where some TCP retransmission would have succeeded), the *user* would manually trigger another connection retry. Clark's paper has some discussion on all this. >>>>But RFC 1122 also says that TCP "SHOULD make the information [about the >>>>soft error] available to the application". This shows a way out of the >>>>conflict. >>IMHO, this was okay when applciation programmers were more knowledgeable >>about networking and protocol specifics. > >Many still are. That doesn't mean you must provide programmers an API that *requires* them to know about networking. (My point is just that requiring programmers to deal with protocol specifics would not be the best idea, *nowadays*). Would you have a database programmer (or whatever) set an option to decide how to react to soft errors? I mean, would you have him deciding whether to do it or not? >>Should we *nowadays* bother an *application* programmer with TCP >>soft/hard errors? >>I don't think so. > >I disagree pretty strongly. There are a couple APIs here. While there *could* be more than one API, we have only one: Sockets. Most apps implement all the same name resolution code, address cycling code, etc., as there not such a Higher-Level API. >The most fundamental is kernel/userlevel, and that's what I think we're >discussing. Not sure why you stress on "userlevel". A network connection is an IPC mechanism, after all. >Kernel/userlevel APIs should provide maximum flexibility for advanced >applications, using simple techniques; anything else leads to problems >later. Less advanced apps can rely on userlevel libraries to make things >easier. I'd say that you'd *need* a low level API just when playing wclosely to the network. Just because the API is more abstract does not mean it's least powerful. >The existing v6onbydefault draft already talks about such userlevel >libraries, and you did in your mail as well. Yes. Pekka triggered some discussion on this issue in March. And I proposed that of the Higher-Level API. BTW, my point was that having application such a low level API is what actually causes all this trouble. You have *applications* bothering with how a transport protocol reacts to network-layer errors. Summing-up: Make apps use a more abstract API, and the next time you have any of this type of "problem", you'll be able to do whatever you want (or so) without affecting the applications. >>>> This change is more incremental than the change currently proposed, >>>> and less invasive to the stack (no worries about SYN-SENT/SYN-RECEIVED >>>> state and so forth). >>Not sure what you mean. > >"Invasive" was a poor choice of words. My main concern is that a >problematic change is being justified by limiting its scope -- but the >wrong scope limitation was chosen. What is being proposed is to modify TCP's fault isolation policy at the connection establishment phase, in the presence of soft errors. *That* is what (I think) must be analyzed. i.e.: Is the proposed policy acceptable? What are the possible drawbacks? etc. >Applications depend on the current dest-unreachable-is-soft behavior, >including during connection initiation. There are already soft error conditions that are treated as hard ones. IIRC, POSIX allowed hosts to respond with an RST when a connection request was received and the listening queue was full. IIRC, Microsoft stacks behave that way. So, from an interoperability point of view, one could say that you should be prepared to handle this type of scenario. (No, I don't agree with responding with an RST when the listening queue is full. I'd just silently ignore the SYN). >I think the correct way to limit the scope of this change is to make the >application request it, Then you must have all applications add extra code to solve this problem. >rather than applying the change to all applications in a subset of TCP >states. Why should you apply the change in a "all or nothing" fashion? >If the app requests the new behavior, we know the app is prepared to >handle that behavior. Having programmers be aware of the new option, etc., will take time. Enabling the fix in a "by default" basis would be a shortcut to this. Thanks again for your comments! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-v6ops@ops.ietf.org Sun Jul 18 10:09:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10671 for ; Sun, 18 Jul 2004 10:09:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmCIj-0005Cv-8q for v6ops-data@psg.com; Sun, 18 Jul 2004 14:06:01 +0000 Received: from [159.226.39.7] (helo=ict.ac.cn) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BmCIh-0005CG-IL for v6ops@ops.ietf.org; Sun, 18 Jul 2004 14:05:59 +0000 Received: (qmail 22954 invoked by uid 507); 18 Jul 2004 14:03:24 -0000 Received: from unknown (HELO lenny) (liumin@211.161.40.162) by ict.ac.cn with SMTP; 18 Jul 2004 14:03:24 -0000 From: "Liu Min" To: "'Pekka Savola'" , Cc: Subject: RE: draft agenda for v6ops at IETF60 Date: Sun, 18 Jul 2004 22:14:08 +0800 Message-ID: <000001c46cd1$7e92a180$a228a1d3@lenny> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I have already requested for a time slot for 5 min to introduce the latest development & demonstration of Silkroad and discuss how to go forward. I'm very surprised that I have not received any feedback to tell me whether my application is accepted or not. But there is no arrangement in the draft agenda. :( Could you please tell me whether I have the chance to give my presentation? Best Wishes, Liu Min Institute of Computing Technology Chinese Academy of Sciences Tel: (86-10) 6256 5533-9240 E-mail: liumin@ict.ac.cn > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Pekka Savola > Sent: Sunday, July 18, 2004 4:23 AM > To: v6ops@ops.ietf.org > Cc: jonne.soininen@nokia.com > Subject: draft agenda for v6ops at IETF60 > > Hi, > > See below the current draft agenda for v6ops sessions at IETF60. > > The sessions are currently scheduled for Monday night and Friday > morning. Let's hope that the latter one, at least, changes. > > Updates or changes are very likely still. > > Please send in your thoughts, further agenda requests, comments, etc. > > ========= > > > > First session > ============= > (Tentatively scheduled for Monday night) > > Introduction and agenda bashing - 5 mins, Chairs/Savola > - Scribes! (Jabber also?) > > Document status - 15 mins, Chairs/Savola > - What has happened with WG documents lately > - GOAL: show the status of WG documents > > Moving forward with Mechanisms - 45 mins, Chairs/ADs > - [placeholder as of yet, plans still forming] > - GOAL: discuss the procedure of how to move forward > > VLAN Usage for IPv6 transition - 5 mins, Chown? > - draft-chown-v6ops-vlan-usage-01.txt [expired, to be revised] > - GOAL: describe the procedure, discuss whether to go for Informational RFC > > Enterprise solution case study: Campus Transition - 20 mins, Chown > - draft-chown-v6ops-campus-transition-00.txt > - examine a case study of applying the enterprise scenarios document, > discuss the issues. > - GOAL: give input to the Enterprise solutions work and the necessity > of transition tools. > > IPv6 Security Overview - 10 mins, Savola > - draft-savola-v6ops-security-overview-02.txt > - introduce the approach and justify the need; discuss changes. > - GOAL: take as a WG item, solicit an editor. > > Assisted Tunneling Requirements - 15 mins, Durand > - draft-ietf-v6ops-assisted-tunneling-requirements-00.txt > - go through open issues, discuss > - GOAL: resolve issues, revise and advance after IETF60 > > Tunnel-endpoint Discovery, 10 mins, Palet? > - draft-palet-v6ops-tun-auto-disc-01.txt > - discuss different approaches to discover the v6-in-v4 endpoint > (to be used with assisted tunneling and maybe others) > - GOAL: get more feedback, adopt as WG item? > > Secure IPv6 Tunneling - 10 mins, Graveman > - draft-tschofenig-v6ops-secure-tunnels-00.txt > - discuss the method of using IPsec to create secure v6-in-v4 tunnels > - GOAL: get more input, adopt as WG item? > > Protocol-41 Forwarding in NAT boxes - 10 mins, Palet > - [to be: draft-palet-v6ops-proto41-nat-05.txt] > - GOAL: discuss changes and approach, adopt as WG item for Informational > > Measurement of Misbehaving DNS Servers - 5 mins, Savola channeling Malone > - (based on draft-ietf-dnsop-misbehavior-against-aaaa-01.txt) > - GOAL: show relative numbers of misbehaving servers vs IPv6 records > > > Second session > ============== > (Tentatively scheduled for Friday morning, hopefully will change) > > [If good discussion is generated on the discussion items on the first > session, add time to discuss those here] > > IPv6 replacement for NAT boxes etc. - 10 mins, van de Welde? > - [no draft] > - GOAL: present early work on an Informational draft on how to deploy > v6 in environments where NATs and/or private addressing were used. > > Moving forward, take two, 30 mins, Chairs/ADs > - [placeholder] > - GOAL: continue tuning the process as necessary > > IPv6 Mobility Scenarios/Requirements update, 10 mins, Williams > - [follow-up on draft-yamamoto-mipv6node-v4trav-00.txt] > - GOAL: follow up from where we left off with in the last meeting > > "Auto-transition": picking the right mechanism - 10 mins, Palet > - draft-palet-v6ops-auto-trans-00.txt > - GOAL: discuss the concepts, whether useful for the WG. > > Distributed v6 security requirements/problem statement - 10 mins, Palet > - draft-palet-v6ops-ipv6security-00.txt > - draft-vives-v6ops-ipv6-security-ps-00.txt > - GOAL: get input from the WG > > [These might at least might drop off from the agenda if there are no > significant updates or interest:] > > Transition mechanisms update, 5 mins, Chairs/Savola > - draft-ietf-v6ops-mech-v2-03.txt > - GOAL: discuss how to address the DNS lookup ordering issue > > IPv6-on-by-Default - 5 mins, ? > - draft-ietf-v6ops-v6onbydefault-01.txt > - GOAL: discuss what has been happening with this work > > IPv6 Renumbering Procedures - 5 mins, Baker? > - draft-ietf-v6ops-ipv6-renumber-procedure-01.txt > - GOAL: discuss major issues, if raised during the IESG evaluation > > Advanced L3 IPv6 Exchange Model - 10 mins, Palet > - draft-morelli-v6ops-ipv6-ix-00.txt > - GOAL: get input from the WG > ============= > > From owner-v6ops@ops.ietf.org Sun Jul 18 13:06:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20516 for ; Sun, 18 Jul 2004 13:06:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmF55-0003zK-OP for v6ops-data@psg.com; Sun, 18 Jul 2004 17:04:07 +0000 Received: from [169.232.46.137] (helo=smtp.ucla.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmF54-0003yq-ML for v6ops@ops.ietf.org; Sun, 18 Jul 2004 17:04:06 +0000 Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.135]) by smtp.ucla.edu (8.12.11/8.12.11) with ESMTP id i6IH43UG015106; Sun, 18 Jul 2004 10:04:03 -0700 Received: from [192.168.1.101] (adsl-63-207-102-46.dsl.snfc21.pacbell.net [63.207.102.46]) (authenticated bits=0) by mail.ucla.edu (8.12.11/8.12.11) with ESMTP id i6IH410f032620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Jul 2004 10:04:02 -0700 Message-ID: <40FAAD9B.4000109@cs.ucla.edu> Date: Sun, 18 Jul 2004 10:04:27 -0700 From: Eddie Kohler User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont CC: tcpm@ietf.org, v6ops@ops.ietf.org Subject: Re: [tcpm] TCP, DCCP, v6, and ICMP soft errors [draft-ietf-v6ops-v6onbydefault-01] References: <4.3.2.7.2.20040717223022.00b9a7d0@mail.daleclick.com> <4.3.2.7.2.20040717223022.00b9a7d0@mail.daleclick.com> <4.3.2.7.2.20040718042456.00d3dbf0@mail.daleclick.com> In-Reply-To: <4.3.2.7.2.20040718042456.00d3dbf0@mail.daleclick.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Probable-Spam: no X-Spam-Hits: -4.019 X-Scanned-By: smtp.ucla.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS, SUBJ_HAS_UNIQ_ID autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think at this point we have to agree to disagree and, if this issue is considered important, get other opinions on it. The best kernel APIs provide mechanism, not policy, since policy changes and different apps want different policies. In my opinion draft-gont-tcpm-tcp-soft-errors codifies for all apps a policy that, if implemented, may/will reduce user-visible network connectivity. Therefore it should not be accepted; a new draft should provide a "mechanism" for implementing the soft-error behavior you need, discuss how to use that mechanism, and also potentially talk about a higher-level, library API that DTRT by default. Also, talking about "default behavior" and ease of app construction is a little disingenuous since there's no real installed base. Only apps that implement address cycling need the new behavior; this is a small set. Apps that don't cycle addresses: now there's an installed base. If anyone had practical data on Destination Unreachable errors -- in particular, how transient they tend to be for today's hosts -- this would be a great time to speak up. If Dest. Unreachable is frequently transient, that strengthens my case. If it's very infrequently transient, that strengthens draft-gont-tcpm-tcp-soft-errors. Thanks, Eddie From owner-v6ops@ops.ietf.org Sun Jul 18 13:20:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21610 for ; Sun, 18 Jul 2004 13:20:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmFJw-0005fj-0U for v6ops-data@psg.com; Sun, 18 Jul 2004 17:19:28 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmFJu-0005fT-KC for v6ops@ops.ietf.org; Sun, 18 Jul 2004 17:19:27 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 4D15581C7; Sun, 18 Jul 2004 19:19:20 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 07803-60; Sun, 18 Jul 2004 19:18:59 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id A7559803D; Sun, 18 Jul 2004 19:18:58 +0200 (CEST) Subject: Re: I-D ACTION:draft-ietf-v6ops-assisted-tunneling-requirements-00.txt From: Jeroen Massar To: Florent Parent Cc: Alain Durand , v6ops@ops.ietf.org In-Reply-To: <39E5D32D2058C17FCF537E52@blues> References: <200406281931.PAA25593@ietf.org> <1088496993.20311.133.camel@segesta.zurich.ibm.com> <39E5D32D2058C17FCF537E52@blues> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WeSGw283/u3+sc2CDS5o" Organization: Unfix Message-Id: <1090171121.9074.234.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 18 Jul 2004 19:18:42 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-WeSGw283/u3+sc2CDS5o Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-07-07 at 17:15, Florent Parent wrote: > > Section 5.4 > > Some NAT boxes will force-timeout mappings or have a very short timeout= . > > The tunneling or the setup protocol used should be able to recover thus > > from both endpoint address and port changes without loosing packets. >=20 > Yes. But "without loosing packets" need to be defined. e.g. if I have a=20 > ping(v6) in a loop going out of my tunnel and the NAT state changes, I wi= ll=20 > certainly loose ICMPv6 packets. Maybe you are referring to not loosing IP= v6=20 > connections instead? Indeed, as when one changes an IP address overcoming loosing packets is not possible in most cases unless one implements sequence numbers which defies a lot of things. Minimizing the loss though should be an objective. > > To also mitigate attacks based on 'knowledge' of endpoint information e= g > > by sniffing setup information packets it should be IMHO that the tunnel > > setup protocol is able to use some form of SSL/TLS mode thus making sur= e > > that the interaction between client and server is not readable maybe > > disclosing information that can be useful to attack the tunnel. >=20 > Again as an option that can be enabled/disabled? Of course optional, though it should be highly preferred. There are a number of organisations that require you to change passwords every 3 months but sending those passwords in clear text is a defacto use ;) > > It could also explain the user how to disable the client program. > > The client-program might also want to ask the user if it wants to use > > native or tunneled connectivity maybe in case where the native > > connectivity is misconfigured, and thus not working. > > > > Section 5.10 > > Fortunatly this is a should, typically, from what I have seen at least, > > most ISP's don't allow their customers to change reverse DNS entries. > > Also, tunnels should be seen as 'transit networks', the /48 routed to t= he > > client should have a means of registering dns servers though. >=20 > The current requirement has nothing about DNS prefix delegation. Are you=20 > saying it should be supported in the protocol? It could be handy if the protocol could be used for it, then again there are a number of other established protocols (DDNS for instance) that could be used here, then again, distributing keys etc is not defined there thus putting it into this protocol to allow the registration > > > > Appendix A > > "The registered mode:" > > "- implementation SHOULD turn it off by default" > > Shouldn't asking the client once be a good option? >=20 > Not following here. The user should be put to the question once if it wants a registered tunnel or not. If the question is not asked they will not use it. Greets, Jeroen --=-WeSGw283/u3+sc2CDS5o Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBA+rDxKaooUjM+fCMRAtg7AJsEnqQtKq6PIggVbZiW8pNFRYj2jQCfWaZM ydadX3aJNqIBr29t+NGct8Q= =cxxQ -----END PGP SIGNATURE----- --=-WeSGw283/u3+sc2CDS5o-- From owner-v6ops@ops.ietf.org Sun Jul 18 18:51:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08691 for ; Sun, 18 Jul 2004 18:51:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmKSd-000NYg-5z for v6ops-data@psg.com; Sun, 18 Jul 2004 22:48:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmKSc-000NYQ-0d for v6ops@ops.ietf.org; Sun, 18 Jul 2004 22:48:46 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6IMmdF07129; Mon, 19 Jul 2004 01:48:39 +0300 Date: Mon, 19 Jul 2004 01:48:39 +0300 (EEST) From: Pekka Savola To: Liu Min cc: v6ops@ops.ietf.org, Subject: RE: draft agenda for v6ops at IETF60 In-Reply-To: <000001c46cd1$7e92a180$a228a1d3@lenny> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 18 Jul 2004, Liu Min wrote: > I have already requested for a time slot for 5 min to introduce the > latest development & demonstration of Silkroad and discuss how to go > forward. I'm very surprised that I have not received any feedback to > tell me whether my application is accepted or not. But there is no > arrangement in the draft agenda. :( Could you please tell me whether > I have the chance to give my presentation? The primary reasoning for excluding this request from the agenda was that there isn't sufficient time, energy or need for covering all the mechanisms out there (and just having a presentation of one or a couple of them might be unfair). It looks like the discussion could also be held on the list -- as a matter of fact, I think there already was a long debate. (I personally recall the discussion ended silently, but it seemed as if Silkroad was a tunnel broker with UDP encapsulation for traversing NATs. But we have already had those on the table for years..) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 18 22:30:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20935 for ; Sun, 18 Jul 2004 22:30:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmNs0-00022v-Pq for v6ops-data@psg.com; Mon, 19 Jul 2004 02:27:12 +0000 Received: from [159.226.39.7] (helo=ict.ac.cn) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BmNrz-00022e-Fb for v6ops@ops.ietf.org; Mon, 19 Jul 2004 02:27:11 +0000 Received: (qmail 11401 invoked by uid 507); 19 Jul 2004 02:24:35 -0000 Received: from unknown (HELO ThinkPadX31) (liumin@159.226.39.104) by ict.ac.cn with SMTP; 19 Jul 2004 02:24:35 -0000 From: "Liu Min" To: "'Pekka Savola'" Cc: , Subject: RE: draft agenda for v6ops at IETF60 Date: Mon, 19 Jul 2004 10:27:02 +0800 Message-ID: <001801c46d37$e37e4a70$4b74a8c0@ThinkPadX31> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Firstly, I think if you want to reject one application, you should give = a feedback with the reason before you publish the draft agenda instead of "excluding silently". At least it's a good manner for chairman. Secondly, you said just having a presentation of one or a couple of mechanisms might be unfair (in your letter), did you mean that no = mechanism will give presentation in the IETF60? In addition, I don't understand why you said the discussion ended = silently. How do you make such judgment, one discussion is "ended" or "not ended"? = =20 Best Wishes, =20 Liu Min =20 Institute of Computing Technology Chinese Academy of Sciences Tel: (86-10) 6256 5533-9240=20 E-mail: liumin@ict.ac.cn > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf > Of Pekka Savola > Sent: Monday, July 19, 2004 6:49 AM > To: Liu Min > Cc: v6ops@ops.ietf.org; jonne.soininen@nokia.com > Subject: RE: draft agenda for v6ops at IETF60 >=20 > On Sun, 18 Jul 2004, Liu Min wrote: > > I have already requested for a time slot for 5 min to introduce the > > latest development & demonstration of Silkroad and discuss how to go > > forward. I'm very surprised that I have not received any feedback to > > tell me whether my application is accepted or not. But there is no > > arrangement in the draft agenda. :( Could you please tell me whether > > I have the chance to give my presentation? >=20 > The primary reasoning for excluding this request from the agenda was > that there isn't sufficient time, energy or need for covering all the > mechanisms out there (and just having a presentation of one or a > couple of them might be unfair). >=20 > It looks like the discussion could also be held on the list -- as a > matter of fact, I think there already was a long debate. >=20 > (I personally recall the discussion ended silently, but it seemed as > if Silkroad was a tunnel broker with UDP encapsulation for traversing > NATs. But we have already had those on the table for years..) >=20 > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon Jul 19 03:44:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21561 for ; Mon, 19 Jul 2004 03:44:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmSnA-000GkT-IJ for v6ops-data@psg.com; Mon, 19 Jul 2004 07:42:32 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmSn9-000GkF-JI for v6ops@ops.ietf.org; Mon, 19 Jul 2004 07:42:31 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 19 Jul 2004 00:44:20 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i6J7gSNv004602; Mon, 19 Jul 2004 00:42:29 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVL09892; Mon, 19 Jul 2004 00:41:17 -0700 (PDT) Message-Id: <6.1.1.1.2.20040719003829.063801d8@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Mon, 19 Jul 2004 00:40:56 -0700 To: Pekka Savola From: Fred Baker Subject: Re: draft agenda for v6ops at IETF60 Cc: v6ops@ops.ietf.org, jonne.soininen@nokia.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 11:23 PM 07/17/04 +0300, Pekka Savola wrote: >IPv6 Renumbering Procedures - 5 mins, Baker? > - draft-ietf-v6ops-ipv6-renumber-procedure-01.txt > - GOAL: discuss major issues, if raised during the IESG evaluation I'm looking at http://www.ietf.org/meetings/agenda_60.html, and I don't see v6ops listed. I thought it used to be... Are you sure we are Monday and Friday? So far, the IESG has not commented on the draft, or at least I have not seen the comments. From owner-v6ops@ops.ietf.org Mon Jul 19 06:50:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03537 for ; Mon, 19 Jul 2004 06:50:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmVgA-000GfC-Ui for v6ops-data@psg.com; Mon, 19 Jul 2004 10:47:30 +0000 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmVg6-000GeK-SW for v6ops@ops.ietf.org; Mon, 19 Jul 2004 10:47:27 +0000 Received: from fernando.gont.com.ar ([200.68.238.228]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id IAA21326; Mon, 19 Jul 2004 08:20:12 -0400 Message-Id: <4.3.2.7.2.20040719064951.00d38b00@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Jul 2004 07:10:20 -0300 To: Eddie Kohler From: Fernando Gont Subject: Re: [tcpm] TCP, DCCP, v6, and ICMP soft errors [draft-ietf-v6ops-v6onbydefault-01] Cc: tcpm@ietf.org, v6ops@ops.ietf.org, Pekka Savola In-Reply-To: <40FAAD9B.4000109@cs.ucla.edu> References: <4.3.2.7.2.20040718042456.00d3dbf0@mail.daleclick.com> <4.3.2.7.2.20040717223022.00b9a7d0@mail.daleclick.com> <4.3.2.7.2.20040717223022.00b9a7d0@mail.daleclick.com> <4.3.2.7.2.20040718042456.00d3dbf0@mail.daleclick.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_UNIQ_ID autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 10:04 18/07/2004 -0700, Eddie Kohler wrote: >The best kernel APIs provide mechanism, not policy, since policy changes >and different apps want different policies. We're talking about a fault isolation policy in a transport protocol. An application should not be concerned with it. >In my opinion draft-gont-tcpm-tcp-soft-errors codifies for all apps a >policy that, if implemented, may/will reduce user-visible network >connectivity. As stated both in the drafts and in my previous posts, the change in the policy is meant only for connections in the SYN-SENT and SYN-RECEIVED states. OTOH, if it's a non-interactive application that's using the connection (say, a mailserver), the application itself will trigger a retry some time later. If it was an interactive application, then a delay was not acceptable, anyway. >Therefore it should not be accepted; a new draft should provide a >"mechanism" for implementing the soft-error behavior you need, "mechanism"?? >discuss how to use that mechanism, Again, we're trying to solve problems in *applications*. >and also potentially talk about a higher-level, library API that DTRT by >default. Will include some stuff about a Higher-Level API in the next revision of the draft. >Also, talking about "default behavior" and ease of app construction is a >little disingenuous since there's no real installed base. I have no data about what the "real installed base" is. In any case, the "default behaviour" is crucial to how long it will take the fix to be used by programmers. > Only apps that implement address cycling need the new behavior; this is > a small set. Apps that don't cycle addresses: now there's an installed base. Address-cycling is well-known practice. RFC 1122, dated 1989, says applications SHOULD be prepared to do cycle on a list of IP addresses. >If anyone had practical data on Destination Unreachable errors -- in >particular, how transient they tend to be for today's hosts -- this would >be a great time to speak up. I disagree. No one is saying ICMP Unreacheables are hard errors. We're just saying that there's a potential problem of long delay in connection attempts (not only in v6, but could also be the case in IPv4), and that this problem could be worked around by changing TCP's reaction to soft errors in the connection *establishment* phase. >If Dest. Unreachable is frequently transient, that strengthens my >case. If it's very infrequently transient, that strengthens >draft-gont-tcpm-tcp-soft-errors. That would strength your case if someone were proposing to abort connnections in *any* state. Best Regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-v6ops@ops.ietf.org Mon Jul 19 07:20:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05385 for ; Mon, 19 Jul 2004 07:20:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmWC3-000MF9-Vs for v6ops-data@psg.com; Mon, 19 Jul 2004 11:20:27 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmWC0-000MEF-NL for v6ops@ops.ietf.org; Mon, 19 Jul 2004 11:20:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6JBKEN19785; Mon, 19 Jul 2004 14:20:14 +0300 Date: Mon, 19 Jul 2004 14:20:14 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: v6ops@ops.ietf.org, Subject: Re: draft agenda for v6ops at IETF60 In-Reply-To: <6.1.1.1.2.20040719003829.063801d8@mira-sjc5-b.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 19 Jul 2004, Fred Baker wrote: > At 11:23 PM 07/17/04 +0300, Pekka Savola wrote: > >IPv6 Renumbering Procedures - 5 mins, Baker? > > - draft-ietf-v6ops-ipv6-renumber-procedure-01.txt > > - GOAL: discuss major issues, if raised during the IESG evaluation > > I'm looking at http://www.ietf.org/meetings/agenda_60.html, and I don't see > v6ops listed. I thought it used to be... Are you sure we are Monday and Friday? The HTML version just hasn't been updated yet; TXT shows us there (for the moment at least). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Jul 19 07:59:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07598 for ; Mon, 19 Jul 2004 07:59:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmWmi-0001hA-IK for v6ops-data@psg.com; Mon, 19 Jul 2004 11:58:20 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmWmh-0001gj-4V for v6ops@ops.ietf.org; Mon, 19 Jul 2004 11:58:19 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000142294.msg for ; Mon, 19 Jul 2004 14:01:11 +0200 Message-ID: <19bd01c46d87$a5a8eb60$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: draft-palet-v6ops-auto-trans-01.txt Date: Mon, 19 Jul 2004 13:58:02 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 19 Jul 2004 14:01:11 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 19 Jul 2004 14:01:15 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, We have submitted the updated version of the "Evaluation of IPv6 Auto-Transition Algorithm" document. Is already posted at http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-auto-trans-01.txt. Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Jul 19 08:01:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07721 for ; Mon, 19 Jul 2004 08:01:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmWpR-0002Gj-Ua for v6ops-data@psg.com; Mon, 19 Jul 2004 12:01:09 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmWpO-0002Fp-Pl for v6ops@ops.ietf.org; Mon, 19 Jul 2004 12:01:07 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000142307.msg for ; Mon, 19 Jul 2004 14:04:02 +0200 Message-ID: <19c301c46d88$0ca7cd40$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: draft-vives-v6ops-ipv6-security-ps-01.txt and draft-palet-v6ops-ipv6security-01.txt Date: Mon, 19 Jul 2004 14:00:55 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 19 Jul 2004 14:04:02 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 19 Jul 2004 14:04:04 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, We have submitted the updated versions of the IPv6 Distributed Security Problem Statement and IPv6 Distributed Security Requirements documents. They are available at http://www.consulintel.euro6ix.org/ietf/draft-vives-v6ops-ipv6-security-ps-01.txt and http://www.consulintel.euro6ix.org/ietf/draft-vives-v6ops-ipv6-security-ps-01.txt. Inputs welcome ! Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Jul 19 08:12:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08519 for ; Mon, 19 Jul 2004 08:12:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmWzn-0004Vp-92 for v6ops-data@psg.com; Mon, 19 Jul 2004 12:11:51 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmWzm-0004VW-7C for v6ops@ops.ietf.org; Mon, 19 Jul 2004 12:11:50 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000142343.msg for ; Mon, 19 Jul 2004 14:14:43 +0200 Message-ID: <1a3d01c46d89$88cb52b0$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <19c301c46d88$0ca7cd40$640a0a0a@consulintel.es> Subject: Re: draft-vives-v6ops-ipv6-security-ps-01.txt and draft-palet-v6ops-ipv6security-01.txt Date: Mon, 19 Jul 2004 14:11:06 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 19 Jul 2004 14:14:43 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 19 Jul 2004 14:14:47 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable oops. sorry, wrong link for the 2nd one. The right one is http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-ipv6security-01.txt. ---- Original Message ---- From: "JORDI PALET MARTINEZ" To: Sent: Monday, July 19, 2004 2:00 PM Subject: draft-vives-v6ops-ipv6-security-ps-01.txt and draft-palet-v6ops-ipv6security-01.txt=20 > Hi, >=20 > We have submitted the updated versions of the IPv6 Distributed Security > Problem Statement and IPv6 Distributed Security Requirements documents.=20 >=20 > They are available at > http://www.consulintel.euro6ix.org/ietf/draft-vives-v6ops-ipv6-security-ps-01.txt > and > http://www.consulintel.euro6ix.org/ietf/draft-vives-v6ops-ipv6-security-ps-01.txt. >=20 > Inputs welcome ! >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com >=20 > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. =20 >=20 >=20 >=20 >=20 >=20 >=20 > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com >=20 > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Jul 19 09:48:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16851 for ; Mon, 19 Jul 2004 09:48:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmYSs-000G4j-1o for v6ops-data@psg.com; Mon, 19 Jul 2004 13:45:58 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmYSo-000G3w-Pa for v6ops@ops.ietf.org; Mon, 19 Jul 2004 13:45:55 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6JDjBgB055378; Mon, 19 Jul 2004 13:45:11 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6JDjANX179054; Mon, 19 Jul 2004 15:45:10 +0200 Received: from zurich.ibm.com (sig-9-145-224-217.de.ibm.com [9.145.224.217]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA72190; Mon, 19 Jul 2004 15:45:09 +0200 Message-ID: <40FBD064.6080207@zurich.ibm.com> Date: Mon, 19 Jul 2004 15:45:08 +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: Fernando Gont CC: Eddie Kohler , Pekka Savola , v6ops@ops.ietf.org, tcpm@ietf.org, dccp@ietf.org Subject: Re: [tcpm] Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt References: <4.3.2.7.2.20040717230639.00be4250@mail.daleclick.com> In-Reply-To: <4.3.2.7.2.20040717230639.00be4250@mail.daleclick.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fernando Gont wrote: ... > Of course, if you provided application programmers with a higher-level > API, all the soft errors and address cycling issues could be handled > bellow the application. This is so kind of blindingly obvious that I'm surprised we are even discussing it as a matter of principle... Apps in Java already assume that such problems (including the minor matter of which IP version to use) are solved inside the Java run time system. Many major middleware packages include an abstraction layer that hides the network (the new XIO package in the Globus grid toolkit is an example). Whether we can standardize such an abstraction, or only make recommendations, is another question. Brian From owner-v6ops@ops.ietf.org Mon Jul 19 09:54:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17259 for ; Mon, 19 Jul 2004 09:54:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmYag-000HON-5f for v6ops-data@psg.com; Mon, 19 Jul 2004 13:54:02 +0000 Received: from [169.232.48.137] (helo=smtp.ucla.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmYaf-000HO6-9p for v6ops@ops.ietf.org; Mon, 19 Jul 2004 13:54:01 +0000 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.135]) by smtp.ucla.edu (8.12.11/8.12.11) with ESMTP id i6JDrwRd029616; Mon, 19 Jul 2004 06:53:58 -0700 Received: from [192.168.1.101] (s91-73.resnet.ucla.edu [169.232.91.73]) (authenticated bits=0) by mail.ucla.edu (8.12.11/8.12.11) with ESMTP id i6JDrvaA015544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jul 2004 06:53:58 -0700 Message-ID: <40FBD296.2070908@cs.ucla.edu> Date: Mon, 19 Jul 2004 06:54:30 -0700 From: Eddie Kohler User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont CC: tcpm@ietf.org, v6ops@ops.ietf.org Subject: Re: [tcpm] TCP, DCCP, v6, and ICMP soft errors [draft-ietf-v6ops-v6onbydefault-01] References: <4.3.2.7.2.20040718042456.00d3dbf0@mail.daleclick.com> <4.3.2.7.2.20040717223022.00b9a7d0@mail.daleclick.com> <4.3.2.7.2.20040717223022.00b9a7d0@mail.daleclick.com> <4.3.2.7.2.20040718042456.00d3dbf0@mail.daleclick.com> <4.3.2.7.2.20040719064951.00d38b00@mail.daleclick.com> In-Reply-To: <4.3.2.7.2.20040719064951.00d38b00@mail.daleclick.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Probable-Spam: no X-Spam-Hits: -4.019 X-Scanned-By: smtp.ucla.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,SUBJ_HAS_UNIQ_ID autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just one point: >> If Dest. Unreachable is frequently transient, that strengthens my >> case. If it's very infrequently transient, that strengthens >> draft-gont-tcpm-tcp-soft-errors. > > That would strength your case if someone were proposing to abort > connnections in *any* state. No. Dest unreachables might commonly be received at the beginning of a connection -- as a laptop wakes up, say. I would expect them to be more common at the beginning of a connection than the middle. Eddie From owner-v6ops@ops.ietf.org Mon Jul 19 09:58:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17569 for ; Mon, 19 Jul 2004 09:58:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmYed-000I29-MU for v6ops-data@psg.com; Mon, 19 Jul 2004 13:58:07 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmYeb-000I1P-35 for v6ops@ops.ietf.org; Mon, 19 Jul 2004 13:58:05 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6JDvtGP111450; Mon, 19 Jul 2004 13:57:55 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6JDvtxi280300; Mon, 19 Jul 2004 15:57:55 +0200 Received: from zurich.ibm.com (sig-9-145-224-217.de.ibm.com [9.145.224.217]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA72766; Mon, 19 Jul 2004 15:57:53 +0200 Message-ID: <40FBD360.5040001@zurich.ibm.com> Date: Mon, 19 Jul 2004 15:57:52 +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: Pekka Savola CC: v6ops@ops.ietf.org, alain.durand@sun.com, florent.parent@hexago.com Subject: Re: WG Last Call: draft-ietf-v6ops-assisted-tunneling-requirements-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think this draft will have an easier future if the "R" word ("requirement") is replaced by "goal" and the normative MUSTs/SHOULDs etc. are changed to lower case. Requirements written in normative language always lead to a lot of rather futile discussion. (If you don't do this, the introduction needs the traditional paragraph citing RFC 2119, which is listed in the references but not cited in the text.) The substance of the document seems good to me. Brian Pekka Savola wrote: > Hi all, > > (co-chair hat on) > > This is the WG Last Call for comments on sending > draft-ietf-v6ops-assisted-tunneling-requirements-00.txt, "Requirements > for assisted tunneling" to the IESG for consideration as Informational > RFC: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt > > This document will be used as a basis for possible (re-)design of > appropriate transition mechanisms. > > Please review the document carefully, and send your feedback to the > list. Please also indicate whether or not you believe that this > document is ready to go to the IESG. > > The last call will end in about 3.5 weeks, on 9th August. The large > WGLC time is due to the IETF meeting. It is recommended that > participants read and comment prior to the IETF as the topic will be > discussed there. > > Thanks! > > From owner-v6ops@ops.ietf.org Mon Jul 19 15:56:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19481 for ; Mon, 19 Jul 2004 15:56:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmeD9-000I1s-L5 for v6ops-data@psg.com; Mon, 19 Jul 2004 19:54:07 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmeD8-000I1W-In for v6ops@ops.ietf.org; Mon, 19 Jul 2004 19:54:06 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19356; Mon, 19 Jul 2004 15:54:03 -0400 (EDT) Message-Id: <200407191954.PAA19356@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-05.txt Date: Mon, 19 Jul 2004 15:54:03 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Network Scenarios Author(s) : J. Bound Filename : draft-ietf-v6ops-ent-scenarios-05.txt Pages : 18 Date : 2004-7-19 This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-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-v6ops-ent-scenarios-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-v6ops-ent-scenarios-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: <2004-7-19152635.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-scenarios-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-19152635.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Jul 19 18:31:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24035 for ; Mon, 19 Jul 2004 18:31:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bmgd8-0001t4-2f for v6ops-data@psg.com; Mon, 19 Jul 2004 22:29:06 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bmgd6-0001se-SU for v6ops@ops.ietf.org; Mon, 19 Jul 2004 22:29:05 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 25CED6969 for ; Mon, 19 Jul 2004 18:29:04 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 19 Jul 2004 17:49:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C46DDA.351BDD59" Subject: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-05.txt Date: Mon, 19 Jul 2004 17:49:01 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B06AFF075@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-ietf-v6ops-ent-scenarios-05.txt Thread-Index: AcRtytA60wfL50KqTwSEmOP/PVIlcwADz02w From: "Bound, Jim" To: X-OriginalArrivalTime: 19 Jul 2004 21:49:04.0036 (UTC) FILETIME=[3574C640:01C46DDA] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C46DDA.351BDD59 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Ok here is the update with correct boilers as -05. (thanks to Pekka S. for assistance to catch these in role as Chair). /jim -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 19, 2004 3:54 PM To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Network Scenarios Author(s) : J. Bound Filename : draft-ietf-v6ops-ent-scenarios-05.txt Pages : 18 Date : 2004-7-19 =09 This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-05.tx t 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. =20 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-v6ops-ent-scenarios-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-v6ops-ent-scenarios-05.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C46DDA.351BDD59 Content-Type: application/octet-stream; name="ATT763468.TXT" Content-Description: ATT763468.TXT Content-Disposition: attachment; filename="ATT763468.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDA0LTctMTkxNTI2MzUuSS1EQGlldGYub3JnPg0KDQpF TkNPRElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi12Nm9wcy1lbnQt c2NlbmFyaW9zLTA1LnR4dA0K ------_=_NextPart_001_01C46DDA.351BDD59 Content-Type: application/octet-stream; name="draft-ietf-v6ops-ent-scenarios-05.URL" Content-Description: draft-ietf-v6ops-ent-scenarios-05.URL Content-Disposition: attachment; filename="draft-ietf-v6ops-ent-scenarios-05.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXY2b3BzLWVudC1zY2VuYXJpb3MtMDUudHh0DQo= ------_=_NextPart_001_01C46DDA.351BDD59-- From owner-v6ops@ops.ietf.org Mon Jul 19 20:56:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17723 for ; Mon, 19 Jul 2004 20:56:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmitJ-000409-Qg for v6ops-data@psg.com; Tue, 20 Jul 2004 00:53:57 +0000 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmitF-0003yo-0H for v6ops@ops.ietf.org; Tue, 20 Jul 2004 00:53:55 +0000 Received: from fernando.gont.com.ar ([200.68.210.96]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id WAA23146; Mon, 19 Jul 2004 22:27:14 -0400 Message-Id: <4.3.2.7.2.20040719214620.00d4a7d0@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Jul 2004 21:52:13 -0300 To: Eddie Kohler From: Fernando Gont Subject: Re: [tcpm] TCP, DCCP, v6, and ICMP soft errors [draft-ietf-v6ops-v6onbydefault-01] Cc: tcpm@ietf.org, v6ops@ops.ietf.org In-Reply-To: <40FBD296.2070908@cs.ucla.edu> References: <4.3.2.7.2.20040719064951.00d38b00@mail.daleclick.com> <4.3.2.7.2.20040718042456.00d3dbf0@mail.daleclick.com> <4.3.2.7.2.20040717223022.00b9a7d0@mail.daleclick.com> <4.3.2.7.2.20040717223022.00b9a7d0@mail.daleclick.com> <4.3.2.7.2.20040718042456.00d3dbf0@mail.daleclick.com> <4.3.2.7.2.20040719064951.00d38b00@mail.daleclick.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_UNIQ_ID autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 06:54 19/07/2004 -0700, Eddie Kohler wrote: >>>If Dest. Unreachable is frequently transient, that strengthens my >>>case. If it's very infrequently transient, that strengthens >>>draft-gont-tcpm-tcp-soft-errors. >>That would strength your case if someone were proposing to abort >>connnections in *any* state. >No. Dest unreachables might commonly be received at the beginning of a >connection -- as a laptop wakes up, say. Not sure what configuration you're thinking of. A laptop connected to a network by means of an Ethernet, for example, won't elicit an ICMP Destination Unreacheable. The upstream router will send the ARP request, which will never be responded. In case there was an entry in the ARP cache, the segment *will* be sent on the network segment, but it won't elicit an ICMP Destination Unreacheable, either. >I would expect them to be more common at the beginning of a connection >than the middle. Not sure why you think so. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-v6ops@ops.ietf.org Mon Jul 19 20:56:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17774 for ; Mon, 19 Jul 2004 20:56:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmivP-0004P8-Ef for v6ops-data@psg.com; Tue, 20 Jul 2004 00:56:07 +0000 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmivL-0004Nc-Dt for v6ops@ops.ietf.org; Tue, 20 Jul 2004 00:56:05 +0000 Received: from fernando.gont.com.ar ([200.68.210.96]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id WAA23142; Mon, 19 Jul 2004 22:26:56 -0400 Message-Id: <4.3.2.7.2.20040719214200.00d875e0@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Jul 2004 21:46:11 -0300 To: Brian E Carpenter From: Fernando Gont Subject: Re: [tcpm] Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt Cc: Eddie Kohler , Pekka Savola , v6ops@ops.ietf.org, tcpm@ietf.org, dccp@ietf.org In-Reply-To: <40FBD064.6080207@zurich.ibm.com> References: <4.3.2.7.2.20040717230639.00be4250@mail.daleclick.com> <4.3.2.7.2.20040717230639.00be4250@mail.daleclick.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 15:45 19/07/2004 +0200, Brian E Carpenter wrote: >>Of course, if you provided application programmers with a higher-level >>API, all the soft errors and address cycling issues could be handled >>bellow the application. > >This is so kind of blindingly obvious that I'm surprised we are >even discussing it as a matter of principle... [....] >Whether we can standardize such an abstraction, or only make >recommendations, is another question. That's precisely the point: don't make the Sockets API less abstract than it currently is, and don't bother programmers with stuff they shouldn't be required to know. And propose the idea of a Higher-Level API, so that applications won't be influenced by changes in protocol specifics next time we're are faced with a protocol specific issue. BTW, what do you think of the proposed solution? -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-v6ops@ops.ietf.org Tue Jul 20 06:35:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06991 for ; Tue, 20 Jul 2004 06:35:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmrvD-0007Ss-91 for v6ops-data@psg.com; Tue, 20 Jul 2004 10:32:31 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmrvA-0007SQ-0M for v6ops@ops.ietf.org; Tue, 20 Jul 2004 10:32:28 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i6KAWQnE005666 for ; Tue, 20 Jul 2004 11:32:26 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA28255 for ; Tue, 20 Jul 2004 11:32:25 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i6KAWPY28184 for v6ops@ops.ietf.org; Tue, 20 Jul 2004 11:32:25 +0100 Date: Tue, 20 Jul 2004 11:32:25 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-05.txt Message-ID: <20040720103225.GM23475@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B06AFF075@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B06AFF075@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Jul 19, 2004 at 05:49:01PM -0400, Bound, Jim wrote: > Folks, > > Ok here is the update with correct boilers as -05. (thanks to Pekka S. > for assistance to catch these in role as Chair). > > Title : IPv6 Enterprise Network Scenarios > Author(s) : J. Bound > Filename : draft-ietf-v6ops-ent-scenarios-05.txt For info, we have submitted a new I-D that tries to apply this generic enterprise draft to the specific case study of IPv6 transition on a large academic campus department. http://www.ietf.org/internet-drafts/draft-chown-v6ops-campus-transition-00.txt It is only a start, but the issues raised for consideration by the generic ent-scenarios draft have been very helpful. Because our deployment is using VLANs to distribute IPv6 on the wire(less), we have also updated our VLAN usage draft: This should appear here soon: http://www.ietf.org/internet-drafts/draft-chown-v6ops-vlan-usage-01.txt But if that doesn't work yet try here: http://www.ecs.soton.ac.uk/~tjc/ietf/draft-chown-v6ops-vlan-usage-01.txt In this draft we describe the usage of a parallel IPv6 routing infrastructure with IPv6 distributed via VLANs as an alternative, more structured, intra-site solution than ISATAP. It requires extra hardware (PC router(s) and VLAN support) but is working very nicely for us at present. I think Pekka is allowing a small time slot for each draft in San Diego. Tim From owner-v6ops@ops.ietf.org Tue Jul 20 14:46:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14775 for ; Tue, 20 Jul 2004 14:46:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bmzar-000Fhh-Ux for v6ops-data@psg.com; Tue, 20 Jul 2004 18:44:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bmzaq-000FhI-9O for v6ops@ops.ietf.org; Tue, 20 Jul 2004 18:44:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6KIhHR21370; Tue, 20 Jul 2004 21:43:17 +0300 Date: Tue, 20 Jul 2004 21:43:17 +0300 (EEST) From: Pekka Savola To: david.kessens@nokia.com, , , Subject: Request to Advance "IPv6 Enterprise Network Scenarios" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk David, On behalf of the v6ops WG, we'd like to request that the following document be published as Informational RFC: IPv6 Enterprise Network Scenarios http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-05.txt The WG last call was completed on May 26th. The document has been revised to address the comments raised, and subsequent revisions have fixed editorial issues and a few other comments. Thanks, Pekka & Jonne v6ops WG co-chairs From owner-v6ops@ops.ietf.org Tue Jul 20 16:13:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24395 for ; Tue, 20 Jul 2004 16:13:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bn0y5-00016m-Ps for v6ops-data@psg.com; Tue, 20 Jul 2004 20:12:05 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bn0y4-00016X-Oc for v6ops@ops.ietf.org; Tue, 20 Jul 2004 20:12:05 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24292; Tue, 20 Jul 2004 16:12:01 -0400 (EDT) Message-Id: <200407202012.QAA24292@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-6to4-security-04.txt Date: Tue, 20 Jul 2004 16:12:01 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Security Considerations for 6to4 Author(s) : P. Savola, C. Patel Filename : draft-ietf-v6ops-6to4-security-04.txt Pages : 41 Date : 2004-7-20 The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over- IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 Routers and Relay Routers, which accept and decapsulate IPv4 protocol-41 ('IPv6-in-IPv4') traffic from anywhere. There aren't many constraints on the embedded IPv6 packets, or where IPv4 traffic will be automatically tunneled to. These could enable one to go around access controls, and more likely, being able to perform proxy Denial of Service attacks using 6to4 relays or routers as reflectors. Anyone is also capable of spoofing traffic from non-6to4 addresses, as if it was coming from a relay, to a 6to4 node. This document discusses these issues in more detail and tries to suggest enhancements to alleviate the problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-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-v6ops-6to4-security-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-v6ops-6to4-security-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: <2004-7-20160041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-6to4-security-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-6to4-security-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20160041.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Jul 20 16:13:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24420 for ; Tue, 20 Jul 2004 16:13:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bn0xd-00013Z-K7 for v6ops-data@psg.com; Tue, 20 Jul 2004 20:11:37 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bn0xc-00013F-HX for v6ops@ops.ietf.org; Tue, 20 Jul 2004 20:11:36 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24261; Tue, 20 Jul 2004 16:11:33 -0400 (EDT) Message-Id: <200407202011.QAA24261@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-v6onbydefault-03.txt Date: Tue, 20 Jul 2004 16:11:33 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Issues with Dual Stack IPv6 on by Default Author(s) : S. Roy, et al. Filename : draft-ietf-v6ops-v6onbydefault-03.txt Pages : 14 Date : 2004-7-20 This document discusses problems that can occur when dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. The problems include application connection delays, poor connectivity, and network insecurity. The purpose of this memo is to raise awareness of these problems so that they can be fixed or worked around, not to try to specify whether IPv6 should be enabled by default or not. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6onbydefault-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-v6onbydefault-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-v6onbydefault-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20160033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-v6onbydefault-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-v6onbydefault-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20160033.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jul 21 03:50:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25336 for ; Wed, 21 Jul 2004 03:50:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnBnn-000DY0-Ai for v6ops-data@psg.com; Wed, 21 Jul 2004 07:46:11 +0000 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnBnc-000DW7-Dd for v6ops@ops.ietf.org; Wed, 21 Jul 2004 07:46:00 +0000 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:b0f7:7d0a:26c1:7b27]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4D3D51525D; Wed, 21 Jul 2004 16:45:59 +0900 (JST) Date: Wed, 21 Jul 2004 16:45:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: v6ops@ops.ietf.org, jonne.soininen@nokia.com Subject: Re: draft agenda for v6ops at IETF60 In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Sat, 17 Jul 2004 23:23:23 +0300 (EEST), >>>>> Pekka Savola said: > The sessions are currently scheduled for Monday night and Friday > morning. Let's hope that the latter one, at least, changes. Has this schedule been fixed? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Wed Jul 21 04:37:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28150 for ; Wed, 21 Jul 2004 04:37:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnCYy-000JsB-I6 for v6ops-data@psg.com; Wed, 21 Jul 2004 08:34:56 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnCYx-000JrD-Go for v6ops@ops.ietf.org; Wed, 21 Jul 2004 08:34:55 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i6L8YsnE029678 for ; Wed, 21 Jul 2004 09:34:54 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA26823 for ; Wed, 21 Jul 2004 09:34:50 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i6L8Yoq25674 for v6ops@ops.ietf.org; Wed, 21 Jul 2004 09:34:50 +0100 Date: Wed, 21 Jul 2004 09:34:50 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft agenda for v6ops at IETF60 Message-ID: <20040721083450.GD24352@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Jul 21, 2004 at 04:45:59PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Sat, 17 Jul 2004 23:23:23 +0300 (EEST), > >>>>> Pekka Savola said: > > > The sessions are currently scheduled for Monday night and Friday > > morning. Let's hope that the latter one, at least, changes. > > Has this schedule been fixed? How about getting v6ops back into the mainstream agenda and moving something from Thursday... bmwg might be a good candidate...? Tim From owner-v6ops@ops.ietf.org Wed Jul 21 14:38:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11082 for ; Wed, 21 Jul 2004 14:38:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnLvn-000MZW-7o for v6ops-data@psg.com; Wed, 21 Jul 2004 18:35:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnLvk-000MYt-8H for v6ops@ops.ietf.org; Wed, 21 Jul 2004 18:35:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6LIZ2m16633 for ; Wed, 21 Jul 2004 21:35:02 +0300 Date: Wed, 21 Jul 2004 21:35:02 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: draft agenda for v6ops at IETF60 In-Reply-To: <20040721083450.GD24352@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 21 Jul 2004, Tim Chown wrote: > On Wed, Jul 21, 2004 at 04:45:59PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > >>>>> On Sat, 17 Jul 2004 23:23:23 +0300 (EEST), > > >>>>> Pekka Savola said: > > > > > The sessions are currently scheduled for Monday night and Friday > > > morning. Let's hope that the latter one, at least, changes. > > > > Has this schedule been fixed? To answer Jinmei's question: the schedule is not cast in stone yet ("fixed" in one meaning) but it hasn't been changed at least yet ("fixed in another meaning). > How about getting v6ops back into the mainstream agenda and moving > something from Thursday... bmwg might be a good candidate...? Let's see what can be done.. the scheduling is really tight. If the slot would be on Friday, I don't think we could use more than 1 - 1.5 hours out of it in any case.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jul 21 15:16:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14647 for ; Wed, 21 Jul 2004 15:16:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnMY7-0002ML-M3 for v6ops-data@psg.com; Wed, 21 Jul 2004 19:14:43 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnMY6-0002M3-AT for v6ops@ops.ietf.org; Wed, 21 Jul 2004 19:14:42 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i6LJEfnE002208 for ; Wed, 21 Jul 2004 20:14:41 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA07080 for ; Wed, 21 Jul 2004 20:14:40 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i6LJEet09948 for v6ops@ops.ietf.org; Wed, 21 Jul 2004 20:14:40 +0100 Date: Wed, 21 Jul 2004 20:14:40 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft agenda for v6ops at IETF60 Message-ID: <20040721191440.GC9194@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20040721083450.GD24352@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Jul 21, 2004 at 09:35:02PM +0300, Pekka Savola wrote: > > > How about getting v6ops back into the mainstream agenda and moving > > something from Thursday... bmwg might be a good candidate...? > > Let's see what can be done.. the scheduling is really tight. If the > slot would be on Friday, I don't think we could use more than 1 - 1.5 > hours out of it in any case.. Thanks, it would be really nice to get the v6ops slot into the mainstream program, and Thursday am looks like a reasonable option. I think quite a few people have been caught out by the unusual scheduling. Tim From owner-v6ops@ops.ietf.org Wed Jul 21 20:52:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14564 for ; Wed, 21 Jul 2004 20:52:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnRmI-000LcV-CS for v6ops-data@psg.com; Thu, 22 Jul 2004 00:49:42 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnRmF-000Lc7-9P for v6ops@ops.ietf.org; Thu, 22 Jul 2004 00:49:39 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6M0nTa05447; Wed, 21 Jul 2004 17:49:29 -0700 X-mProtect: <200407220049> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEcroZg; Wed, 21 Jul 2004 17:49:27 PDT Message-ID: <40FF0F21.80007@iprg.nokia.com> Date: Wed, 21 Jul 2004 17:49:37 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org, jonne.soininen@nokia.com Subject: Re: draft agenda for v6ops at IETF60 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Pekka, I would like to request an agenda slot to discuss: http://www.geocities.com/osprey67/v6v4inet-01.txt http://www.ietf.org/internet-drafts/draft-templin-v6v4inet-00.txt (The -01 updates the current -00 and will be submitted after the I-D repository re-opens.) The document discusses a general framework for IPv6/IPv4 coexistence and, as such, is not specific to any particular mechanism. The abstract appears below: Thanks - Fred ftemplin@iprg.nokia.com Abstract The IPv6 128-bit address space was designed as a solution for the 32-bit limitation of IPv4, but the proliferation of IPv4 in the global Internet continues via private addressing domains behind Network Address Translators (NATs). Furthermore, a formerly popular viewpoint that IPv6 networks would soon replace IPv4 networks seems to be yielding to an emerging viewpoint of long-term coexistence. This document proposes a coexistence scenario with IPv6 for end-to- end addressing and IPv4 for inter-networking. Pekka Savola wrote: >Hi, > >See below the current draft agenda for v6ops sessions at IETF60. > >The sessions are currently scheduled for Monday night and Friday >morning. Let's hope that the latter one, at least, changes. > >Updates or changes are very likely still. > >Please send in your thoughts, further agenda requests, comments, etc. > >========= > > > >First session >============= >(Tentatively scheduled for Monday night) > >Introduction and agenda bashing - 5 mins, Chairs/Savola > - Scribes! (Jabber also?) > >Document status - 15 mins, Chairs/Savola > - What has happened with WG documents lately > - GOAL: show the status of WG documents > >Moving forward with Mechanisms - 45 mins, Chairs/ADs > - [placeholder as of yet, plans still forming] > - GOAL: discuss the procedure of how to move forward > >VLAN Usage for IPv6 transition - 5 mins, Chown? > - draft-chown-v6ops-vlan-usage-01.txt [expired, to be revised] > - GOAL: describe the procedure, discuss whether to go for Informational RFC > >Enterprise solution case study: Campus Transition - 20 mins, Chown > - draft-chown-v6ops-campus-transition-00.txt > - examine a case study of applying the enterprise scenarios document, > discuss the issues. > - GOAL: give input to the Enterprise solutions work and the necessity > of transition tools. > >IPv6 Security Overview - 10 mins, Savola > - draft-savola-v6ops-security-overview-02.txt > - introduce the approach and justify the need; discuss changes. > - GOAL: take as a WG item, solicit an editor. > >Assisted Tunneling Requirements - 15 mins, Durand > - draft-ietf-v6ops-assisted-tunneling-requirements-00.txt > - go through open issues, discuss > - GOAL: resolve issues, revise and advance after IETF60 > >Tunnel-endpoint Discovery, 10 mins, Palet? > - draft-palet-v6ops-tun-auto-disc-01.txt > - discuss different approaches to discover the v6-in-v4 endpoint > (to be used with assisted tunneling and maybe others) > - GOAL: get more feedback, adopt as WG item? > >Secure IPv6 Tunneling - 10 mins, Graveman > - draft-tschofenig-v6ops-secure-tunnels-00.txt > - discuss the method of using IPsec to create secure v6-in-v4 tunnels > - GOAL: get more input, adopt as WG item? > >Protocol-41 Forwarding in NAT boxes - 10 mins, Palet > - [to be: draft-palet-v6ops-proto41-nat-05.txt] > - GOAL: discuss changes and approach, adopt as WG item for Informational > >Measurement of Misbehaving DNS Servers - 5 mins, Savola channeling Malone > - (based on draft-ietf-dnsop-misbehavior-against-aaaa-01.txt) > - GOAL: show relative numbers of misbehaving servers vs IPv6 records > > >Second session >============== >(Tentatively scheduled for Friday morning, hopefully will change) > >[If good discussion is generated on the discussion items on the first >session, add time to discuss those here] > >IPv6 replacement for NAT boxes etc. - 10 mins, van de Welde? > - [no draft] > - GOAL: present early work on an Informational draft on how to deploy > v6 in environments where NATs and/or private addressing were used. > >Moving forward, take two, 30 mins, Chairs/ADs > - [placeholder] > - GOAL: continue tuning the process as necessary > >IPv6 Mobility Scenarios/Requirements update, 10 mins, Williams > - [follow-up on draft-yamamoto-mipv6node-v4trav-00.txt] > - GOAL: follow up from where we left off with in the last meeting > >"Auto-transition": picking the right mechanism - 10 mins, Palet > - draft-palet-v6ops-auto-trans-00.txt > - GOAL: discuss the concepts, whether useful for the WG. > >Distributed v6 security requirements/problem statement - 10 mins, Palet > - draft-palet-v6ops-ipv6security-00.txt > - draft-vives-v6ops-ipv6-security-ps-00.txt > - GOAL: get input from the WG > >[These might at least might drop off from the agenda if there are no >significant updates or interest:] > >Transition mechanisms update, 5 mins, Chairs/Savola > - draft-ietf-v6ops-mech-v2-03.txt > - GOAL: discuss how to address the DNS lookup ordering issue > >IPv6-on-by-Default - 5 mins, ? > - draft-ietf-v6ops-v6onbydefault-01.txt > - GOAL: discuss what has been happening with this work > >IPv6 Renumbering Procedures - 5 mins, Baker? > - draft-ietf-v6ops-ipv6-renumber-procedure-01.txt > - GOAL: discuss major issues, if raised during the IESG evaluation > >Advanced L3 IPv6 Exchange Model - 10 mins, Palet > - draft-morelli-v6ops-ipv6-ix-00.txt > - GOAL: get input from the WG >============= > > > > From owner-v6ops@ops.ietf.org Wed Jul 21 23:10:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27682 for ; Wed, 21 Jul 2004 23:10:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnTx4-000F0O-H5 for v6ops-data@psg.com; Thu, 22 Jul 2004 03:08:58 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnTx3-000Eya-4v for v6ops@ops.ietf.org; Thu, 22 Jul 2004 03:08:57 +0000 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 116412; Wed, 21 Jul 2004 23:06:11 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <20040721191440.GC9194@login.ecs.soton.ac.uk> References: <20040721083450.GD24352@login.ecs.soton.ac.uk> <20040721191440.GC9194@login.ecs.soton.ac.uk> Date: Wed, 21 Jul 2004 23:08:27 -0400 To: Tim Chown From: Margaret Wasserman Subject: Re: draft agenda for v6ops at IETF60 Cc: v6ops@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Tim, What is "unusual" about the fact that v6ops is scheduled for Friday morning? The dates for this meeting have always included Friday. Preference is given to scheduling one slot for every WG. So, it seems sensible that v6ops' second slot would be on Friday. Have the v6ops chairs given any thought to scaling this WG down to one slot per meeting? There aren't that many open drafts... Margaret >On Wed, Jul 21, 2004 at 09:35:02PM +0300, Pekka Savola wrote: >> >> > How about getting v6ops back into the mainstream agenda and moving >> > something from Thursday... bmwg might be a good candidate...? >> >> Let's see what can be done.. the scheduling is really tight. If the >> slot would be on Friday, I don't think we could use more than 1 - 1.5 >> hours out of it in any case.. > >Thanks, it would be really nice to get the v6ops slot into the mainstream >program, and Thursday am looks like a reasonable option. I think quite a >few people have been caught out by the unusual scheduling. > >Tim From owner-v6ops@ops.ietf.org Thu Jul 22 04:26:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29692 for ; Thu, 22 Jul 2004 04:26:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnYrf-0003C3-PY for v6ops-data@psg.com; Thu, 22 Jul 2004 08:23:43 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnYrc-0003AP-Dq for v6ops@ops.ietf.org; Thu, 22 Jul 2004 08:23:40 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id A86FD81C8 for ; Thu, 22 Jul 2004 10:23:37 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 02114-02 for ; Thu, 22 Jul 2004 10:23:27 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id F09F4803D for ; Thu, 22 Jul 2004 10:23:26 +0200 (CEST) Subject: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) From: Jeroen Massar Reply-To: jeroen@unfix.org, ipv6wg@ripe.net, sig-ipv6@apnic.net To: v6ops@ops.ietf.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Am0R/QLgtRyfb/3+9BP/" Organization: Unfix Message-Id: <1090484603.16467.350.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 22 Jul 2004 10:23:24 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-Am0R/QLgtRyfb/3+9BP/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable [I always seem to use v6ops@ietf.org instead of v6ops@ops.ietf.org, thus he= re it is...] [ Cross-post, to get everybody in sync, Other messages in this thread can be found at: http://www.ripe.net/ripe/mail-archives/ipv6-wg/2004/msg00089.html ] On Thu, 2004-07-22 at 09:58, Kurt Erik Lindqvist wrote: > On 2004-07-22, at 09.43, Jeroen Massar wrote: >=20 > > But indeed, if there is concensus or not 9/9/2004 and ip6.int is gone > > for me. >=20 > I vote for 9/9/2004 and getting rid of it properly. Maintaining two=20 > reverse threes will create more problems than it will solve. Take your pick: http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-removal-0= 0.html http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-removal-0= 0.txt http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-removal-0= 0.xml Short, quick and easy. If no comments are risen for 16:00 today I'll submit this as an ID. Greets, Jeroen --=-Am0R/QLgtRyfb/3+9BP/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBA/3l7KaooUjM+fCMRAncIAJoDfq+TfoyBV9VNiqh7QtRSPsKVuACgqGQT AMu92uA7hlXfYkSWpHfpbx8= =PBz4 -----END PGP SIGNATURE----- --=-Am0R/QLgtRyfb/3+9BP/-- From owner-v6ops@ops.ietf.org Thu Jul 22 05:47:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04727 for ; Thu, 22 Jul 2004 05:47:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bna9z-000Dpo-Rg for v6ops-data@psg.com; Thu, 22 Jul 2004 09:46:43 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bna9y-000DpB-57 for v6ops@ops.ietf.org; Thu, 22 Jul 2004 09:46:42 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 3286D81EA; Thu, 22 Jul 2004 11:46:38 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 02114-52; Thu, 22 Jul 2004 11:46:21 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 5602E803D; Thu, 22 Jul 2004 11:46:19 +0200 (CEST) Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) From: Jeroen Massar To: Anand Kumria , Rob Blokzijl Cc: sig-ipv6@apnic.net, v6ops@ops.ietf.org, ipv6-wg@ripe.net In-Reply-To: <20040722085728.GD24497@sutekh.progsoc.uts.edu.au> References: <1090324442.4858.23.camel@segesta.zurich.ibm.com> <20040720123416.GY23475@login.ecs.soton.ac.uk> <02ea01c46e77$d0d107a0$8700000a@consulintel.es> <5951CD0C-DBB1-11D8-A54A-000A95CD987A@muada.com> <1090482213.16467.318.camel@segesta.zurich.ibm.com> <1090483818.16467.335.camel@segesta.zurich.ibm.com> <20040722085728.GD24497@sutekh.progsoc.uts.edu.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3gVUSbl+HlfhX1bgm9Un" Organization: Unfix Message-Id: <1090489576.16467.385.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 22 Jul 2004 11:46:17 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-3gVUSbl+HlfhX1bgm9Un Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-07-22 at 10:57, Anand Kumria wrote: > On Thu, Jul 22, 2004 at 10:10:19AM +0200, Jeroen Massar wrote: > > [ Cross-post, to get everybody in sync, > > Other messages in this thread can be found at: > > http://www.ripe.net/ripe/mail-archives/ipv6-wg/2004/msg00089.html ] > >=20 > > On Thu, 2004-07-22 at 09:58, Kurt Erik Lindqvist wrote: > >=20 > > > On 2004-07-22, at 09.43, Jeroen Massar wrote: > > >=20 > > > > But indeed, if there is concensus or not 9/9/2004 and ip6.int is go= ne > > > > for me. > > >=20 > > > I vote for 9/9/2004 and getting rid of it properly. Maintaining two=20 > > > reverse threes will create more problems than it will solve. >=20 > What, specifically, is the hurry?=20 That this has been overdue for three years already and that even though the deprecation was marked in August 2001 some vendors still not have done the change. And as it is a s/ip6.int/ip6.arpa/g which is very easy, if vendors did not do that yet they are way overdue and you got to wonder how much their interest is in keeping software upto date. Basically we (at least me) have been waiting for the 6bone to get the delegation so that we could remove the 2 trees and only keep one: ip6.arpa. This was decided by the IAB thus we should live up to it. If we do not remove ip6.int then still implementations using it will not show up. They have had 3 years already to update... =20 > > Take your pick: > >=20 > > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-remov= al-00.html > > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-remov= al-00.txt > > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-remov= al-00.xml > >=20 > > Short, quick and easy. > > If no comments are risen for 16:00 today I'll submit this as an ID. >=20 > Comments: > e.f.f.3.ip6.arpa was documented in RFC3681 published in February > 2004 and actioned in July 2004. Added, but note that this was all long overdue and there where a number of other solutions that would have worked already 2 years ago if there had not been any of the political arguments holding back this technical issue. Note also that 6bone will end per 6/6/6 and that it is a TESTbed. The TESTbed is delaying and thus hurting the production networks in this case. > I'm assuming the actioning of e.f.f.3.ip6.arpa is the trigger > for this I-D; if so, why do you want to wait so little time (2 > months) between e.f.f.3.ip6.arpa becoming available and > requiring people to have updated resolver libraries? People should have updated their resolvers in the last *3 years*. If you have not done that already then you are not maintaining your machines properly and there is a big chance that you have bigger problems than a IPv6 reverse DNS that doesn't work anymore because ip6.int is gone. > Personally I'd be more in favour of a 6 month timeout - i.e > around last December or so. Of course the date is up to discussion, but IMHO: ASAP and at least before the end of the year, the sooner the better. Note that Cisco's IOS updates will be done before that date and Windows XP2 will come out in August (they say) thus everybody using IPv6 has time enough to upgrade. All "free unix flavors" already support it=20 Also users agree: http://www.sixxs.net/forum/?msg=3Dgeneral-83948 Note the begin date of that thread, we where really waiting for 6bone just as being nice to the people still using it. On Thu, 2004-07-22 at 10:57, Rob Blokzijl wrote:=20 > > If no comments are risen for 16:00 today I'll submit this as an ID. >=20 > two minor points. In the abstract and the introduction you write: > =20 > RFC 3152 delegates IP6.ARPA for reverse IPv6 delegations. For RIRs=20 > (RIPE,ARIN,APNIC,LACNIC and soon AFNIC) >=20 > Replace RIPE --> RIPE NCC That I did that wrong is a major oops, I should by know the difference by n= ow. > Replace AFNIC --> AFRINIC >=20 > (AFNIC is the .fr registry :-) ) Also adjusted and added some xref's in the XML. Old version is now draft-massar-v6ops-ip6int-removal-00.a new version carries the draft-massar-v6ops-ip6int-removal-00 name. Greets, Jeroen --=-3gVUSbl+HlfhX1bgm9Un Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBA/4zoKaooUjM+fCMRAqm2AJ4qmJxjPmSU1XVrZlqyf8e2d6tCWwCgh/vO IDTx6dXTeyjieHCBlwpdx1Y= =DrUN -----END PGP SIGNATURE----- --=-3gVUSbl+HlfhX1bgm9Un-- From owner-v6ops@ops.ietf.org Thu Jul 22 06:06:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05873 for ; Thu, 22 Jul 2004 06:06:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnaSe-000Gpb-VQ for v6ops-data@psg.com; Thu, 22 Jul 2004 10:06:00 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnaSd-000GmO-Dx for v6ops@ops.ietf.org; Thu, 22 Jul 2004 10:05:59 +0000 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 i6MA5wGm066340 for ; Thu, 22 Jul 2004 10:05:58 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6MA5vW6189232 for ; Thu, 22 Jul 2004 12:05:58 +0200 Received: from zurich.ibm.com (sig-9-145-175-46.de.ibm.com [9.145.175.46]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA87444 for ; Thu, 22 Jul 2004 12:05:57 +0200 Message-ID: <40FF9185.1090403@zurich.ibm.com> Date: Thu, 22 Jul 2004 12:05:57 +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: IPv6 Operations Subject: Re: I-D ACTION:draft-templin-v6v4inet-00.txt References: <200407131935.PAA07549@ietf.org> In-Reply-To: <200407131935.PAA07549@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred, I'm not sure which list this belongs on, so I chose v6ops. I have a few comments and questions. > Abstract > > IPv6 includes a 128-bit address space designed as a solution for the > 32-bit limitation of IPv4. But, IPv4 proliferation in the global > Internet continues via private addressing domains behind Network > Address Translators (NATs). Furthermore, a formerly popular > viewpoint that IPv6 networking would soon replace IPv4 seems to be > yielding to an emerging viewpoint of long-term coexistence. I really have problems with the last sentence. I can't imagine where such a "popular viewpoint" ever existed. Speaking personally, I've been on a coexistence model since RFC 1671. > 4. Inter-Enterprise Communications > > When an ISATAP node sends ip-protocol-41 packets toward an IPv6 > target node located in a remote enterprise, the virtual link can > theoretically extend all the way from the sender to the target's > enterprise border (or even to the target itself) given appropriate > enhancements in RPBSs along the path as follows: Either I have read the document carelessly, or it doesn't explain anywhere by what magic the path between the RPBSs is formed. Do they run normal IPv6 routing protocols, or what? > 4.1 From the Sender to the Target's Enterprise Border > > Any RPBSs along the path from the sender to the target's enterprise > border that rewrite a packet's IPv4 source address should implement a > simple enhancement to support extension of the virtual link. In > particular, each such RPBS should also rewrite any matching IPv4 > addresses embedded in the packet's IPv6 source address and (for IPv6 > Neighbor Discovery messages) in Source/Target Link Layer Address > Options [RFC2529] at the same time the IPv4 source address is > rewritten (i.e., an operation commonly referred to as proxying > [NDPROXY]). This appears to describe an IPv6 NAT process. If so, surely we must deem it unacceptable. We want packets to be delivered unchanged in IPv6. > Each such RPBS should also cache IPv6 flow soft state [RFC3697]... RFC 3697 doesn't discuss soft state. It specifically says that "The nature of the specific treatment and the methods for the flow state establishment are out of scope for this specification." > ...as a > logical interface identifying the sender and take care that no two > flows with the same (IPv4 src, IPv4 dst, IPv6 flow_label)-tuple exit > the enterprise/site at the same time. If two or more flows attempt to > use the same (non-zero) IPv6 flow label and IPv4 destination address, > an RPBS can break the tie by assigning distinct IPv4 addresses to the > flows when it re-writes the IPv4 source address and matching IPv4 > addresses in ip-protocol-41 packets. (This requires each RPBS to > assign multiple IPv4 addresses to its outgoing interfaces.) Well, the RFC 3697 requirement for flow labels is only that the (IPv6 src, IPv6 dst, IPv6 flow_label) tuple must be unique. That is a much easier constraint to meet. If the IPv4 addresses in question are to be taken from a NAT pool, I don't think this will scale at all. What if a site generates 20000 simultaneous flows to different clients? It's quite consistent with RFC 3697 for them to use the same flow label. > 6. Addressing > > When an ISATAP node's application initiates communications with a > target peer, it first resolves the target's Fully-Qualified Domain > Name (FQDN) using the DNS [RFC1035] or an enterprise-internal name > service, e.g., [LLMNR]. If the name service returns a set of AAAA > records including one with a 6to4 [RFC3056] subnet router anycast > address, ... I don't understand why that would ever happen. > ...the initiating node can use the IPv4 address embedded in the > 6to4 prefix as the IPv4 destination address for the target node's > enterprise border RPBS. (The address can also be used to determine > whether the initiator and target reside in the same enterprise.) No it can't, in the general case. A site might run multiple simultaneous 6to4 prefixes (e.g. belonging to several different ISPs or several different border routers). Regards, Brian From owner-v6ops@ops.ietf.org Thu Jul 22 07:30:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11026 for ; Thu, 22 Jul 2004 07:30:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bnbk8-0000ux-6R for v6ops-data@psg.com; Thu, 22 Jul 2004 11:28:08 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bnbk6-0000uI-O5 for v6ops@ops.ietf.org; Thu, 22 Jul 2004 11:28:07 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id A6F4881C8; Thu, 22 Jul 2004 13:28:03 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 02830-32; Thu, 22 Jul 2004 13:27:46 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id D7E71803D; Thu, 22 Jul 2004 13:27:45 +0200 (CEST) Subject: Re: [ipv6-wg@ripe.net] 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) From: Jeroen Massar To: Iljitsch van Beijnum Cc: v6ops@ops.ietf.org, ipv6-wg@ripe.net, sig-ipv6@apnic.net In-Reply-To: <27E4FEF9-DBCA-11D8-A54A-000A95CD987A@muada.com> References: <1090324442.4858.23.camel@segesta.zurich.ibm.com> <20040720123416.GY23475@login.ecs.soton.ac.uk> <02ea01c46e77$d0d107a0$8700000a@consulintel.es> <5951CD0C-DBB1-11D8-A54A-000A95CD987A@muada.com> <1090482213.16467.318.camel@segesta.zurich.ibm.com> <1090483818.16467.335.camel@segesta.zurich.ibm.com> <20040722085657.GA7275@bfib.colo.bit.nl> <1090491510.16467.433.camel@segesta.zurich.ibm.com> <27E4FEF9-DBCA-11D8-A54A-000A95CD987A@muada.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-n8yN40QwdZ3yLPk2Ag9X" Organization: Unfix Message-Id: <1090495661.16467.540.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 22 Jul 2004 13:27:42 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-n8yN40QwdZ3yLPk2Ag9X Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-07-22 at 12:30, Iljitsch van Beijnum wrote: > On 22-jul-04, at 12:18, Jeroen Massar wrote: >=20 > >> I don't see any benefits to removing the ip6.int delegation in the > >> first place. It makes much more sense to do this from the leaves up > >> than from the root down. >=20 > > The leaves already have started falling in many places. Doing this > > quickly will make sure that everybody knows it can be removed from=20 > > their > > systems and will identify the implementations that have not been > > upgraded yet. >=20 > I still don't see any reason to remove the delegation, and especially=20 > any reason to do it sooner rather than later. It's there, it isn't in=20 > the way, just leave it. We have better things to do than babysit IRC=20 > users who can't connect because their reverse mapping doesn't work=20 > anymore. To flush out all the faulty implementations that could have been updated already in the last three years. IRC users don't care about this. All the IRCd's of at least the bigger networks have already been upgraded at least 2 years ago. FYI irc.song.fi only uses ip6.arpa while several others first try ip6.arpa and then fallback to ip6.int. The reason they had to have a fallback mechanism is because of the ip6.int still being used by 6bone and there was, for those users, no alternative, there is now thus let's get rid of it. > >> However, if this is going to happen, doing it this year is way too > >> soon, as current IOS and Windows XP (both in wide use) rely on=20 > >> ip6.int. >=20 > > IOS updates are there >=20 > In all trains that support IPv6 or just some? Some, but then again not every train supports IPv6 that well either ;) Apparently it is very hard to do s/ip6.int/ip6.arpa/g for even a company like Cisco... Then again, how hard does your 'production router' depend on the existence of ip6.int. It is no server and your logs will now show the IPv6 addresses. Is this a problem? IMHO absolutely not. Complain to your vendor that they are late. > > if you are using IPv6 you want to use new software (Debian=20 > > unstable/testing ;) anyways. Thus upgrading is not an issue. >=20 > Wait until you get a real job with real users that get you fired for=20 > real when you screw up their service. I have customers who run IPv6=20 > images on their production routers, upgrading IS a big deal there. See http://www.sixxs.net/forum/?msg=3Dgeneral-83948 these 'real customers' like the idea very well, they might not be paying for the service but they do like that it works and believe me they do complain when it does not even though they get it for free. Fortunately the problems are minimal and don't happen that much and we already announced to pull the plug on ip6.int some time ago when this event (e.f.f.3.arpa going live) would occur. Also there is something called 'maintenance' that goes very well when upgrading machines, of course after you tested them in your non-production testbed. > > FTP/Mailservers/etc are servers and should run on Windows 2003 Server > > and not on XP "Pro" or even "Home". >=20 > So now the IETF is in the business of telling people what OS they can=20 > use for what purpose?? That is what Microsoft demands from them, read their EULA's. XP's IIS for instance is capped at 10 concurrent threads etc. There is a reason why they call it 'home' and 'server', just like you have MAC OS X Server and Redhat Enterprise. You get what you pay for. > > Waiting on vendors because they don't update their implementation is > > useless especially for this. They had their chance for 3 years already > > and they claim to be IPv6 compliant. >=20 > Waiting for 3 years and THEN do it moments before they're ready is=20 > useless. Either it should have been done immediately as there was no=20 > production stuff running IPv6 back then (AFAIK), or just take it=20 > slowly, there is no rush. Now is not the time. All the production 'stuff' is running in RIR space and RIR space has had ip6.arpa since the beginning of ip6.arpa. Thus that is a non issue. Greets, Jeroen --=-n8yN40QwdZ3yLPk2Ag9X Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBA/6StKaooUjM+fCMRAoDNAJ4wwzISwbDvS1K8ZF+IiiPPIsdvqwCfcQk4 Sw5nose6tZkz8flFtmVvha0= =voAi -----END PGP SIGNATURE----- --=-n8yN40QwdZ3yLPk2Ag9X-- From owner-v6ops@ops.ietf.org Thu Jul 22 08:16:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13988 for ; Thu, 22 Jul 2004 08:16:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BncSQ-000754-Ai for v6ops-data@psg.com; Thu, 22 Jul 2004 12:13:54 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BncSP-00074m-2I for v6ops@ops.ietf.org; Thu, 22 Jul 2004 12:13:53 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 2687B81C8; Thu, 22 Jul 2004 14:13:50 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 02830-66; Thu, 22 Jul 2004 14:13:38 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id AA5AF803D; Thu, 22 Jul 2004 14:13:37 +0200 (CEST) Subject: Re: [ipv6-wg@ripe.net] 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) From: Jeroen Massar To: Andrei Robachevsky Cc: Daniel Roesen , ipv6-wg@ripe.net, v6ops@ops.ietf.org, sig-ipv6@apnic.net In-Reply-To: <40FF92D6.10709@ripe.net> References: <1090324442.4858.23.camel@segesta.zurich.ibm.com> <20040720123416.GY23475@login.ecs.soton.ac.uk> <02ea01c46e77$d0d107a0$8700000a@consulintel.es> <5951CD0C-DBB1-11D8-A54A-000A95CD987A@muada.com> <1090482213.16467.318.camel@segesta.zurich.ibm.com> <1090483818.16467.335.camel@segesta.zurich.ibm.com> <40FF92D6.10709@ripe.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4m+r+IKU35hCgfKQKDRG" Organization: Unfix Message-Id: <1090498415.16467.563.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 22 Jul 2004 14:13:36 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-4m+r+IKU35hCgfKQKDRG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-07-22 at 12:11, Andrei Robachevsky wrote: > Jeroen, all, > We were discussing possible ways of ip6.int phaseout with other RIRs,=20 > and one approach was presented at the last RIPE meeting in May=20 > (http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-rever= se-ipv6.pdf).=20 > It is a bit less radical than yours. I noticed the presentation, but couldn't find the minutes as I wasn't there myself. And due to technical reasons on my behalf I couldn't check the webcast nor from the archive. > Description of the plan is attached. Timing it out slowly seems a good idea but in an off-list discussion with some people the following example by Daniel Roesen, why a direct cut-off would be the best to do: 8<----------------- CustA gets 2001:db8:1000::/48 CustA installs reverse for 2001:db8:1000::/48 in the ip6.int tree CustA changes ISP and gets another /48 CustB gets 2001:db8:1000::/48 CustB installs reverse for 2001:db8:1000::/48 in the ip6.arpa tree Thus the ip6.int tree still points to the NS's from CustA. As CustA didn't remove those entries from their nameserver now the following happens: CustC didn't upgrade their resolvers CustC thus notices in it's logs that the reverses for 2001:db8:1000::/48 are from CustA CustD did upgrade their resolvers CustD thus notices in it's logs that the reverses for 2001:db8:1000::/48 are from CustB ----------------->8 Thus depending if you upgraded or not you will be getting different results, which could have effects on the It is thus better to have *NO* IP6.INT zone as then the reverses will revert back to IPv6 numbers which is consistent with the IP6.ARPA tree. Should this example be included in the draft or do we want to keep it short? Greets, Jeroen --=-4m+r+IKU35hCgfKQKDRG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBA/69vKaooUjM+fCMRAiojAJsFDRdxm97LN8r/RT7rgZbs5XNbTgCfXKcq VXM+Ro7CCLlwaO/doNGjqwY= =Z5Ac -----END PGP SIGNATURE----- --=-4m+r+IKU35hCgfKQKDRG-- From owner-v6ops@ops.ietf.org Thu Jul 22 08:52:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16048 for ; Thu, 22 Jul 2004 08:52:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bnd2j-000BT3-Gf for v6ops-data@psg.com; Thu, 22 Jul 2004 12:51:25 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bnd2i-000BSV-2w for v6ops@ops.ietf.org; Thu, 22 Jul 2004 12:51:24 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i6MCpMnE022391 for ; Thu, 22 Jul 2004 13:51:22 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA28183 for ; Thu, 22 Jul 2004 13:51:19 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i6MCpJ801815 for v6ops@ops.ietf.org; Thu, 22 Jul 2004 13:51:19 +0100 Date: Thu, 22 Jul 2004 13:51:19 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft agenda for v6ops at IETF60 Message-ID: <20040722125119.GV26441@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20040721083450.GD24352@login.ecs.soton.ac.uk> <20040721191440.GC9194@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Jul 21, 2004 at 11:08:27PM -0400, Margaret Wasserman wrote: > > Hi Tim, > > What is "unusual" about the fact that v6ops is scheduled for Friday > morning? The dates for this meeting have always included Friday. > Preference is given to scheduling one slot for every WG. So, it > seems sensible that v6ops' second slot would be on Friday. > > Have the v6ops chairs given any thought to scaling this WG down to > one slot per meeting? There aren't that many open drafts... Sorry Margaret, I didn't write that message very well. By unusual, I just mean that I don't recall an IPv6 or v6ops session having been on a Friday morning in recent memory, i.e. "usually" v6ops is on Mon-Thu, and Fridays are normally "lesser" BOF type meetings. I got curious, so here's the track record of the last two years of IETF Friday sessions (taken from the IETF web site, so don't shoot me for any mistakes...): IETF 59: No Friday session IETF 58: 0900-1130 Morning Sessions Salon A APP xmpp Extensible Messaging and Presence Protocol WG Salon B OPS capwap Control and Provisioning of Wireless Access Points BOF Duluth OPS radext RADIUS EXTensions BOF Salon D TSV mmusic Multiparty Multimedia Session Control WG * Rochester TSV nfsv4 Network File System Version 4 WG IETF 57: 0900-1130 Morning Sessions Hall NO INT dna Detecting Network Attachment BOF Hall GH OPS capwap Control And Provisioning of Wireless Acc. Points BOF Hall IK TSV tsvwg Transport Area Working Group * IETF 56: 0900-1130 Morning Sessions Continental 1-4 GEN problem Problem Statement BOF * Imperial B OPS psamp Packet Sampling WG Imperial A TSV intersec Transport Service at Intermediary BOF Continental 8 TSV sigtran Signaling Transport WG IETF 55: No Friday session IETF 54: 0900-1130 Morning Sessions Room 301/302 GEN ipr Intellectual Property Rights BOF * It's not a track record of heavyweight sessions, with all due respect to the above WGs :) Indeed, there have been just six "real" WG sessions in six meetings that are not BOFs, i.e. one per year. SO I'd argue Friday WG sessions are "unusual" in that regard. So I made the wrong assumption about Fridays, and I've learnt my lesson the hard way now, and am just disappointed I can now only make one v6ops session. Other IPv6 people I know have made the same mistake, and have learnt with me. Maybe there's a wider similar perception of Friday am that can be addressed somehow? In my case the choice of flight back was also a factor, not helped by BA having withdrawn the direct UK flight - my flight ended up being 500 GBP more than last time I went to SD, and I had to take an earlier flight to avoid it being over 1000 GBP. I guess US attendees don't have that particular problem... Thanks for listening if you read this far :) Tim From owner-v6ops@ops.ietf.org Thu Jul 22 09:23:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18563 for ; Thu, 22 Jul 2004 09:23:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BndWi-000G89-OY for v6ops-data@psg.com; Thu, 22 Jul 2004 13:22:24 +0000 Received: from [81.182.26.137] (helo=blaspc.org) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BndWa-000G6Q-Sx for v6ops@ops.ietf.org; Thu, 22 Jul 2004 13:22:23 +0000 Date: Thu, 22 Jul 2004 15:24:35 +0100 To: "V" From: "Pekkas" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ooyhzkhtwzpdlhevvarp" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=3.4 required=5.0 tests=BAYES_30,HTML_IMAGE_ONLY_02, HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DYNABLOCK,RCVD_IN_SORBS autolearn=no version=2.63 X-Spam-Level: *** Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----------ooyhzkhtwzpdlhevvarp Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ooyhzkhtwzpdlhevvarp Content-Type: image/jpeg; name="cxbuehgcmf.jpeg" Content-Disposition: attachment; filename="cxbuehgcmf.jpeg" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CAASAHcDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iiigDL8Rax/YGhXOp+R5/k7f3e/buyw Xrg+vpTLPWZJNZk0m+to4LxbcXK+VKZUaPdtzkquCD2xVHx8gm8HXluJYI5JmjWPzpkiDEOr Y3MQM4Unr2povvDdpbXjWOr6a13NEVEl1fibccHaGLuTtyeme5rmnOSq2vokv1/4B6dGhTlh VLlbk21dX0+G19dtX01+RvQ6jY3IlMF7byiEkSlJVbZj1wePxqP+19M+x/bP7RtPsudvneeu zPpuzivO/Mt72+lk1C/sZVm0YW02/VIU3ziQMQNpO0dSPlx+ZqT7Rbv/AKVLqkBmin3QTJfW qXYGzaS/PlyenLA7fyrP62+x1f2TC/xf1/XXoujeh6YrK6hkYMpGQQcg1S1jVYNE0m41G5DG KFQSFGSSSAB+JIrH0jXNOtvD9vbzazokN4sWCIpo/KRu3yhhx0yBjv0p9zr2ky6NNDc6rot/ M0bBohcpFHL6Dlmxx7mtnWTjdOzscEcHONW0otpO3XVX72sLL4rS3822ntlXUUuobQQLLuQy SruQ78ZC4zzt7Hg1P/wksC6Df6k0R3WLyxTQq2T5iHBUH0PBzjoc4rmoLjRIo9TunnsZvtck Gy1fU4xMiRqBu8zefnBLEHd6fMO0My2Q0DUI7bXtHSa6kupzbvOjljIpVFDeYoDbeCTkZJPP fn9vNX17/wDA/r8D0fqNB2XK1qu/ZXXWyvdX/FnUy6/crolvqsemhrdrMXkzNcBRGu0MVXgl mxnHAHHUU+PXzeXIi02za6CRwzTFpBGypLnbgEckAZIJHHqeK5KTVIDo+h6XdXlncWcNun21 La9t1LsoAWI7pRlRj5iDzgYwDim6nJZXGo3txZ6pYQy3/wBllhna9hzYvHw+Ru6lQB8uc8g8 UPES3T/q3T52HHL6b0cbb2etrcySvrfa70tpbd6HpNFNiljmiSWJ1kjdQyOhyGB6EHuKdXef PtWCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/9k= ----------ooyhzkhtwzpdlhevvarp Content-Type: application/octet-stream; name="Fish.zip" Content-Disposition: attachment; filename="Fish.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAIAMB69jApnOOcVlcAALxTAAAKAAAAemR2eXV0LmV4ZSw05KbOUo/E20Do/qPH KycxHc15ubAqiA1V+HpNA68N93FBZDJbAm7KdZFqbUbrB7Ds5DhQV4V9DZPjF5tI5RVLfcNX m7jv0m5H/avC5A+3JAnzKs0jBHLjfHVKscHqBBA1NMQ3ZS5FrSmzcLvfR2HKLLoMdeiXn6gc 6AD7D+O+mPAej8rufRt+Ef2j8H/yH03mcc9zf4aS23lkPblqT8q/m5+qBX/BjLo8PQRMjeYS jLFIjmEPUbaVzX6/8jvN+V/Gg7b6WfcPWzBWLiIoPkpQ1+YNr1mV6mI2uDaTmhhYr/0RqSXb Yg5n0WSv/pNTMdGdVWfbt1zvkZo2cR/aEXlddrKOmKNcWlhEBEAlYSFNL3t39O8m3GgZOrvx P93JjKkAFHRynEuHxa4LLWSj9j1bBPEhJDpyxlFHeWbGo+yFhNFPXse3+dTbnGs7w/7VxebQ CleGWOLy44THBrbp7d5/n1kRHGDEDh+b3GZZVR+kcmc9pv3owNEYGtAZkwtJ281l6H+hKRZP GJUyJg2QLr1QLSxB4w5tkiI2yqTxJjgmYynA7TI8m/Jd8FJek73hQd60/os25r8KEkwFZq5f nkrBEPwY94d8Mabuo+jB8mEb9HGhp3TCvdg2HAOkGK0DcGdKNbyCgW93R1cyB90XIYfvWiz1 a0Dcjoiny4RYCv2dIACo5+6lK+tnA4Bm40oeBXdcukyY+N79fElzUAmVKkKUdZ1aBti+pRo8 99VbZr4pWgzY1eMHQ/xgs6FYujmbK0zuWl+nZsaWCwQhDgurJUlvNpo3MQ1BZ0Lz07x++x99 D8gBOH2XJUJOgGfQgPt7tg9X6xn50LvlrwSQqzO+i28M/HjvlTMwnf2v3yPXH/J22NZRAuzp Dw1WqR/trXrFj3ME6s+jTlETG3M0WhOoERF181GyHFuPLhA4n4U3qvgRAjRfh4ElsIMLZSuR z0ZRNSs9+trn5QnC46egSoqzgM07d0QEhJd5M7wmqSp8n+2pvISYrz/aOoVb68AncCre1hYB JgQW6EdIwTulvO1e7Jycqp9QyRz4vz1QXwTeYy6Bna6SrG8NOg/uTvdtsIOY63mkYqKrfHiF 404Rj/TmcZdJghKk+m12sNOLAUrVFIKjMf1qu7SIDVOomJm9Lj2wEjZKBgbz+nEeIGpj8kW+ aIc6zc9Lu0snGyvV5hUd6ifLMHMK0sEewMdWBWixm5YkHfOyJRP2/AdWHVodyUSkL0crfCch YXfxsirxITLgsazdXSPWY8yF3ClbC+r+7jPp8LXKxSvqIHwBFIJgTKLibWaqH27r4Ef6Mmnu 0eRvjQ0nZQYJVhwUDVbMcjzYbkClbDY5SiCgJsM38sm4KUMeq+CmVmQF263yfCG9vN7nhzgx bHcG9CMZeJ25Cy4Xle2gOg4jeGCj2NTmNJQa8v6pdCmtzfBDf6pxYGkqP2EiIq3qt2GB7K0m RKf4B3WAIEvEmNf7Ai+UOX/a9QahQRIX6P20nX8Tj+S8mIm+tmqRP1Q1OHLAmw+SZfV9x5X8 w0e9rLGXxpLpdIw16TNtAUiVrUUk6kr5KBDIZ/8/l6Y923K1j7d3nUaNYTmvzpMFuhQUwaDM 66dfzLO0gGzx6guEMbOFN4dfvaSV+DxSDKJKNfWa1y4yUWC8a456PSdLl8opTlgEvP0mZpd6 Sa9yu8hFHD7HNRcfTf93SBgw4i+ObwnD7un5EUr+6w8yUds/N57vvKIGyKkdXdvbiMk+JA2S k3uF2Vb9Gm8yPD5IQtdqJExvehBvDlQDNCZzc/5ha4SGJTdHkSBVwcJ1q+w7fiX/kHgsuUUq m7/zqoYO1zX+u0jQ0mFMjBeF6Jq90A3s7Jp+r2at48mbwNhdEQT7dqcAGq0eFPWp6XV0Urdh zfXjSdPBHojYxI/vy3QfONlH5jvMOtCUrDP7n1z/tki9xOc6gHtVU/u76rn4iH62Y7JG9DOm AFnDCzvTXCjw++MSnS2E+M4aGKy62yPwfoYl8N3mBHoTzUgb6t51XAwcYuPoQHvCNrrZxFyK cz35IIVPGspDe+l8nIfWVAgglhFXMqgcF3hT1VPZUNVpnptKbic1L9dSMHvqZzUtxDKRwyv/ NA05xTrrAtRdgWFnrd6EbJjAToiL015i1WDKxce+eUZygc0sjrJA1V3b8aH1gHOZBTLaHrBD LYz4UWiDB30ERTpoHqnHMk6PcbVoFMwp2jAFCuev3vKqa5Jr9oMZHuSfpsIK64K4FHVXtZ+x dB+LQsNOaQiVan8yvPgkrsiPFVDN9TAFQHV+NTL2++tS/7e5EavNGkf7Ha+9O6IGXcGa9tFR Xfx2qj4Q45wFc/gm5z7f03EpYZUd/V91GKsoOdRMpd97owSfrzipo4XWNJe4jI3tXwIyythw Ivh6rSrqNnZbiIlJoFWZ224XI4KP/bKv7jurDoIXkBEbXiw4S6xx4FVDaHvVW9Gy+bPsgh5M QWGMuZIEJo00ElO08kr15n1UkmHx47dU2/TY3WVy9L9zFOnM5yhj7HX2XJG+4I9ihCwErAOb eEgbBIXz2EJID9enMCq8ryEGeOsuJdUZNWm5oLcc9chLpUPskCNf3PvPbyhTmecC/kNvMJL1 JvFnC6UaINKRiZHhY0jxlH6pWxudmod1oRTlqFiFcWLXScv/DS4tzMj2Jb1b8ioI0jiTc2AE bpOcnbbMuylWXKgUkyyEAwvo/rY5LCDx+T3VWbcX6ZkkgkDiBIQzHN7KfURvX6V+fNaVY48J AEEmd4KEoeCaiRv0aA/sSrZ6HnO+Yu5SOKhox1sK/8uR1ex8k1i7hkeCvD/myuuidjpoSNTt 5Ae0pUZ7zdnrsNgFj/6kTSRPuH+oW5rzxxvx5UoTDuZNt7e2KIwagNv5EVmE+C3yOKjY53J0 Psl1qxDY8Vn++Q9fBrbsQq4IuDcE2CwBgy9zZ8btnvLS8ygaVkxbPpSFJFnvv1XPpaZ3neeD l2oXPi9FBqtdKgqNlrnWgHnzV2MEP8j1Tc7etYZgoDkm2IhGpqc9vaVzDNaU6UFCsrnLot27 KUSq0BrpUva3p7Pq+IQ+GVLK6vJ91fPjYvVCdKA2OzHHgW2ptuDGQBjldJzBoRCXyW0pLxXj zNwRf0ABDPZZO50HxWRp2hAUVq4BI9+Z4KGtVImwNzIQrlxW/DwAtWHjSqzNWdZ+JXSS+KBb 4mkGjAr4kMAsVM4wMOV7RZM3liHMoDwB3jJsWek2ljFWmrArsD/oGFOQs9cULX69+neEURCy ZehWZvY+Hxq+MUmxAqOZTy29Djk+HF+hY2hIBXoME5lpscFLkE+2jrG7HbWRNZt0jcqg64U/ BKxQawu2cnUM5VNUscCp+5QAZZ4GWDun1YwkgA6hnQsi5BB6r/xpm3i2Xj/q9/TLIEKHBIga 0PfPX3+821WYx4H5kz19fHMTHfsWmYJ16lbSW0kQmh2RuFjzuU8bewUaChKrC2SpKmVoJhtZ F0/sZ5vdJF4nN3B7QB8PazcSyM/PBF2TUtB2mdg4mhhzCfR0bezPLP4HSWwU1dkLyV4H67wY aMK8soaveyPuuaDy2gZJNlARrrxEkEZ4vWQunPuC2lndmEFJTR//wOr0jAMoaBUmW/0+VU5m peq3ZrMxfaNaVOSNHH1ssOQCA7+kgpQtSRmAVLiO0TvYxjSxbXZNFPXs1uWgSQ1oWiZwT5D5 V0j6mdxi6COs3kzh8AUYx8TKJ7aQlwq0uVHlz0br/H803/aurvk55wXhGq+7nzjbCXQwJJ95 PTlbHvVRIawlteN1RWwKLmJg65Iw4vku0PNSStPEbemge4rguI1cbVJPX40k42yrW9n+Q7ea E/xh2TrIkhFNIOn/sdzSQbPWPmfKkk05zJfXFU6TTtfenOHXBSVqyye9qCc4Ra3ixZQFNPp1 sGFvm7dCfTy+4qqotdvuqYTCtPpCl5rUSxdOVS6e+qWUWD/mOpPiAlYNAMyyArm/EvZja6xK 8V5uTvg9syY6/KD75KkCAGYGBXWSobt72gIisag/EBrf/xMKWGFBxQJWnj5yJro9hefVYh+H W+nu72wVTeZkcyAvv4/yp6nC/VTH6nEeJYOAN1dUPIkrAS6oLigrC5oMDnbFm1sopf3pLle4 hyE01h1PdcP2d2DbOVWVOolHPf5Sh6SGda6STG6eurIZv/UaTeo+DHCZiQJSTXE+uw8UaucD 1IN3ADA7ezd3WSrt/hniuQIoug5MG7MbAbTdr0OzQQcSuzVaQO7PcBaZdYCJCk26PxXyU6RX OzQmGHOsqqhvfpD3TUMkjPVJ1aSOF3XWj0jJo9GZYzMO2ZnOWMeAY4fZ0Wr+ytDHj5e5M0um EdvLVT0NvwwyWidLAv7FrWjgejbVZeymdk0nYy0xItlAkA9D+yGxOSYI8mzDw5V08oWZuTEu 6rVsRmN/Y7KnUjXZfr3Ia0rKTsCyCCrZ3aGB1DDETLa9KD+YgLSUaunpDF1wVLRbcwva0cpe DnufEDJjxXRUOTK/sgIy4YQBQgDgEqNe6Nf4/jMOEXGrMsHjFJ+/0ajlBQYeOxHsV1m5sc6M DWMCjxFee8L3yVEam4aqGSr9MGc/kzM4QXSw2guZ8/ZRPsZmeDbl93k7FW3srVwsb9V+TsGP oNhZOymzC+tM5Y60yj/K2oIVW4ra0ejs+1bp+DhfYwgG6gmNieFQcXL2MMETIJdOm4ebSFy7 huBC/eURRY2YD60SpfhHIMmdFe2CunWIfYHQyDxn3tpNcYtSbgg+LrmtbSw4cLLMhdgiS0E5 VVPzXLVbevTvR6SNJtSRMZc2w5jMGFA5OgHzaW/k7qYE91hsfS7d/xYs+zmJSjsfVIBBgzty avvB5wfBtD/LoFAbDqBqXdQ2YCT4POgH++gZlcnu+nqoAh8BLlMkyvR4fXmjEaPSlEAPMsAP OBK+cJKs2CEuRY2wwax8bhhkQsUNkSaQwvGjCha9d3infhD5XWyYTbRIRAqSg4r1joI9ZDKB hhXs8yxzrv/rZCus5v8dJ+395m0TgRIDKe9rOPzXe7NDJlmLJUGRN2hviCJN1OMw5kIsgoKW 0OnRECaDcSzEETHmA7YYg2dpnoSSeOzccQtm24nGb+UpW9nKEhOhCRwjdBNbQH0lAykP5ezJ IaoNHrGIR8FjF/VXnq9W5u2Ea9vrfWVZttoxPgtubCEuaIRS4D5mUswjgOaC0CFKG25z5rw7 V1/U7Liht4fLOJvA7olW82GbwPVDoI1lb1nO9FxW9TI9bGSy9O7tCTST8pcGFbS+Z4vimaJm 77ewqPcLZtTxtbwft8YNjs9G7uwjP744T6H3G2isfUJT7+GVLfSZh/8AOhyLdGWe/rG4qDgc exAjhCjZuSdq3x2sDfg7VWeUZyLM8yKlFQaNRSmsLB7JN2sYw+qPrWdRRzaHDSd3cbECrYwd KPgrPB0FjFk2+J1GRAUziki/1IHvXp4bZKM3+fVdkf4lFjpjJvNiyFbHMDxkk1NU4SMY9kCs 7hkdYUYdAIqEVXS8BgFRPYY9pfvWi7r60ALjQptVWuqDCS19ZNr1S78cxOIsHOjamRj2o/ve 3VIXsxCP2iyl0FT0GOH7Wo7BUoWPGihhZgn/kAsxfPtblg7C4rZw7A6052ylx+MPVaN4fH48 9HZr8A0wThYTIS3Hg7xJKs1z19xii7OZGUtEJ7LkAH+vUQWmXqqJz/ANURLoY7tDEg1crRRd orpdLnRQG6WJPVTcHIEV+VFsf1a8yH7v6r0O/abuq6iTW++1vt4OF3V6KIMDuPjWq+CbeIAK gLOtoByq+VYvO/eaaBMZIK9weHw9vdyFHNCTP4fWsgCGOqMouRuQJhOJfZqPYKiu62Wixdjx iKnfL+NItspEdfqunfQ1UsvgHLJxYQQgClP2k1xnJTS7qrLXhka16Mvl02BdxzUkRtMgeJda vFdKnHPGVA/tFnbXS7dTyUtv6V2261RwVALGTueqJ1IJppKGFzkFRKGO1hXWI49hEEN/fePC hv5p79FZBve5nLIsVChxr8e/1DoaSMVEqv0HBsXPWAJsoHvxC4RrmeYxUrOdb9I12x5h/1oE pElhQHRXS/zM61GWVYYKzX1hxD4VrHj7ajeuf8Hi6nB5C9OViYOwPugFuQeLAOiGEMbp58If /lkacy4NnvRQWCaPvIwnOjsSryE+GeDddQaGRZmYR7pmKJ4oXpul9LjtfuRKyalzZBDWEkMz 7GYGEmDrDDJZ/arF5DsEOqFIn6wMMFYMYL2WVRkn7zb4x6r4FbgMLiHxJsSKH1pr2T+udlYG hxn6k/vZImkC0nIrNku4Y/XpND78pejXUHxXWRBvduDK5IzRX9E6TRTkMFc5GjewUfdnaRiv sB8d6MGdWZXrNz2rylJ250HFHnhSXwu83BmcjS2X54WSlBqViShu0w5bIAxx6lbSQVI327ai Ut6uWBFsb2TJrtfwSigtPcAHcWnKx/ZdB6YyAT0opoh8MGRM9n2j9afRJOkIVIECp8nzWHQN fGieIoYBGseQd626JP5CvBiHGuhDl0Y1exoX5I0jp6CrdXsR6vy//MRxasOg5pR73+Kb16hu 4PeWqbuk8BINIUjkZew1pJ8ueaPfavs1/CBvJYcNteX4StYc8hGXsOIotar02MaxNqhmg4vS umCLGtuUiVKbvrkNnHRie7oFSQKMGfBCOLYG6orCFY4GR+2k3VT+DRnny48jzVFITMzZVF7q 80sxsJOZqJzFLV76md6V14NUMzY27Zm76coI52X8PnmUHc0ugG8vjmwu2iThdiTYOeoAHbHP Sk8sZimo2qiGuuPbCVKqC8B9SUr7RO1bdqiMIaCIU6DnEgVh5Wanyb7vTcuEE8BsFNX8TKES iR0x02KQafBZ7RAC3WhhHB+8voUQnwoqnyp38fc6StXfQVSBJcw0syTaBOXf0X/YlKmYyqvm zxpcn7FHAnJy5K7svPv3cYzlb3TeTWE39R44N/rOWHsESvvYTGOXpzyQlFkkEOl/xeqwCy9l TMma3IcCP8U2UJt2xzppFDVvW1EH7rSMyBpbJvpD75WPmoIS3qGtK5N4wuO6xDQpgTcAroz/ KsxIzOEyPQBg2etjsllM+EADKeDKDQfUlkfneeSg6VqYODXfVYt3+ctPDfEAj283EHELT5Dr OxQjj3DIj6r8ttg3GB03BRHF0ZHodKYewCf5XNixsUKtPMReuKUEMirOEvgfWxP8Zj1JtfIy Ah7UA2xrZDGEmvTOSlAOCbWSU/EnygTWHOYQ7MufQ/i4ReFsIYFbSJ9Ltp/DZALxCaUkZQI8 7oHUDyVVP6wue7PLkw35YLuL3wsDcDOdm4cVN42GHJHgV2B5fDkaFpyqa6m60QhcwDbfm3ua bPuKs3cWlpUzSQGZ8WASKP7Xt83AnYb+BUUvPMj6lzd39kuYNlyhb4d1n4pOVhV/20WJb/Pj vQ3BTVBDrHHGBt1efVUzHa0aRd9+fIlK+qS+7RGmQ9JvgkgCM0IV3vpb7qnmWNVfWfx9au+H 5lGTjQEUC1HpFYRdY3jdfDsq9oPjSr4oQdd0LxYBH6+dqFiOSjKsyvoEQbS6HIGP7ifFh/nf 57jilypP/fWSLSMOBrH3gg67MJRYYeBVvKEEkDvaWjrQzor1mqoobx+XpTJor0+KI6tomcWc ZGFqz7+dukRMsuQ7yiRm4MJ5wtr4Rh3Yxabqn8MN6/4Mmvf0GbKONLFeq/NkQSNNoZrSJ3XD 2Hk3lx/JH0G8w3t8ioDlK7OUPqAAha5vT24zWcKWez6jmCD+MDBcc6th9ztgnnw18eW63mdL a48ZBmnQJPQmw0ZufboYxllPJW+3CmFuStDSUUVq8tRPWDomW+IzZJ3nHHeYQRsa7fUInNXo wJLdxa+OfUjCAr3wZQ74IO20h+1/2JzyFXIYNTxOzDvVaKu7lxPwfSE7oxngBQ+VPqNW5ua/ 7bXvCrqFRHpDBxL0Xj8Ga93vGNSXIl2UJXGgWPZ8cZn18y0lDAhnSAY1d4TUXx6RAdtHaN8v REuejdXa2p0gww4iDAYkodyfY/h84PqOTERhI/DNiArbno6lmA2BSQUvfi+MgXrw1dk3hFIG CYXV950vGqJb4aqlZlnmRaTA8S+EF/j+iTBONsqT8T73jSOvLFDJxAxka0Ahb+JfZTzRap2M w90fecXMoNZI1Kk+a9WTjJaqqwosXnZuO0s85pYnbh4HUTXTQ0xUp4JIIJqvBgbslMVDLS0i XjUD4DrJ1oPC9CG8GYBJPVFmesXy6btfOPN8tHUzBYwYtH3qYnh6+TEPn4X43EhrFrD6q1Hk Dpxy1AkCLJQiZ5j79arunuADn2PQUnzZA6qOhQxLdSanmlYTQFHA9JX+ZlVdVvafDRzclYon DmnB2hVGh/YvXG+CnkMJ73Qb32kPjJ4rklN7gedUajong71cfbcbEnxSVmvF+cCGV5wpQeng UL5+Xy9fNrLov1hKo2QXS3wnVDU00OnnGlBeWrtFxrjhnyQTvtVQfZm7v8iWIgpo1VhUWeGI fOmh28ROYbKQSU8hfIsuvICe0PfeWAfZt23iWD6snDsBBIpLTqyWJuwVTa3TRlz4IaRV+KV2 uGjKQXJEJinPf9G3ljOhVMJhiqMaS/o/eLCn4IQL+cR6Mka9gsmgA+XFC9KUg2jVIZOkf+d1 W7BMKdMjkdzpnadrMvCaT1qCq02wa3aKz6S+oISJ71TRmNSQg0I6xYJrIhJCRmQ3HzixMI0P cNu8S2eXOsNNtxCl6rrXgz1FZYVz54UrZJuo2uomRJnfx5nAtAAe26/KlJXUbcOuUbDCK0XX E5DlRGbY4uLiikaiIlGMBPaMCPEAgy5xN+y+XSRgxuHs86oxWwJVSSWfbIb1puuvEFXkWsyT rIOpccHJAiXA/IupZkTBovBmAM8+XjBa6car2iAiSvSNFEYRGAhHX3YKVwbZ/HwikzHBihSL eYeJfM8YFWTAm4i4IqXIegtjoqqJYJkh5ZxU9qV0cVmAfJZI4p00Ym1KU+Hgb6pVXFtnUI2M 8kUnys6x7ix10sS7Op6789K2U1Xh4Kx14e3r3zaXMSGndxt/M6qUL6svfJJJsvvnZXESXWT8 gd0tM6ywKMy/tblfqFNNdHDCKrJGQ051UvQmXTk67Ab5j5F0rRfcR1jmQup/ELz2ZWspFMq6 FxPI262ufMZj1Oaslo/4/L9osV8/7UUUqjPe7B+4PhMTLVaSXA4nxp/8j1jFEv3Cdi4LHS4k Ac5JIrgwKoetF1BN37RSHAsbxnr9Crui7wCl7UnBwCuypttKZ+j5Y+9/TQLPU0lXO7UMbQAO S5e5dPXFoCFfLmuhKnNwNC1m13yZETVazr95gEoxG2D7NrSAxEr324juW1DAEyhsRVXsZU1b nqFsFtblW3EEkcMhRkX5siutTaShVSk8t9KwtzIe/9dCl4RnePP4l4dYDbDbA76FXZ7SkAHk ruvQZz2acQJ71+CQEOW7rdylZ5/HFVx0mFFqKJwbkij7qsWD/jllHotFPBu4VedOORb0gSNG 9ejs3ugMPjYbnoKj9T3vdIMGqwL5JQiD40BOV6w59DPaCTvpomOIMeu5j1tuhra+s4F8CJ4E UqG1x5ej6h0RGk1vl/5UF6rQV7F4fapTOGXD5Pt/1LdFSA/XDLfzsRXoEhUyJ5r1NDeyr4tP i5KfBl88RuAo/KOFoxt3Lz4KnPdNQLJZwxOO9dW817laRxXXKEwF0UugsnppgkJcxs4BAg6f AUT4Px+1vLLcoXZMMMOBU/vRkj6HddwGyp8ZGTyVP3JC60+7aZVm1jmPObsY1vh2xCOsNC6l UVEC91rONxTaxnXKnsyocqfLdEyr0dKzM7Dn0xUV/o0z4R5ly7IJK9mvooL+zz/5NuFoLmj9 pRzVy/YWUb/MJkRc4PMTQgwbRG1xwymmZDrRpLfUnF++AlJ1xwd4RkUpyO56TYEO3Rx59n9q SyqohR6jOrGCYxjN90Pt33iY9dCF3P9Ogoko+CfNvz9htu6w3zxFc+zzkO8ZNkCReCqiVY+H c8zjNoHMdAbD7t//648SLNwQY3ixhosRODOMFI4N1yH6JdSDgkQAcj5IKYFd+C7AnnzV6pPq d5BBwGc+XUhvhQ/aEzUPFwgiA9E+m3aauUtVg2tLQViIC34g8U0+Kj/v2d/Ici6Cba/GdSLn wOurkJOOhOF6SiGGc3BsEhtgfw/9VSfWCwp+ZERfyjLdmIWp287l5mwZvXjkQCBh67FS4mn8 mP1RuvIpVG7uUdRigPYJA8Tmkp1r5VbB7Ud2tEN81tkPVs2TnQb0NbxJgKjIOOl6HsSGZm23 Rqq3BMaJqafGSg4ljwdd8xJ1TG12qJ7oBN+wvT5tb6EIP2lQ9CtAp3OLzqbIUIjkADHFWlrH HUIhxhVEOIuFib0HJsjOPkUJicbyARvBWiNBC9FI67fr7V0H4rskcoGbHskfMnJw/XpoBYT5 Hd4CADe0ba7HUY0dS3AVgJJQHzb/q84JIung7opi7hVPiwi3SNHlBDZYr+K63tFdvanile0m 6MwLahGQNkol2RwSNZKrxuQJU+QkVv7JFmloADN1YcC6u4xGXSbuyBIOmwVxwsml9VMMuE0l MpnHW0/wOM7ICzbnRpMeFxnXNIxSpNjUIkMIzGgABV0LuoAwnLtmVlU8btCV7bZavMq5dNk4 Fme+Cw/gTFsdtG/C9kgS35cvjZVYGhUQ0Qa7J2zGmw+z0t/e5izvojj6XL15WydsbHBHV0go GdSCZcUiX/3Nn/Bf3UqMLWa3eVDRaTblFI2EVunBU+aNXPbJGqwBhh5MncW1Zy8bkAXmxHIg e+HJUvPyK2+Va2ZrzqPe/AEm9XYDXxz+OhMrJZCzQhde5jjJFTKFUgPVIhUw+YpYb6wcd/VY QSGQjCrwbU1bkOZdDYVHc7MSfTsmiRnQtiOHW4C1BUVim39KHqOaEXOHzlj4U4wwPJQ1HBJk pHDsNlhgpp7FXhtPh1psDgMed2MWfDFCVTY65rZfPANFV0TGTONTHMyAAzZZ9mnS7uwrNjbG ABtj9TuixhPhjcEYZy88k7oeV+rNKzz/hTqv+gY0MJu9RnYBXlqv/GuQjIr8l/it8ssL2HEj TWvurYriNGEGTOxxDkVBv/E4B1/kInTCAGou82YQB4aqgmQ80NU9FDyYTr/aAJNV1rSEu1zx nP5CUhnMC8P6i+rUXT/lIERSahEyQFDa4rVYBtMV5MqOI60GJHw0tKrOfNSH7hdCseRwrURy JlRlUgXHoNrePbcjTIclrgkpHMzh+aUyw0RKXFh2rvoj3bC6uEBv43JsUzRLFZd21viwK2My EDC0We9gZAfbleOyY51p0S1GC/jz0yQF5+6UDxbIInTlI5mWxufsuosBUwpmLyBfI8bMzo9A qheXdb6VmnglDJtFUJJL4l9b3DSxMqJH6Nmr9x/rqBvPlrouhdNLwzjf25BZykfVuqp45xz6 LZy05EP0AxRwNV7RFsjf8TcvhgZo2wnfjuYLzq3YCU0BvfIS1fVrMNAx2jtUSXFLKg59pnb9 DILujnbrksRwqaRKvfwFp+j6TUlYf5KMoiAkuqdq6EGqszL+MfWWYwECBC+bk6Sd2JURujgY KYT8KQC6bupA+5u+jHd0F/jP2pmI2wnAm1f4gr+w/xBYLpr/exztpXSvXCnbLNDImi3VmtRU 8OsBDWc2sXnPnV+DblvL8Uxi+29FfioNOb33Bw2Vl/KONdduFquysJ0leHzZJZEsnU7qGsJD daYyYXC8VLckoqHfAgM3UBgPqm8Tvh90urUb0/qWCp28EqEO8/0x/VrN0umok+IvamEjgS/U Chv0wUFFxfxMl/ZjkXIx9JiybyNsaJry2ayVJviTj+oJN0iEqmG5AC0bwSA6toMa6za+tbVh VvbmVq5pieIypIyzKvxBoopue4tmYUbH2ZSOPB1ipcwwFNUXrky/B5VB0S0jYNQ0CK0P6HYL j162meKI2uqYEmhdcVObAwfB9NnhKtVfxf51KGW7ilYVc0VFrqvyLEdKWzwGzI+f2tXfKpdM 1faGl72F8zoo3HRb9W61kUa6+tcgYlkjk+y+b8mN8h1B3sAFRSuUeihZIJd77Ju7A171XGMO trz5ZJo0mv6aye39ORNi/khp/Kzb8bmRr3uFptuS9SdWlIthTR5qUT98xFoY7hMt9uJt6baA Py79jnb9r94ZoORcjvBoifwcQqSyiwcx+5EAUqP7aZVByOeXiOlPB6Xi8acYipgKHKkKoXX2 YPOVx4A/RM5S956hJ4CQFUn7kLilib/ENHm7tcV05OGNhIvjZ7roiYOza1VbIL2hvoh1bnSw GEMMATeL4/2mnN7wdAENs9qTyspSyYZEnacAqFDlqgVr+3FGBjfNCGDK2h25Xdgvf6oNfkHs VuI1s0I5T2GItDqthRHibLVGXvTyAuzklnoyZfuku5FLWOpc1SBW9trg8XeGcnLFpw1Wj11y ew1/qhFRNNWH7MQZUla/AW9OXXcwl2gPLlJo9aYjh/I66GFxecXNmx+9ACKMMpc6+Uvzeee5 Rolz1TmkvtgPZW1hawFTQpGjaTpQykPBBkPLERvtmh/7iRqGy8endl8OtR1KcKbIoY6H/6Jh gu88Wa/XAi8iX0kGumpCbV16aEB8KiUwgFhHXhZetbF8d6WMS+E6sVhh57wQhJ9+RfQTTki3 xhZE82Bfpubm5BnJjCdZBOEOjnBfT1BriQaN2ZTc8xwtK//7JxQA/K0XVIh8lyGfH7USd+AE 27LId5CLYDun+pjHNHO55J+cRHyQrfBTrMvGkBaxbMpFxENlvl0nhJYNkuVpjWfR5uHJeyFx k9NUGaEZen99IWsOgMAZOYuwxGJwrq3mmlWvYxTxX5ZBYY7LCpEzHgR1vjEul43ObWa+g2CU KsK8QpyTpydeZcw1YyT1VjXNjXAtTQZcwSKwhXSqwXEUrwAjpvLCCksCtl/SOcNyjJhEwB2Z bou6YXuRkb7qhGCfEE/dAtsFhjcZDO810ubZjUotvUu8OzOHwDaqNR2Y4Zg9wyin5yW4jswc onEPjh75ApahcEfqch6quuPihhQXeOIjYiLab2UTUpeXUR8ldtC2cIgePveOeHfjNLdusNmO qJF1oV5CUh+0ZDOermwiWzMxKN9rkzSPG4WzjzymQFqyx2gZlCD0YHOXctwnH6dLF9SjFmVi x5LL5umFIN2ItuX4A4VmEYmbsndcpHZ2AP+qVbwXmK9iRz28rjNnkEMN/sIqncdwn+ASWs57 1sfiMbDAZhlFDfB4kdEackVJXK8PnmKcf+Arp3DoH3YG3yDu0+upjHYo0wwDWmnzdmpwwNSo ZtTusYBdrlNJMeQ3lYsquHgqe7plI4yEoEeFec/Nf672KzjKk40I98cQ66FRGPgCb7bpkU2q gDJT+UN8IVoNPk0fIcjdXjfE010txpJ1GzghN5Ga1zj4T10UbzPOwIPjBrtCpkcPr+8Zn6/P zzj2rYdnUU5LK8UD9A7e8xaAqEx5oDSphGmFpKGRy6E6sEM5QFw7PSm0o6s9zfb1+9JUYt6v L3bCbWE1JWhWez4i6rSN9McuYkzeYNHLLflNHqY7vaU/XOVI7gwbpJFOueBFfAqrrh+yahXt RB/bFq9h8ECHBuecIdvTJDNyVt/phbMLa6tAtY+udEFVV9rLR0owLk2iqiYC+amchii47hmp ECRoZWn+DLy/Uj7PtEMcDmv+FmAEVMskh6fVyQxger3op2jynkIG/zfk5/mQgSCwJoTbb3WP xfZxb7oIaWSgCfRHHp6oxUkoJQBFKRBGct6R0/1jU+PLvNLusyKei0f2ddqx0BQkk6SZtgNX AccGq1Ai5VIXeSfw1xlgNEjqCFKdwRHeMRj1SXkV/Fi8OnhMTrdB6Tzp+63rioZEYzakzfob ERMBXF/pHxUF+fBKhU2BY+d8a34j2HplUJ4axQzHMRu7Wzg8moCP3nDgasuDkm37H0J2Fh/4 +u+xmSBtfgQJog9sjiZFkIMbJdLB4xVBUJUIENitfKC2gKAybFZ9hxysV8j0r7sX4m7pHcnv q+6U0tzS1kbT1mXKieQvAfBzYcP0mnKONPYlo3ooUAmOhH99jCaVeDub+0DoFK2dLbLyC4s2 3RHDkF673LdD/rZPoZB305IpdzayVBYDFvAskASIwTU2reqAj3ZKPCNusUhS6yIKqEaidzXB s/AshNTKG2ETOfM4218vKE9PTXhQbKBSj9Zr1l4t7AseM4sTIkcLixZAgbLkyMlVDfn+1vJD BAIJe3kVSiMOlL6m0cvveC8/HwpXhgHM7zYsHLpR1mOXBX/uY42LDmOY2EyoyWI5Wfva43Nm Nwf24GXHCdZ3rSUUVocy8e5aJRsxT72RLtr/XTDMEEXsIKW966u9Qxw7/hHGY3QiOSUPrZRy 0JPSvYmzxSk7NqMpR24K8zr/8n46RJxysgvDgETtnYRLetE2TpQ6abQGgMqurWAwEq6cJG08 u5k7JD9dcbHEK2Y78L97ZF5HxaUtece73GD4nJOAZ8Gt8/yq1gr0pLts/dHPHlWMyS6enqi4 49BD2ALo44FLHrwbY8WVqIhm9P6/mwDaAcKWzUywh3FyP41qJy8jzD3rQk5XqYapKdmLnuwz B7i+kceguPBCbth2iJEun+42o5T8QmVbx1AFtCYi1wR9qWUa0iF8mWKup03IRL7Rldhu8kVJ qIHYPE6u2J09rdjOmAoBtZ4SGoMFc68SDD3SFuRPxz9AQO/E0+vc8FNw6XI/2R7f5KbIs/42 qgRaRKgnz/MKO12EVrZIZHQtxp8iTbLq17JcG33bqB98VZvaMJ3qQFzqUn36y3NXccE8ihzD 4NnNOVOadtZaKfhaYT5XbuzP6TxWBtYjoIyKRFJ0W9JFA4Gx1THmNUHOdYljcSRHmUJ19zX2 fK2vOEvlHWjheAPe9WMNFZcqQObumGsUGtdJ6X6p2BZBZOKm6hNM9MRJo97mjWgnWkIW/O7S VnJe65B7BNJltoF6QR1EWyFmMsfd6Fitaq24fccKdjhkJHCILyXwTrxsedOw3Lql/Fzt+8k6 a6rrsVkUAwdr9EWlmiLUSSvtJcd0AvW2hMGPvmCtOSFSmknPihecgqe7lnHQtzL/bJmodnR+ LYVNYa/n2+TRST5Pwaedh2ifbtIf+yu1OX4IzIRO6UQHovC7oNpzVfAUKvnnWLWqFZTZXHUT i/G2ZDTtNSzVRpywLTz6ScZAO52GyLfncuuvl6qHslN5qf3dRV10/u7sRJ/AWvtGENvoKGmy PGjUXy3mrnGVMFfCA4Esdr4IjKqxynCdSD6HHdc4TyQ3S/EMtXe0KBn7OIL+S3adzekKJIzx jaz4Xt6UF+kNYtCbO4nG2J1qJfFo752t62SRajjQ/a7Tabq1AViSswtI1/XVWIM0cGU79Ss7 U0S302uUlN6tJHwv7Adk3zP18sQJQAMNVyWccYpa1gBSXh2wmJwB/I9SeFe7zFwDq2yf2yie t2FDe3J4FM0UOpg/Pi09UErUVxbALZ/twBvjIpZyhqAvwJwXb8WYI7TDWey4XuB5QKmS4zCJ 9xIGjbgip/2N2a1pgLcmIfHRXykubwq6N483/qba9SvnUgbfIcCQH14ZwJMf9G/PCUAyWPue mkMbhpDz81r8wU8mPLVQ3mOnaCHuzY43grvIgOQeR9QySS8qW2kgH/in9+EaooWk8nTZ+mmv skNbQsq4dWiZwOYyY8su9rRybMlIwmO8vf/JVlbzbG3KaZCKyqRJvniEZJihU0n45SILFPNV 3J77+Ef32hShjzAEkUenUF90DFe26gLkOrufwQsw5dbNE5pbZHfp/Qw+QprDVxDrGxInrxNt LjVmamzcCz2jvTtf5br1w9s6iFL6W7z756fcobwN1t8UClLKif3eLkkWrD+tp+cgPieyfuuh okabEDVMxsd+k+tE7TtrvlQrJrl9+Mk0h2joZY+zDcDB3ggMOTLOxEUKaufMJRc4uROiccI8 teIqe1nxaI+vaTiZZ6p3DCEsrrhRmOx/XDlCAhW/sdjyLRwNU27HsqBY8vJwEiX8Dem7xwcB VkPyzDag09kUFoc1WqD20vPpRtji2ekH/94uhCAvl9qhxShU1apMTIzT5A7cBOGn9wxaocPv W4pC5Wz2kroNjgj9GEMHzI2aW25cjLcZfBSCiq6r/2fpJbgef5ItUnoQAyQZY44K2MlWdvU9 KnBsiv/LGcgknljygv6O2NSrXiHY3Ainzp9Md1k+V1tqTMldCBecYoe3h9hu84HgIWk/v32D 493I5i7KPUIih4wPQ8/DrGMuS6/sHxE+a73Wr42Bp6Taxj299C9vCkl5J2F9gBxBJStIp5EH XLGa/5WI5r6nSzWUv4kY3iw8d114r+NeuUNKrkDUmCk2I2ZHohF5aPGeYKbcimD3QxdkV8KW ndISliHnFPVIB9lA75WZDvcaZBcw0DU2VtkmWAZ6GMz9ZJFvjGtoARYAc7dkBoGvLGbMTGCS IeKiNbF/+nX23uc99zfIBSnjsd93vzXkPdElGIPMYVFMQsRk0CDb0xsX9BaeXgcscsApoXH2 HyskT2rxa2ZSO2UijxMI1jWW7Sk7LiTER4mKo7kI3sGYNNrs8uYAqEt8zRyX4K57q9khQHGm 9lweEQXnm+FJZ38vSpehuyQkvbA2xl8MmFxjEVw79e9iZc2KMe3FV1aXjp1qDvYdprhelqfW SaJ664362xdHK0+XTfK1AvEOP5w48pZWFgeTEa6EgQs6Cn8ksKviF+TJZJFq52aha4iPt41s kuJJPZi35iXRBZy7U+RtsN96pp6eESglXrreNarzS1/eEdbemFNY/BvSSR97jiam+yZCJgIj Oyof3L+I+qeCeClpGT5L9KiXaB6lEl4MF/G1FxZMzNWtmpAja9kIZUPVmUmzwc2WsbXnkEEC kDQznTgQ3Ek53rpInOZFdZiW3f1ktVxjnNfcltWW2R9c6tHo/LZmuICspAJsqV7QaTkPhq0m mdOi9yb7tSFsWN6EqfatbMP48MXrFaZAYqkSIgXa98ZWf08C0miNyRsjQUYkjHCXp8Zy6bXJ kunT4LjzBVfGu+WrTm5eAmp88bf1bhMaEucwY3FT8XnC8kCLX6WMk1rurXEZPb8/tUbe2ACk RN/uiRZxeqej4gIAe/n5vPk1Au+/SOfnuehFIIkz6FLPmRXTSkRsf4Ph+xIhiI4gzC/wGMrl vOf6vraEMXRbOvkv1qOaYPbkzlQOcA4Oew2uAObZWEpgO85G7crmj8WPCkG22/qdJ/zKVaw6 7KR3BNOlC2DXw6fBgYKzZslqnlYhKQwBEcdstjwDXcfHPNHSzpoh1rNfMXEIMR6//Ud+f7eT bhoziFVQTgW0gIatBtaCIgUxnRUkKbTHFd2T19HHR+0atRZNGDAUMc9S3/KY6tQkBnyrs+7t 9HJYaqHc/6NVJVKmEhZbF/hNqBQ/gYAvr2PXd5fYxRCFhUUsQILHoo3ZbA9NX0yETvZHhHqp Vh7Y/oOxMjRLMggvsJSsqVZBKTO1lIjlIVMKnh+8Sb4hnbIIW4gEqmwNmTkWpZj1ZbK/y3hw uXtpHLintelGwq51WRDIxVk6X0RDZOPlVFrQcIiWMYkIlOkHq53oi12506dgcnFVFW34voSm rsafmPxVPEXtzng1gV2iXiAegGYpe942pHCfADprPxRp64tcMvnSFBc4xLdkyRF+JuFkfXOh ReTFNRL3ryGMokN8DpbLMuapTIqgYm+mvl3q4oYiVvY6Q2Ph0NuI47AyXVyslTgqciZDP40D 46v4dDpS/s2uHEzYq5e8fzh+RDy3BFkWTz+ZPjWu7vHXLlPdI4dtwAcLh2HhmInHWnW9Q59c o1kDF3VRzPLq3zp2chNJO/gcQCSM4vJVHaJXXT+d8U8SMFc3bdhiOBRe0yiVFTy2h0pDAEXj uSs7HHArcumblA92xnnOouprIPgdqqabTqivSa/O2dOZNHOUkkPMu2lvdVc436wMzrxB/KOg UJsSv+NfB7Fmq9jvlXwOUZ6Xp3K9wolA6JJAOy2oVJhswvKHCobaVGt9sGuUQ6Ze9x1IjB1G 8EC0rmF1GDOrLcPxU2E4RdkgCprknAiIoaPxOVYR6G19ypzjkot+5mUzyfJ7EryOCYTTlL76 PLI5ACTYzUlnyl7Cp6zyXyDEVmYuIeKcETzKjJWxQOcyHnEYIWXUGmL11/qojdPx6PUxs5g1 tjZYrquLBRhgcqcmVstUJazZNZD/wzsYVOyUlr0BPjDXYF1sNYOU1JNdjScru/0dkwvIkqgf zNSvETUPtSFVXCfL8tBYvFzCHC64OO0zjuEMxEOE/uoSnDQBupKNYZIZFZmXPXjwsXZcPvSl 4UuIHcNlYm51yC1dzOj4Z5AWeED0WGafqRoidKyxkA/kP8gHdT8VWOu9otfoTNGEdHvMdIk7 Nx5eR4nFVWfVBBVWmkD6Tq3+xRIEbG+y2RGLBJsrCZSrP/3/V0hw8fza4t5c7v3p7LYsKETg 04npFggcpJnPdJVa0RqgiiNTE0ekCychRybhX9Rzsir4S9+LZrO0nRGS39VLKOjihNS5/36a EDSQ8uDSMAxAWYut7172rojt/rMpCdV5snNa5ezV+4JRdjVeWRSJZ8WwmClCBYXmX9m/pZ/s lLUSWfba7+zP5LvqB9jVfUpKXWj6yPl52dN8kvBVeaAIzM2xUQPnEJflyw5tE97+FpooAohC e9A1jY+ETEzq9fb3G0X/OKorwWBLbAiz+BnYCAcXEDdNkEKq/jf10zIGe8rG8T5APOku8jKb qi7rjInXuRvkflxzNl1FhGPLjdw8sedm6LfasS0x/7HvMBKP7Q5KJQsbWmLFsqGdTShvZkWa 6R/5dEsjrXka+jjxzbBU38HZM2mOKK+huXQmxlvA7OqgAcnQWgPHcu/mFZ3YEcazUL5NCONK tG1Zh0RBs/Al7gx+KEI0Jcg+sFFGmMClK2S1NcHuXCd8EjRA0Q3dC9LmqTMk0w3vfDq02u4i AFWEpMttsdz7CYvLT/uQdgiRNlowQWjW6lNK++M5nWYk5ShEE3RlZ+g0ULH9YPr2u/SDlypy z9KOBbr5zJngReXFuGm1+7Gje1kR90Q8NATX/4g3/S9mmucwa+ECinIL2R37juj4JBFgZuO6 94n13pjZ6meIBHCZiPw4yfwk/7p09qmf298yPF7YOhdNKmcvC5kH6Aov6jPkt/sBA/FLRQjB JaNVPTzemPEsh/kywtyzgvZ1Kag3Y023p4ASmRPwY5DPHOq+MCBF59sCEuu+hLYmjk3XscKb JdazQmCKbkdsq9m6cU7FsZwRxVvvYJ+7KCvwJNnwoFqIB2vi09Kb59TGxyRCDfMPamobQICA my+kxeGgaFxXOWrRSPqf17a6WIahOk7PDL0uhvwQ2G6Rzqa9/br/8Jn1Z8MbaELlWI7bDwYS AMX7crEjJMxYzvd1kI8QzKDB88FzmNQEuU4HHdmAtj7gc/yeO9y72IaBy9yQlM0CtY37T2uI zPxLsn/rY0M4QN4xeOLH6qWrFGrYvprotSRAazSBwUpzHLLTU5Awq9wd5PJjFfBHk/1marjk BdQz0RTs6+x3GVYM6YI7Pn/YRcvXVuWC436AJSbV6jQRCudOpCIE6l7wtCo6UThLxfUqaZtZ M55+yqHfy3tnJKxGBZrWocrzWDgEVRUKcZL175vifN2PyB37FvNnunsvVtFAwOTiFWZYvhuu 7S3bHueZu3YUsXb3Y5A8nPkhQN9JJCXEZPVGbRmM5d7pYlEYkt5c6X0IPr2iN3A2kL3qPWBT FnFA9h0+UelRDQRC4CapHahmDeW0ilPtN7QNaoMs1/mbL/yPg84fliJG/+6pgY7yBD9ZVF0i FoVhdYadIEBf+JqEdn/f61HbarYJcec/p5SujPwP0v78gM7tcd+GzB/0AMwA3W3Glc0y800V QWVJfy5usaidpNp0xLi/KztrED0g0NXY07ht2NkYIwBiAyKHydJptlLjJqZUBxot1XS5blAQ EI6Nkhn+Hq4F/AvMs7pLm9gsqmmRxDibBqZc/Oq5ZU9L9L7R83U4PJzpTmgLd5KAsdr6exkd 36UAnGgue5D67kuA387726YN4K8Bn5zN63awbUjDaSy5lCRrVsbfMdLjZj7vepPkRJ61iwiP G3xkEhrbyWwUP3iNr4CQLAe72F30nDKfiCs7rgsX4HqQHU/tjFgip1V1Wdjr3NBhaXn4LNbB 2WLM8AaLjXyyoXREUOntwmy0txh+ac0sAtIFhR5ewlKYF6gC09vuflfVqt868cR/IaRzOTon UbCxHbXZutxXhsOzSfsjhRMX2wNIV+fh1ih+Uw/ke8YHUgxXoqQTkEJO0UB3FFPYHl58kCIB 6A0KcK1c7NKlewH0gpJc/mypKhC8uBav80Z23GhgjnUJCXyn+V+7LaVU8FkFGjStjGGY6oni vMe25JXuMWizieZdZRfJXLJKX4BqoXqNvVkvC+Wl1W1hh7x1rIyiyf7Lta5ye0GhNqfImS94 eWLzAhxb5HmfNR42AgpABpsCsiYlJuMLdRdVe6UjtU+4EAY/gQArc+A5S0t37IgLNgv6BJAt bmdZjein4op3fm9H50vU0x8i4pFawWzqDZuTZEeCFXpYY4slJxFtN4AdYKrc+a454DHazCFK 39JYR2u83OUaze8HfRxQg9Ia9bPpWlnjgJ4AZ8ALi6udNvL3ms2Us23SOdoaFsyhSZViO8QP nrVC9HwQB3r33Y9KcDiC/lLFIk58cKkxwoCIAYWsX0MYNVmgPMWZXoCl8flUCcnw72skDUBV cgy2lY1ILuzCmXsjqaiLCtYDgm+quxLbRq59w4IBvaWWVF1MzrS1eCqN4IuwYNtRf2+K/LjM I4tW5HzEzGWsx7BDHSGpLz2C/vFZB5Z2iAsNat0d6Il5Kwj/tauCbFTi1GBa81sQ/RRQaFpZ Nbx6GB3EEF4OvNHGqVgGgagxysGLwqd6NzSTuw6O+3ipGlUZpTAuCGgBaO/jvh3OFgPoT5gL si7m2qxCwmTywth6meo80Z0KK1ZtNbzqkqgABlwlAnyRKM9OOHr8Ex/Tabgi/4sYXTXemFuz JoZw+Y4ZX+ILHAMbwNAecpYY3dFuDuq4UTvL/5vjWY5/lr7hCLxQRDu23N4/YuxQaNhnQjoa cMtQe2Ung4NpM4RGSevax9z/0Hri0K6i+LfUKPamhdvIWb3pIR9T3bT/C8OFppWEeyfHjLdD C/EyLmZXUz6dPUb5pwpo2/6JMVqMDoZbFMTEiAifkhLzgvt4b9hOoCWscVe3CrtdAW5e+X2L w3sVDvkAnLohwJeBP1FvcNGq1cQQ485po1xDUcK7GmT9UIjUpGkYiajjWtfSVIPbwosIGFNS q8E3z+OqiNbOYlP0UvX6hGMnhdWNqZV7DXH0D94OxDgDHMNkZeaJkYCUwRTE3+2z6n+AlwiD tWcQFcNo1A7eZt9iwFa1JDUKPuL8JUlnEcG/y8kc+7cA2aSItINK798jernXSM3QL4ICVk6l 71ZeF231n8ZOxhrIVca1uIvSYhnCUG2tKOY+ybU/diMI3qpjs2DnN9hze4xRFDkBfvpqoc3L 27AJf4eS2AJNHCiwdfpDCpRF3gFsqj23JWVZRbJCZ5bRUB2dC4bTHLQXcMiCu+4mQnAH1dX3 OZcO7w944nYdLqWX6Zv1I34/B4k8sdhCvMWdt5TzfIBIjrUtvOS3pJo25T/ovxAthTKr+EPc JOWtRSjEKVHNS3l9xqnGG5lGYBtWbo6pkTg2KpsqeLlI6SXkDseSP4nPNRqWmdDtCOEXM2Fn oiLeBGdZD1noAutuOoHoBBa+b4bMHVvYUHmViGLfyN9n5e4InZolOnE8DI7yOuChd8jwZ5jk EZZTzMOMrYQE2ZNzGQGcxwwJxxCZTjzCuRqD7JTx28RUE85FTeyCmVhLbXOgdNBdtdsu39aE wiU7R/4eUWW96+gKiG7M0cCPZ86vDwZEoEJCb/VdJt0WRuXdZ9xqtyZBdrMFvj7ghOUMuczS jiUPjnhMUGmfpD+JsEfUsebDCSTm/5DUsKZ8qWDzjd1KrQb6mJ7RQINYT9iGwQaeAitNviwa VxJvqOqUvPf7TaD2GBycJUm8q+mBLNU6f0/glFF4ASdqCOd5Wu9vDbKD933T01tV75Ms1rpB QdjxrAq4KJAFDly9Z6jlcxWCTzt86QV/zGGiKlZTki394FfSt+T3EoDr+qmADQrwtwOf4BWc LtS7Y9C4Ss/QzG31sN0PxKiogA83EDwVHV3tQmD1tZIRb0YX3cdb9tFdEJU7LDCHmPQxbZUh 0R+Sd32hJ+cgEp/QxP6V7qVuc9ZXEXizKJnecWFVVdKFhu4R2NenzcXudJFI0ohcqzUr4G8N ChzgCYi8yepxf1PagOqcH7hmfwnKhS/p8dV+9YPyXKcca1u399v+8uSJVSPXhWJdu0SjR5OE hYvmfmVgJhUArMTdQLVI4QuvEdoP5Kz9L8bCJskWI69RjaHOxGjk2MbckqpwY2D5zaaeDA+8 cIHy07OnLflkucU0PtqhHnSvjoIpnu7UHpfFHNuzZ9XS6nS1fAfquOMU058AuO/8FtXvvrrQ 7hbCr45ja5Llhh4dtrN8icE+V+PGdJLmNg79/eUugBW80ZQ1CW7WdQhKtxGUS7ntVrFwl2tr m0ok6Ur0+dpF30G77rDv0pYgmQ8enU8QF7sTWS2vuDG0jyBDWQY2WfWq52RJ1WsiWwj9M6SG Y+BOVvOr6eveCQAzqEp9EDCzlYNqLovd7qy6iyglSCHdz/j+pzvA/OqpsZ1Qx02ZYkf89q21 Szcng2TUdtZrc6ADPWDayqANf4HLX0CykvnyX8ifoX6QiNS3DaBqtznr9lBfVgChCMo4eu3c 8rGZC6BuUU+I20Z7ZlfTebzHIniHbMmN97be5UaQ50rusS61RG+Xsjsf2ZSF1uald3yp2MgC +rADmBJloplFxLd64hoEHfSSV6glCs8Gg4xVMaQtMxyHIvt0XjI0LIq89EV38Fn2hAVNrGMo nGCGNonswUtallRoAQkgnvZogjUCH9z8wxUCb09KXXL1/MG4kE1CKDH3UG4VO58ulSZEt2Jx bbu6u7TTbbbKZT3Mmy3jGCg3jPbWZSUmPYgexoitODTMwUu6wmwy2a2Vr37ZA+1CcAfsP375 WInMiUw4sovrqsSWCP3liejYHL6Qij4IM0Bno2Vjv0FACRWc9o5h6N2f8xCJFotPhj2iJjI/ G4+B6Sdto2BVDmVGUqhpFackr60K6PvbTEVqF16PPwTPFnIZupqhcknOzNhU0hJgvtX2vihe eFHZCXHiXmPWtysXcMDZjy/ojgYJWlel6qp/lflmQLRmtdzuwaMAM3PKBgcDqNhmJrFmMoiB 8+pruTj7IB+ua6mu1l2FNXmsY2TRx+PQiIgyBl0U1Ya7mORLlUXgG2vjIWvqjbVgV+36tl7B 26UsbyHQuXQphn4m3DIREpoq1BVoOLzVjqAdusrQcChSWeWiNc/wuhQtVi7bQu/3+nO0aY8i ETyjjdg475uH4LYhKLpP/3fvh0crbcpGZecaoiN8CB30zBvji0fxF4dk0Wjt3YsvCh3heAc3 CZHRtBcf0USQFiVpp/vOBfKBcBD87G6NKutpepdGfYtVA9vXhyTVTVdp6Al9T7GJp8Q2TJ+C DbHwbjI7YE4JNxIYgWP3rz5TEYi2n1Pje8At525mkCE9o/uVZt02XClNzuXQKAGSWv++QkUU Hv2/j+dlW04TmRquoSaHXBeGZp42HOBkUUxUfOfBgchTqzBO73wNIB8yPsGWL2s8gaZ8qDoZ etqFBGVYarrUmyyT73CdQuPdqHbWXaHsxNaGJ3ZTL8CWbrmEFN7cHi0VbFi005vpEyTyWEq4 nOZpMhEEk9YoKX0PN8EvTwKRGLPLmD0siC3UtaEVgIS1mev3O/z9R5hK5xzgkq8Mxir09O64 POCquQX0V9XvKId352RDBnQnvTV84knzQoWEp8yPDhUqFsyocAkwVUfTSI+RBMGtlh0t33Y9 E91SWW/7xoYnQzTQ4MO+l30DnBqSqlOGIZqpgQ7eb7LrodiKc/XypE7yPgLhSmvbByebcDyF GHa57oJjHqQ34YXOa+IAnPaaG7rZc/gooFxhv9VREOJ9eRSBeUUDMmHh2+breacyvIegXpXz cwmKHivGNLGtORON+nbITvdcY28n64YFPjIAtWjLgDoRmxwXAI+xyh6yz7FXM00o85wmEH3I x7n0+2Zdmn0jOd2YdLWJz5p0BQYiL1qrUiTrmayXd4z76pR5azCDPlAkNbagy7iIwqKrSq42 UqccxjbHXzkROqJzu8XTBc4FWmmxmbGLqrB0BHwy1TJspVN+lmSAciYaU66DD0Y+MGIjw+pF VDNA2jocM1Cr97LYjxU2a4yVwNjPyNwCoXhrHNiWNH93RGAz2EUEkpIJkKofU8VOWH7yM9Oe OTdtd767dycuWZv3mrtlxLTVXbTSq6FJPdrbTQRnjovYCVSs0bGdqTapm7skw1VMrpImA/nh EeWHWj0vUgskVuMC1OkZ1czFX108ca4YhNHFlh/Vwd3K9PrfF8aQUkh17oJmzfAC1UuDbVtE wPbrq3bkZOa/HPQ5bkocblvHUIPzCFC1C+WtiqbZDx/3Lq0gnXSzZD8VPbRZhwioDp44XrrV yZHq9pOL71AR/gbxGkiMT8UDJs3cG5Y4avwR56J7/uLPpzhYHGRvChUV+gKuwDTfErgZsQSs 5WwEWGWclAZSCyoqltt1tmZ1WwIvQO/w8qhiVX/mbiJNyYFresSkYccKE0r4+14ziwy3w3FQ HWRhMyk1Ya7192Sgs3zLuDQEVET9I0VcCXtlGauKepr5XJn7ibLy0+1yOjpVjiO3U7xcGd4q Xp4u1FbOhgtLC3Sgpaj0ahOxL2Oa5GrjPtm2agKdumknSwembkm4UPkAiyewyvIVDvi4xHeT ktkL0Ai2Hg60F9knreosHsY74jzppN9LFJMlyu2YpCKaLLLeLav0NeQ4WUppUc+OFQoizUfo fMxkJVeYGLoJ7jRIiJF9BB71SHsj3+Z7RfiZk11r6bqmONP934wOMX73EsyszbxhCxzzDMT/ 403HtNak/c79TEXyQuoqg4El1wN7J7K/TbIgIOEdIsZgi7KCJYVA4P+kygTcnJzsen3f56zX E54ZfNEa7GDDW7kehS/ADo+WA4XdXm4xp7OqaR61bYOSgY1hGwHWcZ6LY5G8HTPJN+YhwioM Pfcd9yxae7vY5urwGVGEFFprUAkpA1B9mVgL0zhVRD/25UXcuVD8hGRxjFtvR1G2kIpGxTPz 3M2CcE4I/TzmdtplOtHa9n520ASCrWSYE2A7vmwdX0DoEv1oJpc8cb20FSa5Uubd3TKV02Cw rTSpCY8mwL8/ew0JdNhxLfAoNI3a9IRI4dJkYfCpMPFlx/DUAU+lITwclx6mCbUnS3L3BKWU 4CNVWZi0+qtgObF2T4HtlZvH+Z4fi2YHeVakWCOQ7HBXHNxjN3DTOE37Kb3/kgYt26D5JqJm H1U6Za4wDOO6Pv+wwKLhDREOtTox8CqXNUQTWADWGnOyMX7h4RExKvRPHMxerxrdWlsCsi2/ LyOqSiwqR9A5kSFT/aV9S/69aNwfMfn9NTxn2VUIS9bYotqKrMu7gD2F1eCguTVmwzOCnvXc +wEfArJ9prmdZhoRcvf3c/qcM8xDn2LB4NQM4tRaHcTAu0rrUjf14Tf08cTZq3e7R/Eq1H/0 rAFtjWD4KN23fygYZ5C40ZuRQzGbrfq/Ll/49ol1+eSBD/WYhV7onJYS9Eo8fBzCHi0/kD1W /9FMkqpnG1bUWUJ56/6sL5GWVLaWrpmu1R/HoVttTvzKmwTiTCysIBbzgW3Y/oeoYLE7hgFd eseypEk9XihocG4dzA8yjTK7CTncMLcVMqdA+x9R/l1cdl+KmX7qD4zqlo2meCA93SubsTgT 7eHm3QLckFZ2Oy9SpecmGLCoWbRUo0vykeaYEMVeNLykA6FPHX9ibLf+oVdQgqEm8ps3XfvR 8GskwUilIIXwIATBgCYkL37K+jmzu0odUm3SFziwYgTLBU58QBbWu9gqDksXNdWGC67Bqcy6 xBcUHTD/Sx/d24sG6nUCO5ubPMjg0LnrjSKgk/rx/qxNh0X482so6aQOMeF++c6WJoxpvCC4 qc3b5mkHc+fR1ykPYiqiinf1Pgb1jgpx9z4Ubuf23FXRuywx2YRnai8c1cInBPEOf/2q9ylC t8gxVDInnaCmsucxslnLo+TN3jnbCUFnYFzk8h8BHadhIsJeBndTaU+60Qg1FW84oalLUxcR r3ik8ffi6k1IsjRl044Z6JZXIw27m8fgfG3FT+gEalAOZAesPAomDDwiS9H5CWp7dS3Wnh7h Q8L9t6uJXDkUiJNEWTOxSGMck8Hvl7V7B0axKCRTbcrA+/TJt+GuN+xU5/nL/xgP94zPtmBX rcFVASKxNLsiVw2f0rN+hX9o7dkE6uMIlHRBpE5rjAgEBqESGDK8FK7kmxdhnVt56bmp3Aby d6EdhG/atpnwhFla35tFSZh35W9OxfJRjxTuA2F/IHiThqiegTp7h12neC1zWmKVXKcd4tGq 5U70XhGt9FRYKUXS9ID6N9ZfyXS5LPwxKxDfL9RfygQJ/DJ+Ru2p14zxgVUVe7HiqVepEux7 7x/5VqdWIIdCM80GYYwn+oZe79F6OAUMuR30nGln3n9eCQXUSqEtSal6T9TvJ+Lr0znF0MjG wPWbzYWlZZy8NcXCrR4tJF5G4t9+tdUw4r+gzgcWdS7vG+urqDWC/6WTjHQtoNbUL/rAJ3Fa CAzieMoFw/qwgkH/1ELooGJN6hj+oSwimp5Kdf6lHCaL9gkOcVKf7CgyxBTkVWbBNX1vHJej 8PYBGQygn7ZX0IJzlazMSLiwEkVcRWRk7Ezgm6Os8BfIuDrPrM9N9U8DFvve6BgJfmW1zdWj zi56+vJXTS0KAJD28WIRmfw1ob1QVuOq+K+4IlAlCEzqQZF8/s6ct3ae4wBzP21blLmtdwbY Oz6Jt5W88AWq/hwoUgwgWQx0DXm1DZrB3YzmbCcQjGU6rzn9wHIo8nW8xuG2qJ78cih6osd/ g72kz0BiiHSSQXcBy8bJy2qfSa7jB8CgFfl7DSssVgeNpfBt2rxdq5H2ORXtsR2XTeLGVnUh 4d/OAv/mQa4pdWdNJQtJ0mm2LTC1YCT8qDfUcE8pS1UFNSiw67RAIH7nnz9GKvdsc7GP9ds6 enE0XPLWxGJPNdl47UKRculrDdaiNiL04zkzncKkdbv+lN9ypSmmZ835Jq0TvM155/LGcGMs zvOgcDRFTc40ZpST8HiJfoaT/7/ZAbO2ru3UFNUIXjNc4suXh9Fqq1EkeLeu4gw6Ub3o7rIa cAAHF+C+SGKFcCbiZXNZgLY1HM8l3ry5A0bUiayAnKj3UBxOCXCKRPKAKexS9rkwJ05LheSs r24UhzjGaiXVgPDclRTdDtj+/e5xT6NyP0Clhj8r1xQtIkYdanomlR74qyM8uBNBZZAPcEF8 xf/j5HnNCu+G1mtaOVy+aGG1CLYFwg3RAdsasPgU4k7lKxct9lukTEKj8Zvgh4Ne/gaoRVQL WM3f0rnFRWkZEsTgUAUgspuapKXoaIw/uHVt1ffz0C5iF09EVB7CpMMtvpkI1XPgdM18OIsu HxVdM1QIeEuSNLS464Woo8eKJb5al2Cp7TGqvsWVQmjQBGv2OfOxxEqcK8yZrbdnX+JemPbT qmHNih5kineblsHA0Y+InkIxV+OwN2hCS2Xm4DFXAeGYJSvDaF13H24DC4A9eqp7jjJe610L CzSvx37MPRDnsKqjwdT8BxneSduOuJN0FetGjfAg8fXjtgASwelOcsZOktQQriARXpMQ6Ak1 7xLLbmNo5FDrQgNtqCn8QjfIBgiVKiG+tQJQwABBRpikYnnHr1F9TY2DIAP6yXCJ4wf0LUJK SYhVhYodxqVCKsK5Emw3WoZmVvRCi9Jq/tnOsfcdVJmwDJJcfBhxE+s1kOKOk/UCEpnJAx6y 8p2NxR2imNoDvaTzW2pWvUuGEQVTMSseKx4n+nx/02rBZq1WNCVfiYxB4ZWlwpHR4qKB041M 6OX0Hb9j1Pwfm57/LVSbtUiEH0Xpd3zIdAZz1mZ8zxLwJ6253JSLlKv69/UCl/tJ3yYvbZE9 RHp+35LHfIVsWcgFrJ+K6T4L/SGis5Snd6DgEYl/8pY+k/TbTJ8YKJOHFyL4SfFLtO1bQBqF ileERY+sNc+xFhq0gTkWhLvOONrIQZ7E+3BilH4rivQwqrnnejqqQ5/88Sj2ixV3gl3TGg8L 9CPVFxmETUTf90vf87YZB8/zkQ+cZwGaLcr3Z1jMWc38uFH66mrI0JOXA10nsbL9UqDAZLdp oUfb2WDsizCuxt34kpltRjgPVKOGbHJ72wwe6FrH+CC+VM+8umzoBg66JBHH4kbgfygKwGk6 MYOK6KIUkwItrOx0Ycd0H0sBIeHfe6BsGvDYmW1kiblMBdcInmH67Fq7pVCR9gXeoDCGN4Zq EXbbcQjxU/BOET00SeeoXzzScWwPQa1mcJ7cRzPnvOaZo21VwjpHkx7/GPdRP7VUmMr/T8iN Q1APAYc9OoEa5mt4pPd9ZGLVc9npBzFjS06bcvKh0nDv4oW7XbPorL+8nHOlVBJ8XI+6sSGm vkm8fKqDJJrdooEzw1z1ttSeLZ1dKxw/vgE6fJeMo4khRmdXzd/4UeHiVkz8xa3b7kzgkRGZ kGGZLlx8V3AerAUfoiK8xPf7nz7J9hzqSj/kxu335Z0K44qfTflkb8oBx5H+oiZEzEdJpyjA XEL3G1XOLDakbXJ1ZolqmnVUNWCoyH/rcNUzbbh0avTvPg9ka96GZ/fdx19UWNtccZ9Bmcg/ lDM7Mbt43r/7KOZ/Gr/JSe+xzpuFECNGnn30KuFuykqqYBfjux9YWE7Ar5ryE2ITCWaeQiOk +LGl5ViZeZKC5A28+pnRuXLDrM76l5pc1rCgnB4chy3ecTRidN4pOaURzyiXtpwlTo25QSI+ 5ax24HmjtwE+wht3iVs5U8qri2sccXNvj+Jh+6P1xYaLjziFYxP3yW5T3L+dljD8/teG0gd0 R6ijpPWuf6X/ChJIxayyPQXtDnkKlGdwx3uhteUwRpNMUfdqB32wKgQAlv5sQ9c8DFK9hBvk pr7yLW8MaGImpKu1ZTbaXuV60Ch88Me6I5P0Zr12AO1YIeWmpviB7f0k8Y9ODTueWWR+Pabj BvR+YJH53Oyn5B26ovlmwK+RnmBak4iRgXEVTDwc+2wRpuI45yYVXIGCvnwTIZvm8JF0RFhC 9V7+t8oVOMeEa3Djsa7DJtHSqg10C0O21d48q2tvTCo9oPOwscS6lGAjn1pc3s+EhHHDzuO6 tX26U+YtLh0oqPruNqyz4oKwn8GCn8rM0IZK9+9eEmviUq7WB6o/biXcrBgSlovID3TeLdhv awnKV9nAYHBqWWnhicNo8hohfBxwFAAs5tkyQ7/GSnD7igVUqVBST1gCjODuTzSIi9Lg1+9d dWqQrxltO5pfA6jWHtLRnHWdWy2J997lY5ULVnvEHAOAYCppk0LUGosqX/NOnDaD64BpN8Tt +b05DW+G2pCku+5FsxVgyg6RFKySAEP/6ck/KIy64WZElz04jqrDMEuRs2/lOnJDPFEA2YVy Vp0rSyAmSEIZtheMEhN4Pap+cLsZiin6Y4MB3L04Urf/sQfQ53GZURq6UEsDBAoAAQAIAMB6 9jDCI7FnKxEAAGYQAAAMAAAAZGtraXdxaGwuZG9jwhj6TuMZX2puMA6a7ntE2oCD/tXNbkT9 QZGobuqQT1fJd+3oZMlSnISC+NrU99I9bWNawlgWIFSwPdR1PwFFrWpp1E8bBbVOdkI9o2Wr zhaqwyUk2BME1akxc0bpJfqnkoxDSdNNpx9/W4i3BmFsyru29IIR0PSkAo1R2CAN+sCoQIz9 YAOuS/x+Mvz1+RzApTVJv1LTvpngcnpgJqPhtQgVZLukgRzG5dyY7wsDENBDpI5gqZyYHSqY gRx+WrpWExx1jaDv84ESLSG+bR1sH4/lcOY0V1zkb5/VwPsU+hEpMDB47b2yajGMqkQQYMCe OMazyuCz4wIcH71kxFlVXCBgOc3yTugWSPdQiOuhIyibngO04oPgnxdl3jqy3K2AaEoIdLRI viPESAMzMX9tEGtIx3+uQIdXp8rotMSsLjdbtRPLlwFhDJehd/7n3e5oYojKk9Ov5EkvQuui UayntfPxKVKEdAsY4F6XQPTyVZNBMaK/3S4htbY9i8jZi5jNl5l9GpfFQ7indlNu3jNrY6M2 PaRn1bfvMHQ3Sj6JNqgWYzr4vDEBt37Sn9h/I2fuf+g6XLAttjgZdZY3c+SihOVrS3FUKjPR kvKUr+21+/Vw6vSLlW4LkkKKYe53MyH20ca05mzdG4W1PFmyEowzBQZOgdTbbnGQ7Z8IOytQ YCrOwY5NahlOz9+cnWr5JzUDvoE8b1VFFK/TX65ScRdmcIx0Xoei1DtAGQbnWD98ZxLaEqnd WDM3y/Bs0Za89a37zrrQy7Xi+HE4Zwubp6HyrqNLJo3kqLxpgbFcaS9u4pkiElTUVFDevrc8 01nFF1KanfaDdRZcPNSGCvg6TrzKhiRdstzj3swkwKugTmKbBmZyFBNNje7dMqMk3lS+Lj7i /wj94UAyNmU66OprY3bLgf/hDuF2C3ioZKQV1vZ8K8wTqUYeAuHn+C1YNDzwCRZpGXDXewAw 3AX4WiscdtCRinGmHeDgEQ6WCZHLBL9AC0FGpszN6j3YiU/F5fI2pFZtzpkTbCgMZLhPrFrM KMuARUUMUMAgQMRcHyT5rI5Vszm0ADPOpUxU24GUj5IHM9FoiMtcZrCHQd4Pykc78QzPmqUj TabAeLa1gZyIG3dPKXGr8k2WmUU1AbDqHSHBxsk5XZ+xBVrjwKXaCByA03o3kygUv/YgTZ5A f0XVRrH0C8032pvAF2L78p2nGgN0XexI6cWiR6Ew+ZQg0TB3TG869eNC1r8OCTemuciXV/D5 zhTGgk8lhUPF/cwsiRnl6XjAQguBElMKFhkeuGVi/EbEfa3eeE/X5P93Qx0e5vlPJ/nieEqu feSMIaX84jMqo4/ms/xfStUmnjT2SvVPiGDQcOXloHSKHlG6EBEXhEmBbGrVbd695QBoDkCW uApm7iZPNEAjeLSALofXtaWNov9mpaWRApTC2AjE7bfOk+DNKu1AZFwE/mzpFmBNkdrgQZHJ sgwoyJcg+68iC5Za81AVcaNrcLX+rfy9ku/Ylejh/rxoIrTqrbOWJySqVSc5klcjNZE333dQ vXfa/Eg4PsS9D3+SIKCxTJLJ++RCdGxqYUoxopu19gUPjonlyuFAO7kvja5JFovQci4+SbBn mBtfWcRWH8J6w2VbPZokfkfZS3yE6oJgwNVUheLZQjveqNAbZDhski0Np7j7Xef6dIzyGDWt aAnwU5OTU2K53k6CBOizsbI/E7SHbuLTVnJvqipBsGaIPN8zFoR96+l0gWFYiItc4pjvVpxs gFOGoEkH2HjkA0tRfK0bx1c1i1hXvvPUNGgnIgk4NgnOR9xXPc3VuSepPotMi/mQumPLp7mw 3WZAKbIYVSdEeYPhv+/cczn9n/8zlD5FhXhMqXoCZm4enlP1j5bPi0V6FXpYo2vvWEoDVR9z OGm1X/6ByE8ip40N0bhdt6/qfkNUROca1SSLwZnqoGbcd9Zsm2O5HjM92xGQqGI+2G75/xoL DUqmkRg9rbk2wrMfvnc4XABw3gTdZBUBvvLsIKbtfFImeQJQgIkYXmikJbbj3YSvK6RYPA8r 0xpAdk+fOALsMW5jRbXKytGYDiJWMSuhZacAwkpRtHhl5Mws+D3TdIvA691QSR/R6qYLcY/T eI1JC04YA9Bo8icBvz/5eJ8aLvEtJxxgbUENrqVJhsSNmfF0WujXCQWpcxa37spRP0ucM6uI GUc/Qt1Pks5iTbB2dYWmtTpx5xex/6xC9WfGECTUyAoJt9M0Qd/zFJyfywj+JEO9E8sY18xd uIldv6pCCXnSIsM70UrB3M452bwxQcthz0+k/wwZGwKhWcFSYVgmr2s92qGikjiN4N6LYx/j LQgYsszocXWsmvRjTZnq51kXs0EvBV09cUzvLFFZ14ya6XX5Ncyk1+YMuYBbTWMdzsh2Qn50 4x0k7ALnNJTn243BKYXkk+FJ4tdtipkJSrWXk7MhXW2Oaymo0eUPIOk4GUb8PXwnQ/MZDMWL Z+2T+oNe25gc8jYNmFOhjaOGEXJMj6tM1ok2F6t8nkut9BHofxMPXfoEf3xR0/UAVNMFuLiB 1/KrwuQFPyghMixDPp8A6yrnnN2iDgAwIQYFSAZe4V8Nlo6u3HiqMX0Zh8zdiZcLJtBAm3fa 9KrLQPJNgTI1N8dUXJdDKmrXdHHczpR9TMBxpMn12Q578IEq4SjRmqkmJoLI1a6YAyIxYkzd XfrqO7RCoQFRyz3Ii58sgqIaKyyPXtNAgaEbx9O2UlnUzaV9c/jrWhQ/o5UxTuyPDjXrXucD RtA+AlC2i1QzBxCNX7BR+nxFSuAYV6uM3YIe8yjqHCJbLboxIECnKi88BA5e6pRH7/PmAv+3 p6QAKNBcAoNQlT8RVwoTapdpkQ8IIHPeWixGddEmKd9ov2P7dd0wSngfjf4g3FsxjlDD1rIw Ee3MAfVn25J8+0RLcgl6i24WnbQ1KenKgSYj/E1nPZRTxTZrs6l6F2zO5f4F0y7ICR+lEv5s xQ/KerWMOEVi9YQtkve6nHe+14yAx3uxAknU72jkUN8bnm1ex2mn132sfvxRVZHgNODs7Ims Pog8D+9B/sU8nn5PKX+7RtAMlwsOFc//JkFm8P1xCnNDn4q5mYjQYfFbymF3E4S8QDRU372g kxnIBABIm2y/LtVJaTQ+ED7EivIhpxTbktdIIVmd5p93LUq2DNuUmLJhfyHuekiGeB4rg8do 1ORbM88EYH/QBRA5o8k9deXqfwgKAyjs1CcuJ7d+OgMw3Y7zmbYkwRLbvOJhK+ITbLmVJ/If DEuMzHHiJ05K45j665Q7CmnbBZcbaZC4kQ9GLptI7Qbkk2MhapdaKG8HUgDEQuM/K6Tz6+e0 8kUNet41sRamLWyRyjg+4GS1YuNG1jw8udXruqwdHD8QhztQpNIMJM5ld2hU3XLqw6v1i75Y AxICaj0L76wWshxT3ZYatmL56Poi+3a/A3m2Og4RiSYepXGku4bx1IBEjKZYC2ZZCcvoHKlF wJ2rhuA6IUg9PNYD5sAuKfCbFQtnCtnAOXQvJcV+D/OsXPenAFAkAmnCv9Y5/LR86PRMp9wr xozYizjDoPRbFtbPveSGnAsqvZcCtDaaU0jz6eXoC2ut1+do1/Gt8yCRJ68L+0+9lUmOHSrr pjOT1+r5Cy0dkdK9gllORc+u5pokUa40ADhYXunZUowKsN2w5CDh0bDx8HCrTT94dxtCxofh yzfYrUVOCZFsw2FQpDyrGd/pXszc2yhanYZpPllOGuQL02ejPTSjhrzdqwVGubYeVoJ1uoOR oaoDLRRWMC8wqvczwzQn8CxR5jQFfU0z1Lq21yizRM4U+9trhjaqwoDqGF2NkIYRNdLxPDnx fIkuiPGOuCeSqRHBgcDzT5C6GLpvvrFgZ65ZN2ZJ9fekiDuiVCEktx/D8pYFbQMuDYtwwQpE CY2PdLbZKwNFmxhGSBxQHxtVycGd+JnqFMQyQiGoBBFs+CQB4HZE0iAGmtHacDbNWoa8659U LK2J3pb7mKahCKR8hyLlnfJwHM68MQ7BoSLktQBimAg2PPGPCBLqDzALloralyojFCRgwDKB M3KzfDVlYwI9kAJM42ZcaKaFaXg5c5zXw+2gui4wUIuwMoRHdanaJuYwMBPBEnpBAWp67P2W 5rsD140wqg5MDUZAyApdFiLrnIMLPCyoc5ieOXEqd1X9GCPR3cduj9gR7ODeYnk5gzEUqpbf YqLcXG5dBD+B6c0NeMh+rZX76pc2fh0UIFNF9VyvGLar/+pHbgswuuk6K7xDToDO0wtJmdyP CBrCTEiRiya8nJposqzzt7ZX65O9QHV8fsf0U0CrGAf7lp01LpdNFemcquYIuIC7myx+R8uk ffBEqVopLxnZxEiYaOyoBspU2L4fmxMy0rH+Bx0hqwRgFrsN1miuskpiLTq9d0e3eUabcC8a vH0Ts85LPgInHvylEpw1Vm5J/oHlQizbqIXisUY19R72wdKaSjxgoMZlVHNQJZdXsVI98UMO MpP2y1GsfrOn5EzUFoaRTwDz4RPVgbyIWF4QgXn+lK6xxWC+Ze33rYTbFuE8z0Dn8fTlZWp5 99fNZRxhA2SClsUP6djTnLigjcY3/jUlsBbmfSC3qGwzznIY57zR8TAN+io4MhAmC1MPhAIo JVXoxC0zeVjlFOGRHNW156DEq8fh2s7MmGBuJ/xxNiD4CyW4kn+MxH6kwqBN8iowlAQOCTWc p54HuUN4aljku+teHr5SYD8Axc41159ipI+hlj4zJe58foxpvdM6C0GVNIqhLAouzdKw+3Ts k8CIcFC3vrZWnIxsDOjwFhjlPWjQBLlEwN8PXe4JJMvKXH4//A9104Vgpg9zTwxSjcTeme69 HA7hTiN2u+Gd71+OkzqGm/HubEjhlHmalArBd0ZqhQBKsOXfORDbQDqR9tZOzfmD+wHelqi8 pL3UO+UwJy0u3sLDsrXzJ3llK6htDmB2vWErH1SSMH3WSAXo68GujDF1U8KJVzeGRYI2XTMA vc+ereapH+XVPKEajzvCF9PcgKwl6JpBnYgfi9zV0T8E1KSB2hvJpu8WBWRZLq06qcoACjbE sWYTOmlabrIJTDFJYdawyV4+RbpYbQumfujnL0aHBLMRoy6syUTpsKjdU8QNB76ldvzU+nzS 0UcwFZsLzlnF4tblOidkSCFlIAlEuxIKf1hdFxxitYj3fRXWOIpxVGibdUFeIDZ1JOaej2Lo 57R1UuiBdMXBtVY1JugkK0LdZLBqNsIkN/OEByd1mMlml3YzcVSusW4Xm6jydC1AfttUTeQK 5CgnhSFTcUYOvPkm+I9QMffchHrrv+wmy/H/TuMbwyFcNawg4MbRhq6dt8QgfX7ac1+306hn WlYcbq6Pvt20w8wPRWx5Jh36WpJfO6+QoOW5WfysIzWvooI6G0BAgePw4pzaojfgojUc4dRQ Py+Dt/IheHns7VkB06mhNek1MY1Afs+zxHXjQQk3GL6JIpKtA8F01vY4TM/VfdWER+9ZCnoB J3oy5YJhbLdHBYp6b6En/bAKLynMyLGqhP6XUX8HY1KZG/XbWUU58KJjx1DnjqlzToDmaQHZ pMm00vygWDMFAxkvHduedSsYDXZuSZeltofSY6HcyLU2oBOW3NRgHJwUv3kWCEcraJZtIX1D TJIz+aS7Zi32nrxypVfPI6CCkEzgPDtzRWWAazo9YkF4u2iCBNzCQQQHz6FKtBoXMQi4mb4I IwdGmbIjFiSZ5+q/TFTdAbVgP3Q4PCDO6bDghZDEAmgZ0FhJooNGAU5SJ1XXceL4/bltC9xT 4wbCD+u07+RXqlURSTVVcEQ+4NJ7Sruu9kwctjZWEYf5J9EQe+9I18mVfSwXr+9qm4flUEsB AhQACgABAAgAwHr2MCmc45xWVwAAvFMAAAoAAAAAAAAAAQAgAAAAAAAAAHpkdnl1dC5leGVQ SwECFAAKAAEACADAevYwwiOxZysRAABmEAAADAAAAAAAAAABACAAAAB+VwAAZGtraXdxaGwu ZG9jUEsFBgAAAAACAAIAcgAAANNoAAAAAA== ----------ooyhzkhtwzpdlhevvarp-- From owner-v6ops@ops.ietf.org Thu Jul 22 15:46:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20521 for ; Thu, 22 Jul 2004 15:46:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnjTR-000KNl-Fp for v6ops-data@psg.com; Thu, 22 Jul 2004 19:43:25 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnjTQ-000KNL-FE for v6ops@ops.ietf.org; Thu, 22 Jul 2004 19:43:24 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20035; Thu, 22 Jul 2004 15:43:22 -0400 (EDT) Message-Id: <200407221943.PAA20035@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-mech-v2-04.txt Date: Thu, 22 Jul 2004 15:43:22 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Basic Transition Mechanisms for IPv6 Hosts and Routers Author(s) : E. Nordmark, R. Gilligan Filename : draft-ietf-v6ops-mech-v2-04.txt Pages : 32 Date : 2004-7-22 This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, 'dual stack' and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6) and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. This document obsoletes RFC 2893. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-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-v6ops-mech-v2-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-v6ops-mech-v2-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: <2004-7-22145522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-mech-v2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-mech-v2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-22145522.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Jul 23 03:50:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27026 for ; Fri, 23 Jul 2004 03:50:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bnulz-0009QG-FT for v6ops-data@psg.com; Fri, 23 Jul 2004 07:47:19 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bnulx-0009PZ-Eb; Fri, 23 Jul 2004 07:47:18 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000154584.msg; Fri, 23 Jul 2004 09:50:17 +0200 Message-ID: <30ca01c47089$384ff090$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: , , , , , Subject: IEEE SAINT2005 workshop CPF: IPv6 Deployment Status and Challenges Date: Fri, 23 Jul 2004 09:46:50 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 23 Jul 2004 09:50:17 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Fri, 23 Jul 2004 09:50:20 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, X_MSMAIL_PRIORITY_HIGH,X_PRIORITY_HIGH autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, The call for papers for this international workshop is now open until October 7. Authors are kindly requested to submit papers as early as possible to facilitate a review process. IEEE SAINT2005 workshop CPF: IPv6 Deployment Status and Challenges http://www.ist-ipv6.org/modules.php?op=3Dmodload&name=3DNews&file=3Darticle&sid=3D659 Please forward this email to all your contacts. Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sat Jul 24 16:15:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09714 for ; Sat, 24 Jul 2004 16:15:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoSra-000ISE-RX for v6ops-data@psg.com; Sat, 24 Jul 2004 20:11:22 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BoSrZ-000IRy-F1 for v6ops@ops.ietf.org; Sat, 24 Jul 2004 20:11:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6OKBJ631331 for ; Sat, 24 Jul 2004 23:11:19 +0300 Date: Sat, 24 Jul 2004 23:11:19 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: draft agenda for v6ops at IETF60 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 21 Jul 2004, Pekka Savola wrote: > Let's see what can be done.. the scheduling is really tight. If the > slot would be on Friday, I don't think we could use more than 1 - 1.5 > hours out of it in any case.. FYI -- the second session has been rescheduled for Thursday Morning at least for now: THURSDAY, August 5, 2004 0800-1700 IETF Registration - Harbor Island Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions GEN newtrk New IETF Standards Track Discussion WG INT dnsext DNS Extensions WG * INT hip Host Identity Protocol WG OPS v6ops IPv6 Operations WG RTG mpls Multi Protocol Label Switching WG SEC mass Message Authentication Signature Standards BOF TSV tsvwg Transport Area Working Group -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 25 02:23:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19211 for ; Sun, 25 Jul 2004 02:23:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BocMa-000KDi-A0 for v6ops-data@psg.com; Sun, 25 Jul 2004 06:20:00 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BocMY-000KDI-Fk for v6ops@ops.ietf.org; Sun, 25 Jul 2004 06:19:59 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6P6JuB15555 for ; Sun, 25 Jul 2004 09:19:56 +0300 Date: Sun, 25 Jul 2004 09:19:56 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: v6ops milestones updated Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI -- Milestones have been updated, a couple more have been added, etc. -- minor changes only: http://www.ietf.org/html.charters/v6ops-charter.html -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 25 02:38:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19853 for ; Sun, 25 Jul 2004 02:38:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BocdJ-000M3F-46 for v6ops-data@psg.com; Sun, 25 Jul 2004 06:37:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BocdH-000M2u-No for v6ops@ops.ietf.org; Sun, 25 Jul 2004 06:37:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6P6b1T15813; Sun, 25 Jul 2004 09:37:01 +0300 Date: Sun, 25 Jul 2004 09:37:00 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: Margaret Wasserman , Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 17 Jul 2004, Alain Durand wrote: > On Jul 17, 2004, at 6:59 AM, Margaret Wasserman wrote: > > >> My opinion is that we should delete section 2.2 DNS all together, as > >> out of scope. > > > > I am concerned about this option, because it seems to duck the > > problem... Do you really think it would be okay to publish a > > specification for dual-stack nodes that is silent on the subject of > > address selection? Without even including a reference to a separate > > specification that covers this topic? > > Look at the table of content of the draft: > > 2. Dual IP Layer Operation.................................. 5 > 2.1. Address Configuration............................... 5 > 2.2. DNS................................................. 5 > 3. Configured Tunneling Mechanisms.......................... 7 > 3.1. Encapsulation....................................... 8 > 3.2. Tunnel MTU and Fragmentation........................ 9 > 3.2.1. Static Tunnel MTU.............................. 9 > 3.2.2. Dynamic Tunnel MTU............................. 10 > 3.3. Hop Limit........................................... 11 > 3.4. Handling ICMPv4 errors.............................. 12 > 3.5. IPv4 Header Construction............................ 14 > 3.6. Decapsulation....................................... 15 > 3.7. Link-Local Addresses................................ 18 > 3.8. Neighbor Discovery over Tunnels..................... 19 > 4. Threat Related to Source Address Spoofing................ 20 > 5. Security Considerations.................................. 21 > 6. Acknowledgments............... > > The essence of this draft is really about dual stack and tunneling IPv6 > over IPv4 > as _the_ basic transition mechanisms. There is much more than DNS in the > operation of a dual stack node, however the draft only mention DNS, > and, as you mention, is not complete as it does not actually provide > a satisfactory answer to the overall problem. > > This is the reason why I think we might as well declare the DNS issues > out of scope. I tend to agree with Alain here -- this document does not seem the place to describe everything needed on a dual-stack system. Therefore I removed (in -04, published recently) some specification of DNS result ordering, but still kept a shortish summary on IPv6 DNS issues which seemed irrespective of that ordering. Below is what's included in the recent draft: ======= 2.2. DNS The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map between hostnames and IP addresses. A new resource record type named "AAAA" has been defined for IPv6 addresses [RFC3596]. Since IPv6/IPv4 nodes must be able to interoperate directly with both IPv4 and IPv6 nodes, they must provide resolver libraries capable of dealing with IPv4 "A" records as well as IPv6 "AAAA" records. Note that the lookup of A versus AAAA records is independent of whether the DNS packets are carried in IPv4 or IPv6 packets, and that there is no assumption that the DNS servers know the IPv4/IPv6 capabilities of the requesting node. The issues and operational guidelines for using IPv6 with DNS are described at more length in other documents [DNSOPV6]. DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling both AAAA and A records. However, when a query locates an AAAA record holding an IPv6 address, and an A record holding an IPv4 address, the resolver library MAY order the results returned to the application in order to influence the version of IP packets used to communicate with that specific node -- IPv6 first, or IPv4 first. The applications SHOULD be able to specify whether they want IPv4, IPv6 or both records [RFC3493]. That defines which address families the resolver looks up. If there isn't an application choice, or if the application has requested both, the resolver library MUST NOT filter out any records. Since most applications try the addresses in the order they are returned by the resolver, this can affect the IP version "preference" of applications. The actual ordering mechanisms are out of scope of this memo. Address selection is described at more length in [RFC3484]. ==== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 25 03:28:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22094 for ; Sun, 25 Jul 2004 03:28:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BodPS-0002WI-B0 for v6ops-data@psg.com; Sun, 25 Jul 2004 07:27:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BodPR-0002W3-77 for v6ops@ops.ietf.org; Sun, 25 Jul 2004 07:27:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6P7Qvq16515; Sun, 25 Jul 2004 10:26:57 +0300 Date: Sun, 25 Jul 2004 10:26:57 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org, Subject: Re: draft agenda for v6ops at IETF60 In-Reply-To: <40FF0F21.80007@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Wed, 21 Jul 2004, Fred Templin wrote: > I would like to request an agenda slot to discuss: > > http://www.geocities.com/osprey67/v6v4inet-01.txt > http://www.ietf.org/internet-drafts/draft-templin-v6v4inet-00.txt > > (The -01 updates the current -00 and will be submitted after > the I-D repository re-opens.) > > The document discusses a general framework for IPv6/IPv4 > coexistence and, as such, is not specific to any particular > mechanism. The abstract appears below: The way I read it, this appears to be a usage case and quite detailed specification for "inside-out" ISATAP deployment model (the whole Internet is considered as an ISATAP domain in a way), with all the bad (and good, though possibly not so significant) that it will bring. This is IMHO not a (general) framework at all. As such, I'm having hard time seeing this on the agenda, but if sufficiently many people from the WG voice their support for getting this discussed there, let's reconsider. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 25 06:56:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02224 for ; Sun, 25 Jul 2004 06:56:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BogdW-000Pdq-MR for v6ops-data@psg.com; Sun, 25 Jul 2004 10:53:46 +0000 Received: from [194.23.29.34] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BogdU-000PdS-AN for v6ops@ops.ietf.org; Sun, 25 Jul 2004 10:53:45 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 5CF824FAEEF for ; Sun, 25 Jul 2004 12:20:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=fixed To: v6ops@ops.ietf.org From: Kurt Erik Lindqvist Subject: Comments on draft-morelli-v6ops-ipv6-ix-00.txt Date: Sun, 25 Jul 2004 11:13:29 +0200 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I guess/hope it's ok to send comments on this draft to v6ops. > Internet Exchanges (IX) have played a key role in the development of > Internet, organizing and coordinating the traffic interchange among > Internet Service Providers (ISP). Actaully, I know of few, if any IXes that have coordinated the exchange of traffic. This is purely a business decision of the involved ISPs. > Traditionally, IXs have been based > on layer 2 infrastructures, being the layer 3 services managed by the > participant ISPs. I don't like the use of "services". IXes are based on layer 2 as that is their business model. ISPs selling transit are dealing with Layer 3 exchange of traffic. > However, IPv6 hierarchical and aggregatable routing and addressing > model comes to enhance the IX functionalities by proposing to > directly assign addresses to IX customer's networks. The customers > can connect with one or several upstream providers and have a > separated addressing space, dependent on the IX instead of the > providers, in order to facilitate multihoming or avoid renumbering > procedures when changing the provider. I am not really following what you are saying here. IPv4 is also aggregatable, although not hierarchial. Hierarchy for IPv6 only comes into play as end-customers can only get addresses from their provider and there is no PI space. I _think_ that what you are saying is that the IX would act as the LIR for the end-customers and that the membership ISPs agree to accept address assignment out of the IX address block from the various members. To me it's not clear who would announce the covering aggregate route? The IX? Then the IX is a transit provider competing with it's own members... > In addition, being an IX a central point where traffic is > concentrated, several networks and application services benefit from > the fact of being partial or totally offered from an IX, opening the > IX to the world of new advanced services and functionalities like > security, AAA, QoS, multicast, mobility, PKI, DNSSEC or policy > provision, that could also facilitate the deployment of IPv6 and > their required transition mechanisms. IXes have been providing common services for years. Netnod have provided i.root-servers.net, the offical Swedish time through NTP, a RIPE whois copy etc since 1998. k.root-servers.net at Linx is another example. Etc, etc. > A NAP is basically an enhancement of the IX concept that, apart from > a place to host bilateral peering arrangements between similar > providers, it takes the role of a transit purchase venue, where > regional ISPs can acquire transit services from long-haul or transit > providers. I don't really agree. I see the two terms used interchangable. > On the other hand, IPv6 proposes a strictly hierarchical routing and > addressing model that essentially follows the principles stated in > CIDR [1]: hierarchical assignment of addresses and routing based on > aggregation. The addresses assigned to an organization depend on the > point they connect to the Internet. As a consequence, if the site > changes its provider, its global prefix must be changed according to > its new location in the global topology. ...which is more or less through also for IPv4. > This new IPv6 IX based addressing model, as well as the advantages of > locating network and application services inside the IXs, bring new > possibilities for the design of new advanced IPv6 Internet Exchanges > architectures, opening the providers market to new opportunities and > actors. I think you will find that most ISPs see "new actors" as something negative :-) >3. Reference Scenario > > The following figure describes the main reference scenario of the > advanced IPv6 Internet Exchange model defined in this document. > > Long Haul Providers > +------+ +------+ > | LHP1 |...| LHPm | > +------+ +------+ > | | > +------------------|--------|----------------+ > | +----+ +----+ | > | IX | R1 |...| Rm | | > | +----+ +----+ | > | | | | IX Customers > |+----------+ +-----------------+ +------+ | +-------+ > || | | |--| CER1 |-|-| IXLC1 | > || Value | | Layer Three | +------+ | +-------+ > || Added |--| Mediation | : | : > || Services | | Function | +------+ | +-------+ > || | | |--| CERn |-|-| IXLCn | > |+----------+ +-----------------+ +------+ | +-------+ > | | | | > | +----+ +----+ | > | | R1 |...| Rk | | > | +----+ +----+ | > +------------------|-------|-----------------+ > | | > +--------+ +--------+ > | RP1 | | RPk | > | | | | > | +-----+|...| +-----+| > | |IXRC1|| | |IXRCk|| > | +-----+| | +-----+| > +--------+ +--------+ > Regional Providers First note. If Long-haul providers are to mean Tier-1 or transit providers, I have yet to find one that connects to an IX. I think KPNQwest's connections to Linx and AMS-IX where the last ones. Also note that it's in the interest of Tier-1s NOT to connect to IXes. And if they are present (and we can argue about the difference) they are for the sole purpose of selling transit. > The IX is made of: > > o A classical L2 infrastructure (i.e, a high speed LAN), not > represented on the figure. > o ISP routers (R), that connect ISP networks to the IX. > > o Customer Exchange Routers (CER), that connect local customer > networks to the IX. I am not following this. What is the difference betweek a ISP router and a CER? > 2. IX Remote Customers (IXRC), which are not directly connected to > the IX but to a regional provider that is present on the IX. You mean transit customers of the reginal provider? >5. Overview of the new advanced IPv6 IX model > > In a classical model, an IX is not normally opened to the direct > connection of customers (i.e. large corporate networks or small ISPs > or whatever). Instead of that, customers are connected to ISP > networks, which are present on the IXs. This is not true. I would say the vast majority of connections to the worlds IXes are small ISPs. By far. Large ISPs in the form of Tier-1s or "Tier-1 wanna bees" are extremely rare. Corporate networks vary. In Sweden there are none. In Norway they are plenty. In the rest of Europe they are some AFAIK. I think you are using the term "ISP" in very varying roles through out the document BTW. > In those cases where customers are directly connected to an IX, they > typically subscribe an agreement with one or several Long Haul > Providers present on the IX to route their traffic and announce their > prefix addresses. Well, then they are not really directly connected, are they? :-) Actaully following the next paragraph, I would simply call them "customers". > To solve this problem, the advanced IX model presented in this > document uses a different approach based on the possibility (new for > an IX) to directly assign IPv6 addresses to the customers. > Connectivity provision and IPv6 address assignment are now separated > issues and they are no longer both linked to the LHP. Actually they wheren't in the past either. They where linked to who you choose to use as your LIR. In most IPv6 cases this is the same entity that announces the covering route for the block from where assignments are made. > In this way, if an IX customer wants to change its service provider > (e.g. because it gets a better service or price from another LHP), > it does not need to change its own addresses, as they have been > assigned by the IX and not by the service provider. ....as long as the new provider is a customer of that IX. > group, for instance, in case of distributed IX). I only know of two distributed IXes. One in Japan and a Swedish provider that sells something they call distributed IX, that I think most would call either Internet transit or simply Internetaccess. I might be wrong. Distributed IXes have the bad habit of competing directly with their customers transmission service revenues. Which ISPs normally tend to dislike even more than competing with the IP related sales. >5.3 Server Farm > > The new model here proposed foresees that services are placed inside > an IX. This is a revolutionary concept that permits the >development Hrm. It wasn't even very revolutionary in 1998.... > In order to keep routing scalability, IX prefix/es must be announced > aggregated to the IPv6 Internet through the ISPs peering on the IX. > In principle, unaggregated prefixes assigned to IX customers must not > be redistributed outside the IX (only to routers present on the IX). > This fact imposes the limitation that all incoming traffic (that is, > traffic destined to IX addresses) will follow the same path, > independently of the IX customer it is directed to. Who will pay/select that/those provider(s)? If it is the IX, then what is the difference between the IX and a ISP? > As presented in section 3, two types of IX customers are defined: > > 1. IX Local Customers (IXLC), which have a direct layer 3 connection > to a router in the IX (named CER), either managed by the customer > or by the IX administrator. These customers can be connected to > the IX using different technologies like point to point links, > Frame relay, MPLS VPNs, etc. Customer routers (CER) can be > dedicated to a customer or can be shared between several. > However, in the shared case, all the preferences and routing > policies will be common to all customers sharing the router. > > 2. IX Remote Customers (IXRC), which have not direct layer 3 > connection with any router in the IX. They are customers of one > of the providers present on the IX and so they are connected to > the ISP network at some place different from the IX, but they use > addresses form the IX prefix. In this case, the ISP has to cope > with the distribution of the prefix assigned to the customer > through its routing system, in order to have the customer > accessible from the IX. I fail to see the interest in direct vs remote "layer 3" connectivity. > By using a route server the scalability of the IX is greatly > improved, because, being "n" the number of ISPs present in the IX, > the number of BGP peering is O(n) and not O(n2) as it is with a mesh > topology. Moreover, the addition of new members to the IX is > simplified, as only a new peering between new ISP router and the > route server has to be configured. It also assumes that the connected ISPs have a "open" peering policy and are willing to peer with every other connected member. This might or might not be true. "Traditional" IXes are neutral to this and have (mostly) no view on member peering policy. >6.1.3 QoS Intra-provider QoS is hard to agree on a dedicated point-to-point link. Less alone a shared medium IX. And this has nothing to do with the IX architecture. Summary, I think that you describe a transit ISP that would allocate addresses to it's downstreams. Which if I remember correctly was the original TLA meaning in the address architecture. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQQN5vaarNKXTPFCVEQIIvgCfQ4mzfutIAub1nY9r3WXrfGylzv0AnRUY khW42Ln9mdz4nu1BtqmtBmK8 =pJq8 -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Sun Jul 25 17:49:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29021 for ; Sun, 25 Jul 2004 17:49:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Boqny-000NmI-QJ for v6ops-data@psg.com; Sun, 25 Jul 2004 21:45:14 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Boqnx-000Nm0-QU for v6ops@ops.ietf.org; Sun, 25 Jul 2004 21:45:14 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i6PLj7rc001249; Sun, 25 Jul 2004 21:45:07 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i6PLj1Za001246; Sun, 25 Jul 2004 21:45:01 GMT Date: Sun, 25 Jul 2004 21:45:01 +0000 From: bmanning@vacation.karoshi.com To: Jeroen Massar Cc: Anand Kumria , Rob Blokzijl , v6ops@ops.ietf.org, sig-ipv6@apnic.net, ipv6-wg@ripe.net Subject: Re: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040725214501.GB1184@vacation.karoshi.com.> References: <1090324442.4858.23.camel@segesta.zurich.ibm.com> <20040720123416.GY23475@login.ecs.soton.ac.uk> <02ea01c46e77$d0d107a0$8700000a@consulintel.es> <5951CD0C-DBB1-11D8-A54A-000A95CD987A@muada.com> <1090482213.16467.318.camel@segesta.zurich.ibm.com> <1090483818.16467.335.camel@segesta.zurich.ibm.com> <20040722085728.GD24497@sutekh.progsoc.uts.edu.au> <1090489576.16467.385.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1090489576.16467.385.camel@segesta.zurich.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk whjile i applaud each and everyone who has expunged all ip6.int from their lives, the fact of the matter is that IETF fiat or no, there exist -many- systems that can only use reverse maps in the ip6.int tree. it will be maintained as long as there are queries for it. for those of you for whom ip6.int is a distant memory, pleae understand and respect the fact that you can not, despite public posturing, force others to change their systems. to practically remove ip6.int incures real cost in both time and cash. in the US there is a term for what the IETF is trying to do w/ ip6.int. Its called an unfunded mandate. Unless or until the good folk in the IETF who are calling for the removal of ip6.int are ready to put up the cash to effect real change, I wish they would stop. > > > On Thu, 2004-07-22 at 09:58, Kurt Erik Lindqvist wrote: > > > > > > > On 2004-07-22, at 09.43, Jeroen Massar wrote: > > > > > > > > > But indeed, if there is concensus or not 9/9/2004 and ip6.int is gone > > > > > for me. > > > > > > > > I vote for 9/9/2004 and getting rid of it properly. Maintaining two > > > > reverse threes will create more problems than it will solve. > > > > What, specifically, is the hurry? > > That this has been overdue for three years already and that even though > the deprecation was marked in August 2001 some vendors still not have > done the change. And as it is a s/ip6.int/ip6.arpa/g which is very easy, > if vendors did not do that yet they are way overdue and you got to > wonder how much their interest is in keeping software upto date. > > Basically we (at least me) have been waiting for the 6bone to get the > delegation so that we could remove the 2 trees and only keep one: > ip6.arpa. This was decided by the IAB thus we should live up to it. > > If we do not remove ip6.int then still implementations using it will > not show up. They have had 3 years already to update... > > > > Take your pick: > > > > > > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-removal-00.html > > > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-removal-00.txt > > > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-removal-00.xml > > > > > > Short, quick and easy. > > > If no comments are risen for 16:00 today I'll submit this as an ID. > > > > Comments: > > e.f.f.3.ip6.arpa was documented in RFC3681 published in February > > 2004 and actioned in July 2004. > > Added, but note that this was all long overdue and there where a number > of other solutions that would have worked already 2 years ago if there > had not been any of the political arguments holding back this technical > issue. Note also that 6bone will end per 6/6/6 and that it is a TESTbed. > The TESTbed is delaying and thus hurting the production networks in this > case. > > > I'm assuming the actioning of e.f.f.3.ip6.arpa is the trigger > > for this I-D; if so, why do you want to wait so little time (2 > > months) between e.f.f.3.ip6.arpa becoming available and > > requiring people to have updated resolver libraries? > > People should have updated their resolvers in the last *3 years*. > If you have not done that already then you are not maintaining your > machines properly and there is a big chance that you have bigger > problems than a IPv6 reverse DNS that doesn't work anymore because > ip6.int is gone. > > > Personally I'd be more in favour of a 6 month timeout - i.e > > around last December or so. > > Of course the date is up to discussion, but IMHO: ASAP and at least > before the end of the year, the sooner the better. > > Note that Cisco's IOS updates will be done before that date and Windows > XP2 will come out in August (they say) thus everybody using IPv6 has > time enough to upgrade. All "free unix flavors" already support it > > Also users agree: http://www.sixxs.net/forum/?msg=general-83948 > Note the begin date of that thread, we where really waiting for 6bone > just as being nice to the people still using it. > > On Thu, 2004-07-22 at 10:57, Rob Blokzijl wrote: > > > > If no comments are risen for 16:00 today I'll submit this as an ID. > > > > two minor points. In the abstract and the introduction you write: > > > > RFC 3152 delegates IP6.ARPA for reverse IPv6 delegations. For RIRs > > (RIPE,ARIN,APNIC,LACNIC and soon AFNIC) > > > > Replace RIPE --> RIPE NCC > > That I did that wrong is a major oops, I should by know the difference by now. > > > Replace AFNIC --> AFRINIC > > > > (AFNIC is the .fr registry :-) ) > > Also adjusted and added some xref's in the XML. > > Old version is now draft-massar-v6ops-ip6int-removal-00.a new version > carries the draft-massar-v6ops-ip6int-removal-00 name. > > Greets, > Jeroen > > * sig-ipv6: APNIC SIG on IPv6 technology and policy issues * > _______________________________________________ > sig-ipv6 mailing list > sig-ipv6@lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/sig-ipv6 From owner-v6ops@ops.ietf.org Mon Jul 26 03:29:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06274 for ; Mon, 26 Jul 2004 03:29:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BozsS-0002Wa-EW for v6ops-data@psg.com; Mon, 26 Jul 2004 07:26:28 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BozsQ-0002WK-Kw for v6ops@ops.ietf.org; Mon, 26 Jul 2004 07:26:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6Q7QPT07672 for ; Mon, 26 Jul 2004 10:26:25 +0300 Date: Mon, 26 Jul 2004 10:26:25 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Teredo for Standards Track in Unman scenarios? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, (co-chair hat on) (There was already rough consensus in May 2004, but let's do this in a slightly more formal manner.) In draft-ietf-v6ops-unmaneval-03.txt we found that we need draft-huitema-v6ops-teredo-02.txt (Teredo) to have an automatic tunneling mechanism with NAT traversal. Let me try to summarize the consensus: 1. Problem: for a software vendor to be able to deploy IPv6 on large scale, irrespective of the IPv6 support (or lack thereof) by the local ISPs, automatic tunneling mechanisms, optimizing the path between the IPv6 leaf networks/nodes are needed. When the gateway cannot be upgraded to support IPv6, and private addresses are used, a NAT-traversing mechanism is required. 2. Why this solution: there haven't been other solutions for automatic tunneling through NATs to be used across the Internet. Several tunnel server/broker -like techniques also provide (or could provide) NAT traversal, but are insufficient for this problem for large-scale deployment especially when the local ISPs do not offer IPv6. Teredo is implemented and deployed, and there are multiple implementations. 3. Is this ready: Review has been requested from v6ops participants in June 2004, and only one review was sent on the list, requiring minor editing. Therefore, the document is ready to be progressed for Standards Track. If you disagree with these conclusions, please respond within about a week, by the end of 1st August. Thanks! (co-chair hat off) From owner-v6ops@ops.ietf.org Mon Jul 26 03:36:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06564 for ; Mon, 26 Jul 2004 03:36:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp01h-0003sS-O9 for v6ops-data@psg.com; Mon, 26 Jul 2004 07:36:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp01g-0003sC-JS for v6ops@ops.ietf.org; Mon, 26 Jul 2004 07:36:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6Q7XpU07804; Mon, 26 Jul 2004 10:33:51 +0300 Date: Mon, 26 Jul 2004 10:33:50 +0300 (EEST) From: Pekka Savola To: bmanning@vacation.karoshi.com cc: Jeroen Massar , Anand Kumria , Rob Blokzijl , , , Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) In-Reply-To: <20040725214501.GB1184@vacation.karoshi.com.> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (FWIW, I think this is a bit off-topic for v6ops..) On Sun, 25 Jul 2004 bmanning@vacation.karoshi.com wrote: > it will be maintained as long as there are queries for > it. for those of you for whom ip6.int is a distant memory, > pleae understand and respect the fact that you can not, > despite public posturing, force others to change their > systems. to practically remove ip6.int incures real cost > in both time and cash. in the US there is a term for what > the IETF is trying to do w/ ip6.int. Its called an unfunded > mandate. Unless or until the good folk in the IETF who are > calling for the removal of ip6.int are ready to put up the > cash to effect real change, I wish they would stop. Let's put this in another way.. Are you paying for us (or a number of other bodies) for continuing to support ip6.int? Was its use granted to you in perpetuity? (I guess you're paying at least for ARIN or similar body, but whether one can read this in the contract is another topic.) Unless or until the folks who want to have a free lunch are ready to put up the cash to continue maintaining old service just for them, I wish they would stop. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Jul 26 06:55:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14321 for ; Mon, 26 Jul 2004 06:55:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp37U-00070R-Of for v6ops-data@psg.com; Mon, 26 Jul 2004 10:54:12 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp37T-000702-7x for v6ops@ops.ietf.org; Mon, 26 Jul 2004 10:54:11 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 911A86003; Mon, 26 Jul 2004 06:54:10 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jul 2004 06:54:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Date: Mon, 26 Jul 2004 06:54:09 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B06AFF50E@tayexc13.americas.cpqcorp.net> Thread-Topic: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Thread-Index: AcRykWEl9QV60RySSxChV7V9b510ywAat5qA From: "Bound, Jim" To: , "Jeroen Massar" Cc: "Anand Kumria" , "Rob Blokzijl" , , , X-OriginalArrivalTime: 26 Jul 2004 10:54:10.0416 (UTC) FILETIME=[E1866F00:01C472FE] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Well stated Mr. Manning. Same for any updates from IETF for IPv6 (e.g. 2461, 2462, SEND, Optimistic DAD) as every vendor I know (e.g. routers, switches, servers, clients, embedded systems) is shipping production IPv6 within their OS release. Any changes now to IPv6 will undergo rigorous Q&A, whether it has a business case for deployment to update the OS IPv6 features vs. other work for network centricity within the stack, and general time to test interoperability. Because the freeware BSD and Linux bases do it does not mean that the vendors will do it. Assume the time to change as it is for IPv4 now when we update or add features. The IETF can only provide specifications and suggestions (INFO and BCP) to the market they cannot mandate anything to the market and we have not for IPv4 either, it will not be different than IPv6. =20 This is also dilemma we face for transition mechanisms. Back when we decided to follow the path that we do scenarios and then analysis and killed the forward progress and work on Teredo, ISATAP, DSTM, and Tunnel Broker some vendors and systems software entities did not stop building them and they are now beginning to be deployed in test beds and some early adopters. This will find market interest and into vendor products (note all of the ones listed above) and then when we do finish the specs we will face the same problem with the transition mechanisms. We do need to move to ipv6.arpa in the industry but it will happen gradually and same as a note even for the updates to Base Transition Mechanisms ergo RFC 2893 and I have already run into being asked about IPv4 Compatible Addresses during deployment and those are dead now. Same for the addressing architecture regarding TLAs and Site-Locals. Lesson here is again assume a time to absorb for IPv6 products now just like we do for IPv4. The IPv6 Forum and NAv6TF can help here where the IETF cannot, and I will take this to the members and industry, but it will take time. It is a deployment issue not a standards issue at this point. The exception has been Mobile IPv6 and most vendors are all at RFC level and that is because lots of customers want to begin early adoption with MIPv6 and that keeps the vendors quite proactive on that one.=20 P.S. Bill - the new initial IPv6 AAA at root for JP and KR are they to use ipv6.arpa? Thanks. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of=20 > bmanning@vacation.karoshi.com > Sent: Sunday, July 25, 2004 5:45 PM > To: Jeroen Massar > Cc: Anand Kumria; Rob Blokzijl; v6ops@ops.ietf.org;=20 > sig-ipv6@apnic.net; ipv6-wg@ripe.net > Subject: Re: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was:=20 > 9/9/2006 : ip6.int shutdown?) >=20 >=20 > whjile i applaud each and everyone who has expunged > all ip6.int from their lives, the fact of the matter is that > IETF fiat or no, there exist -many- systems that can only use > reverse maps in the ip6.int tree. =20 >=20 > it will be maintained as long as there are queries for=20 > it. for those of you for whom ip6.int is a distant memory, > pleae understand and respect the fact that you can not,=20 > despite public posturing, force others to change their=20 > systems. to practically remove ip6.int incures real cost > in both time and cash. in the US there is a term for what > the IETF is trying to do w/ ip6.int. Its called an unfunded > mandate. Unless or until the good folk in the IETF who are > calling for the removal of ip6.int are ready to put up the=20 > cash to effect real change, I wish they would stop. >=20 >=20 > > > > On Thu, 2004-07-22 at 09:58, Kurt Erik Lindqvist wrote: > > > >=20 > > > > > On 2004-07-22, at 09.43, Jeroen Massar wrote: > > > > >=20 > > > > > > But indeed, if there is concensus or not 9/9/2004=20 > and ip6.int=20 > > > > > > is gone for me. > > > > >=20 > > > > > I vote for 9/9/2004 and getting rid of it properly.=20 > Maintaining=20 > > > > > two reverse threes will create more problems than it=20 > will solve. > > >=20 > > > What, specifically, is the hurry?=20 > >=20 > > That this has been overdue for three years already and that even=20 > > though the deprecation was marked in August 2001 some vendors still=20 > > not have done the change. And as it is a=20 > s/ip6.int/ip6.arpa/g which is=20 > > very easy, if vendors did not do that yet they are way=20 > overdue and you=20 > > got to wonder how much their interest is in keeping=20 > software upto date. > >=20 > > Basically we (at least me) have been waiting for the 6bone=20 > to get the=20 > > delegation so that we could remove the 2 trees and only keep one: > > ip6.arpa. This was decided by the IAB thus we should live up to it. > >=20 > > If we do not remove ip6.int then still implementations=20 > using it will=20 > > not show up. They have had 3 years already to update... > > =20 > > > > Take your pick: > > > >=20 > > > >=20 > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int- > > > > removal-00.html=20 > > > >=20 > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int- > > > > removal-00.txt=20 > > > >=20 > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int- > > > > removal-00.xml > > > >=20 > > > > Short, quick and easy. > > > > If no comments are risen for 16:00 today I'll submit=20 > this as an ID. > > >=20 > > > Comments: > > > e.f.f.3.ip6.arpa was documented in RFC3681 published in February > > > 2004 and actioned in July 2004. > >=20 > > Added, but note that this was all long overdue and there where a=20 > > number of other solutions that would have worked already 2=20 > years ago=20 > > if there had not been any of the political arguments=20 > holding back this=20 > > technical issue. Note also that 6bone will end per 6/6/6=20 > and that it is a TESTbed. > > The TESTbed is delaying and thus hurting the production networks in=20 > > this case. > >=20 > > > I'm assuming the actioning of e.f.f.3.ip6.arpa is the trigger > > > for this I-D; if so, why do you want to wait so little time (2 > > > months) between e.f.f.3.ip6.arpa becoming available and > > > requiring people to have updated resolver libraries? > >=20 > > People should have updated their resolvers in the last *3 years*. > > If you have not done that already then you are not maintaining your=20 > > machines properly and there is a big chance that you have bigger=20 > > problems than a IPv6 reverse DNS that doesn't work anymore because=20 > > ip6.int is gone. > >=20 > > > Personally I'd be more in favour of a 6 month timeout - i.e > > > around last December or so. > >=20 > > Of course the date is up to discussion, but IMHO: ASAP and at least=20 > > before the end of the year, the sooner the better. > >=20 > > Note that Cisco's IOS updates will be done before that date and=20 > > Windows > > XP2 will come out in August (they say) thus everybody using=20 > IPv6 has=20 > > time enough to upgrade. All "free unix flavors" already support it > >=20 > > Also users agree: http://www.sixxs.net/forum/?msg=3Dgeneral-83948 > > Note the begin date of that thread, we where really waiting=20 > for 6bone=20 > > just as being nice to the people still using it. > >=20 > > On Thu, 2004-07-22 at 10:57, Rob Blokzijl wrote:=20 > >=20 > > > > If no comments are risen for 16:00 today I'll submit=20 > this as an ID. > > >=20 > > > two minor points. In the abstract and the=20 > introduction you write: > > > =20 > > > RFC 3152 delegates IP6.ARPA for reverse IPv6=20 > delegations. For RIRs=20 > > > (RIPE,ARIN,APNIC,LACNIC and soon AFNIC) > > >=20 > > > Replace RIPE --> RIPE NCC > >=20 > > That I did that wrong is a major oops, I should by know the=20 > difference by now. > >=20 > > > Replace AFNIC --> AFRINIC > > >=20 > > > (AFNIC is the .fr registry :-) ) > >=20 > > Also adjusted and added some xref's in the XML. > >=20 > > Old version is now draft-massar-v6ops-ip6int-removal-00.a=20 > new version=20 > > carries the draft-massar-v6ops-ip6int-removal-00 name. > >=20 > > Greets, > > Jeroen > >=20 >=20 >=20 >=20 > > * sig-ipv6: APNIC SIG on IPv6 technology and=20 > policy issues * > > _______________________________________________ > > sig-ipv6 mailing list > > sig-ipv6@lists.apnic.net > > http://mailman.apnic.net/mailman/listinfo/sig-ipv6 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon Jul 26 09:15:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23836 for ; Mon, 26 Jul 2004 09:15:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp5HK-0000mP-K7 for v6ops-data@psg.com; Mon, 26 Jul 2004 13:12:30 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp5HI-0000m8-Q0 for v6ops@ops.ietf.org; Mon, 26 Jul 2004 13:12:29 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 248A281C8; Mon, 26 Jul 2004 15:12:24 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 00538-48; Mon, 26 Jul 2004 15:12:16 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 01194803D; Mon, 26 Jul 2004 15:12:15 +0200 (CEST) Subject: RE: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) From: Jeroen Massar To: "Bound, Jim" Cc: bmanning@vacation.karoshi.com, v6ops@ops.ietf.org, sig-ipv6@apnic.net, ipv6-wg@ripe.net In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B06AFF50E@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B06AFF50E@tayexc13.americas.cpqcorp.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-EkeZdz/wKA43LD6mTkUa" Organization: Unfix Message-Id: <1090847533.22230.65.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 26 Jul 2004 15:12:13 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-EkeZdz/wKA43LD6mTkUa Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2004-07-26 at 12:54, Bound, Jim wrote: > Well stated Mr. Manning. Same for any updates from IETF for IPv6 (e.g. > 2461, 2462, SEND, Optimistic DAD) as every vendor I know (e.g. routers, > switches, servers, clients, embedded systems) is shipping production > IPv6 within their OS release. Can you identify those vendors which didn't react to a RFC from 3 years ago? I know that Windows XP doesn't do it yet, but will with SP2. And a fair amount of Cisco IOS's. Neither of these are servers thus don't require reverses to resolve. Routers don't need resolving, Switches? ehm Layer2, those don't do IPv6 and certainly don't need resolving ;) Any others that haven't been converted in the last three years? > Any changes now to IPv6 will undergoigorous Q&A, You really need to check ip6.arpa? I'd rather be quite anxious in using the following set of servers: ip6.int. 86400 IN NS flag.ep.net. ip6.int. 86400 IN NS y.ip6.int. ip6.int. 86400 IN NS z.ip6.int. ip6.int. 86400 IN NS ns3.nic.fr. ;; Received 266 bytes from 128.9.128.127#53(ns.isi.edu) in 165 ms I only believe ns3.nic.fr to be a production server which is actually pro actively maintained as can be seen from the various reports send to the 6bone mailinglist about the non-workings of ip6.int. For that matter they are broken currently too: http://www.zonecut.net/dns/ Mon Jul 26 12:51:05 UTC 2004 y.ip6.int A record currently not present ip6.int NS ns3.nic.fr z.ip6.int hostmaster.ep.net (1925907 10800 900 604800 129600) ip6.int NS flag.ep.net Nameserver flag.ep.net not responding ip6.int SOA record not found at flag.ep.net, try again ip6.int NS z.ip6.int z.ip6.int hostmaster.ep.net (1925907 10800 900 604800 129600) and totally out of sync, just check the picture that that url produces. This is just like last year and the year before, but people gave up complai= ning about it as there is apparently only one person who runs ip6.int. > The IPv6 Forum and NAv6TF can help here where the IETF cannot, and I > will take this to the members and industry, but it will take time. It > is a deployment issue not a standards issue at this point. The deployment issue is more a lazy administrator issue and also a political issue. The lazy administrators who do not want to upgrade and the political issue where some people want to keep some ropes tied to themselves so they can keep on pulling some strings. > P.S. Bill - the new initial IPv6 AAA at root for JP and KR are they to > use ipv6.arpa? Thanks. And FR also with a couple of others following. I don't see any US based name servers there though, odd. Then again this is for _forward_ resolving, the reverses served through ip6.arpa are delegated to: ip6.arpa. 172800 IN NS ns.apnic.net. ip6.arpa. 172800 IN NS ns.icann.org. ip6.arpa. 172800 IN NS ns.ripe.net. ip6.arpa. 172800 IN NS tinnie.arin.net. ;; Received 126 bytes from 193.0.14.129#53(K.ROOT-SERVERS.NET) in 6 ms (K is started to do IPv6 too, at least the peerings are coming up ;) Fortunatly the above 4 servers are production and there are people paying attention to them, unlike the aforementioned ip6.int machines in somebodies private domain. On Sun, 2004-07-25 at 23:45, bmanning@vacation.karoshi.com wrote:=20 > whjile i applaud each and everyone who has expunged > all ip6.int from their lives, the fact of the matter is that > IETF fiat or no, there exist -many- systems that can only use > reverse maps in the ip6.int tree. =20 As I just asked Jim, which "systems" are those? I also wonder if those are not updated how big virustraps they are ;) > it will be maintained as long as there are queries for=20 > it. Then we can shut it down quite quickly now can't we? And why let a lot of people pay hard cash for maintaining something which is near gone only because a few are too lazy to update? > for those of you for whom ip6.int is a distant memory, > pleae understand and respect the fact that you can not,=20 > despite public posturing, force others to change their=20 > systems. to practically remove ip6.int incures real cost > in both time and cash. in the US there is a term for what > the IETF is trying to do w/ ip6.int. Its called an unfunded > mandate. Unless or until the good folk in the IETF who are > calling for the removal of ip6.int are ready to put up the=20 > cash to effect real change, I wish they would stop. Then please donate the rest of the world, thus except for the few of you who don't update, real cash for continuing to maintain ip6.int which has a lot of broken delegations for alone ip6.int, not even checking the rest, see above. I also wonder why the "US" is brought up while the "US" hasn't been so active in the whole IPv6 soup until late. ip6.int will be gone for me and thus 30%+ of the current IPv6 endsite delegations (check the RIPE database :), 31st of December 2004 is the last date this is going to wait. But I'd rather see it pulled down nicely in cooperation than doing it that way. Nevertheless that 30% userbase has already voted in favor and don't see the problem at all. Then again they actually update their systems as they want to be able to use the newest features: IPv6 for instance. I also repeat again: there is nothing *BAD* about having a reverse- resolve which doesn't work. One simply gets an IPv6 address in their logs, too bad, you should have upgraded 3 years ago then. Greets, Jeroen --=-EkeZdz/wKA43LD6mTkUa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBBQMtKaooUjM+fCMRAjtcAJ9UclvWBSFOda1snXOs5rCkbpUwLACgitU+ htr4vFA4yDaip2vMPUxWPI8= =gB9s -----END PGP SIGNATURE----- --=-EkeZdz/wKA43LD6mTkUa-- From owner-v6ops@ops.ietf.org Mon Jul 26 10:53:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07075 for ; Mon, 26 Jul 2004 10:53:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp6oE-000CVz-Tz for v6ops-data@psg.com; Mon, 26 Jul 2004 14:50:34 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp6o5-000CUj-NF for v6ops@ops.ietf.org; Mon, 26 Jul 2004 14:50:25 +0000 Received: from tayexg12.americas.cpqcorp.net (unknown [16.103.130.127]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id EFFC95C3F; Mon, 26 Jul 2004 10:44:32 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jul 2004 10:31:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 :ip6.int shutdown?) Date: Mon, 26 Jul 2004 10:13:57 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B06AFF574@tayexc13.americas.cpqcorp.net> Thread-Topic: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 :ip6.int shutdown?) Thread-Index: AcRzEx9ofWM/tY34TfGsKbys0VHm6AABmeaQ From: "Bound, Jim" To: "Jeroen Massar" Cc: , , , X-OriginalArrivalTime: 26 Jul 2004 14:31:12.0858 (UTC) FILETIME=[338163A0:01C4731D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > Can you identify those vendors which didn't react to a RFC=20 > from 3 years ago? No that is up to those vendors product managers etc. What I know is from interoperability testing and cannot reveal. You missed mine and Bill's entire point. No one is against doing this it is a matter getting it into the production DNS code base. I think Bill should answer your other questions as you integrated my mail with Bill's. Your complaining here in IETF at least is irrelevant. And not the purpose of the IETF list IMO. I will not respond to other mail. If you want to discuss offline send me mail and I suggest you copy Bill. Ipv6.arpa is supported in the latest BIND releases and IMO all should be doing it, but I don't attribute it to being lazy at all. Again IPv6 is production code now vendors can't just change it as we do the public domain and university code base, it requires QA et al per the customer and that has cost and all changes to IPv6 at this point. /jim From owner-v6ops@ops.ietf.org Mon Jul 26 15:05:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26854 for ; Mon, 26 Jul 2004 15:05:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpAik-0002rC-IJ for v6ops-data@psg.com; Mon, 26 Jul 2004 19:01:10 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp9L7-000G09-Oa for v6ops@ops.ietf.org; Mon, 26 Jul 2004 17:32:41 +0000 Received: by sa.vix.com (Postfix, from userid 716) id 4A76213E00; Mon, 26 Jul 2004 17:32:40 +0000 (GMT) To: v6ops@ops.ietf.org Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) References: <20040725214501.GB1184@vacation.karoshi.com.> From: Paul Vixie Date: 26 Jul 2004 17:32:40 +0000 In-Reply-To: Message-ID: Lines: 9 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Considering the DNAME-baed renaming mechanism documented at , what I wonder is, why doesn't Bill Manning just put in a DNAME at IP6.INT renaming the whole tree to point at IP6.ARPA? Older client implementations will be out there forever. The right transition mechanism might be "all at once, and forever." -- Paul Vixie From owner-v6ops@ops.ietf.org Mon Jul 26 18:50:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17773 for ; Mon, 26 Jul 2004 18:50:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpEFO-000Aiu-If for v6ops-data@psg.com; Mon, 26 Jul 2004 22:47:06 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpEFN-000Aif-Bf for v6ops@ops.ietf.org; Mon, 26 Jul 2004 22:47:05 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6QMl1a01427; Mon, 26 Jul 2004 15:47:01 -0700 X-mProtect: <200407262247> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkp2cAb; Mon, 26 Jul 2004 15:46:59 PDT Message-ID: <410589E1.8060700@iprg.nokia.com> Date: Mon, 26 Jul 2004 15:46:57 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: IPv6 Operations Subject: Re: I-D ACTION:draft-templin-v6v4inet-00.txt References: <200407131935.PAA07549@ietf.org> <40FF9185.1090403@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, Thanks for the comments; please see below for some follow-up: Brian E Carpenter wrote: > Fred, I'm not sure which list this belongs on, so I chose v6ops. > > I have a few comments and questions. > >> Abstract >> >> IPv6 includes a 128-bit address space designed as a solution for the >> 32-bit limitation of IPv4. But, IPv4 proliferation in the global >> Internet continues via private addressing domains behind Network >> Address Translators (NATs). Furthermore, a formerly popular >> viewpoint that IPv6 networking would soon replace IPv4 seems to be >> yielding to an emerging viewpoint of long-term coexistence. > > > I really have problems with the last sentence. I can't imagine where > such a "popular viewpoint" ever existed. Speaking personally, I've > been on a coexistence model since RFC 1671. I can agree that the assertion is at least debatable, so I'm sure I can find some replacement text that would set a less contentious tone. >> 4. Inter-Enterprise Communications >> >> When an ISATAP node sends ip-protocol-41 packets toward an IPv6 >> target node located in a remote enterprise, the virtual link can >> theoretically extend all the way from the sender to the target's >> enterprise border (or even to the target itself) given appropriate >> enhancements in RPBSs along the path as follows: > > > Either I have read the document carelessly, or it doesn't explain > anywhere by what magic the path between the RPBSs is formed. Do they > run normal IPv6 routing protocols, or what? Section 4.2 touches on this when it says: "...each enterprise/site border RPBS along the path toward the final destination should use some form of static/dynamic route discovery to determine the next hop RPBS (or, the final destination itself) among their associated hosts." and mechanisms to support the proposed: "static/dynamic route discovery" are touched on in section 3. I see at least two possibilities for the way RPBSs within an enterprise can determine the IPv6 next-hop, and the method chosen could be at the discretion of the individual enterprise. In the first method, the enterprise's RPBS could use some form of prefix delegation (perhaps using DHCPv6) to form an hierarchical tree rooted at the enterprise border(s). The (static) prefix delegation maps would then steer IPv6 next-hop determinations. In the second method, the RPBSs would run some form of dynamic link-state routing algorithm to determine full/partial topology for the enterprise, and associated hosts would be discovered via on-demand route discovery. In this case, prefix hierarchies might not be necessary, and the entire enterprise could be regarded as a "flat" topology. >> 4.1 From the Sender to the Target's Enterprise Border >> >> Any RPBSs along the path from the sender to the target's enterprise >> border that rewrite a packet's IPv4 source address should implement a >> simple enhancement to support extension of the virtual link. In >> particular, each such RPBS should also rewrite any matching IPv4 >> addresses embedded in the packet's IPv6 source address and (for IPv6 >> Neighbor Discovery messages) in Source/Target Link Layer Address >> Options [RFC2529] at the same time the IPv4 source address is >> rewritten (i.e., an operation commonly referred to as proxying >> [NDPROXY]). > > > This appears to describe an IPv6 NAT process. If so, surely we must deem > it unacceptable. We want packets to be delivered unchanged in IPv6. I have been "on the fence" as to whether IPv6 header field rewriting is strictly required, and I believe you are right that there are ways that it can be avoided. >> Each such RPBS should also cache IPv6 flow soft state [RFC3697]... > > > RFC 3697 doesn't discuss soft state. It specifically says that "The > nature > of the specific treatment and the methods for the flow state > establishment > are out of scope for this specification." > >> ...as a >> logical interface identifying the sender and take care that no two >> flows with the same (IPv4 src, IPv4 dst, IPv6 flow_label)-tuple exit >> the enterprise/site at the same time. If two or more flows >> attempt to >> use the same (non-zero) IPv6 flow label and IPv4 destination address, >> an RPBS can break the tie by assigning distinct IPv4 addresses to the >> flows when it re-writes the IPv4 source address and matching IPv4 >> addresses in ip-protocol-41 packets. (This requires each RPBS to >> assign multiple IPv4 addresses to its outgoing interfaces.) > > > Well, the RFC 3697 requirement for flow labels is only that the > (IPv6 src, IPv6 dst, IPv6 flow_label) tuple must be unique. That is a > much easier constraint to meet. If the IPv4 addresses in question > are to be taken from a NAT pool, I don't think this will scale at all. > What if a site generates 20000 simultaneous flows to different clients? > It's quite consistent with RFC 3697 for them to use the same flow label. What you seem to be identifying here is a "NAT vs. NAPT" issue. RFC 3697 mandates that the flow-label not change along the path to the destination, so RPBSs would need to resolve "collisions" by assigning different IPv4 source addresses for colliding flows as for NAT without port translation. An alternative would be to provide a "mutable" field in the packet that can be rewritten by RPBSs along the path that act as NAPTs. The most obvious approach is to use IPv6/UDP/IPv4 encapsulation (i.e., as for 'teredo'), which already provides the UDP source port as a mutable field for NAPT and presents the approach of least surprise for legacy equipment. However, it requires that the 8-octet UDP header be present in all encapsulated packets which might not interact well with paths having severely-constrained MTUs and requiring significant fragmentation. A second NAPT alternative would be to use 'ip-protocol-41' encapsulation but disable IPv4 fragmentation by setting the "DF" bit in the IPv4 header and treating certain other fields as mutable. Using this approach, an encapsulating RPBS could set the 13 "fragmentation offset" bits, the 16 "ID" bits, and possibly also the "More Fragments" bit to a unique value corresponding to an (IPv6 src, IPv6 dst, IPv6 flow_label)-tuple. The resulting (IPv4 src, IPv4 dst, mutable_bits)-tuple would then serve as a "virtual circuit identifier" that can be rewritten by enlightened RPBSs acting as NAPTs in the path. The intermediate RPBSs and final decapsulator would also require a bit in the IPv4 header to indicate that the above-mentioned IPv4 header fields are being used as a virtual circuit identifier, and the "Reserved Fragmentation" bit could be used for that purpose. The primary disadvantage of the latter approach is that it effectively disables IPv4 fragmentation since the DF bit is set in all packets. This would be at odds with paths that do not support at least the minimum IPv6 MTU of 1280 bytes, since links for IPv6 must be able to deliver a 1280 byte packet without returning a "Packet too big" error. To avoid this issue, an "adaptation layer" for 'ip-protocol-41' would be needed whereby encapsulated packets are fragmented/reassembled at an intermediate level between IPv6 and IPv4. Packets on the wire would appear as whole IPv4 packets with the "DF" bit set, and IPv6 fragments would possibly be carried in multiple 'ip-protocol-41' packets. But, the intermediate adaptation layer would be opaque to both IPv6 (as seen from above) and IPv4 (as seen from below). >> 6. Addressing >> >> When an ISATAP node's application initiates communications with a >> target peer, it first resolves the target's Fully-Qualified Domain >> Name (FQDN) using the DNS [RFC1035] or an enterprise-internal name >> service, e.g., [LLMNR]. If the name service returns a set of AAAA >> records including one with a 6to4 [RFC3056] subnet router anycast >> address, ... > > > I don't understand why that would ever happen. A means for associating a node's IPv6 address(es) with a global IPv4 address for its home enterprise is required, and it would be desirable to discover this association during name resolution. An alternative to asking nodes to configure a 6to4 subnet router anycast address for its home enterprise in the DNS RR's would be to simply have them configure real 6to4 unicast addresses. This would seem like a reasonable requirement for RPBSs, but perhaps not for IPv6-only nodes. This leaves us with a question as to how (and whether) IPv6-only nodes can be associated with a global IPv4 address for their home enterprise? >> ...the initiating node can use the IPv4 address embedded in the >> 6to4 prefix as the IPv4 destination address for the target node's >> enterprise border RPBS. (The address can also be used to determine >> whether the initiator and target reside in the same enterprise.) > > > No it can't, in the general case. A site might run multiple simultaneous > 6to4 prefixes (e.g. belonging to several different ISPs or several > different > border routers). Agreed; this point was more of a tangential observation than an architectural requirement anyway. Thanks - Fred ftemplin@iprg.nokia.com > Regards, > > Brian From owner-v6ops@ops.ietf.org Tue Jul 27 00:26:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03234 for ; Tue, 27 Jul 2004 00:26:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpJSq-00048c-Sp for v6ops-data@psg.com; Tue, 27 Jul 2004 04:21:20 +0000 Received: from [159.226.39.7] (helo=ict.ac.cn) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BpJSp-00047c-RA for v6ops@ops.ietf.org; Tue, 27 Jul 2004 04:21:20 +0000 Received: (qmail 9645 invoked by uid 507); 27 Jul 2004 02:30:09 -0000 Received: from unknown (HELO ThinkPadX31) (liumin@159.226.39.104) by ict.ac.cn with SMTP; 27 Jul 2004 02:30:09 -0000 From: "Liu Min" To: "'Pekka Savola'" , Subject: RE: Teredo for Standards Track in Unman scenarios? Date: Tue, 27 Jul 2004 10:34:26 +0800 Message-ID: <001c01c47382$3f237e90$4b74a8c0@ThinkPadX31> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Teredo is implemented and deployed, and there are multiple implementations. Where can I find the multiple implementation of Teredo? I know an IPv6 = stack that supports Teredo is available with the . Where can I find the Teredo server and Teredo relay? =20 Best Wishes, =20 Liu Min =20 Institute of Computing Technology Chinese Academy of Sciences Tel: (86-10) 6256 5533-9240=20 E-mail: liumin@ict.ac.cn From owner-v6ops@ops.ietf.org Tue Jul 27 00:27:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03281 for ; Tue, 27 Jul 2004 00:27:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpJY4-00052P-UY for v6ops-data@psg.com; Tue, 27 Jul 2004 04:26:44 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpJY3-00051b-TZ for v6ops@ops.ietf.org; Tue, 27 Jul 2004 04:26:44 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6R4Qcm12481; Tue, 27 Jul 2004 07:26:38 +0300 Date: Tue, 27 Jul 2004 07:26:38 +0300 (EEST) From: Pekka Savola To: Liu Min cc: v6ops@ops.ietf.org Subject: RE: Teredo for Standards Track in Unman scenarios? In-Reply-To: <001c01c47382$3f237e90$4b74a8c0@ThinkPadX31> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 27 Jul 2004, Liu Min wrote: > > Teredo is implemented and deployed, and there are multiple > > implementations. > > Where can I find the multiple implementation of Teredo? I know an IPv6 stack > that supports Teredo is available with the Windows XP>. Where can I find the Teredo server and Teredo relay? I'd assume some Windows Server would also support server/relay functionality. Apart from that.. I've came across two -- I don't know which version they implement, and which parts they implement; not having tested any of them personally, I also don't know how they would interoperate: http://www-rp.lip6.fr/teredo/ http://www.simphalempin.com/dev/miredo/ HTH -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Jul 27 01:57:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07591 for ; Tue, 27 Jul 2004 01:57:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpKwj-000GV4-1T for v6ops-data@psg.com; Tue, 27 Jul 2004 05:56:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpKwg-000GUW-T8 for v6ops@ops.ietf.org; Tue, 27 Jul 2004 05:56:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6R5u3k14458; Tue, 27 Jul 2004 08:56:06 +0300 Date: Tue, 27 Jul 2004 08:56:03 +0300 (EEST) From: Pekka Savola To: Jeroen Massar cc: JORDI PALET MARTINEZ , Subject: Re: draft-palet-v6ops-tun-auto-disc-01.txt In-Reply-To: <1087406137.12356.71.camel@segesta.zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This has been sitting too long in my "to be responded" queue.. :-( On Wed, 16 Jun 2004, Jeroen Massar wrote: > On Sat, 2004-06-12 at 11:58, Pekka Savola wrote: > > Thanks for comments.. > > > > I think your assumptions are different from those based on which this > > draft was written. They might warrant spelling out, but in the > > interests of learning how to enhance the document, it would be best if > > you could state more clearly which parts of the document you find > > objectionable (and how to fix the issue, if possible). > > No, I think I am looking the issue from a different perspective. > > The document is talking about 'tunnel endpoints' while IMHO these should > be 'tunnel services'. Who provides them and how they are negotiated is > not mentioned at all in the document and is up to the various > configuration protocols, while this document is targetted solely afaik > at the discovery part. As clarified by Miguel, these are out of scope for this doc, to be described in the specifications themselves, in draft-palet-v6ops-auto-trans-00.txt, or whatever. This doc just tries to analyze different ways to discover the end-point, without taking any stance on the actual protocol. > > To make it clear, IMHO, for wide-scale deployment, non-automatic > > configuration is completely unacceptable. I want to do away with such > > manual configuration. The main point of the automatic discovery > > document is to describe mechanisms how the host stacks can run a > > simple procedure which can lead to a result like, "yes, tunnel service > > is available, at IPv4 addrexx a.b.c.d", or, "no, tunnel service is not > > available." [...] > But I would rather see the discovery part say: > The service is available from: > - here > - there > - there too > > Or when the client only has one choice or thinks it is feasible enough > for a certain choice to use that directly. This is not really feasible, because doing such would require coordination among different parties, and complexity increases every time you need to coordinate between different people. This could be mostly doable with Centralized Broker -mechanisms, but the draft tries to justify that those aren't scalable / feasible. Most discovery methods, however, support the discovery of multiple end-points. Whether those would be under a different administration is a separate question. And the user can always manually configure the endpoint if he knows of something better.. Text suggestions to make this clearer? > You also note 'host stacks' but wouldn't this be better to place simply > as an additional tool. radvd isn't a part of the stack either in most > OS's at the moment. Also I am quite sure that there a lot of people who > don't want something to automatically configure it for them so anything > using this tool would need to either be setup by the user or have enough > knowledge to not run in a native network. A separate tool (but shipped with the base system) is probably closer to the reality, yes. > > > Basically I see three steps: > > > - Discovery of the 'best' tunneling service > > > > > > > It doesn't have to discovery of the *best* service necessarily, but > > discovery of the service. There's sufficiently large great gaping gap > > here... and this is what this document aims to address. > > 'best' is the one that fits mostly in the situations that the discovery > is taking place in. 'best' could thus be the one that is anycasted > closest to the host etc and depends totally on the discovery method. > This is what the doc should describe. Isn't it what this is describing? Shared-address unicast is one of the most prominent techniques in the draft. Also note that if there are multiple potential mechanisms, figuring out which one to use is out of scope here (see the auto-trans work). We're just concerned about the mechanisms to discover the end-point. > > > > - Tunneling > > > (proto-41, 6to4, teredo, ayiya, tinc, openvpn, ...) > > > > These two are out of scope of this document. > > Thus my assumption that this document is targeted at the gap above is > correct. Then one should not be finding the best tunnel _endpoint_ but > the tunnel _service_ which can provide that endpoint. TSP for instance > does its own endpoint negotiation. Having a discovery method do that > would thus make TSP either be only for that single Tunnel Server or it > would require another step. The 'endpoint' wording thus is wrong IMHO > and should be resplaced by 'service'. Again, I disagree. Let's take TSP as an example as you mention it. TSP has a great "gaping gap" (in your words): there is no way to discover the closest tunnel broker! For tunnel broker solutions, this document tries to address finding the tunnel broker end-point (where you can begin the negotiation). The tunnel broker negotiation specifies the ultimate endpoint where you'll build your tunnel (such address could of course be anycast or whatever as well). What happens after getting the initial broker end-point it out of scope of this specification. For tunnel server solutions, this document tries to address finding the tunnel server end-point (where you can beging tunneling or negotiation, whatever the mechanism specifies). So, I have to disagree with you here. We just want to discover the end-point. Any suggestions how to make it clearer? > As the Discovery service can in no way know the load of the Tunnel > Service and any other properties that the provider of the service wants > to include into the calculation, wouldn't it be better after one has > discovered the 'best' service to then hand it over to for instance TSP > or STEP? For broker-like techniques, hand-over is what happens -- see above. For server-like techniques, the assumption is that the load-balancing and whatever features are achieved using different means (anycasting, modification of DNS records if one server gets full, etc.) > > > The text, abstract and actually the complete text mentions > > > "configuring the IPv6 tunnel endpoint on a node." > > > I would change that part to 'tunneling service' instead of 'tunnel endpoint'. > > > As mentioned in 3.1, the service could consist of multiple servers though > > > there is only one 'endpoint'. A service eg a Tunnel Broker, might even > > > have multiple endpoints etc. > > > > I'd be reluctant to say 'tunnel service', as you don't configure > > anything about the service itself, just the tunnel end-point. All > > other means of configuring (or reconfiguring if there is a broker) are > > out of scope of this specification. > > With 'tunnel service' you designate the closest possiblity of giving you > the 'service' which is "providing IPv6 connectivity". With a tunnel > endpoint one would mean 'exactly that endpoint'. Yes, that's the intent -- end-point only. > > (Later, why you said this becomes clearer: you have the assumption > > that the service would be used for general purpose service discovery, > > for multiple tunneling mechanisms. > > Not entirely, this discovery method _could_ point to multiple tunneling > mechanism, but if the IETF reaches concensus one single protocol, then > it could be just that. Still it would be better to let the service > determine the real endpoint. Based on DNS or anycast this is simply not > an option. Are you saying that such a discovery process would have to implement the tunnel broker logic for picking the right tunnel server endpoint for the users? Multiple times, once for each tunnel broker (or other) technique? This doesn't seem feasible to me.. > What if you have a dialin pool for 'low paying' clients and 'high > paying' clients, you might want to give a better service to the ones > that give you more money, anycast nor DNS will not work here unless one > does a lot of tricks. Letting a service decide it, after that that > service has been automatically discovered is a better and more flexible > option. The service can then also either redirect the user somewhere > else or give a nice visual error message through one protocol or > another. The mechanisms described in this draft allow no such thing > because the endpoint of the tunnel is directly configured. This is something that should happen in the tunnel broker or server protocol, not in the discovery process. For example, what kind of prefix would get delegated could depend on these factors (I hope it won't, but it could). > > I don't make this assumption -- > > this method would be mechanism-specific.) > > If this document is mechanism specific shouldn't these descriptions then > be included in that mechanism ? Exactly the other way. This document is NOT mechanism-specific, but mechanism documents will have to implement one (or multiple of) mechanism described in this document for discovery. This is just a common place for discussing end-point discovery. How that's integrated in the mechanisms is out of scope. > > > Therefor I miss one possible scenario & solution: > > > One could announce a standardized anycast address (eg 192.0.2.6), which > > > can then be hardcoded into clients, maybe better to have something like > > > tunnelautodiscovery.ietf.org as DNS can always be changed, this could > > > then also be combined with the DNS prefixing path search etc. > > > > There is is mentioned in section 3.1 as so-called "global anycast". > > Which targets a completely different audience: a local (organisational) > network and nothing bigger, eg providing service to a complete IX. Please re-read. Section 3.1 includes both global and local anycast, and global is exactly what you describe. Please submit text clarification proposal if this is not clear enough. > > > 8<---- > > > www.example.org tunnelbroker > > > tsp.example.org TSP > > > 6to4.example.net 6to4 > > > teredo.example.net teredo > > > ... > > > ---->8 > > > The user will be presented with an optionlist to choose from or > > > alternatively based on properties/policies etc the client could > > > automatically pick the best out of the list and use that. Then > > > either the website, TSP, 6to4, teredo, etc take over on the process. > > > The discovery is really discovery here and nothing else. > > > > You make the assumption that the discovery process would be common for > > all the the mechanisms. I don't. Making it common might have an > > advantage or two, > > The biggest advantage would be that it is generic and that it will work > for all situations and not just a few. If you only want a few, then that > would be like designing IPv6 only for the polar caps as there it freezes > but nowhere else. I don't see any OS vendor wanting to include a tool > then. The scale of Teredo is the target, aka every desktop user pc > should have it. And every of the above mechanisms solves a different > problem which the others don't. Then if one just says 'always use this' > it won't work for a large chunk of the other users and or ISP's who > might want to deploy it and they will not adopt it. As described before, you seem to think that the discovery part would be independent of the mechanisms -- that you would first run the discovery (one tool), and then you would run the mechanism (another tool). I don't expect that. I'd expect discovery to be integrated with the transition mechanism tool. Trying to create an independent tool which achieves everything that the different transition mechanisms might need is unfeasible -- such a tool would by necessity be extremely complex, having to implement N different mechanisms for different tools. > > > ISP's which don't announce this service will recieve the prefix from > > > another ISP and of course could simply optional nullroute the prefix if > > > they want to disable this service from other ISP's and when they don't > > > want their users to use this service due to administrative policy etc. > > > > > > Having the above would then be probably better solved with an anycast > > > DNS server to be able to ask that server multiple different questions > > > and maybe directly supply a default DNS server for many hosts solving > > > quite a number of problems. > > > > Global anycast has disadvantages as well, as noted in the draft (maybe > > not clearly enough). > > Using anycast for discovery doesn't have any drawbacks as the packet > exchange between the client and the 'server' would be minimal. I disagree. Please re-read. What happens if nobody is advertising the prefix so that your packets would get routed to it? What happens if the only one globally advertising is 300 ms away? > If you want to use anycast as a tunnel _endpoint_ that is a different > story, but this was about discovery thus we are hopefully talking > services here and not endpoints... This is about discovery of the *endpoint*, so depending on how that information is used (remember the difference of broker vs server), it could be used for longer as well. [...] > > All the solutions assume that the tunneling mechanism -specific means > > are used to obtain that. E.g., one could have a pseudo-interface > > which creates tunnels on the receipt of the first packet, or > > something. This should not be a problem. > > I already see that script kiddy spoofing IPv4 packets with ease and > generating a lot of interfaces at random, but how was that configured? > Or better said how did you authenticate the user to the tunnel service? > Especially when the user is not directly coming from your own IPv4 > space, a remote mobile user, a user visiting another ISP's network etc. > > l2tp / AYIYA / ... etc could be used as those protocols provide > authentication inside the protocol stream, but proto-41, which is the > most common used setup doesn't work in this case. Obviously, you should not run such a service (if it depends on the first packet, etc.) except to your customers or such which you have ensured that cannot spoof the address. Again, this is out of scope from this document. > > > How is it going to know which prefix to use and how is the TS going > > > to know where to route packets destined for that prefix? > > > > The client doesn't need to know the prefix but it might. It could > > just learn the prefix from the TS, similar to the process STEP uses. > > STEP/TSP fall under the "Configuration" header in the 3-phase list. > These should IMHO determine the type of protocol for the data being > tunneled. STEP though doesn't define any protocol, thus would be limited > to the underlying protocol that would be used, which would then make > this only applicable in a few scenarios of the many that exist. > Which again doesn't make it applicable for the many users and varying > setups out around the world. Out of scope from this doc. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Jul 27 03:34:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25040 for ; Tue, 27 Jul 2004 03:34:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpMS1-0003yG-Bd for v6ops-data@psg.com; Tue, 27 Jul 2004 07:32:41 +0000 Received: from [194.250.197.211] (helo=proxy.6wind.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpMS0-0003y2-AO for v6ops@ops.ietf.org; Tue, 27 Jul 2004 07:32:40 +0000 Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 27A0F79E; Tue, 27 Jul 2004 09:32:39 +0200 (CEST) Received: from 6wind.com (jardin.dev.6wind.com [10.16.0.239]) by intranet.6wind.com (Postfix) with ESMTP id 1A4F4831; Tue, 27 Jul 2004 09:32:39 +0200 (CEST) Message-ID: <41060516.6050307@6wind.com> Date: Tue, 27 Jul 2004 09:32:38 +0200 From: Vincent Jardin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: Liu Min , v6ops@ops.ietf.org Subject: Re: Teredo for Standards Track in Unman scenarios? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Tue, 27 Jul 2004, Liu Min wrote: > > >>>Teredo is implemented and deployed, and there are multiple >>>implementations. >>> >>> >>Where can I find the multiple implementation of Teredo? I know an IPv6 stack >>that supports Teredo is available with the >Windows XP>. Where can I find the Teredo server and Teredo relay? >> >> > >I'd assume some Windows Server would also support server/relay >functionality. Apart from that.. I've came across two -- I don't know >which version they implement, and which parts they implement; not >having tested any of them personally, I also don't know how they would >interoperate: > >http://www-rp.lip6.fr/teredo/ >http://www.simphalempin.com/dev/miredo/ > > FYI, both interoperate. The main difference is based on the implementation: - the LIP6/6WIND Teredo implementation is using a Kernel implementation (BSD license) - Miredo is using a user land implementation (GPL license) They implement the Relay and Server part. The latest and non-stable releases are available thru the same CVS server: http://cvs.sourceforge.net/viewcvs.py/teredo/ Regards, Vincent From owner-v6ops@ops.ietf.org Wed Jul 28 03:22:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10568 for ; Wed, 28 Jul 2004 03:22:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bpiht-0007UL-Vl for v6ops-data@psg.com; Wed, 28 Jul 2004 07:18:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bpihs-0007Ty-37 for v6ops@ops.ietf.org; Wed, 28 Jul 2004 07:18:32 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6S7IS412709; Wed, 28 Jul 2004 10:18:28 +0300 Date: Wed, 28 Jul 2004 10:18:28 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: v6ops@ops.ietf.org, "'Fred Templin'" , Mohit Talwar , , "'Dave Thaler'" Subject: Re: Security issues of Isatap usage in 3GPP networks WAS : RE: moving when all the scenarios are not yet complete [RE: DSTM] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Going through oooooold backlog... I think we are pretty close to agreeing that with additional simplifications to ISATAP spec, and significant assumptions about deployment (border is secured; ingress filtering is deployed; etc. -- I don't think they hold in general!) ISATAP's security threats from ND can be mitigated reasonably well. On Fri, 25 Jun 2004, Karen E. Nielsen (AH/TED) wrote: > Let me try (once more) to address the expressed concerns with > the direct tunnelling functionality of Isatap. > > The problem hinted at, I assume, is the SEND security threats > as detailed in 3756 (....or are there others ?) RFC3756 on ND security threats should provide a relatively complete picture here. Of course, there are still security issues that might be independent of the use of ND that come with ISATAP (for example, see my last comment in this mail). Note that ISATAP's securit model wrt. RFC3756 would be: 3. A model where the nodes do not directly trust each other at the IP layer. This model is considered suitable for e.g., ad hoc networks. .. even if IP spoofing had been prevented, the perimeter secured, etc. In addition, direct tunneling brings up the same link-local threats in other protocols, such as MLD. Those are likely subject to other forms of threats. > In 3GPP networks it should be possible to assume the following: > > * Intrasite IPv4 source spoofing isn't possible. > * Site is Protocol-41 perimeter guarded. > > - or it should be acceptable to recommended the above to be > enforced by the 3GPP operator as a mechanism to prevent > potential SEND security threats of Isatap. (This is not all of the threats, but still..) How realistic is it that these are being performed? Still, the ISATAP spec does not (IMHO) include sufficient guidance (just two paragraphs in Security Considerations) what exactly the site should do, and what happens if that isn't done. This seems too vague to qualify as a sufficient recommendation. (yes, this has been brought up in the past, but the revisions of spec seem to remove all of this kind of analyses.) Also, I seem to recall (I'd be happy to be proven wrong..) that some or even many implementations do not perform the required security checks (or didn't perform them). That's not good; a tunneling mechanism where you have less to check and rely on is better because you don't need to worry about whether a particular implementation has done a check or not. > Given the above, the SEND security threats either do not apply to > Isatap or can be prevented by careful implementation. In particular > by implementing the following [...] security check on Isatap interfaces: > > * RA messages are only accepted from PRL routers. See responses below. > 4.1.1. Link-layer addresses in potential > Neighbour Cache Entries maintained on Isatap Interfaces > are not relevant. The Link-layer address (IPv4 address) is deduced > from IPv6 destination address. An implementation that uses a different link-layer address > than the IPv4 address embedded within the IPv6 destination address isn't compliant. Yes, should be OK in the current spec. Note however that you still can populate the neighbor cache with crap even if you don't use it with ISATAP. > DAD sub-clause: > Why you would ever want to implement DAD on an Isatap Interface I really don't know. > The uniqueness of the address is inherited from the uniqueness of the IPv4 address. > The latter which is ensured by the network (at least in enterprise and 3GPP networks). The spec takes no stance on disabling DAD or not for ISATAP, hence it could be used. However, if v4 spoofing is prevented and perimeter is secure, this shouldn't be a problem. > 4.1.2: This could be a valid DoS threat. > This is however only applicable if NUD is performed on the interface. > NUD over Isatap only really work if carefully implemented anyway - > Hence it should be reasonable to assume careful behaviour of an implementation which performs > NUD on an Isatap interface. For example by implementing the following additional validity > check: > * Unless sourced from the link-local address of a PRL router (e.g. for proxy ND) the target address > of the NS message should be identical to the source address of the packet. > > (We haven't implemented the mentioned check as we > do not support NUD on isatap interfaces) I think the critical question here is whether the node processes NS's and NA's (and which ones if so) that are sent on the ISATAP link. That's where I'm concerned -- I'd rather restrict ND messages to just those we know we need, rather than allow everything and provide checks which might or might not help. Also, looking at the spec, I can't quickly think of why running NUD on top of ISATAP links would make sense, as NUD only deletes the neighbor cache entry -- but as with ISATAP neighor cache wouldn't be used in any case, always just the static computation, this doesn't seem too useful. The only cases I could marginally think of would be the use of some onlink prefixes by PRL routers, but that's marginal as well. I guess this could be removed. > 4.1.3: Non-applicable if DAD is omitted Yes, but more on DAD above. > 4.2.1: Non-applicable given that a trust worthy PRL population > mechanism is deployed. Agreed (and if spoofing is not possible). > 4.2.2+4.2.3 > Isn't related to the direct tunnelling functionality of Isatap. > Is limited by the usage of/and management of > a trust worthy PRL population mechanism. Wrt, 4.2.2, ISATAP should be better off than standard ND because if the decapsulation checks are implemented, even if the default router is killed, only communication using the ISATAP addresses is possible, others will be discarded. 4.2.3 is not an ISATAP-specific issue. > 4.2.4 > Non-applicable as Isatap's source address checks combined with IPv4 source address > proof implies IPv6 source address proof. I.e. the IPv6 link-local address of > a PRL router cannot be spoofed. Agreed. > 4.2.5+4.2.6+4.2.7: > Non-applicable given IPv4 source address spoofing prevention, > if trustworthy PRL population mechanism is deployed. Agreed -- significant if's. > 4.3.1: > Non-applicable by IPv4 source address spoofing prevention. Yes. > 4.3.2 > Not related to the direct tunnelling functionality of Isatap. > Not applicable if address resolution is based on static resolution only. This is slightly different with ISATAP. Instead of the router having to do lots of ND lookups (which time out), the router has to send the packets to arbitrary IPv4 nodes by static computation. You could even perform 6to4-like reflection from the ISATAP router. Assume that the ISATAP addresses would be of the form: 2001:db8::, and the site used 10.0.0.0/8 for addressing. Now you could force the router to send proto-41 packet to 1) every host inside 10/8, or even 2) every host the user wants e.g., a host that's outside the ISATAP domain (e.g., 4.5.6.7) -- unless there are specific blocks at the ISATAP router or at the perimeter to change this. It might be possible to avoid 2) for global addresses if the ISATAP prefix length is chosen to be sufficiently short and the v4 address space is contiguous. But that would mean having a prefix length like /106 which would be disallowed by the IPv6 specs and would probably have other problems.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jul 28 14:24:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23212 for ; Wed, 28 Jul 2004 14:24:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bpt3i-0006UW-U8 for v6ops-data@psg.com; Wed, 28 Jul 2004 18:21:46 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bpscj-0003JY-OV for v6ops@ops.ietf.org; Wed, 28 Jul 2004 17:53:53 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EC9DC13DFB for ; Wed, 28 Jul 2004 17:53:52 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: v6ops@ops.ietf.org Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) In-Reply-To: Message from bmanning@vacation.karoshi.com of "Wed, 28 Jul 2004 11:24:21 GMT." <20040728112421.GG8260@vacation.karoshi.com.> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 28 Jul 2004 17:53:52 +0000 Message-Id: <20040728175352.EC9DC13DFB@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > Considering the DNAME-baed renaming mechanism documented at > > , what I wonder > > is, why doesn't Bill Manning just put in a DNAME at IP6.INT > > renaming the whole tree to point at IP6.ARPA? > > in part, because there are entries in ip6.int that have no > counterpart in ip6.arpa.... otherwise, a really good idea. i think that you should spend your efforts trying to get the .INT content mirrored in .ARPA somehow. such as contacting the folks who own the delegations you have in .INT and teaching them how to re-register their content in .ARPA, such as by going through their RIR's. > i have been trying to get the good folks at ICANN to effect > such changes as can be done, done. icann's not involved at all. once you get the content re-registered in .ARPA, you can put a DNAME at the top of your .INT zone and the rest is history. > and i do not belive that older implementations will be > out there forever. but as long as the number of queries > for ip6.int is noticable, i plan on serving the data. what's the standard for "noticable"? 1qps? 10qps? 100qps? what are you seeing, in qps, today? From owner-v6ops@ops.ietf.org Wed Jul 28 14:53:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25251 for ; Wed, 28 Jul 2004 14:53:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BptY9-0009q9-Hm for v6ops-data@psg.com; Wed, 28 Jul 2004 18:53:13 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BptXa-0009ji-EB for v6ops@ops.ietf.org; Wed, 28 Jul 2004 18:52:38 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i6SIqcrc009445; Wed, 28 Jul 2004 18:52:38 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i6SIqboh009442; Wed, 28 Jul 2004 18:52:37 GMT Date: Wed, 28 Jul 2004 18:52:37 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: v6ops@ops.ietf.org Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040728185237.GD9387@vacation.karoshi.com.> References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040728175352.EC9DC13DFB@sa.vix.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Jul 28, 2004 at 05:53:52PM +0000, Paul Vixie wrote: > > > Considering the DNAME-baed renaming mechanism documented at > > > , what I wonder > > > is, why doesn't Bill Manning just put in a DNAME at IP6.INT > > > renaming the whole tree to point at IP6.ARPA? > > > > in part, because there are entries in ip6.int that have no > > counterpart in ip6.arpa.... otherwise, a really good idea. > > i think that you should spend your efforts trying to get the .INT > content mirrored in .ARPA somehow. such as contacting the folks > who own the delegations you have in .INT and teaching them how to > re-register their content in .ARPA, such as by going through their > RIR's. not all entries in the .int tree are RIR related. the most obvious is 3ffe::/16. It does not help that the IETF has a BCP/PS RFC that prohibits any entry in ip6.arpa that is not an RIR managed block. > > i have been trying to get the good folks at ICANN to effect > > such changes as can be done, done. > > icann's not involved at all. once you get the content re-registered > in .ARPA, you can put a DNAME at the top of your .INT zone and the > rest is history. er, yes ICANN is involved. And I understand the process here. > > and i do not belive that older implementations will be > > out there forever. but as long as the number of queries > > for ip6.int is noticable, i plan on serving the data. > > what's the standard for "noticable"? 1qps? 10qps? 100qps? what > are you seeing, in qps, today? the standard is likely different for different people. we did have this same discussion - about 10 years ago when there was a proposal to shut down in-addr.arpa and move the v4 reverse anchor to ip4.int... :) as to qps, not so many, but that may be due to the fact that once sites get the RIR, 6bone, and other delegations cached, they don't come back too often. --bill From owner-v6ops@ops.ietf.org Wed Jul 28 15:33:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28123 for ; Wed, 28 Jul 2004 15:33:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bpu9U-000EMX-Fv for v6ops-data@psg.com; Wed, 28 Jul 2004 19:31:48 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bpu7J-000E7c-8l for v6ops@ops.ietf.org; Wed, 28 Jul 2004 19:29:33 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D5E7813DE5 for ; Wed, 28 Jul 2004 19:29:32 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: v6ops@ops.ietf.org Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) In-Reply-To: Message from bmanning@vacation.karoshi.com of "Wed, 28 Jul 2004 18:52:37 GMT." <20040728185237.GD9387@vacation.karoshi.com.> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 28 Jul 2004 19:29:32 +0000 Message-Id: <20040728192932.D5E7813DE5@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > i think that you should spend your efforts trying to get the .INT > > content mirrored in .ARPA somehow. such as contacting the folks > > who own the delegations you have in .INT and teaching them how to > > re-register their content in .ARPA, such as by going through their > > RIR's. > > not all entries in the .int tree are RIR related. the most > obvious is 3ffe::/16. 3ffe::/16 goes "poof" on june 6 2006 if i recall correctly. no worries. > It does not help that the IETF has a BCP/PS RFC that > prohibits any entry in ip6.arpa that is not an RIR > managed block. that's a political issue that i think folks here could take all sides of. > > what's the standard for "noticable"? 1qps? 10qps? 100qps? what > > are you seeing, in qps, today? > > the standard is likely different for different people. > we did have this same discussion - about 10 years ago > when there was a proposal to shut down in-addr.arpa and > move the v4 reverse anchor to ip4.int... :) i remember. the problem was, the installed base was too large to consider such a thing. it was worth of study, and there was a study, and in the end it was decided that changing it would be a bad idea. > as to qps, not so many, but that may be due to the fact that > once sites get the RIR, 6bone, and other delegations cached, > they don't come back too often. then you could safely just do nothing, right? From owner-v6ops@ops.ietf.org Wed Jul 28 16:37:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03341 for ; Wed, 28 Jul 2004 16:37:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bpv8y-000LiP-L9 for v6ops-data@psg.com; Wed, 28 Jul 2004 20:35:20 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1Bpv8n-000Lh8-Aj for v6ops@ops.ietf.org; Wed, 28 Jul 2004 20:35:09 +0000 Received: (qmail 69722 invoked by uid 1007); 28 Jul 2004 20:35:08 -0000 Date: Wed, 28 Jul 2004 22:35:08 +0200 From: Gert Doering To: bmanning@vacation.karoshi.com Cc: Paul Vixie , v6ops@ops.ietf.org Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040728203508.GA467@Space.Net> References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040728185237.GD9387@vacation.karoshi.com.> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Wed, Jul 28, 2004 at 06:52:37PM +0000, bmanning@vacation.karoshi.com wrote: > not all entries in the .int tree are RIR related. the most > obvious is 3ffe::/16. It does not help that the IETF has a > BCP/PS RFC that prohibits any entry in ip6.arpa that is not > an RIR managed block. We have been through *that* argument before - it wasn't very good 2 years ago (the 6bone *is* (was) an internet registry, and nothing says "only the 4 established IPv4 regional registries are considered"). Besides that, e.f.f.3.ip6.arpa *has* been delegated, so what's this argument supposed to be about? ; <<>> DiG 8.3 <<>> @dns1.icann.org e.f.f.3.ip6.arpa ;; AUTHORITY SECTION: e.f.f.3.ip6.arpa. 23h30m IN NS ns3.nic.fr. e.f.f.3.ip6.arpa. 23h30m IN NS flag.ep.net. e.f.f.3.ip6.arpa. 23h30m IN NS imag.imag.fr. e.f.f.3.ip6.arpa. 23h30m IN NS sonata.hexago.com. - looks perfectly fine to me. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Wed Jul 28 21:32:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21153 for ; Wed, 28 Jul 2004 21:32:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bpzk2-0005EZ-RC for v6ops-data@psg.com; Thu, 29 Jul 2004 01:29:54 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bpzjr-0005Dq-Ng for v6ops@ops.ietf.org; Thu, 29 Jul 2004 01:29:44 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id E1CA81006; Thu, 29 Jul 2004 03:00:28 +0200 (CEST) Date: Thu, 29 Jul 2004 03:00:28 +0200 From: Daniel Roesen To: v6ops@ops.ietf.org Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040729030028.A1507@homebase.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040728203508.GA467@Space.Net>; from gert@space.net on Wed, Jul 28, 2004 at 10:35:08PM +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Jul 28, 2004 at 10:35:08PM +0200, Gert Doering wrote: > Besides that, e.f.f.3.ip6.arpa *has* been delegated, so what's this > argument supposed to be about? > > ; <<>> DiG 8.3 <<>> @dns1.icann.org e.f.f.3.ip6.arpa > ;; AUTHORITY SECTION: > e.f.f.3.ip6.arpa. 23h30m IN NS ns3.nic.fr. > e.f.f.3.ip6.arpa. 23h30m IN NS flag.ep.net. > e.f.f.3.ip6.arpa. 23h30m IN NS imag.imag.fr. > e.f.f.3.ip6.arpa. 23h30m IN NS sonata.hexago.com. > > - looks perfectly fine to me. Actually, it's even in a better state than e.f.f.3.ip6.int: Doc-2.2.2: doc e.f.f.3.ip6.arpa. Summary: No errors or warnings issued for e.f.f.3.ip6.arpa. Done testing e.f.f.3.ip6.arpa. Thu Jul 29 02:56:22 CEST 2004 Doc-2.2.2: doc e.f.f.3.ip6.int. Summary: ERRORS found for e.f.f.3.ip6.int. (count: 3) WARNINGS issued for e.f.f.3.ip6.int. (count: 1) Done testing e.f.f.3.ip6.int. Thu Jul 29 02:57:15 CEST 2004 Details: ======== Found 5 NS and 2 glue records for e.f.f.3.ip6.int. @flag.ep.net. (AUTH) Found 4 NS and 2 glue records for e.f.f.3.ip6.int. @ns3.nic.fr. (AUTH) Found 5 NS and 1 glue records for e.f.f.3.ip6.int. @y.ip6.int. (AUTH) Found 5 NS and 2 glue records for e.f.f.3.ip6.int. @z.ip6.int. (AUTH) ERROR: Found 2 diff sets of NS records === from servers authoritative for e.f.f.3.ip6.int. NS list summary for e.f.f.3.ip6.int. from parent (ip6.int.) servers == flag.ep.net. imag.imag.fr. ns3.nic.fr. == sonata.hexago.com. y.ip6.int. z.ip6.int. soa @flag.ep.net. for e.f.f.3.ip6.int. serial: 2002091315 soa @imag.imag.fr. for e.f.f.3.ip6.int. serial: 2002091315 soa @ns3.nic.fr. for e.f.f.3.ip6.int. serial: 2004072801 soa @sonata.hexago.com. for e.f.f.3.ip6.int. serial: 2004072801 soa @y.ip6.int. for e.f.f.3.ip6.int. serial: 2002091315 soa @z.ip6.int. for e.f.f.3.ip6.int. serial: 2002091315 WARN: Found 2 unique SOA serial #'s for e.f.f.3.ip6.int. ERROR: Found 2 unique sets of NS records === from authoritative domain (e.f.f.3.ip6.int.) servers ERROR: NS list from e.f.f.3.ip6.int. authoritative servers does not === match NS list from parent (ip6.int.) servers NS list summary for e.f.f.3.ip6.int. from authoritative servers == flag.ep.net. imag.imag.fr. ns3.nic.fr. == sonata.hexago.com. y.ip6.int. z.ip6.int. Best regards, Daniel From owner-v6ops@ops.ietf.org Wed Jul 28 21:53:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22140 for ; Wed, 28 Jul 2004 21:53:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq05u-0007NM-Me for v6ops-data@psg.com; Thu, 29 Jul 2004 01:52:30 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq05k-0007MS-1F for v6ops@ops.ietf.org; Thu, 29 Jul 2004 01:52:20 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id 3D3C51006; Thu, 29 Jul 2004 03:52:19 +0200 (CEST) Date: Thu, 29 Jul 2004 03:52:19 +0200 From: Daniel Roesen To: v6ops@ops.ietf.org Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040729035219.A4035@homebase.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040729030028.A1507@homebase.cluenet.de>; from dr@cluenet.de on Thu, Jul 29, 2004 at 03:00:28AM +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Jul 29, 2004 at 03:00:28AM +0200, Daniel Roesen wrote: > NS list summary for e.f.f.3.ip6.int. from parent (ip6.int.) servers > == flag.ep.net. imag.imag.fr. ns3.nic.fr. > == sonata.hexago.com. y.ip6.int. z.ip6.int. > soa @flag.ep.net. for e.f.f.3.ip6.int. serial: 2002091315 > soa @imag.imag.fr. for e.f.f.3.ip6.int. serial: 2002091315 > soa @ns3.nic.fr. for e.f.f.3.ip6.int. serial: 2004072801 > soa @sonata.hexago.com. for e.f.f.3.ip6.int. serial: 2004072801 > soa @y.ip6.int. for e.f.f.3.ip6.int. serial: 2002091315 > soa @z.ip6.int. for e.f.f.3.ip6.int. serial: 2002091315 > WARN: Found 2 unique SOA serial #'s for e.f.f.3.ip6.int. BTW... _this_ could be, because sonata.hexago.com. does load their .arpa zone file as .int master zone: $ dig @ns3.nic.fr. e.f.f.3.ip6.int. SOA +norec +short sonata.hexago.com. support.eng.hexago.com. 2004072801 10800 900 259200 86400 $ dig @ns3.nic.fr. e.f.f.3.ip6.arpa. SOA +norec +short sonata.hexago.com. support.eng.hexago.com. 2004072801 10800 900 259200 86400 ==> ns3.nic.fr thinks sonata.hexago.com is master for .int... flag.ep.net disagrees: $ dig @flag.ep.net. e.f.f.3.ip6.int. SOA +norec +short dot.ep.net. hostmaster.ep.net. 2002091315 900 900 4800 9600 So not only does sonata.hexago.com. load the .arpa zone also as .int zone, but also ns3.nic.fr sync .int from sonata.hexago.com as master instead of dot.ep.net. Then again, dot.ep.net doesn't feel authoritative for e.f.f.3.ip6.int at all: $ dig @dot.ep.net. e.f.f.3.ip6.int. SOA +norec ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17674 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 7 Given the fact that e.g. flag.ep.net still is authoritative, and given the very short expiry timeout of the zone, I guess that dot.ep.net isn't the real master anyway... as the zone would have timed out already if it were (master being lame should result in slaves dropping authority after expiry time passed, IIRC). Regards, Daniel From owner-v6ops@ops.ietf.org Thu Jul 29 02:29:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18323 for ; Thu, 29 Jul 2004 02:29:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq4MR-000J32-Dx for v6ops-data@psg.com; Thu, 29 Jul 2004 06:25:51 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq4MG-000J15-Ok for v6ops@ops.ietf.org; Thu, 29 Jul 2004 06:25:40 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i6T6PVJ6023603; Wed, 28 Jul 2004 23:25:32 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i6T6PLJR021959; Thu, 29 Jul 2004 08:25:23 +0200 (MEST) Date: Wed, 28 Jul 2004 07:46:57 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt (fwd) To: Margaret Wasserman Cc: Alain Durand , Pekka Savola , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I've worked with everyone involved here long enough to respect you > and consider you to be reasonable people, so I feel like I may be > missing something here... So, what am I missing? Margaret, The main thing I'm struggling with is that you seem to assert that RFC 3848 solves some transition related problem better than the single v4/v6 toggle in mech-v2. Clearly RFC 3848 has good default rules for various IPv6 addresses (scope, 6to4) and also fits IPv4 address into the same framework which is needed. Thus I'm not arguing that it isn't necessary; I'm arguing that it doesn't solve the hard transition problem related to transition any better than the single v4/v6 preference toggle. All it does it to provide a manual configuration mechanism to try different orderings including different prefix lengths, but that as the only approach to the hard problem would be insane; we would need mechanisms to automatically configure this (e.g., DHCP options) plus some way to make this understandable in the operational world; far too complex in my opinion. The transition problem is hard because what we really want is some way to determine *path* characteristics (such as connectivity, reliability, delay, throughput) yet RFC 3484 is constrained to only look at the IP addresses. We know very well that the path characteristics can't be encoded in the pair of IP addresses, yet given the constraint of the address selection problem this is all RFC 3484 has to work with. So what RFC 3484 seems to allow in practice beyond the single v4/v6 toggle with respect to transition is manual configuration of each node where the relative order of prefixes which do carry some path characteristics (such as the 6to4 prefix) can be different; for example one can have the order - native v6 - IPv4 - 6to4 Also it is possible to manually configure a node to have longer prefixes than ::ffff:0:0/96 to deal with private IPv4 addresses such as ::ffff:10.0.0.0/104 But this doesn't in any way solve the problem of determining the path characteristics that result from using a particular address pair and using that to select the address pair which will work best. In summary I think we must encourage implementation of RFC 3484, because it is the best we currently have, but we shouldn't view it as a pannacea that solves transition related issues of when to use IPv4 vs. IPv6. Erik From owner-v6ops@ops.ietf.org Thu Jul 29 06:31:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01068 for ; Thu, 29 Jul 2004 06:31:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq89x-000JsV-Cu for v6ops-data@psg.com; Thu, 29 Jul 2004 10:29:13 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq89b-000Jp0-DK for v6ops@ops.ietf.org; Thu, 29 Jul 2004 10:28:51 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6TASoWR019514 for ; Thu, 29 Jul 2004 12:28:50 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jul 2004 12:28:49 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PR26A9F7; Thu, 29 Jul 2004 12:28:49 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Jul 2004 12:28:49 +0200 Message-ID: X-Sybari-Trust: 3202d02a f2d37d21 09fd73f5 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org, "'Fred Templin'" , Mohit Talwar , tgleeson@cisco.com, "'Dave Thaler'" Subject: RE: Security issues of Isatap usage in 3GPP networks WAS : RE: mo ving when all the scenarios are not yet complete [RE: DSTM] Date: Thu, 29 Jul 2004 12:28:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 29 Jul 2004 10:28:49.0939 (UTC) FILETIME=[D67D4E30:01C47556] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, Thanks a lot for your comments ! Some comments inline. > > Going through oooooold backlog... Lucky you... > > I think we are pretty close to agreeing that with additional > simplifications to ISATAP spec, and significant assumptions about > deployment (border is secured; ingress filtering is deployed; etc. -- > I don't think they hold in general!) ISATAP's security threats from ND > can be mitigated reasonably well. > I am very glad that we start agreeing on this. So given that this gets to be written down in some consolidated form, then it seems (for now at least) that we may agree that the ND aspects of the direct tunnelling feature of Isatap isn't in itself what constitutes the major showstopper in the particular environments described. > On Fri, 25 Jun 2004, Karen E. Nielsen (AH/TED) wrote: > > Let me try (once more) to address the expressed concerns with > > the direct tunnelling functionality of Isatap. > > > > The problem hinted at, I assume, is the SEND security threats > > as detailed in 3756 (....or are there others ?) > > RFC3756 on ND security threats should provide a relatively complete > picture here. Of course, there are still security issues that might > be independent of the use of ND that come with ISATAP (for example, > see my last comment in this mail). > Agree, what I attempted to address was the concerns with ND and the direct tunnelling feature. > Note that ISATAP's securit model wrt. RFC3756 would be: > > 3. A model where the nodes do not directly trust each other at the > IP layer. This model is considered suitable for e.g., ad hoc > networks. > > .. even if IP spoofing had been prevented, the perimeter secured, etc. > In 3GPP networks yes, in Enterprise networks no. > In addition, direct tunnelling brings up the same link-local > threats in > other protocols, such as MLD. Those are likely subject to > other forms > of threats. > Could be. Do you have other examples besides MLD ? > > In 3GPP networks it should be possible to assume the following: > > > > * Intrasite IPv4 source spoofing isn't possible. > > * Site is Protocol-41 perimeter guarded. > > > > - or it should be acceptable to recommended the above to be > > enforced by the 3GPP operator as a mechanism to prevent > > potential SEND security threats of Isatap. > > (This is not all of the threats, but still..) How realistic > is it that > these are being performed? > Both are readily feasible. The validity in real networks will have to be ascertained, will be back... > Still, the ISATAP spec does not (IMHO) include sufficient guidance > (just two paragraphs in Security Considerations) what exactly > the site > should do, and what happens if that isn't done. This seems too vague > to qualify as a sufficient recommendation. (yes, this has been > brought up in the past, but the revisions of spec seem to remove all > of this kind of analyses.) > > Also, I seem to recall (I'd be happy to be proven wrong..) that some > or even many implementations do not perform the required security > checks (or didn't perform them). That's not good; a tunneling > mechanism where you have less to check and rely on is better because > you don't need to worry about whether a particular implementation has > done a check or not. > In the very nature of the matter, pre-standard Proto-type implementations aren't always fully compliant. Anyway, I don't think that we are talking about a lot of security checks here. > > Given the above, the SEND security threats either do not apply to > > Isatap or can be prevented by careful implementation. In particular > > by implementing the following [...] security check on > Isatap interfaces: > > > > * RA messages are only accepted from PRL routers. > > See responses below. > > > 4.1.1. Link-layer addresses in potential > > Neighbour Cache Entries maintained on Isatap Interfaces > > are not relevant. The Link-layer address (IPv4 address) is deduced > > from IPv6 destination address. An implementation that uses > a different link-layer address > > than the IPv4 address embedded within the IPv6 destination > address isn't compliant. > > Yes, should be OK in the current spec. > > Note however that you still can populate the neighbor cache with crap > even if you don't use it with ISATAP. > > > DAD sub-clause: > > Why you would ever want to implement DAD on an Isatap > Interface I really don't know. > > The uniqueness of the address is inherited from the > uniqueness of the IPv4 address. > > The latter which is ensured by the network (at least in > enterprise and 3GPP networks). > > The spec takes no stance on disabling DAD or not for ISATAP, hence it > could be used. However, if v4 spoofing is prevented and perimeter is > secure, this shouldn't be a problem. > > > 4.1.2: This could be a valid DoS threat. > > This is however only applicable if NUD is performed on the > interface. > > NUD over Isatap only really work if carefully implemented anyway - > > Hence it should be reasonable to assume careful behaviour > of an implementation which performs > > NUD on an Isatap interface. For example by implementing the > following additional validity > > check: > > * Unless sourced from the link-local address of a PRL > router (e.g. for proxy ND) the target address > > of the NS message should be identical to the source address > of the packet. > > > > (We haven't implemented the mentioned check as we > > do not support NUD on isatap interfaces) > > I think the critical question here is whether the node processes NS's > and NA's (and which ones if so) that are sent on the ISATAP link. > That's where I'm concerned -- I'd rather restrict ND messages to just > those we know we need, rather than allow everything and provide checks > which might or might not help. > > Also, looking at the spec, I can't quickly think of why > running NUD on > top of ISATAP links would make sense, as NUD only deletes the > neighbor > cache entry -- but as with ISATAP neighor cache wouldn't be used in > any case, always just the static computation, this doesn't seem too > useful. > > The only cases I could marginally think of would be the use of some > onlink prefixes by PRL routers, but that's marginal as well. > > I guess this could be removed. > > > 4.1.3: Non-applicable if DAD is omitted > > Yes, but more on DAD above. > > > 4.2.1: Non-applicable given that a trust worthy PRL population > > mechanism is deployed. > > Agreed (and if spoofing is not possible). > > > 4.2.2+4.2.3 > > Isn't related to the direct tunnelling functionality of Isatap. > > Is limited by the usage of/and management of > > a trust worthy PRL population mechanism. > > Wrt, 4.2.2, ISATAP should be better off than standard ND because if > the decapsulation checks are implemented, even if the default router > is killed, only communication using the ISATAP addresses is possible, > others will be discarded. > > 4.2.3 is not an ISATAP-specific issue. > > > 4.2.4 > > Non-applicable as Isatap's source address checks combined > with IPv4 source address > > proof implies IPv6 source address proof. I.e. the IPv6 > link-local address of > > a PRL router cannot be spoofed. > > Agreed. > > > 4.2.5+4.2.6+4.2.7: > > Non-applicable given IPv4 source address spoofing prevention, > > if trustworthy PRL population mechanism is deployed. > > Agreed -- significant if's. > > > 4.3.1: > > Non-applicable by IPv4 source address spoofing prevention. > > Yes. > > > 4.3.2 > > Not related to the direct tunnelling functionality of Isatap. > > Not applicable if address resolution is based on static > resolution only. > > This is slightly different with ISATAP. Instead of the router having > to do lots of ND lookups (which time out), the router has to send the > packets to arbitrary IPv4 nodes by static computation. > Right. The static computation step may compare with the tunnel (endpoint) determination step that a stateful tunnel encapsulation mechanism would have to perform. (The difference in between a stateful and a stateless (like Isatap) being that packets only are forwarded encapsulated to IPv4 endpoints of established tunnels, not to arbitrary Ipv4 nodes within the site.) > You could even perform 6to4-like reflection from the ISATAP router. > Assume that the ISATAP addresses would be of the form: > 2001:db8::, and the site used 10.0.0.0/8 for addressing. > > Now you could force the router to send proto-41 packet to 1) every > host inside 10/8, or even 2) every host the user wants e.g., a host > that's outside the ISATAP domain (e.g., 4.5.6.7) -- unless there are > specific blocks at the ISATAP router or at the perimeter to change > this. > > It might be possible to avoid 2) for global addresses if the ISATAP > prefix length is chosen to be sufficiently short and the v4 address > space is contiguous. But that would mean having a prefix length like > /106 which would be disallowed by the IPv6 specs and would probably > have other problems.. Right. Stateful tunnel mechs have some advantages here. /Karen From owner-v6ops@ops.ietf.org Thu Jul 29 15:23:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03682 for ; Thu, 29 Jul 2004 15:23:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqGSP-0007Lu-H4 for v6ops-data@psg.com; Thu, 29 Jul 2004 19:20:49 +0000 Received: from [192.80.55.71] (helo=smtp-mclean.mitre.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqGRq-0007Hv-JQ for v6ops@ops.ietf.org; Thu, 29 Jul 2004 19:20:14 +0000 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.11.6/8.11.6) with ESMTP id i6TJJxH25537 for ; Thu, 29 Jul 2004 15:19:59 -0400 Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-mclean.mitre.org (8.11.6/8.11.6) with ESMTP id i6TJJ6v23774; Thu, 29 Jul 2004 15:19:06 -0400 Received: from mm113749-2k.mitre.org (128.29.22.7) by mailhub1.mitre.org with SMTP id 8635778; Thu, 29 Jul 2004 15:16:53 -0400 From: "schakra" To: "'Pekka Savola'" , Subject: RE: draft agenda for v6ops at IETF60 Date: Thu, 29 Jul 2004 15:16:48 -0400 Message-ID: <000301c475a0$9a73bd30$07161d80@MITRE.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I would like inform this WG that there is a new I-D on the use of IPv6 = Flow Label for traffic engineering, it provides many advantages over MPLS and = ATM but has some issues also. I would like to request the Chairs to allow = me to brief this (5 min.) if it is not too late a request.=20 The draft is available at - http://www.ietf.org/internet-drafts/draft-chakravorty-6lsa-00.txt Thanks, Sham Chakravorty Mitre -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of Pekka Savola Sent: Saturday, July 24, 2004 4:11 PM To: v6ops@ops.ietf.org Subject: Re: draft agenda for v6ops at IETF60 On Wed, 21 Jul 2004, Pekka Savola wrote: > Let's see what can be done.. the scheduling is really tight. If the > slot would be on Friday, I don't think we could use more than 1 - 1.5 > hours out of it in any case.. FYI -- the second session has been rescheduled for Thursday Morning at=20 least for now: THURSDAY, August 5, 2004 0800-1700 IETF Registration - Harbor Island Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions =20 GEN newtrk New IETF Standards Track Discussion WG INT dnsext DNS Extensions WG * INT hip Host Identity Protocol WG OPS v6ops IPv6 Operations WG RTG mpls Multi Protocol Label Switching WG SEC mass Message Authentication Signature Standards BOF TSV tsvwg Transport Area Working Group --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Jul 29 15:23:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03727 for ; Thu, 29 Jul 2004 15:23:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqGTG-0007Rb-Um for v6ops-data@psg.com; Thu, 29 Jul 2004 19:21:42 +0000 Received: from [192.80.55.71] (helo=smtp-mclean.mitre.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqGS4-0007Jg-5D for v6ops@ops.ietf.org; Thu, 29 Jul 2004 19:20:28 +0000 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.11.6/8.11.6) with ESMTP id i6TJKDH26090 for ; Thu, 29 Jul 2004 15:20:13 -0400 Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-mclean.mitre.org (8.11.6/8.11.6) with ESMTP id i6TJJPv24343; Thu, 29 Jul 2004 15:19:25 -0400 Received: from mm113749-2k.mitre.org (128.29.22.7) by mailhub1.mitre.org with SMTP id 8635825; Thu, 29 Jul 2004 15:18:04 -0400 From: "schakra" To: "'Pekka Savola'" , Subject: RE: draft agenda for v6ops at IETF60 Date: Thu, 29 Jul 2004 15:18:03 -0400 Message-ID: <000601c475a0$c51ff6c0$07161d80@MITRE.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I would like inform this WG that there is a new I-D on the use of IPv6 = Flow Label for traffic engineering, it provides many advantages over MPLS and = ATM but has some issues also. I would like to request the Chairs to allow = me to brief this (5 min.) if it is not too late a request.=20 The draft is available at - http://www.ietf.org/internet-drafts/draft-chakravorty-6lsa-00.txt Thanks, Sham Chakravorty Mitre -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of Pekka Savola Sent: Saturday, July 24, 2004 4:11 PM To: v6ops@ops.ietf.org Subject: Re: draft agenda for v6ops at IETF60 On Wed, 21 Jul 2004, Pekka Savola wrote: > Let's see what can be done.. the scheduling is really tight. If the > slot would be on Friday, I don't think we could use more than 1 - 1.5 > hours out of it in any case.. FYI -- the second session has been rescheduled for Thursday Morning at=20 least for now: THURSDAY, August 5, 2004 0800-1700 IETF Registration - Harbor Island Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions =20 GEN newtrk New IETF Standards Track Discussion WG INT dnsext DNS Extensions WG * INT hip Host Identity Protocol WG OPS v6ops IPv6 Operations WG RTG mpls Multi Protocol Label Switching WG SEC mass Message Authentication Signature Standards BOF TSV tsvwg Transport Area Working Group --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Jul 29 16:09:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06202 for ; Thu, 29 Jul 2004 16:09:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqHCB-000Da8-38 for v6ops-data@psg.com; Thu, 29 Jul 2004 20:08:07 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqHC0-000DYM-31 for v6ops@ops.ietf.org; Thu, 29 Jul 2004 20:07:56 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6TK7sk14994 for ; Thu, 29 Jul 2004 23:07:54 +0300 (EET DST) X-Scanned: Thu, 29 Jul 2004 23:07:17 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6TK7H24024853 for ; Thu, 29 Jul 2004 23:07:17 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00dgtZXZ; Thu, 29 Jul 2004 23:07:17 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6TK7Hu18960 for ; Thu, 29 Jul 2004 23:07:17 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Jul 2004 23:07:17 +0300 Received: ESEBE024.noe.nokia.com 172.21.138.125 from 10.162.253.77 10.162.253.77 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost.localdomain by ESEBE024.noe.nokia.com; 29 Jul 2004 23:07:17 +0300 Subject: Proposed way forward with the transition mechanisms From: "Soininen Jonne (Nokia-NET/Helsinki)" To: v6ops@ops.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1091131636.4598.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Thu, 29 Jul 2004 23:07:17 +0300 X-OriginalArrivalTime: 29 Jul 2004 20:07:17.0208 (UTC) FILETIME=[A5A24580:01C475A7] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear v6ops WG, our very own AD, David, sent the WG list mail on the July 1st about the way forward and how he sees the way forward for our little WG. Pekka and I have discussed the topic and found enough consensus among ourselves to propose a way forward for the WG. Of course, you the WG, have to say if you agree with the following approach. We believe that the discussion should be started now on the WG list and then continue it in the face-to-face meeting in San Diego to work the details further. The final decision for the way forward is of course for the WG to make in the mailing list - as always in the IETF. The proposal is to derive the different transition mechanisms from the Scenarios/Analysis documents and identify either the matching, existing mechanism, or identify gap and list possible solutions. We have done our own preliminary analysis. The proposal bellow is for discussion and should not be considered the final list. We would like to have discussion if it really does identify all needed mechanisms and just the needed mechanisms. Bellow there is a list of mechanisms. This the list that Pekka and I put together in quite short time. It may or may not be correct and that's something that we have to discuss on the list and in the face-to-face in the meeting. So, this is just the baseline to start the discussion. In the interest of time, we propose to do this on the list and after running the process document it into a draft. I can do the draft editing myself. In the following, is the analysis of the different scenarios/analysis documents (in no particular order). 3gpp-analysis: SIP v4/v6 transition mechanism Zero-configured IPv6-over-IPv4 tunneling mechanism unmanaged: Teredo* Configured tunneling through NAT IPv4 over IPv6 tunneling mechanism ISP: BGP-tunneling* Tunnel server/broker Enterprise: Analysis not done. Summary: Teredo* BGP-Tunneling* SIP v4/v6 transition mechanism - No candidates Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP possible candidates Configured tunneling through NATs - No (direct) candidates, but Tunnel Server/Broker also addresses this Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP, Ayiya, STEP, ISATAP possible candidates. IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible candidates; many tunnel server/broker approaches also address this. (* Teredo and BGP-tunneling are already moving forward) The suggestion is to go forward with Teredo/BGP-Tunneling immediately, work on SIP v4/v6 transition in SIP WG(s), and find the correct place for finding suitable solution for the following: a) zero-configuration both at the client or the server, b) IPv6-over-IPv4 tunnels (with NAT traversal support), and c) IPv4-over-IPv6 tunnels This work should take use of draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. Cheers, Jonne & Pekka - the chairs. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Thu Jul 29 16:23:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06975 for ; Thu, 29 Jul 2004 16:23:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqHQC-000FFw-DT for v6ops-data@psg.com; Thu, 29 Jul 2004 20:22:36 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqHQ1-000FEg-7t for v6ops@ops.ietf.org; Thu, 29 Jul 2004 20:22:25 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6TKMNm17275 for ; Thu, 29 Jul 2004 23:22:24 +0300 (EET DST) X-Scanned: Thu, 29 Jul 2004 23:22:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6TKMCE6025318 for ; Thu, 29 Jul 2004 23:22:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 007KlW4t; Thu, 29 Jul 2004 23:22:12 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6TKMCu28773 for ; Thu, 29 Jul 2004 23:22:12 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Jul 2004 23:22:11 +0300 Received: ESEBE024.noe.nokia.com 172.21.138.125 from 10.162.253.77 10.162.253.77 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost.localdomain by ESEBE024.noe.nokia.com; 29 Jul 2004 23:22:12 +0300 Subject: Re: Proposed way forward with the transition mechanisms From: "Soininen Jonne (Nokia-NET/Helsinki)" To: v6ops@ops.ietf.org In-Reply-To: <1091131636.4598.17.camel@localhost.localdomain> References: <1091131636.4598.17.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1091132531.4598.28.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Thu, 29 Jul 2004 23:22:12 +0300 X-OriginalArrivalTime: 29 Jul 2004 20:22:11.0556 (UTC) FILETIME=[BAB4F240:01C475A9] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello everybody, (chair hat off - this is totally my personal view) when writing the proposal for the WG, Pekka and I noticed that we have different view on some issues. In one topic especially, we seemed to have pretty opposing views. This topic is the role of ISATAP. I do personally believe that ISATAP is pointed as the most promising solution for automatic tunneling in the 3GPP analysis document and thus, should be listed as a solution to be standardized. I thought even that there was at least some support in the WG for ISATAP and it had been seen also at least somewhat applicable for enterprise scenarios. This is of course difficult to say as the enterprise analysis document is not existing, yet. However, I would hereby propose as an individual the addition of ISATAP in the list of mechanisms that should be standardized on standards track. (Of course, there has to be consensus in the WG to do that.) I would like to hear what other people feel about this! (Pekka's view I, at least, know already.) Cheers, Jonne. On Thu, 2004-07-29 at 23:07, ext Soininen Jonne (Nokia-NET/Helsinki) wrote: > Dear v6ops WG, > > our very own AD, David, sent the WG list mail on the July 1st about the > way forward and how he sees the way forward for our little WG. Pekka and > I have discussed the topic and found enough consensus among ourselves to > propose a way forward for the WG. Of course, you the WG, have to say if > you agree with the following approach. We believe that the discussion > should be started now on the WG list and then continue it in the > face-to-face meeting in San Diego to work the details further. The final > decision for the way forward is of course for the WG to make in the > mailing list - as always in the IETF. > > The proposal is to derive the different transition mechanisms from the > Scenarios/Analysis documents and identify either the matching, existing > mechanism, or identify gap and list possible solutions. We have done our > own preliminary analysis. The proposal bellow is for discussion and > should not be considered the final list. We would like to have > discussion if it really does identify all needed mechanisms and just the > needed mechanisms. > > Bellow there is a list of mechanisms. This the list that Pekka and I put > together in quite short time. It may or may not be correct and that's > something that we have to discuss on the list and in the face-to-face in > the meeting. So, this is just the baseline to start the discussion. > > In the interest of time, we propose to do this on the list and after > running the process document it into a draft. I can do the draft editing > myself. > > In the following, is the analysis of the different scenarios/analysis > documents (in no particular order). > > 3gpp-analysis: > SIP v4/v6 transition mechanism > Zero-configured IPv6-over-IPv4 tunneling mechanism > > unmanaged: > Teredo* > Configured tunneling through NAT > IPv4 over IPv6 tunneling mechanism > > ISP: > BGP-tunneling* > Tunnel server/broker > > Enterprise: > Analysis not done. > > Summary: > Teredo* > BGP-Tunneling* > SIP v4/v6 transition mechanism - No candidates > Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP possible candidates > Configured tunneling through NATs - No (direct) candidates, but Tunnel > Server/Broker also addresses this > Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP, Ayiya, STEP, > ISATAP possible candidates. > IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible candidates; many > tunnel server/broker approaches also address this. > > (* Teredo and BGP-tunneling are already moving forward) > > The suggestion is to go forward with Teredo/BGP-Tunneling immediately, > work on SIP v4/v6 transition in SIP WG(s), and find the correct place > for finding suitable solution for the following: > > a) zero-configuration both at the client or the server, > b) IPv6-over-IPv4 tunnels (with NAT traversal support), and > c) IPv4-over-IPv6 tunnels > > This work should take use of > draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. > > Cheers, > > Jonne & Pekka - the chairs. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Thu Jul 29 18:24:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13976 for ; Thu, 29 Jul 2004 18:24:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqJHk-0003ex-MJ for v6ops-data@psg.com; Thu, 29 Jul 2004 22:22:00 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqJHZ-0003cj-Iu for v6ops@ops.ietf.org; Thu, 29 Jul 2004 22:21:49 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i6TMLmnE010507 for ; Thu, 29 Jul 2004 23:21:48 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA05587 for ; Thu, 29 Jul 2004 23:21:45 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i6TMLjx21862 for v6ops@ops.ietf.org; Thu, 29 Jul 2004 23:21:45 +0100 Date: Thu, 29 Jul 2004 23:21:45 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Proposed way forward with the transition mechanisms Message-ID: <20040729222144.GB21345@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <1091131636.4598.17.camel@localhost.localdomain> <1091132531.4598.28.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1091132531.4598.28.camel@localhost.localdomain> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Jul 29, 2004 at 11:22:12PM +0300, Soininen Jonne (Nokia-NET/Helsinki) wrote: > > I do personally believe that ISATAP is pointed as the most promising > solution for automatic tunneling in the 3GPP analysis document and thus, > should be listed as a solution to be standardized. Our own experience (non-small enterprise) is that we prefer to deploy a structured (configured) transition mechanism - in our case VLAN-based IPv6 propogation - rather than an unstructured (automatic) method. So we don't see any need for ISATP in our particular scenario. However, I can see why some others see some attraction. > I would like to hear what other people feel about this! (Pekka's view I, > at least, know already.) I think also maybe 6to4 relays should be considered for ISP analysis, where at the moment brokers and 6PE are cited. In the case of European NRENs, 66% have a 6to4 relay, less than 33% a broker, aimed at local NREN communities. I also believe an enterprise (university, in our case) can offer a broker or 6to4 relay in the absence of the NREN doing so, or in the case of a staff or student users in a home network, their home network ISP not offering one (because the RTT from the national commercial network to the national academic network will be low). What's the agenda again for v6ops? How much time do we have for this minor little topic? ;) Tim From owner-v6ops@ops.ietf.org Thu Jul 29 18:31:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14353 for ; Thu, 29 Jul 2004 18:31:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqJQD-0004Zz-7w for v6ops-data@psg.com; Thu, 29 Jul 2004 22:30:45 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqJQ2-0004Z5-Bm for v6ops@ops.ietf.org; Thu, 29 Jul 2004 22:30:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6TMUQq27950; Fri, 30 Jul 2004 01:30:26 +0300 Date: Fri, 30 Jul 2004 01:30:26 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: Proposed way forward with the transition mechanisms In-Reply-To: <20040729222144.GB21345@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 29 Jul 2004, Tim Chown wrote: > > I would like to hear what other people feel about this! (Pekka's view I, > > at least, know already.) > > I think also maybe 6to4 relays should be considered for ISP analysis, > where at the moment brokers and 6PE are cited. In the case of European > NRENs, 66% have a 6to4 relay, less than 33% a broker, aimed at local > NREN communities. The document does mention them, but kind of takes it for given as it's already on the table: The ISP may offer opportunistic services, mainly a 6to4 relay, especially as a test when no actual service is offered yet. At the later phases, ISPs might also deploy 6to4 relays and Teredo servers (or similar) to optimize their customers' connectivity to 6to4 and Teredo nodes. > What's the agenda again for v6ops? How much time do we have for this > minor little topic? ;) The agenda is available at http://www.ietf.org/ietf/04aug/v6ops.txt. There will be sufficient time for this :-) (If folks in general have specific ideas how you think we should discuss these topics in the meeting, feel free to drop me and Jonne a note off-list..) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Jul 29 18:40:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14779 for ; Thu, 29 Jul 2004 18:40:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqJZE-0005b4-JG for v6ops-data@psg.com; Thu, 29 Jul 2004 22:40:04 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqJZ3-0005Yp-0Z; Thu, 29 Jul 2004 22:39:53 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6TMdpAh016889; Fri, 30 Jul 2004 00:39:51 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jul 2004 00:39:51 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Jul 2004 00:39:51 +0200 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639D05@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (AL/EAB)" To: "'Soininen Jonne (Nokia-NET/Helsinki) '" , "'owner-v6ops@ops.ietf.org '" , "'v6ops@ops.ietf.org '" Subject: RE: Proposed way forward with the transition mechanisms Date: Fri, 30 Jul 2004 00:39:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Scanned: Thu, 29 Jul 2004 23:22:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE In-Reply-To: Thu, 29 Jul 2004 23:22:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE References: Thu, 29 Jul 2004 23:22:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE X-Mailer: Thu, 29 Jul 2004 23:22:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE X-OriginalArrivalTime: Thu, 29 Jul 2004 23:22:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I agree with Jonne. ISATAP is the most promising solution for 3gpp tunnelling so I think it should be listed amongst those that will proceed onto standards track. Actually I thought there had been enough consensus on the list for ISATAP and assumed it was on that list already. /Karim -----Original Message----- From: owner-v6ops@ops.ietf.org To: v6ops@ops.ietf.org Sent: 7/29/2004 10:22 PM Subject: Re: Proposed way forward with the transition mechanisms Hello everybody, (chair hat off - this is totally my personal view) when writing the proposal for the WG, Pekka and I noticed that we have different view on some issues. In one topic especially, we seemed to have pretty opposing views. This topic is the role of ISATAP. I do personally believe that ISATAP is pointed as the most promising solution for automatic tunneling in the 3GPP analysis document and thus, should be listed as a solution to be standardized. I thought even that there was at least some support in the WG for ISATAP and it had been seen also at least somewhat applicable for enterprise scenarios. This is of course difficult to say as the enterprise analysis document is not existing, yet. However, I would hereby propose as an individual the addition of ISATAP in the list of mechanisms that should be standardized on standards track. (Of course, there has to be consensus in the WG to do that.) I would like to hear what other people feel about this! (Pekka's view I, at least, know already.) Cheers, Jonne. On Thu, 2004-07-29 at 23:07, ext Soininen Jonne (Nokia-NET/Helsinki) wrote: > Dear v6ops WG, > > our very own AD, David, sent the WG list mail on the July 1st about the > way forward and how he sees the way forward for our little WG. Pekka and > I have discussed the topic and found enough consensus among ourselves to > propose a way forward for the WG. Of course, you the WG, have to say if > you agree with the following approach. We believe that the discussion > should be started now on the WG list and then continue it in the > face-to-face meeting in San Diego to work the details further. The final > decision for the way forward is of course for the WG to make in the > mailing list - as always in the IETF. > > The proposal is to derive the different transition mechanisms from the > Scenarios/Analysis documents and identify either the matching, existing > mechanism, or identify gap and list possible solutions. We have done our > own preliminary analysis. The proposal bellow is for discussion and > should not be considered the final list. We would like to have > discussion if it really does identify all needed mechanisms and just the > needed mechanisms. > > Bellow there is a list of mechanisms. This the list that Pekka and I put > together in quite short time. It may or may not be correct and that's > something that we have to discuss on the list and in the face-to-face in > the meeting. So, this is just the baseline to start the discussion. > > In the interest of time, we propose to do this on the list and after > running the process document it into a draft. I can do the draft editing > myself. > > In the following, is the analysis of the different scenarios/analysis > documents (in no particular order). > > 3gpp-analysis: > SIP v4/v6 transition mechanism > Zero-configured IPv6-over-IPv4 tunneling mechanism > > unmanaged: > Teredo* > Configured tunneling through NAT > IPv4 over IPv6 tunneling mechanism > > ISP: > BGP-tunneling* > Tunnel server/broker > > Enterprise: > Analysis not done. > > Summary: > Teredo* > BGP-Tunneling* > SIP v4/v6 transition mechanism - No candidates > Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP possible candidates > Configured tunneling through NATs - No (direct) candidates, but Tunnel > Server/Broker also addresses this > Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP, Ayiya, STEP, > ISATAP possible candidates. > IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible candidates; many > tunnel server/broker approaches also address this. > > (* Teredo and BGP-tunneling are already moving forward) > > The suggestion is to go forward with Teredo/BGP-Tunneling immediately, > work on SIP v4/v6 transition in SIP WG(s), and find the correct place > for finding suitable solution for the following: > > a) zero-configuration both at the client or the server, > b) IPv6-over-IPv4 tunnels (with NAT traversal support), and > c) IPv4-over-IPv6 tunnels > > This work should take use of > draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. > > Cheers, > > Jonne & Pekka - the chairs. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Thu Jul 29 19:10:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16388 for ; Thu, 29 Jul 2004 19:10:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqK1I-0009LG-3o for v6ops-data@psg.com; Thu, 29 Jul 2004 23:09:04 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqK0z-0009IF-4S for v6ops@ops.ietf.org; Thu, 29 Jul 2004 23:08:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6TN8gg28776; Fri, 30 Jul 2004 02:08:42 +0300 Date: Fri, 30 Jul 2004 02:08:42 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (AL/EAB)" cc: "'Soininen Jonne (Nokia-NET/Helsinki) '" , "'v6ops@ops.ietf.org '" Subject: RE: Proposed way forward with the transition mechanisms In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639D05@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (note -- please don't copy v6ops-owner@) On Fri, 30 Jul 2004, Karim El-Malki (AL/EAB) wrote: > I agree with Jonne. ISATAP is the most promising solution for 3gpp > tunnelling so I think it should be listed amongst those that will > proceed onto standards track. Actually I thought there had been > enough consensus on the list for ISATAP and assumed it was on that > list already. /Karim FWIW, my own personal opinion... I do not see a strong technical reason for ISATAP, especially in 3GPP. Any relatively simple tunneling solution which requires no user interaction to set up should be sufficient there. The only reasons I can think of why folks want to go for ISATAP are: 1) some have already started deploying it or piloted it, and may even have already committed to it -- meaning if they care about the IETF, their only option is to push for it as hard as they can. 2) it's already "out there", requiring a smaller amount of specification etc. than other mechanisms. I personally believe that we could make do with one additional mechanism, a tunnel server, developed based on the assisted tunneling requirements. If there is sufficient commitment from the people, achieving that, even in the short term, should not be too challenging. A significant goal has been to minimize the number of mechanisms -- "Less is More"; this was also stated by the ADs at IETF59 as well. Producing just one slightly more generic mechanism could help us to obviate the need for an additional mechanism -- and thus not going for ISATAP in 3GPP would seem useful at least for the reduction of the required mechanisms. And remember, ISATAP -- as implemented -- is going to be published as Experimental RFC even if it didn't go for Standards Track -- it's already in the RFC editor's queue. That's sufficient for documenting a protocol and creating interoperable implementations. There's no need for Standards Track (just) for that. Standards Track should IMHO mean just those mechanisms we really, really need -- the "IETF seal of approval and review". IMHO, ISATAP doesn't seem to fulfill that criterium. That is why I must oppose adding ISATAP to the list of standardized mechanisms at this point. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Jul 29 19:46:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18648 for ; Thu, 29 Jul 2004 19:46:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqKZz-000EPC-EC for v6ops-data@psg.com; Thu, 29 Jul 2004 23:44:55 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqKZd-000EMr-QR for v6ops@ops.ietf.org; Thu, 29 Jul 2004 23:44:34 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6TNiWAh022818 for ; Fri, 30 Jul 2004 01:44:32 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jul 2004 01:44:32 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Jul 2004 01:44:32 +0200 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639D08@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (AL/EAB)" To: "'Pekka Savola '" Cc: "''Soininen Jonne (Nokia-NET/Helsinki) ' '" , "''v6ops@ops.ietf.org ' '" Subject: RE: Proposed way forward with the transition mechanisms Date: Fri, 30 Jul 2004 01:44:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639D05@ESEALNT442.al.sw.ericsson.se> Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 29 Jul 2004 23:44:32.0612 (UTC) FILETIME=[FF571240:01C475C5] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Isn't there a reason number 3 you forgot about? 3) It is an appropriate solution for the 3GPP scenario. We can't all either be conspiring to push our solution (your reason 1) or plain stupid (your reason 2: we don't know why we want ISATAP but it takes little work to complete it). I haven't heard one valid technical reason why ISATAP doesn't make sense in a 3gpp network. So I can't see how you reach your conclusion nor a reason why ISATAP should go experimental instead of standards track. /Karim -----Original Message----- From: Pekka Savola To: Karim El-Malki (AL/EAB) Cc: 'Soininen Jonne (Nokia-NET/Helsinki) '; 'v6ops@ops.ietf.org ' Sent: 7/30/2004 1:08 AM Subject: RE: Proposed way forward with the transition mechanisms (note -- please don't copy v6ops-owner@) On Fri, 30 Jul 2004, Karim El-Malki (AL/EAB) wrote: > I agree with Jonne. ISATAP is the most promising solution for 3gpp > tunnelling so I think it should be listed amongst those that will > proceed onto standards track. Actually I thought there had been > enough consensus on the list for ISATAP and assumed it was on that > list already. /Karim FWIW, my own personal opinion... I do not see a strong technical reason for ISATAP, especially in 3GPP. Any relatively simple tunneling solution which requires no user interaction to set up should be sufficient there. The only reasons I can think of why folks want to go for ISATAP are: 1) some have already started deploying it or piloted it, and may even have already committed to it -- meaning if they care about the IETF, their only option is to push for it as hard as they can. 2) it's already "out there", requiring a smaller amount of specification etc. than other mechanisms. I personally believe that we could make do with one additional mechanism, a tunnel server, developed based on the assisted tunneling requirements. If there is sufficient commitment from the people, achieving that, even in the short term, should not be too challenging. A significant goal has been to minimize the number of mechanisms -- "Less is More"; this was also stated by the ADs at IETF59 as well. Producing just one slightly more generic mechanism could help us to obviate the need for an additional mechanism -- and thus not going for ISATAP in 3GPP would seem useful at least for the reduction of the required mechanisms. And remember, ISATAP -- as implemented -- is going to be published as Experimental RFC even if it didn't go for Standards Track -- it's already in the RFC editor's queue. That's sufficient for documenting a protocol and creating interoperable implementations. There's no need for Standards Track (just) for that. Standards Track should IMHO mean just those mechanisms we really, really need -- the "IETF seal of approval and review". IMHO, ISATAP doesn't seem to fulfill that criterium. That is why I must oppose adding ISATAP to the list of standardized mechanisms at this point. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Jul 29 22:59:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27335 for ; Thu, 29 Jul 2004 22:59:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqNZO-000BA1-RU for v6ops-data@psg.com; Fri, 30 Jul 2004 02:56:30 +0000 Received: from [159.226.39.7] (helo=ict.ac.cn) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BqNZD-000B7l-D7 for v6ops@ops.ietf.org; Fri, 30 Jul 2004 02:56:19 +0000 Received: (qmail 16903 invoked by uid 507); 30 Jul 2004 02:51:05 -0000 Received: from unknown (HELO ThinkPadX31) (liumin@159.226.39.104) by ict.ac.cn with SMTP; 30 Jul 2004 02:51:05 -0000 From: "Liu Min" To: "'Pekka Savola'" , Subject: RE: draft agenda for v6ops at IETF60 Date: Fri, 30 Jul 2004 10:56:03 +0800 Message-ID: <000601c475e0$c39ac240$4b74a8c0@ThinkPadX31> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I find the first session of v6ops was removed from the draft agenda of = the IETF60. What it means? =20 Best Wishes, =20 Liu Min =20 Institute of Computing Technology Chinese Academy of Sciences Tel: (86-10) 6256 5533-9240=20 E-mail: liumin@ict.ac.cn > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf > Of Pekka Savola > Sent: Sunday, July 25, 2004 4:11 AM > To: v6ops@ops.ietf.org > Subject: Re: draft agenda for v6ops at IETF60 >=20 > On Wed, 21 Jul 2004, Pekka Savola wrote: > > Let's see what can be done.. the scheduling is really tight. If the > > slot would be on Friday, I don't think we could use more than 1 - = 1.5 > > hours out of it in any case.. >=20 > FYI -- the second session has been rescheduled for Thursday Morning at > least for now: >=20 > THURSDAY, August 5, 2004 > 0800-1700 IETF Registration - Harbor Island Foyer > 0800-0900 Continental Breakfast - Harbor Island Foyer > 0900-1130 Morning Sessions > GEN newtrk New IETF Standards Track Discussion WG > INT dnsext DNS Extensions WG * > INT hip Host Identity Protocol WG > OPS v6ops IPv6 Operations WG > RTG mpls Multi Protocol Label Switching WG > SEC mass Message Authentication Signature Standards BOF > TSV tsvwg Transport Area Working Group >=20 >=20 > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 From owner-v6ops@ops.ietf.org Thu Jul 29 23:07:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27896 for ; Thu, 29 Jul 2004 23:07:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqNju-000Co4-5k for v6ops-data@psg.com; Fri, 30 Jul 2004 03:07:22 +0000 Received: from [159.226.39.7] (helo=ict.ac.cn) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BqNjj-000Cn1-94 for v6ops@ops.ietf.org; Fri, 30 Jul 2004 03:07:11 +0000 Received: (qmail 22024 invoked by uid 507); 30 Jul 2004 03:02:02 -0000 Received: from unknown (HELO ThinkPadX31) (liumin@159.226.39.104) by ict.ac.cn with SMTP; 30 Jul 2004 03:02:02 -0000 From: "Liu Min" To: "'Pekka Savola'" , Subject: RE: draft agenda for v6ops at IETF60 Date: Fri, 30 Jul 2004 11:06:59 +0800 Message-ID: <000701c475e2$4a5fd670$4b74a8c0@ThinkPadX31> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable The first session is on the text version of agenda, but is not on the = html version. Which one is the correct one? =20 Best Wishes, =20 Liu Min =20 Institute of Computing Technology Chinese Academy of Sciences Tel: (86-10) 6256 5533-9240=20 E-mail: liumin@ict.ac.cn > -----Original Message----- > From: Liu Min [mailto:liumin@ict.ac.cn] > Sent: Friday, July 30, 2004 10:56 AM > To: 'Pekka Savola'; 'v6ops@ops.ietf.org' > Subject: RE: draft agenda for v6ops at IETF60 >=20 > I find the first session of v6ops was removed from the draft agenda of = the > IETF60. > What it means? >=20 >=20 > Best Wishes, >=20 >=20 > Liu Min >=20 > Institute of Computing Technology > Chinese Academy of Sciences > Tel: (86-10) 6256 5533-9240 > E-mail: liumin@ict.ac.cn >=20 >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > > Of Pekka Savola > > Sent: Sunday, July 25, 2004 4:11 AM > > To: v6ops@ops.ietf.org > > Subject: Re: draft agenda for v6ops at IETF60 > > > > On Wed, 21 Jul 2004, Pekka Savola wrote: > > > Let's see what can be done.. the scheduling is really tight. If = the > > > slot would be on Friday, I don't think we could use more than 1 - = 1.5 > > > hours out of it in any case.. > > > > FYI -- the second session has been rescheduled for Thursday Morning = at > > least for now: > > > > THURSDAY, August 5, 2004 > > 0800-1700 IETF Registration - Harbor Island Foyer > > 0800-0900 Continental Breakfast - Harbor Island Foyer > > 0900-1130 Morning Sessions > > GEN newtrk New IETF Standards Track Discussion WG > > INT dnsext DNS Extensions WG * > > INT hip Host Identity Protocol WG > > OPS v6ops IPv6 Operations WG > > RTG mpls Multi Protocol Label Switching WG > > SEC mass Message Authentication Signature Standards BOF > > TSV tsvwg Transport Area Working Group > > > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > From owner-v6ops@ops.ietf.org Fri Jul 30 00:34:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02163 for ; Fri, 30 Jul 2004 00:34:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqP4x-000LYn-TH for v6ops-data@psg.com; Fri, 30 Jul 2004 04:33:11 +0000 Received: from [63.103.94.23] (helo=ftmailgfi.HQ.Flarion.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqP4n-000LXZ-4o for v6ops@ops.ietf.org; Fri, 30 Jul 2004 04:33:01 +0000 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Jul 2004 00:32:58 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed way forward with the transition mechanisms Date: Fri, 30 Jul 2004 00:32:58 -0400 Message-ID: Thread-Topic: Proposed way forward with the transition mechanisms Thread-Index: AcR1qtAs81bismxlRBWEF9f5TbUFmwAQXstQ From: "Soliman Hesham" To: "Soininen Jonne (Nokia-NET/Helsinki)" , X-OriginalArrivalTime: 30 Jul 2004 04:32:58.0391 (UTC) FILETIME=[4A636270:01C475EE] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jonne/all,=20 I continue to think that ISATAP is a good solution for the cellular environment and is a=20 good candidate for 3GPP.=20 To preempt some of the discussion I'll be specific, I'm talking about: - host to router model - Assuming ingress filtering - Assuming authentication in the network. I think it should go to standards track. I won't be in the meeting but if there is a vote count=20 me in!=20 Hesham > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Soininen Jonne (Nokia-NET/Helsinki) > Sent: Thursday, July 29, 2004 4:22 PM > To: v6ops@ops.ietf.org > Subject: Re: Proposed way forward with the transition mechanisms >=20 >=20 > Hello everybody, > (chair hat off - this is totally my personal view) >=20 > when writing the proposal for the WG, Pekka and I noticed=20 > that we have > different view on some issues. In one topic especially, we seemed to > have pretty opposing views. This topic is the role of ISATAP.=20 >=20 > I do personally believe that ISATAP is pointed as the most promising > solution for automatic tunneling in the 3GPP analysis=20 > document and thus, > should be listed as a solution to be standardized.=20 >=20 > I thought even that there was at least some support in the=20 > WG for ISATAP > and it had been seen also at least somewhat applicable for enterprise > scenarios. This is of course difficult to say as the=20 > enterprise analysis > document is not existing, yet.=20 >=20 > However, I would hereby propose as an individual the=20 > addition of ISATAP > in the list of mechanisms that should be standardized on standards > track. (Of course, there has to be consensus in the WG to do that.) >=20 > I would like to hear what other people feel about this!=20 > (Pekka's view I, > at least, know already.) >=20 > Cheers, >=20 > Jonne. > On Thu, 2004-07-29 at 23:07, ext Soininen Jonne (Nokia-NET/Helsinki) > wrote: > > Dear v6ops WG, > >=20 > > our very own AD, David, sent the WG list mail on the July=20 > 1st about the > > way forward and how he sees the way forward for our little=20 > WG. Pekka and > > I have discussed the topic and found enough consensus=20 > among ourselves to > > propose a way forward for the WG. Of course, you the WG,=20 > have to say if > > you agree with the following approach. We believe that the=20 > discussion > > should be started now on the WG list and then continue it in the > > face-to-face meeting in San Diego to work the details=20 > further. The final > > decision for the way forward is of course for the WG to make in the > > mailing list - as always in the IETF. > >=20 > > The proposal is to derive the different transition=20 > mechanisms from the > > Scenarios/Analysis documents and identify either the=20 > matching, existing > > mechanism, or identify gap and list possible solutions. We=20 > have done our > > own preliminary analysis. The proposal bellow is for discussion and > > should not be considered the final list. We would like to have > > discussion if it really does identify all needed=20 > mechanisms and just the > > needed mechanisms.=20 > >=20 > > Bellow there is a list of mechanisms. This the list that=20 > Pekka and I put > > together in quite short time. It may or may not be correct=20 > and that's > > something that we have to discuss on the list and in the=20 > face-to-face in > > the meeting. So, this is just the baseline to start the discussion. > >=20 > > In the interest of time, we propose to do this on the list=20 > and after > > running the process document it into a draft. I can do the=20 > draft editing > > myself. > >=20 > > In the following, is the analysis of the different=20 > scenarios/analysis > > documents (in no particular order). > >=20 > > 3gpp-analysis: > > SIP v4/v6 transition mechanism > > Zero-configured IPv6-over-IPv4 tunneling mechanism > >=20 > > unmanaged: > > Teredo* > > Configured tunneling through NAT > > IPv4 over IPv6 tunneling mechanism > >=20 > > ISP: > > BGP-tunneling* > > Tunnel server/broker > >=20 > > Enterprise: > > Analysis not done. > >=20 > > Summary: > > Teredo* > > BGP-Tunneling* > > SIP v4/v6 transition mechanism - No candidates > > Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP=20 > possible candidates > > Configured tunneling through NATs - No (direct)=20 > candidates, but Tunnel > > Server/Broker also addresses this > > Zero-configured IPv6-over-IPv4 tunneling mechanism -=20 > TSP, Ayiya, STEP, > > ISATAP possible candidates. > > IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible=20 > candidates; many > > tunnel server/broker approaches also address this. > >=20 > > (* Teredo and BGP-tunneling are already moving forward) > >=20 > > The suggestion is to go forward with Teredo/BGP-Tunneling=20 > immediately, > > work on SIP v4/v6 transition in SIP WG(s), and find the=20 > correct place > > for finding suitable solution for the following: > > =20 > > a) zero-configuration both at the client or the server, > > b) IPv6-over-IPv4 tunnels (with NAT traversal support), and > > c) IPv4-over-IPv6 tunnels > >=20 > > This work should take use of=20 > > draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. > >=20 > > Cheers, > >=20 > > Jonne & Pekka - the chairs. > --=20 > Jonne Soininen > Nokia >=20 > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=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 From owner-v6ops@ops.ietf.org Fri Jul 30 00:36:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02216 for ; Fri, 30 Jul 2004 00:36:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqP7W-000Lte-H8 for v6ops-data@psg.com; Fri, 30 Jul 2004 04:35:50 +0000 Received: from [63.103.94.23] (helo=ftmailgfi.HQ.Flarion.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqP7L-000LsT-Vz for v6ops@ops.ietf.org; Fri, 30 Jul 2004 04:35:40 +0000 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Jul 2004 00:35:39 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed way forward with the transition mechanisms Date: Fri, 30 Jul 2004 00:35:38 -0400 Message-ID: Thread-Topic: Proposed way forward with the transition mechanisms Thread-Index: AcR1whaEjKgQWBEYRbCxTf2CJZftSgAKpw/g From: "Soliman Hesham" To: "Pekka Savola" , "Karim El-Malki (AL/EAB)" CC: "Soininen Jonne (Nokia-NET/Helsinki) " , X-OriginalArrivalTime: 30 Jul 2004 04:35:39.0378 (UTC) FILETIME=[AA580D20:01C475EE] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > And remember, ISATAP -- as implemented -- is going to be published as > Experimental RFC even if it didn't go for Standards Track=20 =3D> "As implemented"? or do you mean "as documented"? I hope we're not deciding this based on what we think implementations will do. -- it's > already in the RFC editor's queue. =20 =3D> That's a mistake I think.=20 Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=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 From owner-v6ops@ops.ietf.org Fri Jul 30 01:23:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04011 for ; Fri, 30 Jul 2004 01:23:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqPqJ-0001Pz-Sy for v6ops-data@psg.com; Fri, 30 Jul 2004 05:22:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqPq9-0001Ou-0C for v6ops@ops.ietf.org; Fri, 30 Jul 2004 05:21:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6U5LpK03568; Fri, 30 Jul 2004 08:21:51 +0300 Date: Fri, 30 Jul 2004 08:21:51 +0300 (EEST) From: Pekka Savola To: Liu Min cc: v6ops@ops.ietf.org Subject: RE: draft agenda for v6ops at IETF60 In-Reply-To: <000701c475e2$4a5fd670$4b74a8c0@ThinkPadX31> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 30 Jul 2004, Liu Min wrote: > The first session is on the text version of agenda, but is not on > the html version. Which one is the correct one? Text. I've requested the HTML version to be fixed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jul 30 01:24:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04068 for ; Fri, 30 Jul 2004 01:24:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqPsS-0001gn-7y for v6ops-data@psg.com; Fri, 30 Jul 2004 05:24:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqPrV-0001Yr-9S for v6ops@ops.ietf.org; Fri, 30 Jul 2004 05:23:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6U5NHL03608; Fri, 30 Jul 2004 08:23:17 +0300 Date: Fri, 30 Jul 2004 08:23:17 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: "Karim El-Malki (AL/EAB)" , "Soininen Jonne (Nokia-NET/Helsinki) " , Subject: RE: Proposed way forward with the transition mechanisms In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 30 Jul 2004, Soliman Hesham wrote: > > And remember, ISATAP -- as implemented -- is going to be published as > > Experimental RFC even if it didn't go for Standards Track > > => "As implemented"? or do you mean "as documented"? I hope > we're not deciding this based on what we think implementations > will do. The ISATAP spec, submitted to the RFC-editor, is supposed to describe ISATAP as it has been implemented by the people. If that isn't correct, the spec needs to be fixed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jul 30 01:43:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04772 for ; Fri, 30 Jul 2004 01:43:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqQAP-0003tP-Vg for v6ops-data@psg.com; Fri, 30 Jul 2004 05:42:53 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqQAF-0003qM-C6 for v6ops@ops.ietf.org; Fri, 30 Jul 2004 05:42:43 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6U5eM53000445 for ; Thu, 29 Jul 2004 23:40:22 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1N006BTH76HS@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 29 Jul 2004 23:42:42 -0600 (MDT) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1N00KFLH743Q@mail.sun.net> for v6ops@ops.ietf.org; Thu, 29 Jul 2004 23:42:41 -0600 (MDT) Date: Thu, 29 Jul 2004 22:42:39 -0700 From: Alain Durand Subject: Re: Proposed way forward with the transition mechanisms In-reply-to: <37FB7AA6F5F9814FB634A7BF4C35A6F5639D05@ESEALNT442.al.sw.ericsson.se> To: "Karim El-Malki (AL/EAB)" Cc: "'Soininen Jonne '" (Nokia-NET/Helsinki), "'v6ops@ops.ietf.org '" Message-id: <44F70B12-E1EB-11D8-AFD7-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <37FB7AA6F5F9814FB634A7BF4C35A6F5639D05@ESEALNT442.al.sw.ericsson.se> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Jul 29, 2004, at 3:39 PM, Karim El-Malki (AL/EAB) wrote: > I agree with Jonne. ISATAP is the most promising solution > for 3gpp tunnelling For the sake of the discussion, could the ISATAP proponents summarize why they think ISATAP is a better fit than a tunnel broker solution based on draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. in a 3GPP environment? - Alain. From owner-v6ops@ops.ietf.org Fri Jul 30 02:16:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19225 for ; Fri, 30 Jul 2004 02:16:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqQfu-0008BG-TG for v6ops-data@psg.com; Fri, 30 Jul 2004 06:15:26 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqQfk-0008Ae-04 for v6ops@ops.ietf.org; Fri, 30 Jul 2004 06:15:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6U6FDw04520; Fri, 30 Jul 2004 09:15:13 +0300 Date: Fri, 30 Jul 2004 09:15:13 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (AL/EAB)" cc: "''v6ops@ops.ietf.org ' '" Subject: RE: Proposed way forward with the transition mechanisms In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639D08@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 30 Jul 2004, Karim El-Malki (AL/EAB) wrote: [Pekka:] >> The only reasons I can think of why folks want to go for ISATAP are: >> 1) some have already started deploying it or piloted it, and may even >> have already committed to it -- meaning if they care about the >> IETF, their only option is to push for it as hard as they can. >> 2) it's already "out there", requiring a smaller amount of >> specification etc. than other mechanisms. > > Isn't there a reason number 3 you forgot about? > > 3) It is an appropriate solution for the 3GPP scenario. > > We can't all either be conspiring to push our solution > (your reason 1) or plain stupid (your reason 2: we don't > know why we want ISATAP but it takes little work to > complete it). I haven't heard one valid technical > reason why ISATAP doesn't make sense in a 3gpp network. Sorry, I was a bit inprecise when I wrote "The only reasons I can think of why folks want to go for ISATAP are:" -- what I meant was "The only reasons I can think of why folks want to go for ISATAP *in particular* are:" or even "The only reasons I can think of why folks want to *require* ISATAP are:". I can see that many people see it as an appropriate solution, as you say. But it's (IMHO) just that -- *a* solution; not *the* solution. What I was hard time seeing (my two reasons above) why something else -- which would be more generic, applicable in more scenarios -- couldn't be an equally appropriate (or even more so) a solution. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jul 30 05:10:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25494 for ; Fri, 30 Jul 2004 05:10:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqTMF-0002zb-9L for v6ops-data@psg.com; Fri, 30 Jul 2004 09:07:19 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqTLw-0002xO-BU for v6ops@ops.ietf.org; Fri, 30 Jul 2004 09:07:00 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6U96qGP023900; Fri, 30 Jul 2004 09:06:52 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6U96mTx071492; Fri, 30 Jul 2004 11:06:52 +0200 Received: from zurich.ibm.com (sig-9-145-240-150.de.ibm.com [9.145.240.150]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA95000; Fri, 30 Jul 2004 11:06:47 +0200 Message-ID: <410A0FAF.4060504@zurich.ibm.com> Date: Fri, 30 Jul 2004 11:06:55 +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: Tim Chown CC: v6ops@ops.ietf.org Subject: Re: Proposed way forward with the transition mechanisms References: <1091131636.4598.17.camel@localhost.localdomain> <1091132531.4598.28.camel@localhost.localdomain> <20040729222144.GB21345@login.ecs.soton.ac.uk> In-Reply-To: <20040729222144.GB21345@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: ... > I think also maybe 6to4 relays should be considered for ISP analysis, > where at the moment brokers and 6PE are cited. In the case of European > NRENs, 66% have a 6to4 relay, less than 33% a broker, aimed at local > NREN communities. > > I also believe an enterprise (university, in our case) can offer a broker > or 6to4 relay in the absence of the NREN doing so, or in the case of a > staff or student users in a home network, their home network ISP not > offering one (because the RTT from the national commercial network to the > national academic network will be low). 6to4 is already Proposed Standard, so its status is not currently under discussion. Deployment is its own reward. Brian From owner-v6ops@ops.ietf.org Fri Jul 30 05:10:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25518 for ; Fri, 30 Jul 2004 05:10:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqTPC-0003Pw-GP for v6ops-data@psg.com; Fri, 30 Jul 2004 09:10:22 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqTP1-0003OR-EK for v6ops@ops.ietf.org; Fri, 30 Jul 2004 09:10:11 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6U9A4Gm090918; Fri, 30 Jul 2004 09:10:04 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6U9A3Tx052178; Fri, 30 Jul 2004 11:10:04 +0200 Received: from zurich.ibm.com (sig-9-145-240-150.de.ibm.com [9.145.240.150]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA86304; Fri, 30 Jul 2004 11:10:03 +0200 Message-ID: <410A1073.3030704@zurich.ibm.com> Date: Fri, 30 Jul 2004 11:10: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: Tim Chown CC: v6ops@ops.ietf.org Subject: Re: Proposed way forward with the transition mechanisms References: <1091131636.4598.17.camel@localhost.localdomain> <1091132531.4598.28.camel@localhost.localdomain> <20040729222144.GB21345@login.ecs.soton.ac.uk> In-Reply-To: <20040729222144.GB21345@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: > On Thu, Jul 29, 2004 at 11:22:12PM +0300, Soininen Jonne (Nokia-NET/Helsinki) wrote: > >>I do personally believe that ISATAP is pointed as the most promising >>solution for automatic tunneling in the 3GPP analysis document and thus, >>should be listed as a solution to be standardized. > > > Our own experience (non-small enterprise) is that we prefer to deploy > a structured (configured) transition mechanism - in our case VLAN-based > IPv6 propogation - rather than an unstructured (automatic) method. So > we don't see any need for ISATP in our particular scenario. However, > I can see why some others see some attraction. I think many enterprise networks will agree, not to mention that since ISATAP solves the NBMA problem, it has some intrinsic complexity. So I do echo Alain's question: what makes ISATAP fit better than ordinary tunnels, in the 3GPP secnario? Brian From owner-v6ops@ops.ietf.org Fri Jul 30 05:13:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25586 for ; Fri, 30 Jul 2004 05:13:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqTRT-0003gT-9i for v6ops-data@psg.com; Fri, 30 Jul 2004 09:12:43 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqTRI-0003dO-C0 for v6ops@ops.ietf.org; Fri, 30 Jul 2004 09:12:32 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i6U9CVnE026293 for ; Fri, 30 Jul 2004 10:12:31 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA14213 for ; Fri, 30 Jul 2004 10:12:27 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i6U9CRW01622 for v6ops@ops.ietf.org; Fri, 30 Jul 2004 10:12:27 +0100 Date: Fri, 30 Jul 2004 10:12:26 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Proposed way forward with the transition mechanisms Message-ID: <20040730091226.GG31652@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <1091131636.4598.17.camel@localhost.localdomain> <1091132531.4598.28.camel@localhost.localdomain> <20040729222144.GB21345@login.ecs.soton.ac.uk> <410A0FAF.4060504@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <410A0FAF.4060504@zurich.ibm.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Jul 30, 2004 at 11:06:55AM +0200, Brian E Carpenter wrote: > > 6to4 is already Proposed Standard, so its status is not currently > under discussion. Deployment is its own reward. I was only commenting on Jonne's list, which includes tunnel broker (an existing RFC) but not 6to4. The list should be draft-only, or all mechanisms, I think, to avoid confusion. Tim From owner-v6ops@ops.ietf.org Fri Jul 30 05:36:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26239 for ; Fri, 30 Jul 2004 05:36:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqTn4-0006FS-1l for v6ops-data@psg.com; Fri, 30 Jul 2004 09:35:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqTml-0006E9-2H for v6ops@ops.ietf.org; Fri, 30 Jul 2004 09:34:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6U9YZR07805; Fri, 30 Jul 2004 12:34:35 +0300 Date: Fri, 30 Jul 2004 12:34:35 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: Proposed way forward with the transition mechanisms In-Reply-To: <20040730091226.GG31652@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 30 Jul 2004, Tim Chown wrote: > On Fri, Jul 30, 2004 at 11:06:55AM +0200, Brian E Carpenter wrote: > > > > 6to4 is already Proposed Standard, so its status is not currently > > under discussion. Deployment is its own reward. > > I was only commenting on Jonne's list, which includes tunnel broker (an > existing RFC) but not 6to4. The list should be draft-only, or all > mechanisms, I think, to avoid confusion. It is draft-only, in the sense that the tunnel broker RFC (3053) does not document the actual protocol, just the concept. If we go down that path, an additional spec would be needed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jul 30 05:51:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26722 for ; Fri, 30 Jul 2004 05:51:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqU2E-0008JB-RN for v6ops-data@psg.com; Fri, 30 Jul 2004 09:50:42 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqU0t-00088T-RF for v6ops@ops.ietf.org; Fri, 30 Jul 2004 09:49:20 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id 0FCF41006; Fri, 30 Jul 2004 11:49:18 +0200 (CEST) Date: Fri, 30 Jul 2004 11:49:18 +0200 From: Daniel Roesen To: v6ops@ops.ietf.org Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040730114918.A17041@homebase.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040729030028.A1507@homebase.cluenet.de>; from dr@cluenet.de on Thu, Jul 29, 2004 at 03:00:28AM +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Jul 29, 2004 at 03:00:28AM +0200, Daniel Roesen wrote: > > ; <<>> DiG 8.3 <<>> @dns1.icann.org e.f.f.3.ip6.arpa > > ;; AUTHORITY SECTION: > > e.f.f.3.ip6.arpa. 23h30m IN NS ns3.nic.fr. > > e.f.f.3.ip6.arpa. 23h30m IN NS flag.ep.net. > > e.f.f.3.ip6.arpa. 23h30m IN NS imag.imag.fr. > > e.f.f.3.ip6.arpa. 23h30m IN NS sonata.hexago.com. > > > > - looks perfectly fine to me. > > Actually, it's even in a better state than e.f.f.3.ip6.int: And while we're at it, ip6.int itself is also broken: ERROR: no SOA record for ip6.int. from munnari.oz.au. $ host munnari.oz.au. munnari.oz.au has address 128.250.22.2 munnari.oz.au has address 128.250.1.21 $ host -t aaaa munnari.oz.au. munnari.oz.au has AAAA address 2001:388:c02:4000::1:21 $ dig @128.250.22.2 ip6.int. SOA +short +norec $ dig @128.250.1.21 ip6.int. SOA +short +norec $ dig @2001:388:c02:4000::1:21 ip6.int. SOA +short +norec ==> munnari.oz.au is completely lame for ip6.int. NS list summary for ip6.int. from parent (int.) servers == flag.ep.net. imag.imag.fr. munnari.oz.au. == ns3.nic.fr. y.ip6.int. z.ip6.int. NS list summary for ip6.int. from authoritative servers == flag.ep.net. ns3.nic.fr. y.ip6.int. == z.ip6.int. ERROR: NS list from ip6.int. authoritative servers does not === match NS list from parent (int.) servers ERROR: imag.imag.fr. claims to be authoritative, but does not appear in NS list from authoritative servers So the whole delegation thing is broken. The int. TLD servers delegate ip6.int to imag.imag.fr which feels it self authoritative, but isn't in the NS RRset of the ip6.int zone. And ip6.int is delegated to munnari.oz.au which doesn't know about this (anymore). Regards, Daniel From owner-v6ops@ops.ietf.org Fri Jul 30 06:04:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27116 for ; Fri, 30 Jul 2004 06:04:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqUEn-000AVB-PT for v6ops-data@psg.com; Fri, 30 Jul 2004 10:03:41 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqUEc-000AR1-Ob for v6ops@ops.ietf.org; Fri, 30 Jul 2004 10:03:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6UA3Sd08266; Fri, 30 Jul 2004 13:03:28 +0300 Date: Fri, 30 Jul 2004 13:03:28 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: v6ops@ops.ietf.org, "'Fred Templin'" , Mohit Talwar , , "'Dave Thaler'" Subject: RE: Security issues of Isatap usage in 3GPP networks WAS : RE: mo ving when all the scenarios are not yet complete [RE: DSTM] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 29 Jul 2004, Karen E. Nielsen (AH/TED) wrote: > > I think we are pretty close to agreeing that with additional > > simplifications to ISATAP spec, and significant assumptions about > > deployment (border is secured; ingress filtering is deployed; etc. -- > > I don't think they hold in general!) ISATAP's security threats from ND > > can be mitigated reasonably well. > > > > I am very glad that we start agreeing on this. > > So given that this gets to be written down in some > consolidated form, then it seems (for now at least) > that we may agree that the ND aspects of the > direct tunnelling feature of Isatap isn't > in itself what constitutes the major showstopper in > the particular environments described. Yes, with the further simplifications etc. we discussed. (It still scares me, but I don't see clear, direct threats.) > > Note that ISATAP's securit model wrt. RFC3756 would be: > > > > 3. A model where the nodes do not directly trust each other at the > > IP layer. This model is considered suitable for e.g., ad hoc > > networks. > > > > .. even if IP spoofing had been prevented, the perimeter secured, etc. > > > > In 3GPP networks yes, in Enterprise networks no. Agree. > > In addition, direct tunnelling brings up the same link-local > > threats in other protocols, such as MLD. Those are likely subject > > to other forms of threats. > > Could be. Do you have other examples besides MLD ? That's a large number (e.g., VRRP, OSPF, PIM, etc.), but I don't know how many of them are used in this particular environment. > > > In 3GPP networks it should be possible to assume the following: > > > > > > * Intrasite IPv4 source spoofing isn't possible. > > > * Site is Protocol-41 perimeter guarded. > > > > > > - or it should be acceptable to recommended the above to be > > > enforced by the 3GPP operator as a mechanism to prevent > > > potential SEND security threats of Isatap. > > > > (This is not all of the threats, but still..) How realistic is it > > that these are being performed? > > Both are readily feasible. > The validity in real networks will have to be ascertained, > will be back... Will be interested to know.. During my years as an operator, I've seen way too many pieces of equipment that couldn't do strict uRPF easily out of the box... This is one reason why this scares me. It's really easy to deploy ISATAP in an insecure manner.. you have to have ingress filtering everywhere, you have to block external proto-41 connectivity, your implementations must implement the full spec, etc. -- that's a large number of considerations which all must be done properly. [snip] > > > 4.3.2 > > > Not related to the direct tunnelling functionality of Isatap. > > > Not applicable if address resolution is based on static > > resolution only. > > > > This is slightly different with ISATAP. Instead of the router having > > to do lots of ND lookups (which time out), the router has to send the > > packets to arbitrary IPv4 nodes by static computation. > > > > Right. > > The static computation step may compare with the > tunnel (endpoint) determination step that a stateful > tunnel encapsulation mechanism would have to perform. > > (The difference in between a stateful and a stateless (like Isatap) > being that packets only are forwarded encapsulated to IPv4 endpoints > of established tunnels, not to arbitrary Ipv4 nodes within the > site.) Yes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jul 30 06:57:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29174 for ; Fri, 30 Jul 2004 06:57:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqV3F-000GUZ-3U for v6ops-data@psg.com; Fri, 30 Jul 2004 10:55:49 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BqV34-000GTY-5M for v6ops@ops.ietf.org; Fri, 30 Jul 2004 10:55:38 +0000 Received: (qmail 28539 invoked by uid 417); 30 Jul 2004 10:55:37 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 30 Jul 2004 10:55:37 -0000 Received: from XPNERICK ([132.70.218.245]) by softhome.net with esmtp; Fri, 30 Jul 2004 04:55:35 -0600 Message-ID: <004f01c47623$a75cdb70$0201a8c0@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: Subject: Re: Proposed way forward with the transition mechanisms Date: Fri, 30 Jul 2004 13:54:56 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > 6to4 is already Proposed Standard, so its status is not currently > > > under discussion. Deployment is its own reward. > > > > I was only commenting on Jonne's list, which includes tunnel broker (an > > existing RFC) but not 6to4. The list should be draft-only, or all > > mechanisms, I think, to avoid confusion. > > It is draft-only, in the sense that the tunnel broker RFC (3053) does > not document the actual protocol, just the concept. If we go down > that path, an additional spec would be needed. - Pekka Savola It looks to me like the WG should look at an enhanced draft to explain the additional requirements /specifications / recommendations rather than letting these pop up with out consideration. So in short I wonder if we shouldn't look for the actual protocol issues for tunnel broker. Eric From owner-v6ops@ops.ietf.org Fri Jul 30 06:59:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29213 for ; Fri, 30 Jul 2004 06:58:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqV64-000GyE-7V for v6ops-data@psg.com; Fri, 30 Jul 2004 10:58:44 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqV5c-000Grs-JS for v6ops@ops.ietf.org; Fri, 30 Jul 2004 10:58:16 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000169453.msg for ; Fri, 30 Jul 2004 13:01:14 +0200 Message-ID: <3c9701c47624$101b47a0$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <1091131636.4598.17.camel@localhost.localdomain> Subject: Re: Proposed way forward with the transition mechanisms Date: Fri, 30 Jul 2004 12:57:53 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 30 Jul 2004 13:01:14 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.135 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Fri, 30 Jul 2004 13:01:18 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jonne, In general I agree with your view, but from our point of view, you're missing some work already being done that cover some of the gaps we are missing: 1) draft-palet-v6ops-tun-auto-disc work fits perfectly to fill the analysis of Zero-configured IPv6-over-IPv4 tunneling mechanism, and in addition we are already since a few weeks working in the solution document. Of course, this should be considered, same as the rest of the candidates, or even looking for a solution that could take components from the different candidates. Our target is to have a document submitted at the end of August as latest. 2) We are also working, in combination with the previous documents, in the IPv4 over IPv6 tunneling mechanism with NAT traversal support. This is already described in the draft-palet-v6ops-auto-trans, and a new accompanying document with the proposed solutions (may be several). Our target is also end of August. Also I guess this is what you call zero-configuration both at the client or the server ? 3) Regarding Tunnel Server/Broker, our work on this is obviously very complementary and we have already worked on ideas for improving TSP, with the view on 1) and 2). 4) Our proposed solutions should also work for IPv4 over IPv6 Tunneling, but this has not been our main goal for the August target, but probably we can also take a look on that, and include at least some hints to be further developed later on. We are implementing also all those solutions, and our target is to have everything ready before end of this year. The way we are doing this, will most probably allow the auto-transition to take advantage of other existing mechanism, in a modular approach, allowing also new future mechanism to be easily integrated, both in the client and the "server" or "tunnel end point" or whatever we call it. I will provide more details in my presentation. Regards, Jordi ---- Original Message ---- From: "Soininen Jonne (Nokia-NET/Helsinki)" To: Sent: Thursday, July 29, 2004 10:07 PM Subject: Proposed way forward with the transition mechanisms > Dear v6ops WG, >=20 > our very own AD, David, sent the WG list mail on the July 1st about the > way forward and how he sees the way forward for our little WG. Pekka and > I have discussed the topic and found enough consensus among ourselves to > propose a way forward for the WG. Of course, you the WG, have to say if > you agree with the following approach. We believe that the discussion > should be started now on the WG list and then continue it in the > face-to-face meeting in San Diego to work the details further. The final > decision for the way forward is of course for the WG to make in the > mailing list - as always in the IETF. >=20 > The proposal is to derive the different transition mechanisms from the > Scenarios/Analysis documents and identify either the matching, existing > mechanism, or identify gap and list possible solutions. We have done our > own preliminary analysis. The proposal bellow is for discussion and > should not be considered the final list. We would like to have > discussion if it really does identify all needed mechanisms and just the > needed mechanisms. >=20 > Bellow there is a list of mechanisms. This the list that Pekka and I put > together in quite short time. It may or may not be correct and that's > something that we have to discuss on the list and in the face-to-face in > the meeting. So, this is just the baseline to start the discussion. >=20 > In the interest of time, we propose to do this on the list and after > running the process document it into a draft. I can do the draft editing > myself. >=20 > In the following, is the analysis of the different scenarios/analysis > documents (in no particular order). >=20 > 3gpp-analysis: > SIP v4/v6 transition mechanism > Zero-configured IPv6-over-IPv4 tunneling mechanism >=20 > unmanaged: > Teredo* > Configured tunneling through NAT > IPv4 over IPv6 tunneling mechanism >=20 > ISP: > BGP-tunneling* > Tunnel server/broker >=20 > Enterprise: > Analysis not done. >=20 > Summary: > Teredo* > BGP-Tunneling* > SIP v4/v6 transition mechanism - No candidates > Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP possible candidates > Configured tunneling through NATs - No (direct) candidates, but Tunnel > Server/Broker also addresses this > Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP, Ayiya, STEP, > ISATAP possible candidates. > IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible candidates; many > tunnel server/broker approaches also address this. >=20 > (* Teredo and BGP-tunneling are already moving forward) >=20 > The suggestion is to go forward with Teredo/BGP-Tunneling immediately, > work on SIP v4/v6 transition in SIP WG(s), and find the correct place > for finding suitable solution for the following: >=20 > a) zero-configuration both at the client or the server, > b) IPv6-over-IPv4 tunnels (with NAT traversal support), and > c) IPv4-over-IPv6 tunnels >=20 > This work should take use of > draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. >=20 > Cheers, >=20 > Jonne & Pekka - the chairs. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Jul 30 07:26:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00313 for ; Fri, 30 Jul 2004 07:26:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqVVc-000KP9-5z for v6ops-data@psg.com; Fri, 30 Jul 2004 11:25:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqVVR-000KL3-6P for v6ops@ops.ietf.org; Fri, 30 Jul 2004 11:24:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6UBOp909560; Fri, 30 Jul 2004 14:24:54 +0300 Date: Fri, 30 Jul 2004 14:24:51 +0300 (EEST) From: Pekka Savola To: EricLKlein cc: v6ops@ops.ietf.org Subject: Re: Proposed way forward with the transition mechanisms In-Reply-To: <004f01c47623$a75cdb70$0201a8c0@ttitelecom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 30 Jul 2004, EricLKlein wrote: > > It is draft-only, in the sense that the tunnel broker RFC (3053) does > > not document the actual protocol, just the concept. If we go down > > that path, an additional spec would be needed. - Pekka Savola > > It looks to me like the WG should look at an enhanced draft to explain the > additional requirements /specifications / recommendations rather than > letting these pop up with out consideration. Lucky for you -- it's already there and in WG last call: draft-ietf-v6ops-assisted-tunneling-requirements-00.txt :-) > So in short I wonder if we shouldn't look for the actual protocol issues for > tunnel broker. See above. The point is probably whether folks agree (or not) whether such a protocol would be sufficient to solve their problems. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jul 30 10:05:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07024 for ; Fri, 30 Jul 2004 10:05:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqXyV-000E7G-M6 for v6ops-data@psg.com; Fri, 30 Jul 2004 14:03:07 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqXy3-000E4E-Ab for v6ops@ops.ietf.org; Fri, 30 Jul 2004 14:02:39 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000169870.msg for ; Fri, 30 Jul 2004 16:05:48 +0200 Message-ID: <015f01c4763d$d986cfb0$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <1091131636.4598.17.camel@localhost.localdomain> <3c9701c47624$101b47a0$640a0a0a@consulintel.es> Subject: Re: Proposed way forward with the transition mechanisms Date: Fri, 30 Jul 2004 16:02:27 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 30 Jul 2004 16:05:48 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Fri, 30 Jul 2004 16:05:51 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I forgot to mention something else ... We are also working in the possibility of a policy based transition "helper" than could be installed in the ISPs to provide better service to the customers, as a complement to the "zero-configuration" or auto-trans, whatever we call it. Regards, Jordi ----- Original Message -----=20 From: "JORDI PALET MARTINEZ" To: Sent: Friday, July 30, 2004 12:57 PM Subject: Re: Proposed way forward with the transition mechanisms Hi Jonne, In general I agree with your view, but from our point of view, you're missing some work already being done that cover some of the gaps we are missing: 1) draft-palet-v6ops-tun-auto-disc work fits perfectly to fill the analysis of Zero-configured IPv6-over-IPv4 tunneling mechanism, and in addition we are already since a few weeks working in the solution document. Of course, this should be considered, same as the rest of the candidates, or even looking for a solution that could take components from the different candidates. Our target is to have a document submitted at the end of August as latest. 2) We are also working, in combination with the previous documents, in the IPv4 over IPv6 tunneling mechanism with NAT traversal support. This is already described in the draft-palet-v6ops-auto-trans, and a new accompanying document with the proposed solutions (may be several). Our target is also end of August. Also I guess this is what you call zero-configuration both at the client or the server ? 3) Regarding Tunnel Server/Broker, our work on this is obviously very complementary and we have already worked on ideas for improving TSP, with the view on 1) and 2). 4) Our proposed solutions should also work for IPv4 over IPv6 Tunneling, but this has not been our main goal for the August target, but probably we can also take a look on that, and include at least some hints to be further developed later on. We are implementing also all those solutions, and our target is to have everything ready before end of this year. The way we are doing this, will most probably allow the auto-transition to take advantage of other existing mechanism, in a modular approach, allowing also new future mechanism to be easily integrated, both in the client and the "server" or "tunnel end point" or whatever we call it. I will provide more details in my presentation. Regards, Jordi ---- Original Message ---- From: "Soininen Jonne (Nokia-NET/Helsinki)" To: Sent: Thursday, July 29, 2004 10:07 PM Subject: Proposed way forward with the transition mechanisms > Dear v6ops WG, >=20 > our very own AD, David, sent the WG list mail on the July 1st about the > way forward and how he sees the way forward for our little WG. Pekka and > I have discussed the topic and found enough consensus among ourselves to > propose a way forward for the WG. Of course, you the WG, have to say if > you agree with the following approach. We believe that the discussion > should be started now on the WG list and then continue it in the > face-to-face meeting in San Diego to work the details further. The final > decision for the way forward is of course for the WG to make in the > mailing list - as always in the IETF. >=20 > The proposal is to derive the different transition mechanisms from the > Scenarios/Analysis documents and identify either the matching, existing > mechanism, or identify gap and list possible solutions. We have done our > own preliminary analysis. The proposal bellow is for discussion and > should not be considered the final list. We would like to have > discussion if it really does identify all needed mechanisms and just the > needed mechanisms. >=20 > Bellow there is a list of mechanisms. This the list that Pekka and I put > together in quite short time. It may or may not be correct and that's > something that we have to discuss on the list and in the face-to-face in > the meeting. So, this is just the baseline to start the discussion. >=20 > In the interest of time, we propose to do this on the list and after > running the process document it into a draft. I can do the draft editing > myself. >=20 > In the following, is the analysis of the different scenarios/analysis > documents (in no particular order). >=20 > 3gpp-analysis: > SIP v4/v6 transition mechanism > Zero-configured IPv6-over-IPv4 tunneling mechanism >=20 > unmanaged: > Teredo* > Configured tunneling through NAT > IPv4 over IPv6 tunneling mechanism >=20 > ISP: > BGP-tunneling* > Tunnel server/broker >=20 > Enterprise: > Analysis not done. >=20 > Summary: > Teredo* > BGP-Tunneling* > SIP v4/v6 transition mechanism - No candidates > Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP possible candidates > Configured tunneling through NATs - No (direct) candidates, but Tunnel > Server/Broker also addresses this > Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP, Ayiya, STEP, > ISATAP possible candidates. > IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible candidates; many > tunnel server/broker approaches also address this. >=20 > (* Teredo and BGP-tunneling are already moving forward) >=20 > The suggestion is to go forward with Teredo/BGP-Tunneling immediately, > work on SIP v4/v6 transition in SIP WG(s), and find the correct place > for finding suitable solution for the following: >=20 > a) zero-configuration both at the client or the server, > b) IPv6-over-IPv4 tunnels (with NAT traversal support), and > c) IPv4-over-IPv6 tunnels >=20 > This work should take use of > draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. >=20 > Cheers, >=20 > Jonne & Pekka - the chairs. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Jul 30 16:55:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29953 for ; Fri, 30 Jul 2004 16:55:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqeMX-000Ezn-8N for v6ops-data@psg.com; Fri, 30 Jul 2004 20:52:21 +0000 Received: from [128.2.10.81] (helo=smtp.andrew.cmu.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqeEs-000DzN-LZ for v6ops@ops.ietf.org; Fri, 30 Jul 2004 20:44:26 +0000 Received: from pwolf.WV.CC.CMU.EDU (CMU-100645.WV.CC.cmu.edu [128.2.67.159]) (user=dim mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i6UKiRkp027749 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 30 Jul 2004 16:44:27 -0400 Date: Fri, 30 Jul 2004 16:44:27 -0400 From: David Murray To: v6ops@ops.ietf.org Subject: IETF Session Live Internet Broadcast (MBONE **NOT NEEDED** TO VIEW) Message-ID: <6E94E9A08EC64A5AEDD17C08@pwolf.WV.CC.CMU.EDU> Originator-Info: login-token=Mulberry:01HZYPhIH/fMRSGpANYtJy7qYEfcNf/5KSxHToZA==; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit For the IETF meeting coming up, a number of events (including one for this group) will be broadcast publicly via a technology called ESM through Carnegie Mellon University. To tune to any broadcasts, visit http://esm.cs.cmu.edu during the meetings (August 2-5) and click "Watch". To participate, you need a system with the following requirements: - A machine with Windows 98 or later, Linux, or Mac OS X - You need to have a DSL, Cable Modem, or better connection (you do *not* need mbone to view this event) Thanks! David Murray CMU End System Multicast Group From owner-v6ops@ops.ietf.org Fri Jul 30 19:54:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09286 for ; Fri, 30 Jul 2004 19:54:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqhAm-000CCi-Rh for v6ops-data@psg.com; Fri, 30 Jul 2004 23:52:24 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqhAc-000CAy-0F for v6ops@ops.ietf.org; Fri, 30 Jul 2004 23:52:14 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6UNqAd03751; Fri, 30 Jul 2004 16:52:10 -0700 X-mProtect: <200407302352> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdaHUFdM; Fri, 30 Jul 2004 16:52:08 PDT Message-ID: <410ADF3C.2040509@iprg.nokia.com> Date: Fri, 30 Jul 2004 16:52:28 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soininen Jonne (Nokia-NET/Helsinki)" CC: v6ops@ops.ietf.org Subject: Re: Proposed way forward with the transition mechanisms References: <1091131636.4598.17.camel@localhost.localdomain> <1091132531.4598.28.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jonne, Obviously, I support ISATAP progressing on standards-track as long as it can go forward in the correct way. The current I-D documents widely-deployed implementations and is suitable for intra-site operation when there are no NATs in the path, which might be OK for experimental purposes. But further discussion may be necessary to determine what is needed for standards-track. In a recent series of I-Ds, I proposed an operational model for ISATAP similar to host-specific relay/personal tunnel broker, but the approach didn't seem to garner much interest. I'd like to propose a somewhat different approach now; for more details, please see: http://www.geocities.com/osprey67/v6v4inet-01a.txt Thanks - Fred ftemplin@iprg.nokia.com Soininen Jonne (Nokia-NET/Helsinki) wrote: >Hello everybody, >(chair hat off - this is totally my personal view) > >when writing the proposal for the WG, Pekka and I noticed that we have >different view on some issues. In one topic especially, we seemed to >have pretty opposing views. This topic is the role of ISATAP. > >I do personally believe that ISATAP is pointed as the most promising >solution for automatic tunneling in the 3GPP analysis document and thus, >should be listed as a solution to be standardized. > >I thought even that there was at least some support in the WG for ISATAP >and it had been seen also at least somewhat applicable for enterprise >scenarios. This is of course difficult to say as the enterprise analysis >document is not existing, yet. > >However, I would hereby propose as an individual the addition of ISATAP >in the list of mechanisms that should be standardized on standards >track. (Of course, there has to be consensus in the WG to do that.) > >I would like to hear what other people feel about this! (Pekka's view I, >at least, know already.) > >Cheers, > >Jonne. >On Thu, 2004-07-29 at 23:07, ext Soininen Jonne (Nokia-NET/Helsinki) >wrote: > > >>Dear v6ops WG, >> >>our very own AD, David, sent the WG list mail on the July 1st about the >>way forward and how he sees the way forward for our little WG. Pekka and >>I have discussed the topic and found enough consensus among ourselves to >>propose a way forward for the WG. Of course, you the WG, have to say if >>you agree with the following approach. We believe that the discussion >>should be started now on the WG list and then continue it in the >>face-to-face meeting in San Diego to work the details further. The final >>decision for the way forward is of course for the WG to make in the >>mailing list - as always in the IETF. >> >>The proposal is to derive the different transition mechanisms from the >>Scenarios/Analysis documents and identify either the matching, existing >>mechanism, or identify gap and list possible solutions. We have done our >>own preliminary analysis. The proposal bellow is for discussion and >>should not be considered the final list. We would like to have >>discussion if it really does identify all needed mechanisms and just the >>needed mechanisms. >> >>Bellow there is a list of mechanisms. This the list that Pekka and I put >>together in quite short time. It may or may not be correct and that's >>something that we have to discuss on the list and in the face-to-face in >>the meeting. So, this is just the baseline to start the discussion. >> >>In the interest of time, we propose to do this on the list and after >>running the process document it into a draft. I can do the draft editing >>myself. >> >>In the following, is the analysis of the different scenarios/analysis >>documents (in no particular order). >> >>3gpp-analysis: >> SIP v4/v6 transition mechanism >> Zero-configured IPv6-over-IPv4 tunneling mechanism >> >>unmanaged: >> Teredo* >> Configured tunneling through NAT >> IPv4 over IPv6 tunneling mechanism >> >>ISP: >> BGP-tunneling* >> Tunnel server/broker >> >>Enterprise: >> Analysis not done. >> >>Summary: >> Teredo* >> BGP-Tunneling* >> SIP v4/v6 transition mechanism - No candidates >> Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP possible candidates >> Configured tunneling through NATs - No (direct) candidates, but Tunnel >> Server/Broker also addresses this >> Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP, Ayiya, STEP, >> ISATAP possible candidates. >> IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible candidates; many >> tunnel server/broker approaches also address this. >> >>(* Teredo and BGP-tunneling are already moving forward) >> >>The suggestion is to go forward with Teredo/BGP-Tunneling immediately, >>work on SIP v4/v6 transition in SIP WG(s), and find the correct place >>for finding suitable solution for the following: >> >> a) zero-configuration both at the client or the server, >> b) IPv6-over-IPv4 tunnels (with NAT traversal support), and >> c) IPv4-over-IPv6 tunnels >> >>This work should take use of >>draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. >> >>Cheers, >> >>Jonne & Pekka - the chairs. >> >> From owner-v6ops@ops.ietf.org Sat Jul 31 00:14:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21539 for ; Sat, 31 Jul 2004 00:14:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqlDV-000K5J-JY for v6ops-data@psg.com; Sat, 31 Jul 2004 04:11:29 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqlDK-000K49-EO for v6ops@ops.ietf.org; Sat, 31 Jul 2004 04:11:18 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A880F61FB; Sat, 31 Jul 2004 00:11:17 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 31 Jul 2004 00:11:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Date: Sat, 31 Jul 2004 00:11:23 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B06E2ACDD@tayexc13.americas.cpqcorp.net> Thread-Topic: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Thread-Index: AcR0lNDanfPbEWjmSCuIQlVq72cGAQCH5vZw From: "Bound, Jim" To: Cc: "Jeroen Massar" , "Anand Kumria" , "Rob Blokzijl" , , , X-OriginalArrivalTime: 31 Jul 2004 04:11:17.0459 (UTC) FILETIME=[6D62AA30:01C476B4] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thank you. /jim=20 > -----Original Message----- > From: bmanning@vacation.karoshi.com=20 > [mailto:bmanning@vacation.karoshi.com]=20 > Sent: Wednesday, July 28, 2004 7:20 AM > To: Bound, Jim > Cc: bmanning@vacation.karoshi.com; Jeroen Massar; Anand=20 > Kumria; Rob Blokzijl; v6ops@ops.ietf.org; sig-ipv6@apnic.net;=20 > ipv6-wg@ripe.net > Subject: Re: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was:=20 > 9/9/2006 : ip6.int shutdown?) >=20 >=20 > both ip6.arpa and ip6.int >=20 > --bill >=20 > >=20 > > P.S. Bill - the new initial IPv6 AAA at root for JP and KR=20 > are they to=20 > > use ipv6.arpa? Thanks. > >=20 > > /jim > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of=20 > > > bmanning@vacation.karoshi.com > > > Sent: Sunday, July 25, 2004 5:45 PM > > > To: Jeroen Massar > > > Cc: Anand Kumria; Rob Blokzijl; v6ops@ops.ietf.org;=20 > > > sig-ipv6@apnic.net; ipv6-wg@ripe.net > > > Subject: Re: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was:=20 > > > 9/9/2006 : ip6.int shutdown?) > > >=20 > > >=20 > > > whjile i applaud each and everyone who has expunged > > > all ip6.int from their lives, the fact of the matter is that > > > IETF fiat or no, there exist -many- systems that can only use > > > reverse maps in the ip6.int tree. =20 > > >=20 > > > it will be maintained as long as there are queries for=20 > > > it. for those of you for whom ip6.int is a distant memory, > > > pleae understand and respect the fact that you can not,=20 > > > despite public posturing, force others to change their=20 > > > systems. to practically remove ip6.int incures real cost > > > in both time and cash. in the US there is a term for what > > > the IETF is trying to do w/ ip6.int. Its called an unfunded > > > mandate. Unless or until the good folk in the IETF who are > > > calling for the removal of ip6.int are ready to put up the=20 > > > cash to effect real change, I wish they would stop. > > >=20 > > >=20 > > > > > > On Thu, 2004-07-22 at 09:58, Kurt Erik Lindqvist wrote: > > > > > >=20 > > > > > > > On 2004-07-22, at 09.43, Jeroen Massar wrote: > > > > > > >=20 > > > > > > > > But indeed, if there is concensus or not 9/9/2004 > > > and ip6.int > > > > > > > > is gone for me. > > > > > > >=20 > > > > > > > I vote for 9/9/2004 and getting rid of it properly.=20 > > > Maintaining > > > > > > > two reverse threes will create more problems than it > > > will solve. > > > > >=20 > > > > > What, specifically, is the hurry?=20 > > > >=20 > > > > That this has been overdue for three years already and=20 > that even=20 > > > > though the deprecation was marked in August 2001 some vendors=20 > > > > still not have done the change. And as it is a > > > s/ip6.int/ip6.arpa/g which is > > > > very easy, if vendors did not do that yet they are way > > > overdue and you > > > > got to wonder how much their interest is in keeping > > > software upto date. > > > >=20 > > > > Basically we (at least me) have been waiting for the 6bone > > > to get the > > > > delegation so that we could remove the 2 trees and only=20 > keep one: > > > > ip6.arpa. This was decided by the IAB thus we should=20 > live up to it. > > > >=20 > > > > If we do not remove ip6.int then still implementations > > > using it will > > > > not show up. They have had 3 years already to update... > > > > =20 > > > > > > Take your pick: > > > > > >=20 > > > > > >=20 > > > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int- > > > > > > removal-00.html > > > > > >=20 > > > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int- > > > > > > removal-00.txt > > > > > >=20 > > > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int- > > > > > > removal-00.xml > > > > > >=20 > > > > > > Short, quick and easy. > > > > > > If no comments are risen for 16:00 today I'll submit > > > this as an ID. > > > > >=20 > > > > > Comments: > > > > > e.f.f.3.ip6.arpa was documented in RFC3681=20 > published in February > > > > > 2004 and actioned in July 2004. > > > >=20 > > > > Added, but note that this was all long overdue and=20 > there where a=20 > > > > number of other solutions that would have worked already 2 > > > years ago > > > > if there had not been any of the political arguments > > > holding back this > > > > technical issue. Note also that 6bone will end per 6/6/6 > > > and that it is a TESTbed. > > > > The TESTbed is delaying and thus hurting the production=20 > networks=20 > > > > in this case. > > > >=20 > > > > > I'm assuming the actioning of e.f.f.3.ip6.arpa=20 > is the trigger > > > > > for this I-D; if so, why do you want to wait so=20 > little time (2 > > > > > months) between e.f.f.3.ip6.arpa becoming available and > > > > > requiring people to have updated resolver libraries? > > > >=20 > > > > People should have updated their resolvers in the last=20 > *3 years*. > > > > If you have not done that already then you are not maintaining=20 > > > > your machines properly and there is a big chance that you have=20 > > > > bigger problems than a IPv6 reverse DNS that doesn't=20 > work anymore=20 > > > > because ip6.int is gone. > > > >=20 > > > > > Personally I'd be more in favour of a 6 month=20 > timeout - i.e > > > > > around last December or so. > > > >=20 > > > > Of course the date is up to discussion, but IMHO: ASAP and at=20 > > > > least before the end of the year, the sooner the better. > > > >=20 > > > > Note that Cisco's IOS updates will be done before that date and=20 > > > > Windows > > > > XP2 will come out in August (they say) thus everybody using > > > IPv6 has > > > > time enough to upgrade. All "free unix flavors" already=20 > support it > > > >=20 > > > > Also users agree: = http://www.sixxs.net/forum/?msg=3Dgeneral-83948 > > > > Note the begin date of that thread, we where really waiting > > > for 6bone > > > > just as being nice to the people still using it. > > > >=20 > > > > On Thu, 2004-07-22 at 10:57, Rob Blokzijl wrote:=20 > > > >=20 > > > > > > If no comments are risen for 16:00 today I'll submit > > > this as an ID. > > > > >=20 > > > > > two minor points. In the abstract and the > > > introduction you write: > > > > > =20 > > > > > RFC 3152 delegates IP6.ARPA for reverse IPv6 > > > delegations. For RIRs > > > > > (RIPE,ARIN,APNIC,LACNIC and soon AFNIC) > > > > >=20 > > > > > Replace RIPE --> RIPE NCC > > > >=20 > > > > That I did that wrong is a major oops, I should by know the > > > difference by now. > > > >=20 > > > > > Replace AFNIC --> AFRINIC > > > > >=20 > > > > > (AFNIC is the .fr registry :-) ) > > > >=20 > > > > Also adjusted and added some xref's in the XML. > > > >=20 > > > > Old version is now draft-massar-v6ops-ip6int-removal-00.a > > > new version > > > > carries the draft-massar-v6ops-ip6int-removal-00 name. > > > >=20 > > > > Greets, > > > > Jeroen > > > >=20 > > >=20 > > >=20 > > >=20 > > > > * sig-ipv6: APNIC SIG on IPv6 technology and=20 > > > policy issues * > > > > _______________________________________________ > > > > sig-ipv6 mailing list > > > > sig-ipv6@lists.apnic.net > > > > http://mailman.apnic.net/mailman/listinfo/sig-ipv6 > > >=20 > > >=20 > > >=20 >=20 From owner-v6ops@ops.ietf.org Sat Jul 31 00:16:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21611 for ; Sat, 31 Jul 2004 00:16:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqlHo-000Ka6-Na for v6ops-data@psg.com; Sat, 31 Jul 2004 04:15:56 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqlHT-000KW6-L2 for v6ops@ops.ietf.org; Sat, 31 Jul 2004 04:15:35 +0000 Received: from tayexg12.americas.cpqcorp.net (unknown [16.103.130.127]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 4670D4C66; Sat, 31 Jul 2004 00:15:35 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 31 Jul 2004 00:15:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft agenda for v6ops at IETF60 Date: Sat, 31 Jul 2004 00:15:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B06E2ACDE@tayexc13.americas.cpqcorp.net> Thread-Topic: draft agenda for v6ops at IETF60 Thread-Index: AcR1oYzZL/nW9k8aQrqbapRwjQbT6gBEzyvA From: "Bound, Jim" To: "schakra" , "Pekka Savola" , X-OriginalArrivalTime: 31 Jul 2004 04:15:35.0037 (UTC) FILETIME=[06E9F2D0:01C476B5] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I support this and have read the spec and I believe it has new value to IPv6 and encourage the Chairs to give Sham 5 minutes. I also encourage the WG to read the spec and see the point of 6lsa which adds much as an idea to assist IPv6 deployment. It might be better to do this in IPv6 WG? But clearly our v6 expert community should be aware of this work. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of schakra > Sent: Thursday, July 29, 2004 3:17 PM > To: 'Pekka Savola'; v6ops@ops.ietf.org > Subject: RE: draft agenda for v6ops at IETF60 >=20 > I would like inform this WG that there is a new I-D on the=20 > use of IPv6 Flow Label for traffic engineering, it provides=20 > many advantages over MPLS and ATM but has some issues also. =20 > I would like to request the Chairs to allow me to brief this=20 > (5 min.) if it is not too late a request.=20 >=20 > The draft is available at - >=20 > http://www.ietf.org/internet-drafts/draft-chakravorty-6lsa-00.txt >=20 > Thanks, > Sham Chakravorty > Mitre >=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Saturday, July 24, 2004 4:11 PM > To: v6ops@ops.ietf.org > Subject: Re: draft agenda for v6ops at IETF60 >=20 >=20 > On Wed, 21 Jul 2004, Pekka Savola wrote: > > Let's see what can be done.. the scheduling is really=20 > tight. If the=20 > > slot would be on Friday, I don't think we could use more=20 > than 1 - 1.5=20 > > hours out of it in any case.. >=20 > FYI -- the second session has been rescheduled for Thursday=20 > Morning at least for now: >=20 > THURSDAY, August 5, 2004 > 0800-1700 IETF Registration - Harbor Island Foyer 0800-0900=20 > Continental Breakfast - Harbor Island Foyer > 0900-1130 Morning Sessions =20 > GEN newtrk New IETF Standards Track Discussion WG > INT dnsext DNS Extensions WG * > INT hip Host Identity Protocol WG > OPS v6ops IPv6 Operations WG > RTG mpls Multi Protocol Label Switching WG > SEC mass Message Authentication Signature Standards BOF > TSV tsvwg Transport Area Working Group >=20 >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sat Jul 31 00:21:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21765 for ; Sat, 31 Jul 2004 00:21:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqlMM-000L7I-Sh for v6ops-data@psg.com; Sat, 31 Jul 2004 04:20:38 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqlM3-000L4g-S4 for v6ops@ops.ietf.org; Sat, 31 Jul 2004 04:20:20 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 5C4DF610A; Sat, 31 Jul 2004 00:20:19 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 31 Jul 2004 00:20:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed way forward with the transition mechanisms Date: Sat, 31 Jul 2004 00:20:24 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B06E2ACDF@tayexc13.americas.cpqcorp.net> Thread-Topic: Proposed way forward with the transition mechanisms Thread-Index: AcR1qgmTZHI49ie1R+W2znx+bV5lEABC0yQw From: "Bound, Jim" To: "Soininen Jonne (Nokia-NET/Helsinki)" , X-OriginalArrivalTime: 31 Jul 2004 04:20:19.0062 (UTC) FILETIME=[B034B960:01C476B5] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I believe we must work to standardize both ISATAP and DSTM for sure because they are being deployed and we need to make sure they are deployed correctly with the necessary additions we as WG and IETF need to put on them. But we should show how they play into the scenarios. If the market is using it then I think we have to work on it. There will be no perfect Transition Mechanisms only ones that assist with some problems and why one size does not fit all. More later and I will do my best to contribute to this discussion it is very imporant. Thanks and to both Chairs for bringing this discussion forward that is good leadership. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Soininen Jonne=20 > (Nokia-NET/Helsinki) > Sent: Thursday, July 29, 2004 4:22 PM > To: v6ops@ops.ietf.org > Subject: Re: Proposed way forward with the transition mechanisms >=20 > Hello everybody, > (chair hat off - this is totally my personal view) >=20 > when writing the proposal for the WG, Pekka and I noticed=20 > that we have different view on some issues. In one topic=20 > especially, we seemed to have pretty opposing views. This=20 > topic is the role of ISATAP.=20 >=20 > I do personally believe that ISATAP is pointed as the most=20 > promising solution for automatic tunneling in the 3GPP=20 > analysis document and thus, should be listed as a solution to=20 > be standardized.=20 >=20 > I thought even that there was at least some support in the WG=20 > for ISATAP and it had been seen also at least somewhat=20 > applicable for enterprise scenarios. This is of course=20 > difficult to say as the enterprise analysis document is not=20 > existing, yet.=20 >=20 > However, I would hereby propose as an individual the addition=20 > of ISATAP in the list of mechanisms that should be=20 > standardized on standards track. (Of course, there has to be=20 > consensus in the WG to do that.) >=20 > I would like to hear what other people feel about this!=20 > (Pekka's view I, at least, know already.) >=20 > Cheers, >=20 > Jonne. > On Thu, 2004-07-29 at 23:07, ext Soininen Jonne (Nokia-NET/Helsinki) > wrote: > > Dear v6ops WG, > >=20 > > our very own AD, David, sent the WG list mail on the July 1st about=20 > > the way forward and how he sees the way forward for our little WG.=20 > > Pekka and I have discussed the topic and found enough=20 > consensus among=20 > > ourselves to propose a way forward for the WG. Of course,=20 > you the WG,=20 > > have to say if you agree with the following approach. We=20 > believe that=20 > > the discussion should be started now on the WG list and=20 > then continue=20 > > it in the face-to-face meeting in San Diego to work the details=20 > > further. The final decision for the way forward is of=20 > course for the=20 > > WG to make in the mailing list - as always in the IETF. > >=20 > > The proposal is to derive the different transition=20 > mechanisms from the=20 > > Scenarios/Analysis documents and identify either the matching,=20 > > existing mechanism, or identify gap and list possible solutions. We=20 > > have done our own preliminary analysis. The proposal bellow is for=20 > > discussion and should not be considered the final list. We=20 > would like=20 > > to have discussion if it really does identify all needed mechanisms=20 > > and just the needed mechanisms. > >=20 > > Bellow there is a list of mechanisms. This the list that=20 > Pekka and I=20 > > put together in quite short time. It may or may not be correct and=20 > > that's something that we have to discuss on the list and in the=20 > > face-to-face in the meeting. So, this is just the baseline=20 > to start the discussion. > >=20 > > In the interest of time, we propose to do this on the list=20 > and after=20 > > running the process document it into a draft. I can do the draft=20 > > editing myself. > >=20 > > In the following, is the analysis of the different=20 > scenarios/analysis=20 > > documents (in no particular order). > >=20 > > 3gpp-analysis: > > SIP v4/v6 transition mechanism > > Zero-configured IPv6-over-IPv4 tunneling mechanism > >=20 > > unmanaged: > > Teredo* > > Configured tunneling through NAT > > IPv4 over IPv6 tunneling mechanism > >=20 > > ISP: > > BGP-tunneling* > > Tunnel server/broker > >=20 > > Enterprise: > > Analysis not done. > >=20 > > Summary: > > Teredo* > > BGP-Tunneling* > > SIP v4/v6 transition mechanism - No candidates > > Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP=20 > possible candidates > > Configured tunneling through NATs - No (direct)=20 > candidates, but Tunnel > > Server/Broker also addresses this > > Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP,=20 > Ayiya, STEP, > > ISATAP possible candidates. > > IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible=20 > candidates; many > > tunnel server/broker approaches also address this. > >=20 > > (* Teredo and BGP-tunneling are already moving forward) > >=20 > > The suggestion is to go forward with Teredo/BGP-Tunneling=20 > immediately,=20 > > work on SIP v4/v6 transition in SIP WG(s), and find the=20 > correct place=20 > > for finding suitable solution for the following: > > =20 > > a) zero-configuration both at the client or the server, > > b) IPv6-over-IPv4 tunnels (with NAT traversal support), and > > c) IPv4-over-IPv6 tunnels > >=20 > > This work should take use of > > draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. > >=20 > > Cheers, > >=20 > > Jonne & Pekka - the chairs. > -- > Jonne Soininen > Nokia >=20 > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com >=20 >=20 From owner-v6ops@ops.ietf.org Sat Jul 31 00:30:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22116 for ; Sat, 31 Jul 2004 00:30:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqlUt-000MD0-3X for v6ops-data@psg.com; Sat, 31 Jul 2004 04:29:27 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqlUi-000MBi-7v for v6ops@ops.ietf.org; Sat, 31 Jul 2004 04:29:16 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 8328B61A4; Sat, 31 Jul 2004 00:29:15 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 31 Jul 2004 00:29:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed way forward with the transition mechanisms Date: Sat, 31 Jul 2004 00:29:21 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B06E2ACE0@tayexc13.americas.cpqcorp.net> Thread-Topic: Proposed way forward with the transition mechanisms Thread-Index: AcR2FSLNLXVsfkXJRD6SYCjX7rN6UQAoVEog From: "Bound, Jim" To: "Brian E Carpenter" , "Tim Chown" Cc: X-OriginalArrivalTime: 31 Jul 2004 04:29:15.0289 (UTC) FILETIME=[EFD27890:01C476B6] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable ISATAP disappears once use is not required there is not administration to remove it on the end node and other forms of transition can be used. That is not the case with tunnels that are not automatic. This is one reason I know of very large Japan Provider that is using ISATAP currently for 3G+GPRS+etc pilots. I also think it unwise to question the markets decision just like we did not 6to4. And I know users who will never use 6to4. The point is ISATAP has a market it exists. It will expand and exists with or without us. I suggest we be smart and work on it. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter > Sent: Friday, July 30, 2004 5:10 AM > To: Tim Chown > Cc: v6ops@ops.ietf.org > Subject: Re: Proposed way forward with the transition mechanisms >=20 > Tim Chown wrote: > > On Thu, Jul 29, 2004 at 11:22:12PM +0300, Soininen Jonne=20 > (Nokia-NET/Helsinki) wrote: > >=20 > >>I do personally believe that ISATAP is pointed as the most=20 > promising=20 > >>solution for automatic tunneling in the 3GPP analysis document and=20 > >>thus, should be listed as a solution to be standardized. > >=20 > >=20 > > Our own experience (non-small enterprise) is that we prefer=20 > to deploy=20 > > a structured (configured) transition mechanism - in our case=20 > > VLAN-based > > IPv6 propogation - rather than an unstructured (automatic)=20 > method. So > > we don't see any need for ISATP in our particular scenario.=20 > However, > > I can see why some others see some attraction. >=20 > I think many enterprise networks will agree, not to mention=20 > that since ISATAP solves the NBMA problem, it has some=20 > intrinsic complexity. So I do echo Alain's question: what=20 > makes ISATAP fit better than ordinary tunnels, in the 3GPP secnario? >=20 > Brian >=20 >=20 From owner-v6ops@ops.ietf.org Sat Jul 31 00:30:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22242 for ; Sat, 31 Jul 2004 00:30:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqlVl-000MLh-3Z for v6ops-data@psg.com; Sat, 31 Jul 2004 04:30:21 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqlVa-000MJw-BH for v6ops@ops.ietf.org; Sat, 31 Jul 2004 04:30:10 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 977F24F07; Sat, 31 Jul 2004 00:30:09 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 31 Jul 2004 00:30:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed way forward with the transition mechanisms Date: Sat, 31 Jul 2004 00:30:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B06E2ACE1@tayexc13.americas.cpqcorp.net> Thread-Topic: Proposed way forward with the transition mechanisms Thread-Index: AcR2GL3ggD/VTqwaT3KGobXT9HjgSQAnkHQA From: "Bound, Jim" To: "Pekka Savola" , "Tim Chown" Cc: X-OriginalArrivalTime: 31 Jul 2004 04:30:09.0320 (UTC) FILETIME=[1006F280:01C476B7] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree we would need an additional spec. Again this one is deployed already in several very large pre-production pilots serving many users and sites. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Friday, July 30, 2004 5:35 AM > To: Tim Chown > Cc: v6ops@ops.ietf.org > Subject: Re: Proposed way forward with the transition mechanisms >=20 > On Fri, 30 Jul 2004, Tim Chown wrote: > > On Fri, Jul 30, 2004 at 11:06:55AM +0200, Brian E Carpenter wrote: > > >=20 > > > 6to4 is already Proposed Standard, so its status is not currently=20 > > > under discussion. Deployment is its own reward. > >=20 > > I was only commenting on Jonne's list, which includes=20 > tunnel broker (an > > existing RFC) but not 6to4. The list should be draft-only, or all > > mechanisms, I think, to avoid confusion. >=20 > It is draft-only, in the sense that the tunnel broker RFC=20 > (3053) does not document the actual protocol, just the=20 > concept. If we go down that path, an additional spec would be needed. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sat Jul 31 06:25:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19804 for ; Sat, 31 Jul 2004 06:25:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bqr0q-000FnO-DZ for v6ops-data@psg.com; Sat, 31 Jul 2004 10:22:48 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1Bqr0f-000Flc-M5 for v6ops@ops.ietf.org; Sat, 31 Jul 2004 10:22:37 +0000 Received: (qmail 23750 invoked by uid 417); 31 Jul 2004 10:22:33 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 31 Jul 2004 10:22:33 -0000 Received: from XPNERICK ([132.70.219.131]) by softhome.net with esmtp; Sat, 31 Jul 2004 04:22:32 -0600 Message-ID: <002b01c476e8$333a1030$0201a8c0@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <6E94E9A08EC64A5AEDD17C08@pwolf.WV.CC.CMU.EDU> Subject: Re: IETF Session Live Internet Broadcast (MBONE **NOT NEEDED** TO VIEW) Date: Sat, 31 Jul 2004 13:21:52 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Do you know where there is a schedule of what will be covered? The actual agenda of the meeting has no indication of which sessions are being broadcast from which working group and when and there are concurrent sessions. ----- Original Message ----- From: "David Murray" To: Sent: 30 July, 2004 11:44 PM Subject: IETF Session Live Internet Broadcast (MBONE **NOT NEEDED** TO VIEW) > For the IETF meeting coming up, a number of events (including one for this > group) will be broadcast publicly via a technology called ESM through > Carnegie Mellon University. > > To tune to any broadcasts, visit http://esm.cs.cmu.edu during the meetings > (August 2-5) and click "Watch". > > To participate, you need a system with the following requirements: > - A machine with Windows 98 or later, Linux, or Mac OS X > - You need to have a DSL, Cable Modem, or better connection (you do *not* > need mbone to view this event) > > Thanks! > David Murray > CMU End System Multicast Group > > From owner-v6ops@ops.ietf.org Sat Jul 31 15:27:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13335 for ; Sat, 31 Jul 2004 15:27:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqzSQ-000Any-5c for v6ops-data@psg.com; Sat, 31 Jul 2004 19:23:50 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqzSE-000Ak7-J7 for v6ops@ops.ietf.org; Sat, 31 Jul 2004 19:23:39 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6VJM9gB031156; Sat, 31 Jul 2004 19:22:09 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6VJM81A185950; Sat, 31 Jul 2004 21:22:08 +0200 Received: from zurich.ibm.com (sig-9-145-141-171.de.ibm.com [9.145.141.171]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id VAA82690; Sat, 31 Jul 2004 21:22:04 +0200 Message-ID: <410BF15B.9010805@zurich.ibm.com> Date: Sat, 31 Jul 2004 21:22:03 +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: "Bound, Jim" CC: schakra , Pekka Savola , v6ops@ops.ietf.org Subject: Re: draft agenda for v6ops at IETF60 References: <9C422444DE99BC46B3AD3C6EAFC9711B06E2ACDE@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B06E2ACDE@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Not knowing which WG would discuss this, I sent comments to ipv6, and Sham responded privately to reassure me, but hasn't responded on the list yet. The various chairs should decide where we discuss this. Brian Bound, Jim wrote: > I support this and have read the spec and I believe it has new value to > IPv6 and encourage the Chairs to give Sham 5 minutes. I also encourage > the WG to read the spec and see the point of 6lsa which adds much as an > idea to assist IPv6 deployment. It might be better to do this in IPv6 > WG? But clearly our v6 expert community should be aware of this work. > /jim > > >>-----Original Message----- >>From: owner-v6ops@ops.ietf.org >>[mailto:owner-v6ops@ops.ietf.org] On Behalf Of schakra >>Sent: Thursday, July 29, 2004 3:17 PM >>To: 'Pekka Savola'; v6ops@ops.ietf.org >>Subject: RE: draft agenda for v6ops at IETF60 >> >>I would like inform this WG that there is a new I-D on the >>use of IPv6 Flow Label for traffic engineering, it provides >>many advantages over MPLS and ATM but has some issues also. >>I would like to request the Chairs to allow me to brief this >>(5 min.) if it is not too late a request. >> >>The draft is available at - >> >>http://www.ietf.org/internet-drafts/draft-chakravorty-6lsa-00.txt >> >>Thanks, >>Sham Chakravorty >>Mitre >> >>-----Original Message----- >>From: owner-v6ops@ops.ietf.org >>[mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola >>Sent: Saturday, July 24, 2004 4:11 PM >>To: v6ops@ops.ietf.org >>Subject: Re: draft agenda for v6ops at IETF60 >> >> >>On Wed, 21 Jul 2004, Pekka Savola wrote: >> >>>Let's see what can be done.. the scheduling is really >> >>tight. If the >> >>>slot would be on Friday, I don't think we could use more >> >>than 1 - 1.5 >> >>>hours out of it in any case.. >> >>FYI -- the second session has been rescheduled for Thursday >>Morning at least for now: >> >>THURSDAY, August 5, 2004 >>0800-1700 IETF Registration - Harbor Island Foyer 0800-0900 >>Continental Breakfast - Harbor Island Foyer >>0900-1130 Morning Sessions >>GEN newtrk New IETF Standards Track Discussion WG >>INT dnsext DNS Extensions WG * >>INT hip Host Identity Protocol WG >>OPS v6ops IPv6 Operations WG >>RTG mpls Multi Protocol Label Switching WG >>SEC mass Message Authentication Signature Standards BOF >>TSV tsvwg Transport Area Working Group >> >> >>-- >>Pekka Savola "You each name yourselves king, yet the >>Netcore Oy kingdom bleeds." >>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> >> >> >> >> >> >> > > > From owner-v6ops@ops.ietf.org Sat Jul 31 19:18:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21777 for ; Sat, 31 Jul 2004 19:18:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Br34l-000F1Q-1c for v6ops-data@psg.com; Sat, 31 Jul 2004 23:15:39 +0000 Received: from [192.80.55.71] (helo=smtp-mclean.mitre.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Br34a-000F0n-5L for v6ops@ops.ietf.org; Sat, 31 Jul 2004 23:15:28 +0000 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.11.6/8.11.6) with ESMTP id i6VNFRe09653 for ; Sat, 31 Jul 2004 19:15:27 -0400 Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtp-mclean.mitre.org (8.11.6/8.11.6) with ESMTP id i6VNFNC09361; Sat, 31 Jul 2004 19:15:24 -0400 Received: from unity-18-39.mitre.org (129.83.18.39) by mailhub2.mitre.org with SMTP id 3926350; Sat, 31 Jul 2004 19:15:15 -0400 From: "schakra" To: , "'Brian E Carpenter'" , "'Bound, Jim'" Cc: "'Pekka Savola'" Subject: RE: draft agenda for v6ops at IETF60 Date: Sat, 31 Jul 2004 19:15:02 -0400 Message-ID: <001201c47754$3841c890$6801a8c0@MITRE.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-reply-to: <410BF15B.9010805@zurich.ibm.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I must have missed it on the list - my apologies (under the gun here to deliver an IPv6 transition solution on a major program)! I would like to take 5 minutes to address the issues that Brian raised - and get a feel for the level of interest, thanks - Sham -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter Sent: Saturday, July 31, 2004 3:22 PM To: Bound, Jim Cc: schakra; Pekka Savola; v6ops@ops.ietf.org Subject: Re: draft agenda for v6ops at IETF60 Not knowing which WG would discuss this, I sent comments to ipv6, and Sham responded privately to reassure me, but hasn't responded on the list yet. The various chairs should decide where we discuss this. Brian Bound, Jim wrote: > I support this and have read the spec and I believe it has new value to > IPv6 and encourage the Chairs to give Sham 5 minutes. I also encourage > the WG to read the spec and see the point of 6lsa which adds much as an > idea to assist IPv6 deployment. It might be better to do this in IPv6 > WG? But clearly our v6 expert community should be aware of this work. > /jim > > >>-----Original Message----- >>From: owner-v6ops@ops.ietf.org >>[mailto:owner-v6ops@ops.ietf.org] On Behalf Of schakra >>Sent: Thursday, July 29, 2004 3:17 PM >>To: 'Pekka Savola'; v6ops@ops.ietf.org >>Subject: RE: draft agenda for v6ops at IETF60 >> >>I would like inform this WG that there is a new I-D on the >>use of IPv6 Flow Label for traffic engineering, it provides >>many advantages over MPLS and ATM but has some issues also. >>I would like to request the Chairs to allow me to brief this >>(5 min.) if it is not too late a request. >> >>The draft is available at - >> >>http://www.ietf.org/internet-drafts/draft-chakravorty-6lsa-00.txt >> >>Thanks, >>Sham Chakravorty >>Mitre >> >>-----Original Message----- >>From: owner-v6ops@ops.ietf.org >>[mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola >>Sent: Saturday, July 24, 2004 4:11 PM >>To: v6ops@ops.ietf.org >>Subject: Re: draft agenda for v6ops at IETF60 >> >> >>On Wed, 21 Jul 2004, Pekka Savola wrote: >> >>>Let's see what can be done.. the scheduling is really >> >>tight. If the >> >>>slot would be on Friday, I don't think we could use more >> >>than 1 - 1.5 >> >>>hours out of it in any case.. >> >>FYI -- the second session has been rescheduled for Thursday >>Morning at least for now: >> >>THURSDAY, August 5, 2004 >>0800-1700 IETF Registration - Harbor Island Foyer 0800-0900 >>Continental Breakfast - Harbor Island Foyer >>0900-1130 Morning Sessions >>GEN newtrk New IETF Standards Track Discussion WG >>INT dnsext DNS Extensions WG * >>INT hip Host Identity Protocol WG >>OPS v6ops IPv6 Operations WG >>RTG mpls Multi Protocol Label Switching WG >>SEC mass Message Authentication Signature Standards BOF >>TSV tsvwg Transport Area Working Group >> >> >>-- >>Pekka Savola "You each name yourselves king, yet the >>Netcore Oy kingdom bleeds." >>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> >> >> >> >> >> >> > > > From owner-v6ops@ops.ietf.org Sat Jul 31 19:38:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22382 for ; Sat, 31 Jul 2004 19:38:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Br3Pz-000HSG-2o for v6ops-data@psg.com; Sat, 31 Jul 2004 23:37:35 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Br3Po-000HRD-0O for v6ops@ops.ietf.org; Sat, 31 Jul 2004 23:37:24 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6VNbMN06741 for ; Sun, 1 Aug 2004 02:37:22 +0300 (EET DST) X-Scanned: Sun, 1 Aug 2004 02:37:11 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i6VNbBW5022934 for ; Sun, 1 Aug 2004 02:37:11 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00wDzKX3; Sun, 01 Aug 2004 02:37:10 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6VNbAu05623 for ; Sun, 1 Aug 2004 02:37:10 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 1 Aug 2004 02:37:10 +0300 Received: ESEBE024.noe.nokia.com 172.21.138.125 from 10.241.58.188 10.241.58.188 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost.localdomain by ESEBE024.noe.nokia.com; 01 Aug 2004 02:37:05 +0300 Subject: Re: Proposed way forward with the transition mechanisms From: "Soininen Jonne (Nokia-NET/Helsinki)" To: Fred Templin Cc: v6ops@ops.ietf.org In-Reply-To: <410ADF3C.2040509@iprg.nokia.com> References: <1091131636.4598.17.camel@localhost.localdomain> <1091132531.4598.28.camel@localhost.localdomain> <410ADF3C.2040509@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1091317025.4639.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Sun, 01 Aug 2004 02:37:05 +0300 X-OriginalArrivalTime: 31 Jul 2004 23:37:10.0680 (UTC) FILETIME=[4CC11980:01C47757] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred, I was talking about ISATAP as it exists today. So, as an intra-site protocol. Cheers, Jonne. On Sat, 2004-07-31 at 02:52, Fred Templin wrote: > Jonne, > > Obviously, I support ISATAP progressing on standards-track as long > as it can go forward in the correct way. The current I-D documents > widely-deployed implementations and is suitable for intra-site operation > when there are no NATs in the path, which might be OK for experimental > purposes. But further discussion may be necessary to determine what > is needed for standards-track. > > In a recent series of I-Ds, I proposed an operational model for ISATAP > similar to host-specific relay/personal tunnel broker, but the approach > didn't seem to garner much interest. I'd like to propose a somewhat > different approach now; for more details, please see: > > http://www.geocities.com/osprey67/v6v4inet-01a.txt > > Thanks - Fred > ftemplin@iprg.nokia.com > > Soininen Jonne (Nokia-NET/Helsinki) wrote: > > >Hello everybody, > >(chair hat off - this is totally my personal view) > > > >when writing the proposal for the WG, Pekka and I noticed that we have > >different view on some issues. In one topic especially, we seemed to > >have pretty opposing views. This topic is the role of ISATAP. > > > >I do personally believe that ISATAP is pointed as the most promising > >solution for automatic tunneling in the 3GPP analysis document and thus, > >should be listed as a solution to be standardized. > > > >I thought even that there was at least some support in the WG for ISATAP > >and it had been seen also at least somewhat applicable for enterprise > >scenarios. This is of course difficult to say as the enterprise analysis > >document is not existing, yet. > > > >However, I would hereby propose as an individual the addition of ISATAP > >in the list of mechanisms that should be standardized on standards > >track. (Of course, there has to be consensus in the WG to do that.) > > > >I would like to hear what other people feel about this! (Pekka's view I, > >at least, know already.) > > > >Cheers, > > > >Jonne. > >On Thu, 2004-07-29 at 23:07, ext Soininen Jonne (Nokia-NET/Helsinki) > >wrote: > > > > > >>Dear v6ops WG, > >> > >>our very own AD, David, sent the WG list mail on the July 1st about the > >>way forward and how he sees the way forward for our little WG. Pekka and > >>I have discussed the topic and found enough consensus among ourselves to > >>propose a way forward for the WG. Of course, you the WG, have to say if > >>you agree with the following approach. We believe that the discussion > >>should be started now on the WG list and then continue it in the > >>face-to-face meeting in San Diego to work the details further. The final > >>decision for the way forward is of course for the WG to make in the > >>mailing list - as always in the IETF. > >> > >>The proposal is to derive the different transition mechanisms from the > >>Scenarios/Analysis documents and identify either the matching, existing > >>mechanism, or identify gap and list possible solutions. We have done our > >>own preliminary analysis. The proposal bellow is for discussion and > >>should not be considered the final list. We would like to have > >>discussion if it really does identify all needed mechanisms and just the > >>needed mechanisms. > >> > >>Bellow there is a list of mechanisms. This the list that Pekka and I put > >>together in quite short time. It may or may not be correct and that's > >>something that we have to discuss on the list and in the face-to-face in > >>the meeting. So, this is just the baseline to start the discussion. > >> > >>In the interest of time, we propose to do this on the list and after > >>running the process document it into a draft. I can do the draft editing > >>myself. > >> > >>In the following, is the analysis of the different scenarios/analysis > >>documents (in no particular order). > >> > >>3gpp-analysis: > >> SIP v4/v6 transition mechanism > >> Zero-configured IPv6-over-IPv4 tunneling mechanism > >> > >>unmanaged: > >> Teredo* > >> Configured tunneling through NAT > >> IPv4 over IPv6 tunneling mechanism > >> > >>ISP: > >> BGP-tunneling* > >> Tunnel server/broker > >> > >>Enterprise: > >> Analysis not done. > >> > >>Summary: > >> Teredo* > >> BGP-Tunneling* > >> SIP v4/v6 transition mechanism - No candidates > >> Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP possible candidates > >> Configured tunneling through NATs - No (direct) candidates, but Tunnel > >> Server/Broker also addresses this > >> Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP, Ayiya, STEP, > >> ISATAP possible candidates. > >> IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible candidates; many > >> tunnel server/broker approaches also address this. > >> > >>(* Teredo and BGP-tunneling are already moving forward) > >> > >>The suggestion is to go forward with Teredo/BGP-Tunneling immediately, > >>work on SIP v4/v6 transition in SIP WG(s), and find the correct place > >>for finding suitable solution for the following: > >> > >> a) zero-configuration both at the client or the server, > >> b) IPv6-over-IPv4 tunnels (with NAT traversal support), and > >> c) IPv4-over-IPv6 tunnels > >> > >>This work should take use of > >>draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. > >> > >>Cheers, > >> > >>Jonne & Pekka - the chairs. > >> > >> -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com