From mailman-bounces@ietf.org Wed Dec 1 06:58:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18886 for ; Wed, 1 Dec 2004 06:58:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZTDG-0006eo-BR for v6tc-archive@ietf.org; Wed, 01 Dec 2004 07:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZSBe-0002rd-Mf for v6tc-archive@ietf.org; Wed, 01 Dec 2004 05:58:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: v6tc-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:34:09 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for v6tc-archive@ietf.org: List Password // URL ---- -------- v6tc@ietf.org uredbu https://www1.ietf.org/mailman/options/v6tc/v6tc-archive%40ietf.org From v6tc-bounces@ietf.org Tue Dec 14 11:01:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12377; Tue, 14 Dec 2004 11:01:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeFEw-0005DO-UY; Tue, 14 Dec 2004 11:09:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeF0z-0004Yp-PC; Tue, 14 Dec 2004 10:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeEz4-0003Q8-Dv for v6tc@megatron.ietf.org; Tue, 14 Dec 2004 10:53:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11505 for ; Tue, 14 Dec 2004 10:53:04 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeF76-000519-07 for v6tc@ietf.org; Tue, 14 Dec 2004 11:01:25 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iBEFr1k08003 for ; Tue, 14 Dec 2004 17:53:02 +0200 (EET) X-Scanned: Tue, 14 Dec 2004 17:52:45 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iBEFqj2j026950 for ; Tue, 14 Dec 2004 17:52:45 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00LhaH0x; Tue, 14 Dec 2004 17:52:43 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iBEFqYD08775 for ; Tue, 14 Dec 2004 17:52:34 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 14 Dec 2004 17:50:19 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 14 Dec 2004 17:50:18 +0200 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.154.15 172.21.154.15 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15415.ntc.nokia.com by ESEBE054.noe.nokia.com; 14 Dec 2004 17:50:19 +0200 From: "Soininen Jonne (Nokia-NET/Helsinki)" To: v6tc@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1103039418.15593.41.camel@essrv103nok15415.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 14 Dec 2004 17:50:19 +0200 X-OriginalArrivalTime: 14 Dec 2004 15:50:19.0167 (UTC) FILETIME=[9CC56AF0:01C4E1F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [v6tc] Being silent is ok, but this is already too much. X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Hi, I have noticed that there is no traffic what so ever on this list. There actually has been nothing for almost a month. I was wondering what's going on. Is the requirements work moving anywhere? The protocol proposals seem to be lacking as well. I wonder how easy it will be us to propose this as a WG in a short time frame, if there is no discussion and no work on-going... Cheers, Jonne. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Dec 14 11:07:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13095; Tue, 14 Dec 2004 11:07:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeFLH-0005OZ-IC; Tue, 14 Dec 2004 11:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeFBh-0007jb-IT; Tue, 14 Dec 2004 11:06:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeF9U-0006B6-Kk for v6tc@megatron.ietf.org; Tue, 14 Dec 2004 11:03:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12688 for ; Tue, 14 Dec 2004 11:03:50 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeFHT-0005H3-VG for v6tc@ietf.org; Tue, 14 Dec 2004 11:12:11 -0500 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 iBEG3bi3029649 for ; Tue, 14 Dec 2004 16:03:37 GMT 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 QAA09985 for ; Tue, 14 Dec 2004 16:03:35 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iBEG3ZG06277 for v6tc@ietf.org; Tue, 14 Dec 2004 16:03:35 GMT Date: Tue, 14 Dec 2004 16:03:35 +0000 From: Tim Chown To: v6tc@ietf.org Subject: Re: [v6tc] Being silent is ok, but this is already too much. Message-ID: <20041214160335.GD6071@login.ecs.soton.ac.uk> Mail-Followup-To: v6tc@ietf.org References: <1103039418.15593.41.camel@essrv103nok15415.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1103039418.15593.41.camel@essrv103nok15415.ntc.nokia.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-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 My understanding is that some people offered to consolidate the requirements, but Jordi said he was doing it already, hence I guess we're waiting on him to do so. Tim On Tue, Dec 14, 2004 at 05:50:19PM +0200, Soininen Jonne (Nokia-NET/Helsinki) wrote: > Hi, > > I have noticed that there is no traffic what so ever on this list. There > actually has been nothing for almost a month. I was wondering what's > going on. > > Is the requirements work moving anywhere? The protocol proposals seem to > be lacking as well. I wonder how easy it will be us to propose this as a > WG in a short time frame, if there is no discussion and no work > on-going... > > Cheers, > > Jonne. > -- > Jonne Soininen > Nokia > > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc -- Tim _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Dec 14 11:28:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17358; Tue, 14 Dec 2004 11:28:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeFfP-00064z-86; Tue, 14 Dec 2004 11:36:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeFQW-0007yR-4H; Tue, 14 Dec 2004 11:21:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeFP2-0007Fq-74 for v6tc@megatron.ietf.org; Tue, 14 Dec 2004 11:19:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16573 for ; Tue, 14 Dec 2004 11:19:54 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeFX2-0005qx-22 for v6tc@ietf.org; Tue, 14 Dec 2004 11:28:15 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iBEGJmk20124; Tue, 14 Dec 2004 18:19:49 +0200 (EET) X-Scanned: Tue, 14 Dec 2004 18:19:38 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iBEGJciV024729; Tue, 14 Dec 2004 18:19:38 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00lUKZbs; Tue, 14 Dec 2004 18:19:37 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iBEGJYD05322; Tue, 14 Dec 2004 18:19:34 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 14 Dec 2004 18:19:31 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 14 Dec 2004 18:19:31 +0200 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.154.15 172.21.154.15 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15415.ntc.nokia.com by ESEBE054.noe.nokia.com; 14 Dec 2004 18:19:31 +0200 Subject: Re: [v6tc] Being silent is ok, but this is already too much. From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Tim Chown In-Reply-To: <20041214160335.GD6071@login.ecs.soton.ac.uk> References: <1103039418.15593.41.camel@essrv103nok15415.ntc.nokia.com> <20041214160335.GD6071@login.ecs.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1103041170.15593.54.camel@essrv103nok15415.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 14 Dec 2004 18:19:31 +0200 X-OriginalArrivalTime: 14 Dec 2004 16:19:31.0215 (UTC) FILETIME=[B112B9F0:01C4E1F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Hello, yep, but that's almost a month ago. In addition, I would have thought there to be some preliminary protocol proposals already. Cheers, Jonne. On Tue, 2004-12-14 at 18:03, ext Tim Chown wrote: > My understanding is that some people offered to consolidate the requirements, > but Jordi said he was doing it already, hence I guess we're waiting on him > to do so. > > Tim > > On Tue, Dec 14, 2004 at 05:50:19PM +0200, Soininen Jonne (Nokia-NET/Helsinki) wrote: > > Hi, > > > > I have noticed that there is no traffic what so ever on this list. There > > actually has been nothing for almost a month. I was wondering what's > > going on. > > > > Is the requirements work moving anywhere? The protocol proposals seem to > > be lacking as well. I wonder how easy it will be us to propose this as a > > WG in a short time frame, if there is no discussion and no work > > on-going... > > > > Cheers, > > > > Jonne. > > -- > > Jonne Soininen > > Nokia > > > > Tel: +358 40 527 46 34 > > E-mail: jonne.soininen@nokia.com > > > > _______________________________________________ > > v6tc mailing list > > v6tc@ietf.org > > https://www1.ietf.org/mailman/listinfo/v6tc -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Dec 14 17:44:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00787; Tue, 14 Dec 2004 17:44:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeLWq-0001R7-RO; Tue, 14 Dec 2004 17:52:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeLJE-0002lW-Sa; Tue, 14 Dec 2004 17:38:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeLC1-0001JU-Un for v6tc@megatron.ietf.org; Tue, 14 Dec 2004 17:30:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29496 for ; Tue, 14 Dec 2004 17:30:51 -0500 (EST) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeLK7-00012g-5i for v6tc@ietf.org; Tue, 14 Dec 2004 17:39:16 -0500 Received: from [10.0.0.58] ([217.224.220.109]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.1.R) with ESMTP id md50000649591.msg for ; Tue, 14 Dec 2004 23:36:11 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 14 Dec 2004 23:28:56 +0100 Subject: Re:[v6tc] Being silent is ok, but this is already too much. From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <20041214160335.GD6071@login.ecs.soton.ac.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 217.224.220.109 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Processed: consulintel.es, Tue, 14 Dec 2004 23:36:11 +0100 X-MDAV-Processed: consulintel.es, Tue, 14 Dec 2004 23:36:32 +0100 X-Spam-Score: 0.2 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Yes, taking longer than expected because several circumstances, but I'm trying to get an acceptable version tonight, hopefully. What is also weird is not having heard anything from the IESG regarding the WG ? Regards, Jordi > De: Tim Chown > Responder a: > Fecha: Tue, 14 Dec 2004 16:03:35 +0000 > Para: > Asunto: Re: [v6tc] Being silent is ok, but this is already too much. > > My understanding is that some people offered to consolidate the requirements, > but Jordi said he was doing it already, hence I guess we're waiting on him > to do so. > > Tim > > On Tue, Dec 14, 2004 at 05:50:19PM +0200, Soininen Jonne (Nokia-NET/Helsinki) > wrote: >> Hi, >> >> I have noticed that there is no traffic what so ever on this list. There >> actually has been nothing for almost a month. I was wondering what's >> going on. >> >> Is the requirements work moving anywhere? The protocol proposals seem to >> be lacking as well. I wonder how easy it will be us to propose this as a >> WG in a short time frame, if there is no discussion and no work >> on-going... >> >> Cheers, >> >> Jonne. >> -- >> Jonne Soininen >> Nokia >> >> Tel: +358 40 527 46 34 >> E-mail: jonne.soininen@nokia.com >> >> _______________________________________________ >> v6tc mailing list >> v6tc@ietf.org >> https://www1.ietf.org/mailman/listinfo/v6tc > > -- > Tim > > > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc ********************************** 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. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Wed Dec 15 09:18:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02942; Wed, 15 Dec 2004 09:18:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cea7G-0006j2-LO; Wed, 15 Dec 2004 09:26:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeZuD-0002Mo-5V; Wed, 15 Dec 2004 09:13:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeZqh-00013G-5o for v6tc@megatron.ietf.org; Wed, 15 Dec 2004 09:09:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02288 for ; Wed, 15 Dec 2004 09:09:49 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeZyv-0006Va-Nz for v6tc@ietf.org; Wed, 15 Dec 2004 09:18:22 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iBFE9Zr15271; Wed, 15 Dec 2004 16:09:36 +0200 (EET) X-Scanned: Wed, 15 Dec 2004 16:09:05 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iBFE95tL023625; Wed, 15 Dec 2004 16:09:05 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00vYfPyK; Wed, 15 Dec 2004 16:08:18 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iBFDpgD07557; Wed, 15 Dec 2004 15:51:42 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Dec 2004 15:51:32 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Dec 2004 15:51:31 +0200 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.154.15 172.21.154.15 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15415.ntc.nokia.com by ESEBE054.noe.nokia.com; 15 Dec 2004 15:51:30 +0200 Subject: Re: Re:[v6tc] Being silent is ok, but this is already too much. From: "Soininen Jonne (Nokia-NET/Helsinki)" To: jordi.palet@consulintel.es In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1103118690.4573.343.camel@essrv103nok15415.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 15 Dec 2004 15:51:30 +0200 X-OriginalArrivalTime: 15 Dec 2004 13:51:31.0976 (UTC) FILETIME=[2F0C2080:01C4E2AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Jordi, yes, it is strange that we have not heard anything from IESG. However, I feel a little bit shy to ask the IESG to act more timely in this, if we don't get the show on the road ourselves. I hope we can get your first version soon that we can start discussing it. Remember, it does not have to be perfect. Cheers, Jonne. On Wed, 2004-12-15 at 00:28, ext JORDI PALET MARTINEZ wrote: > Yes, taking longer than expected because several circumstances, but I'm > trying to get an acceptable version tonight, hopefully. > > What is also weird is not having heard anything from the IESG regarding the > WG ? > > Regards, > Jordi > > > > > > De: Tim Chown > > Responder a: > > Fecha: Tue, 14 Dec 2004 16:03:35 +0000 > > Para: > > Asunto: Re: [v6tc] Being silent is ok, but this is already too much. > > > > My understanding is that some people offered to consolidate the requirements, > > but Jordi said he was doing it already, hence I guess we're waiting on him > > to do so. > > > > Tim > > > > On Tue, Dec 14, 2004 at 05:50:19PM +0200, Soininen Jonne (Nokia-NET/Helsinki) > > wrote: > >> Hi, > >> > >> I have noticed that there is no traffic what so ever on this list. There > >> actually has been nothing for almost a month. I was wondering what's > >> going on. > >> > >> Is the requirements work moving anywhere? The protocol proposals seem to > >> be lacking as well. I wonder how easy it will be us to propose this as a > >> WG in a short time frame, if there is no discussion and no work > >> on-going... > >> > >> Cheers, > >> > >> Jonne. > >> -- > >> Jonne Soininen > >> Nokia > >> > >> Tel: +358 40 527 46 34 > >> E-mail: jonne.soininen@nokia.com > >> > >> _______________________________________________ > >> v6tc mailing list > >> v6tc@ietf.org > >> https://www1.ietf.org/mailman/listinfo/v6tc > > > > -- > > Tim > > > > > > > > _______________________________________________ > > v6tc mailing list > > v6tc@ietf.org > > https://www1.ietf.org/mailman/listinfo/v6tc > > > > > ********************************** > 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. > > > > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Dec 16 15:20:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04341; Thu, 16 Dec 2004 15:20:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cf2Fp-0006ou-DX; Thu, 16 Dec 2004 15:29:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf1zB-0004KU-OZ; Thu, 16 Dec 2004 15:12:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf1t8-0008Ly-Tk for v6tc@megatron.ietf.org; Thu, 16 Dec 2004 15:06:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02170 for ; Thu, 16 Dec 2004 15:06:12 -0500 (EST) Received: from ex.hexago.com ([209.71.226.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cf21c-0006Gy-FP for v6tc@ietf.org; Thu, 16 Dec 2004 15:15:01 -0500 Received: from dhcp-118.226.71.209.hexago.com (dhcp-118.226.71.209.hexago.com [209.71.226.118] (may be forged)) by ex.hexago.com ( hexago/8.12.9) with ESMTP id iBGK5ggq087463 for ; Thu, 16 Dec 2004 15:05:42 -0500 (EST) (envelope-from Florent.Parent@hexago.com) Date: Thu, 16 Dec 2004 15:05:36 -0500 From: Florent Parent To: v6tc@ietf.org Message-ID: <796972EB7CA1D55BD8D2967E@[192.168.31.2]> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========6501F0095A3A5EF02B81==========" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d926c18f94eda32f0a6732c7d97b75a Subject: [v6tc] v6tc Protocol Exploration X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93bce5d70bbe500b12c29cf0ebf45c12 --==========6501F0095A3A5EF02B81========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit This draft was submitted today to the ID. I'm attaching it to this message to allow everyone to read it now and startup some discussion on the list. Abstract: This document aims to provide a rough sketch on different approaches to meet the zeroconf/assisted tunneling requirements for a simple IPv6-in-IPv4 tunnel set-up mechanism. This will hopefully set the list into motion ;-) Florent --==========6501F0095A3A5EF02B81========== Content-Type: text/plain; charset=us-ascii; name="draft-parent-v6tc-protocol-exploration-00.txt" Content-Disposition: attachment; filename="draft-parent-v6tc-protocol-exploration-00.txt"; size=26991 Content-Transfer-Encoding: 7bit Network Working Group F. Parent Internet-Draft Hexago Expires: June 16, 2005 P. Savola CSC/FUNET A. Durand SUN Microsystems,inc. December 16, 2004 v6tc Protocol Exploration draft-parent-v6tc-protocol-exploration-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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 as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document aims to provide a rough sketch on different approaches to meet the zeroconf/assisted tunneling requirements for a simple IPv6-in-IPv4 tunnel set-up mechanism. Parent, et al. Expires June 16, 2005 [Page 1] Internet-Draft v6tc protocol exploration December 2004 Table of Contents 1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Implicit Tunnel Setup . . . . . . . . . . . . . . . . . . 4 2.1.1 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2 Router Advertisement . . . . . . . . . . . . . . . . . 6 2.2 Negotiated Tunnel Setup . . . . . . . . . . . . . . . . . 8 2.2.1 Tunnel Setup Messages . . . . . . . . . . . . . . . . 9 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 5.2 Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Parent, et al. Expires June 16, 2005 [Page 2] Internet-Draft v6tc protocol exploration December 2004 1. Goals Meet assisted tunneling and zero-conf tunneling requirement documents. o Simple mode o Ipv6 endpoint o v6v4 tunneling o Nat traversal o User authentication o IPv6 prefix TBD. 2. Approaches A Reusing existing standardized protocols as far as possible: DHCPv6, Router Advertisements: these will establish the tunnel implicitly. B Define a tunnel setup protocol to exchange the tunnel information. DHCPv6 and RA are not defined to establish configured tunnels, but instead to assign addresses/prefixes and other related information on the link after one has been established. Therefore, there are two possibly separate problems that need to be addressed: 1. Setting up an IPv4 tunnel over which IPv6 packets can be sent; this link may or may not have more than a link-local address. 2. Configuring information related to the tunnel, e.g., global addresses, default routes, etc. Additionally, one may want to configure other parameters (such as recursive DNS server addresses, SIP server addresses, etc.) unrelated to obtaining simple IPv6 connectivity, but that is considered a non-problem for this work. As the main issue in v6tc is finding a means to establish the link (problem #1), we assume that the tunnel link must be established as part of the v6tc solution. Parent, et al. Expires June 16, 2005 [Page 3] Internet-Draft v6tc protocol exploration December 2004 Obviously, DHCPv6 and RA can be used for problem #2 when a separate protocol (e.g., explicit tunnel setup as described in Section 2.2) has been used for #1, but it is debatable whether this is useful. This is not discussed at this point. 2.1 Implicit Tunnel Setup Existing mechanisms such as DHCPv6 and RA can be used to assign an address or use a prefix (problem #2), but are not suitable *as-is* to establish a configured tunnel (problem #1). With a small change, this shortcoming can be fixed. With the implicit tunnel creation, the first DHCPv6 solicit/RS message sent by the client is received by the server, and triggers the creation of the tunnel link, on top of which a reply is sent back. The messaging uses link-local addresses automatically assigned for tunnel links. DAD can be disabled as long as the generation of the link-local address is unique enough (e.g., derives the address from the IPv4 address, as is typical for v6-over-v4 implementations). The DHCPv6 and RA approaches are described in more length below, in Section 2.1.1 and Section 2.1.2. The following generic issues/considerations apply to both DHCPv6 and RA approaches: o Cannot negotiate tunnel encapsulation type (always over UDP) o NAT detection is no longer necessary since UDP is always used. There can be no keepalive negotiation (for the benefit of both firewalls and NATs); it is assumed that keepalives are always sent by the host except when disabled in the host. o ISPs will likely not use authentication for their own users, but instead rely on IP-address based filtering. o Implementation is likely a process which listens at the UDP port and directs packets relating to existing tunnels to those tunnel interfaces, and demultiplexes he incoming initial packets by creating new interfaces based on need, and when created, injects the initial DHCPv6/RS messages on that interface, so they'll end up in the local unmodified DHCPv6 server process or RA process. 2.1.1 DHCPv6 The steps are as follows: Parent, et al. Expires June 16, 2005 [Page 4] Internet-Draft v6tc protocol exploration December 2004 1. Client configures IPv6/UDP/IPv4 interface towards tunnel server. (The address has been discovered using the discovery mechanism, e.g., DNS.) 2. Client sends DHCP solicit over tunnel using the rapid commit option ([RFC3315] section 22.14). 3. Tunnel server listening on UDP port receives message and configures tunnel interface link (based on the IPv4 source address). 4. DHCPv6 solicit message is received by DHCPv6 server through the tunnel link that was just created. 5. DHCPv6 advertise IPv6 address to client. client server 1.Configure | | tunnel o| | | 2.DHCP solicit | | (rapid commit) | DHCP/IPv6/UDP/IPv4 |------------------------->| | | | |o 3.configure tunnel | | 4.message to DHCPv6 | 5.DHCP advertise | server |<------------------------ | Figure 1: DHCPv6 in simple mode If the client uses authentication, DHCP delayed authentication is used [RFC3118]. This requires the client and server to share a known secret. This differs from the above in that Rapid Commit option cannot be used at step 2, above, and Advertise option (at step 5) carries the authentication and requires a couple of additional steps: o Client sends Request with auth options. At this point, the server is able to validate the authenticity of the user. If that fails, the request is dropped and the tunnel may be removed. o Server sends Reply + auth options. Parent, et al. Expires June 16, 2005 [Page 5] Internet-Draft v6tc protocol exploration December 2004 client server 1.Configure | | tunnel o| | | 2.DHCP solicit | DHCP/IPv6/UDP/IPv4 |------------------------->| | | | |o 3.configure tunnel | | 4.message to DHCPv6 | 5.DHCP advertise | server |<------------------------ | | DHCP request | |------------------------->|o client identity | DHCP reply | verified here. |<------------------------ | Figure 2: DHCPv6 in authenticated mode DHCP delayed authentication [RFC3118] is used to provide a user authentication based on shared secrets. The secrets are not sent in clear. Prefix delegation may be done using IPv6 prefix options [RFC3633]. In the non-authenticated case, prefix delegation can be accomplished in one round-trip using the rapid commit option. Notes/Issues o Might be an issue about using DHCPv6 for address assignment. What are the host requirements? 2.1.2 Router Advertisement ICMPv6 Neighbor Discovery [RFC2461] Router Advertisements are very similar to DHCPv6, with a few notable differences: o Authentication where needed can be done using SEND [I-D.ietf-send-ndopt]. o Prefix delegation is not supported, but multiple nodes can use the same prefix if using bridging or ND-proxy [I-D.ietf-ipv6-ndproxy]. o Requires no DHCPv6 implementation (for address assignment, at least) on hosts. The steps are as follows: Parent, et al. Expires June 16, 2005 [Page 6] Internet-Draft v6tc protocol exploration December 2004 1. Client configures IPv6/UDP/IPv4 interface towards tunnel server. (The address has been discovered using the discovery mechanism, e.g., DNS.) 2. Client sends Router Solicitation over tunnel. 3. Tunnel server listening on UDP port receives message and configures tunnel interface link (based on the IPv4 source address) 4. The RA/RS handling process receives the RS message from the new link that was just set up. 5. Route Advertisement message is sent in response through the tunnel link. client server 1.Configure | | tunnel o| | | 2.ND/Router Solicitation | RS/IPv6/UDP/IPv4 |------------------------->| | | | |o 3.configure tunnel | | 4.message to RA | 5. Router Advertisement | process |<------------------------ | Figure 3: RA in simple mode If SEND is used for authentication, Router Solicitation additionally includes the CGA, RSA Signature, Nonce, and Timestamp options. The server has the user's public key in file, and checks the CGA address against that. The fact that the client has been able to sign the ND message with the private key is sufficient for the server to ascertain user's identity. In a similar fashion, the server uses CGA in its replies, allowing the client to ensure no one is able to thwart the signalling. The Certification Path Discovery and Certificates are not required as the link is point-to-point. The use of SEND incurs no additional roundtrips. Parent, et al. Expires June 16, 2005 [Page 7] Internet-Draft v6tc protocol exploration December 2004 Notes: o If the client needs to configure any other IPv6 parameters than a global address, running DHCPv6(-lite) or the like may be necessary. 2.2 Negotiated Tunnel Setup An alternative approach is to define a new protocol to exchange the tunnel parameters explicitly. The tunnel setup protocol is done over UDP and NAT detection is done to determine if IPv6-over-IPv4 tunneling or IPv6 over UDP tunnel will be used. The characteristics of this protocol are similar to TSP ([I-D.blanchet-v6ops-tunnelbroker-tsp]), with simplified signaling. o Tunnel signaling is transported over UDP/IPv4. o Tunnel parameters are explicitly exchanged o NAT detection/traversal o Tunnel is explicitly configured from tunnel parameters exchanged after signaling o Simple mode supported (no authentication, one round trip); note that getting to one roundtrip requires that the protocol is also used for assigning the IPv6 address or prefix. o Prefix delegation The steps are as follows: 1. Client sends tunnel request over UDP/IPv4 2. Tunnel server listening on UDP port receives message and determines if client behind NAT (based on IPv4 header information and client IPv4 address in message) 3. Server sends tunnel information to client 4. Client and server configure tunnel endpoint. Parent, et al. Expires June 16, 2005 [Page 8] Internet-Draft v6tc protocol exploration December 2004 client server | 1.Tunnel request | UDP/IPv4 |----------------------------->| | | 2.NAT detection | 3.Tunnel reply | |<---------------------------- | | Tunnel established | 4.configure tunnel |==============================| Figure 4: Tunnel setup protocol in simple mode 2.2.1 Tunnel Setup Messages The tunnel request from the client must contain: o Client IPv4 address (used for NAT detection) o Tunnel encapsulation mode requested The tunnel request from the client may contain (optional parameters): o Prefix delegation request o Authentication information o Keepalive information A possible protocol message structure is to use a fixed message header followed by one or more TLV. This header is used in every packets sent during the tunnel signaling. Other information is added as TLV. Parent, et al. Expires June 16, 2005 [Page 9] Internet-Draft v6tc protocol exploration December 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xF |M|KA |0| Encapsulation | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Tunnel setup protocol UDP header The first 8 bytes is the standard UDP header. 0xF Marker. Used to differentiate a signaling packet from an IPv6 datagram. M One bit mode flag. Set to 0 for no authentication. Set to 1 if authentication is requested. KA Two bits keepalive flags. Set to 10 for no keepalive. Set to 01 if keepalive requested. Set to 11 if don't care (server reply will decide on what to do). Encapsulation Indicates the type of encapsulation requested. Set to 41 for IPv6-over-IPv4 tunnels, ? for IPv6 over UDP. May need to define new value here to define "IPv6 over foo" (let server decide after NAT detection) Type Message type (request, response) 2.2.1.1 Client IPv4 address A client request uses the tunnel setup header, plus an extra TLV containing the client IPv4 address. Including the IPv4 address inside the payload can be used by the server to detect if the client is behind a NAT. Should address obfuscation be used? According to Teredo spec, it is. [I-D.ietf-ipsec-nat-t-ike] uses a HASH of the address (and port). The server can compute the HASH and validate if it corresponds to what the client sees. If not, an address translation occurred. Parent, et al. Expires June 16, 2005 [Page 10] Internet-Draft v6tc protocol exploration December 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Client IPv4 address TLV 2.2.1.1.1 Authentication information (optional) If the M bit is set to 1, client is requesting authentication. A TLV representing the identity of the client is sent. The server will need to sent a challenge. TLV details to be worked out. 2.2.1.1.2 Prefix delegation request (optional) If a prefix delegation TLV is included in the request, it indicates to the server that the client is requesting a prefix. TLV details to be worked out. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Prefix delegation request TLV 2.2.1.2 Server response Message type is X (response) In simple mode (no prefix delegation, no auth), the server will provide the following information in its response o IPv4 server endpoint (IPv6 in IPv4 tunnel) o IPv6 address of client Parent, et al. Expires June 16, 2005 [Page 11] Internet-Draft v6tc protocol exploration December 2004 o IPv6 address of server o Encapsulation type Keepalive TLV is sent by server if requested by client. TLV holds the keepalive time interval to be used by the client. If authentication is requested, the server will send a challenge to the client. The authentication can be based on HTTP authentication (RFC2617) or something like DHCP delayed authentication (RFC3118). This needs to be further defined. Likely to add one round trip (challenge-response). If a prefix delegation is requested by the client, the server response includes a TLV specifying the delegated prefix. Some notes o When keepalive is requested, should the client supply a keepalive time interval that will be used? This can be useful from the server point of view to decide when a tunnel is inactive o The server could only return its IPv4 address to the client and use RA to configure the client (IPv6 address, default route). Doing so would have the advantage of using an existing mechanism at the cost of an extra packet sent from the server to the client. o DAD disabled by default on the tunnel link. o Some authentication mechanism may depend on transport layer to reliably deliver packets. Since UDP is used, may need to handle this in protocol ([I-D.blanchet-v6ops-tunnelbroker-tsp]) 3. IANA Considerations None at this point. 4. Security Considerations Creating tunnel state based on the first UDP packet is can open the server to a DoS attack with spoofed source addresses. There are a couple of ways to mitigate this: o Use ingress filtering towards your customers and at your own borders, and provide the service to your own customers only. The threat is eliminated. Parent, et al. Expires June 16, 2005 [Page 12] Internet-Draft v6tc protocol exploration December 2004 o As above, but apply rate-limiting or other IP-address based controls to those who desire to use the service from outside networks. o Require authentication from the outside users. 5. References 5.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 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. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. 5.2 Informative References [I-D.blanchet-v6ops-tunnelbroker-tsp] Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in progress), June 2004. [I-D.ietf-ipsec-nat-t-ike] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", draft-ietf-ipsec-nat-t-ike-08 (work in progress), February 2004. [I-D.ietf-ipv6-ndproxy] Thaler, D., "Bridge-like Neighbor Discovery Proxies (ND Proxy)", draft-ietf-ipv6-ndproxy-00 (work in progress), December 2004. [I-D.ietf-send-ndopt] Parent, et al. Expires June 16, 2005 [Page 13] Internet-Draft v6tc protocol exploration December 2004 Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 (work in progress), July 2004. [RFC3053] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. Authors' Addresses Florent Parent Hexago 2875 boul. Laurier, suite 300 Sainte-Foy, QC G1V 2M2 Canada EMail: Florent.Parent@hexago.com Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland EMail: psavola@funet.fi Alain Durand SUN Microsystems,inc. 17 Network circle UMPK17-202 Menlo Park, CA 94025 USA EMail: Alain.Durand@sun.com Parent, et al. Expires June 16, 2005 [Page 14] Internet-Draft v6tc protocol exploration December 2004 Intellectual Property Statement 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. 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Parent, et al. Expires June 16, 2005 [Page 15] --==========6501F0095A3A5EF02B81========== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --==========6501F0095A3A5EF02B81==========-- From v6tc-bounces@ietf.org Thu Dec 16 15:34:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06063; Thu, 16 Dec 2004 15:34:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cf2TE-0007M6-Gw; Thu, 16 Dec 2004 15:43:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf2EV-0005aC-IQ; Thu, 16 Dec 2004 15:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf27F-0000E7-6C for v6tc@megatron.ietf.org; Thu, 16 Dec 2004 15:20:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04328 for ; Thu, 16 Dec 2004 15:20:46 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cf2Fi-0006ob-9L for v6tc@ietf.org; Thu, 16 Dec 2004 15:29:36 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iBGKKkVu015179 for ; Thu, 16 Dec 2004 13:20:46 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I8U0029F0ILEG@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Thu, 16 Dec 2004 13:20:45 -0700 (MST) Received: from [192.168.1.2] ([83.113.89.164]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I8U0065N0IIP6@mail.sun.net> for v6tc@ietf.org; Thu, 16 Dec 2004 13:20:45 -0700 (MST) Date: Thu, 16 Dec 2004 12:20:47 -0800 From: Alain Durand Subject: Re: [v6tc] Being silent is ok, but this is already too much. In-reply-to: <1103118690.4573.343.camel@essrv103nok15415.ntc.nokia.com> To: "Soininen Jonne (Nokia-NET/Helsinki)" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1103118690.4573.343.camel@essrv103nok15415.ntc.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7BIT Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7BIT On Dec 15, 2004, at 5:51 AM, Soininen Jonne (Nokia-NET/Helsinki) wrote: > Jordi, > > yes, it is strange that we have not heard anything from IESG. However, > I > feel a little bit shy to ask the IESG to act more timely in this, if we > don't get the show on the road ourselves. > I had a Email conversation with Margaret last week, Thomas is the AD that will be handling the spin off of v6tc. I have asked him for a telechat, still waiting for him - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Dec 17 04:48:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28925; Fri, 17 Dec 2004 04:48:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfErf-0006ef-80; Fri, 17 Dec 2004 04:57:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfEh7-0000yA-RF; Fri, 17 Dec 2004 04:46:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfEaA-0008TU-D9 for v6tc@megatron.ietf.org; Fri, 17 Dec 2004 04:39:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28362 for ; Fri, 17 Dec 2004 04:39:28 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfEik-0006RI-2G for v6tc@ietf.org; Fri, 17 Dec 2004 04:48:24 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iBH9dQVu020009 for ; Fri, 17 Dec 2004 02:39:26 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I8V001YG1HPYI@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Fri, 17 Dec 2004 02:39:26 -0700 (MST) Received: from [192.168.1.4] ([83.113.218.143]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I8V005ID1HNUK@mail.sun.net> for v6tc@ietf.org; Fri, 17 Dec 2004 02:39:25 -0700 (MST) Date: Fri, 17 Dec 2004 01:39:25 -0800 From: Alain Durand Subject: Re: [v6tc] v6tc Protocol Exploration In-reply-to: <796972EB7CA1D55BD8D2967E@[192.168.31.2]> To: Florent Parent Message-id: <89CDF53C-500F-11D9-81E4-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <796972EB7CA1D55BD8D2967E@[192.168.31.2]> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7BIT Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT Thank you Florent for sending this, it will help framing the next discussion. Back to a message I sent a while ago, some of the key issues we need to discuss are: Issue 1: - Could we live with UDP encapsulation always on? Issue 2: - Do we need mutual authentication? How strong should this be? Issue 3: Should some of this authentication mechanism "follow-on" atfer the tunnel set-up phase as finished? Issue 4: - Should we embed some kind of signaling in the tunnel? I will start email threads for each one of them. Please fell free to add other issues to this list. ps: I'll ask our ADs to be if we can use some of the issue tracker tools to help here. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Dec 17 04:56:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29349; Fri, 17 Dec 2004 04:56:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfEyq-0006pa-Uk; Fri, 17 Dec 2004 05:05:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfEpE-0002mV-40; Fri, 17 Dec 2004 04:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfEnF-0002Mm-SH for v6tc@megatron.ietf.org; Fri, 17 Dec 2004 04:53:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29144 for ; Fri, 17 Dec 2004 04:52:59 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfEvq-0006lL-A5 for v6tc@ietf.org; Fri, 17 Dec 2004 05:01:56 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iBH9qudt028157 for ; Fri, 17 Dec 2004 02:52:56 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I8V002XF247EG@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Fri, 17 Dec 2004 02:52:56 -0700 (MST) Received: from [192.168.1.4] ([83.113.94.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I8V006L024544@mail.sun.net> for v6tc@ietf.org; Fri, 17 Dec 2004 02:52:55 -0700 (MST) Date: Fri, 17 Dec 2004 01:52:56 -0800 From: Alain Durand To: v6tc@ietf.org Message-id: <6D2CE1A0-5011-11D9-81E4-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7BIT Subject: [v6tc] Issue 1: Could we live with UDP encapsulation always on? X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7BIT Obviously the first thing to consider is the UDP overhead. When the payload is large, there isn't much difference, but when it is small, there is a non negligible impact. Another point to consider is that UDP encapsulation might force packets to go to the slow path on the tunnel end-point unless special code is added in the forwarding plane. Also, IPv6/UDP/IPv4 has not generally been implemented so far, so we have a deployment problem. Also, tons of PCs have now teredo, so there may be some compatibility issues and/or some potential code to leverage. Anything else to consider? - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Dec 17 05:19:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01339; Fri, 17 Dec 2004 05:19:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfFLV-0007SF-GH; Fri, 17 Dec 2004 05:28:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfFBs-0007FT-EB; Fri, 17 Dec 2004 05:18:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfF6j-0005zo-Hr for v6tc@megatron.ietf.org; Fri, 17 Dec 2004 05:13:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00774 for ; Fri, 17 Dec 2004 05:13:07 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfFFB-0007Gb-C9 for v6tc@ietf.org; Fri, 17 Dec 2004 05:22:03 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id DE7D92400C; Fri, 17 Dec 2004 11:12:51 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24786-02; Fri, 17 Dec 2004 11:12:51 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id E558124008; Fri, 17 Dec 2004 11:12:50 +0100 (CET) Subject: Re: [v6tc] Issue 1: Could we live with UDP encapsulation always on? From: Jeroen Massar To: Alain Durand In-Reply-To: <6D2CE1A0-5011-11D9-81E4-00039358A080@sun.com> References: <6D2CE1A0-5011-11D9-81E4-00039358A080@sun.com> Organization: Unfix Date: Fri, 17 Dec 2004 11:12:49 +0100 Message-Id: <1103278369.25975.57.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1678583960==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --===============1678583960== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-R/IFazmbqZb6ELyF+mG3" --=-R/IFazmbqZb6ELyF+mG3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-12-17 at 01:52 -0800, Alain Durand wrote: > Obviously the first thing to consider is the UDP overhead. When the=20 > payload is large,there isn't much difference, but when it is small, there= is a non=20 > negligible impact. >=20 > Another point to consider is that UDP encapsulation might force packets > to go to the slow path on the tunnel end-point unless special code is=20 > added > in the forwarding plane. >=20 > Also, IPv6/UDP/IPv4 has not generally been implemented so far, so we=20 > have a deployment problem. Not implemented or deployed? I wonder why Freenet6 has their special NAT traversal code and why SixXS have AYIYA then ;) > Also, tons of PCs have now teredo, so there may=20 > be some compatibility issues and/or some potential code to leverage. Teredo basically is one of the main three (are there others?) versions of IPv6/UDP/IPv4 protocol. The only thing being that it is more a p2p like application in that it not uses a pre-configured or out-of-band managed designated server. It is possible to configure that though (it is something like: netsh set teredo ...) Byte-wise you could easily 'live' with UDP encaps btw. Especially as proto-41 is non-authenticated and very spoof sensitive, oh hmm so is the protocol which is proposed in the new draft. AYIYA, which looks somewhat quite like the proposed protocol, does not have this issue btw... With people downloading movies etc, do 3 bytes per packet extra hurt? The target is getting IPv6 deployed and available to the masses (Longhorn in 2006 will come default with IPv6 and you can turn of IPv4 ;) Who does this or how does not really matter as long as it is done and people can enjoy the freedom of enough addresses and thus end-2-end connectivity. Why is there a checksum in that newly proposed protocol anyway? There was a reason why checksumming was removed from the IPv6 headers ;) Greets, Jeroen PS: The mailinglist archives don't work... --=-R/IFazmbqZb6ELyF+mG3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBwrEgKaooUjM+fCMRAsZ1AJsH/QFkf+8S5OCuTjnAZh3BYbliKQCbBCjn nB92er1rPLZ7TFp+BosRKKo= =UXEb -----END PGP SIGNATURE----- --=-R/IFazmbqZb6ELyF+mG3-- --===============1678583960== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1678583960==-- From v6tc-bounces@ietf.org Fri Dec 17 05:46:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04038; Fri, 17 Dec 2004 05:46:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfFm5-0008GC-Ny; Fri, 17 Dec 2004 05:55:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfFXD-0004dr-CR; Fri, 17 Dec 2004 05:40:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfFSu-0003N8-Mx for v6tc@megatron.ietf.org; Fri, 17 Dec 2004 05:36:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03234 for ; Fri, 17 Dec 2004 05:36:02 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfFbV-0007vg-TW for v6tc@ietf.org; Fri, 17 Dec 2004 05:44:59 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBHAZFR19934; Fri, 17 Dec 2004 12:35:17 +0200 Date: Fri, 17 Dec 2004 12:35:15 +0200 (EET) From: Pekka Savola To: Jeroen Massar Subject: Re: [v6tc] Issue 1: Could we live with UDP encapsulation always on? In-Reply-To: <1103278369.25975.57.camel@firenze.zurich.ibm.com> Message-ID: References: <6D2CE1A0-5011-11D9-81E4-00039358A080@sun.com> <1103278369.25975.57.camel@firenze.zurich.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Alain Durand , v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb >From Alain: > Obviously the first thing to consider is the UDP overhead. When the > payload is large, there isn't much difference, but when it is small, > there is a non negligible impact. What I'd be interested in knowing here is whether the typical UDP header compression algorithms fix this problem automatically in those deployments where the extra bytes are important. On Fri, 17 Dec 2004, Jeroen Massar wrote: > Byte-wise you could easily 'live' with UDP encaps btw. Especially as > proto-41 is non-authenticated and very spoof sensitive, oh hmm so is the > protocol which is proposed in the new draft. AYIYA, which looks somewhat > quite like the proposed protocol, does not have this issue btw... > With people downloading movies etc, do 3 bytes per packet extra hurt? The assumption is that if you want to protect the payload, you'll want to use a real security mechanism -- this is not the place to (try to) invent one. > Why is there a checksum in that newly proposed protocol anyway? > There was a reason why checksumming was removed from the IPv6 headers ;) It is the standard UDP checksum. The first two lines are the UDP header. > PS: The mailinglist archives don't work... Thanks for pointing that out. I'll raise it with the IETF secretariat. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Dec 17 06:13:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05575; Fri, 17 Dec 2004 06:13:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfGCE-0000TX-4p; Fri, 17 Dec 2004 06:22:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfG2d-0001gB-V0; Fri, 17 Dec 2004 06:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfG2E-0001S1-CH for v6tc@megatron.ietf.org; Fri, 17 Dec 2004 06:12:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05507 for ; Fri, 17 Dec 2004 06:12:31 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfGAq-0000SN-KO for v6tc@ietf.org; Fri, 17 Dec 2004 06:21:29 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 0FF1324042; Fri, 17 Dec 2004 12:12:31 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26598-09; Fri, 17 Dec 2004 12:12:29 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id 6EE3B2403F; Fri, 17 Dec 2004 12:11:53 +0100 (CET) Subject: Re: [v6tc] Issue 1: Could we live with UDP encapsulation always on? From: Jeroen Massar To: Pekka Savola In-Reply-To: References: <6D2CE1A0-5011-11D9-81E4-00039358A080@sun.com> <1103278369.25975.57.camel@firenze.zurich.ibm.com> Organization: Unfix Date: Fri, 17 Dec 2004 12:11:52 +0100 Message-Id: <1103281912.25975.87.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Alain Durand , v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1329649839==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 --===============1329649839== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3aBKTVbwN0NtiQ1QvYRY" --=-3aBKTVbwN0NtiQ1QvYRY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-12-17 at 12:35 +0200, Pekka Savola wrote: > From Alain: > > Obviously the first thing to consider is the UDP overhead. When the=20 > > payload is large, there isn't much difference, but when it is small,=20 > > there is a non negligible impact. >=20 > What I'd be interested in knowing here is whether the typical UDP=20 > header compression algorithms fix this problem automatically in those=20 > deployments where the extra bytes are important. You mean eg dailup users? Do those still exist? Also G3 phones don't have this issue either with UMTS and other goodies being deployed, coming upto speeds of most lower DSL lines... > On Fri, 17 Dec 2004, Jeroen Massar wrote: > > Byte-wise you could easily 'live' with UDP encaps btw. Especially as > > proto-41 is non-authenticated and very spoof sensitive, oh hmm so is th= e > > protocol which is proposed in the new draft. AYIYA, which looks somewha= t > > quite like the proposed protocol, does not have this issue btw... > > With people downloading movies etc, do 3 bytes per packet extra hurt? >=20 > The assumption is that if you want to protect the payload, you'll want=20 > to use a real security mechanism -- this is not the place to=20 > (try to) invent one. You mean using IPSEC, which does not (easily) work over the NAT we where trying to cross in the first place ? :) Also I don't mean to protect the payload, I could not care less about crypto, use SSH/HTTPS/TLS in the cases you need to crypt something. It is about verification that the sender really send the packet which you are going to forward for them. Because that is the issue here. Also expect people to abuse this proposed protocol, just like they are abusing proto-41 by simply spoofing packets and inserting them, causing some nice network traffic spikes, being totally untraceable as there is no way to trace where they are coming from and one will think it is coming from the legit user, who is suddenly getting claims of sending a large ddos to somebody, while that person is really only browsing the web, if using the connection at all. By having at least a *small* md5/MMH/UMAC signature on the packet this problem gets solved and the packet can be quietly dropped at the tunnelserver. btw typo in the draft (sect 4, security): 8<--------- Creating tunnel state based on the first UDP packet ___is can___ open the server to a DoS attack with spoofed source addresses. --------->8 As none of the following packets are verified, anybody who is able to send a spoofed packet, which is very commonly possible with most networks not doing RPF and other mechanisms, every packet can be spoofed and sent out over the tunnelserver. Thus please add "can become the source of an untraceable ddos attack in case the infrastructure between the endpoints is not secure". As this protocol is for endpoints behind NAT's I guess there is also a very large assumption which can be made that the above is the case, thus roll up your sleeves when your friendly (ahem) neighbourhood kid finds out that he can use his 100k+ botnet* for some more 'action' in the new world... * these things also exist because the network administrator is either too busy/lazy or simply doesn't care about his network. For that matter I am waiting for them to start abusing Teredo and other public relays, as there is normally unconfigured only a few number of Teredo relays you don't want to imagine the effect it will have on them. It would boost IPv6 traffic a bit of course, but this is not the kind of traffic that people would like to see I think ;) Next to this security issue, the proposed protocol (is there a name for it, would make it easier to reference it) does not take care of the case where a user gets an IP address, starts a huge video stream, thus eg multicast udp packets at 2mbit/s, coming unacked to the endpoint. User disconnects/changes IP, which is a common case with ISP's who also limit their users to one IP address, they also usually have some nice change- your-ip-every-day tricks to get you to maybe buy a more expensive account, the next user getting this IP will then get this nice streams of 2mbit/s tunneled IPv6 traffic. And actually she didn't want to get 1 byte, maybe she is even paying for the bandwidth and thus is paying for a lot of unwanted traffic. Cash for the ISP, but not very nice for the user. In short: please add a heartbeat mechanism, which also allows one to change IP during the tunnel lifetime and thus seamlessy swap over to another IP. No, this is not to replace Mobile IP and no it is not intended to replace IPSEC, but it does make certain things much better without having to rely on two of the protocols which most OS's don't have/support nor can't use because of the NAT which they are behind. It has also already been proven that it is very easy to deploy the above described protocol and I actually I wonder why there is need for yet another one while the others are sufficient for the purposes requisted. But that could be me of course ;) > > Why is there a checksum in that newly proposed protocol anyway? > > There was a reason why checksumming was removed from the IPv6 headers ;= ) >=20 > It is the standard UDP checksum. The first two lines are the UDP=20 > header. Ah, I glanced over it too quickly, usually protocol descriptions don't include the upper layer protocol again, this more looks like a redefinition of UDP in this case... Greets, Jeroen --=-3aBKTVbwN0NtiQ1QvYRY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBwr74KaooUjM+fCMRAmmwAJ9mFNVPLbII84LdN9SQhVF3XMsgxgCgofdZ FBYgJVvpqS5My6HTSTAfgGA= =t/ks -----END PGP SIGNATURE----- --=-3aBKTVbwN0NtiQ1QvYRY-- --===============1329649839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1329649839==-- From v6tc-bounces@ietf.org Fri Dec 17 06:22:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06139; Fri, 17 Dec 2004 06:22:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfGJv-0000fe-Gs; Fri, 17 Dec 2004 06:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfGAI-0004It-Ac; Fri, 17 Dec 2004 06:20:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfG9i-0004Ah-TP for v6tc@megatron.ietf.org; Fri, 17 Dec 2004 06:20:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06015 for ; Fri, 17 Dec 2004 06:20:16 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfGIK-0000cN-HP for v6tc@ietf.org; Fri, 17 Dec 2004 06:29:14 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iBHBKGVu013522 for ; Fri, 17 Dec 2004 04:20:16 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I8V0018765RYI@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Fri, 17 Dec 2004 04:20:16 -0700 (MST) Received: from [192.168.1.4] ([83.113.219.105]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I8V007P265POK@mail.sun.net> for v6tc@ietf.org; Fri, 17 Dec 2004 04:20:15 -0700 (MST) Date: Fri, 17 Dec 2004 03:20:19 -0800 From: Alain Durand Subject: Re: [v6tc] Issue 1: Could we live with UDP encapsulation always on? In-reply-to: <1103281912.25975.87.camel@firenze.zurich.ibm.com> To: Jeroen Massar Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6D2CE1A0-5011-11D9-81E4-00039358A080@sun.com> <1103278369.25975.57.camel@firenze.zurich.ibm.com> <1103281912.25975.87.camel@firenze.zurich.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7BIT Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7BIT On Dec 17, 2004, at 3:11 AM, Jeroen Massar wrote: > You mean eg dailup users? Do those still exist? Also G3 phones don't > have this issue either with UMTS and other goodies being deployed, > coming upto speeds of most lower DSL lines... The issue is not so much speed but money. If there is a 7-10% overhead, this is not insignificant, regardless of bandwidth. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Dec 17 06:25:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06308; Fri, 17 Dec 2004 06:25:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfGMz-0000je-Kj; Fri, 17 Dec 2004 06:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfGD7-0004qi-LW; Fri, 17 Dec 2004 06:23:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfGC5-0004cL-Cx for v6tc@megatron.ietf.org; Fri, 17 Dec 2004 06:22:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06180 for ; Fri, 17 Dec 2004 06:22:43 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfGKi-0000ga-8Y for v6tc@ietf.org; Fri, 17 Dec 2004 06:31:40 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iBHBMidt015613 for ; Fri, 17 Dec 2004 04:22:44 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I8V002BJ69VEG@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Fri, 17 Dec 2004 04:22:43 -0700 (MST) Received: from [192.168.1.4] ([83.113.219.105]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I8V007P969SOK@mail.sun.net> for v6tc@ietf.org; Fri, 17 Dec 2004 04:22:43 -0700 (MST) Date: Fri, 17 Dec 2004 03:22:47 -0800 From: Alain Durand Subject: Re: [v6tc] Issue 1: Could we live with UDP encapsulation always on? In-reply-to: <1103281912.25975.87.camel@firenze.zurich.ibm.com> To: Jeroen Massar Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6D2CE1A0-5011-11D9-81E4-00039358A080@sun.com> <1103278369.25975.57.camel@firenze.zurich.ibm.com> <1103281912.25975.87.camel@firenze.zurich.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7BIT Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7BIT Please keep this discussion for the upcoming issue 3 thread: "Should some of this authentication mechanism "follow-on" atfer the tunnel set-up phase as finished?" To keep the discussion focussed, I will only introduce one issue at a time. - Alain. On Dec 17, 2004, at 3:11 AM, Jeroen Massar wrote: >> The assumption is that if you want to protect the payload, you'll want >> to use a real security mechanism -- this is not the place to >> (try to) invent one. > > You mean using IPSEC, which does not (easily) work over the NAT we > where > trying to cross in the first place ? :) > > Also I don't mean to protect the payload, I could not care less about > crypto, use SSH/HTTPS/TLS in the cases you need to crypt something. It > is about verification that the sender really send the packet which you > are going to forward for them. > > Because that is the issue here. Also expect people to abuse this > proposed protocol, just like they are abusing proto-41 by simply > spoofing packets and inserting them, causing some nice network traffic > spikes, being totally untraceable as there is no way to trace where > they > are coming from and one will think it is coming from the legit user, > who > is suddenly getting claims of sending a large ddos to somebody, while > that person is really only browsing the web, if using the connection at > all. > > By having at least a *small* md5/MMH/UMAC signature on the packet this > problem gets solved and the packet can be quietly dropped at the > tunnelserver. > > btw typo in the draft (sect 4, security): > 8<--------- > Creating tunnel state based on the first UDP packet ___is can___ open > the server to a DoS attack with spoofed source addresses. > --------->8 > > As none of the following packets are verified, anybody who is able to > send a spoofed packet, which is very commonly possible with most > networks not doing RPF and other mechanisms, every packet can be > spoofed > and sent out over the tunnelserver. Thus please add "can become the > source of an untraceable ddos attack in case the infrastructure between > the endpoints is not secure". > > As this protocol is for endpoints behind NAT's I guess there is also a > very large assumption which can be made that the above is the case, > thus > roll up your sleeves when your friendly (ahem) neighbourhood kid finds > out that he can use his 100k+ botnet* for some more 'action' in the new > world... > > * these things also exist because the network administrator is either > too busy/lazy or simply doesn't care about his network. > For that matter I am waiting for them to start abusing Teredo and other > public relays, as there is normally unconfigured only a few number of > Teredo relays you don't want to imagine the effect it will have on > them. > It would boost IPv6 traffic a bit of course, but this is not the kind > of > traffic that people would like to see I think ;) > > > Next to this security issue, the proposed protocol (is there a name for > it, would make it easier to reference it) does not take care of the > case > where a user gets an IP address, starts a huge video stream, thus eg > multicast udp packets at 2mbit/s, coming unacked to the endpoint. User > disconnects/changes IP, which is a common case with ISP's who also > limit > their users to one IP address, they also usually have some nice change- > your-ip-every-day tricks to get you to maybe buy a more expensive > account, the next user getting this IP will then get this nice streams > of 2mbit/s tunneled IPv6 traffic. And actually she didn't want to get 1 > byte, maybe she is even paying for the bandwidth and thus is paying for > a lot of unwanted traffic. Cash for the ISP, but not very nice for the > user. In short: please add a heartbeat mechanism, which also allows one > to change IP during the tunnel lifetime and thus seamlessy swap over to > another IP. > > No, this is not to replace Mobile IP and no it is not intended to > replace IPSEC, but it does make certain things much better without > having to rely on two of the protocols which most OS's don't > have/support nor can't use because of the NAT which they are behind. > It has also already been proven that it is very easy to deploy the > above > described protocol and I actually I wonder why there is need for yet > another one while the others are sufficient for the purposes requisted. > But that could be me of course ;) > >>> Why is there a checksum in that newly proposed protocol anyway? >>> There was a reason why checksumming was removed from the IPv6 >>> headers ;) >> >> It is the standard UDP checksum. The first two lines are the UDP >> header. > > Ah, I glanced over it too quickly, usually protocol descriptions don't > include the upper layer protocol again, this more looks like a > redefinition of UDP in this case... > > Greets, > Jeroen > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Dec 17 06:48:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08324; Fri, 17 Dec 2004 06:48:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfGjc-0001QH-Mk; Fri, 17 Dec 2004 06:57:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfGWr-0008Oh-0X; Fri, 17 Dec 2004 06:44:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfGP4-0006KF-Cx for v6tc@megatron.ietf.org; Fri, 17 Dec 2004 06:36:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07412 for ; Fri, 17 Dec 2004 06:36:07 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfGXg-00014x-41 for v6tc@ietf.org; Fri, 17 Dec 2004 06:45:05 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 7CE862400C; Fri, 17 Dec 2004 12:35:58 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27573-05; Fri, 17 Dec 2004 12:35:57 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id A89AB24008; Fri, 17 Dec 2004 12:35:57 +0100 (CET) Subject: Re: [v6tc] Issue 1: Could we live with UDP encapsulation always on? From: Jeroen Massar To: Alain Durand In-Reply-To: References: <6D2CE1A0-5011-11D9-81E4-00039358A080@sun.com> <1103278369.25975.57.camel@firenze.zurich.ibm.com> <1103281912.25975.87.camel@firenze.zurich.ibm.com> Organization: Unfix Date: Fri, 17 Dec 2004 12:35:53 +0100 Message-Id: <1103283353.25975.96.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1751368381==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc --===============1751368381== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7Duqui8qANY8Elrj8Hwq" --=-7Duqui8qANY8Elrj8Hwq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-12-17 at 03:20 -0800, Alain Durand wrote: > On Dec 17, 2004, at 3:11 AM, Jeroen Massar wrote: > > You mean eg dailup users? Do those still exist? Also G3 phones don't > > have this issue either with UMTS and other goodies being deployed, > > coming upto speeds of most lower DSL lines... >=20 > The issue is not so much speed but money. If there is a 7-10% overhead, > this is not insignificant, regardless of bandwidth. In general for 'office/home environments' aka webbrowsing and alike, it seems the trend is that packet length distribution is that about 40% of the packets is between the 0-400 size. the other 60% is in between 400-1200 with only relatively few packetlengths in tehe 1200-1400 range, one will have a peak for the 1500 size, thus completely full packets. On average, from the couple of graphs that I have I would estimate the packetlength to be around 600 bytes/packet. This is based on an ethernet (mtu=3D1500) environment though, thus the peek at 1500 will move downwards, relative to the mtu size of the environment. Also, when there is a high concentration of 'downloaders' it might well be that that the packetsize distribution shifts almost completely to the maximum mtu. All depends on the usage of the network and if you count packets or octets as an importance. There will always be some sort of overhead with encapsulation. But if you are thinking of that, make a new protocol number which would make it proto-41 or GRE, which did not work over NAT's. > Please keep this discussion for the upcoming issue 3 thread: > "Should some of this authentication mechanism "follow-on" after the=20 > tunnel set-up phase as finished?" > To keep the discussion focussed, I will only introduce one issue at a=20 > time. Ack, though if you want to minimize the header, you can't introduce any of those parts anymore because the header is to small ;) Greets, Jeroen --=-7Duqui8qANY8Elrj8Hwq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBwsSZKaooUjM+fCMRAs7cAKCD92I7GzxaRGwlytoLz5OWHsTN7wCeIdaZ BIA0L3L/n0dDfG9/0o0Bp8U= =L9el -----END PGP SIGNATURE----- --=-7Duqui8qANY8Elrj8Hwq-- --===============1751368381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1751368381==-- From v6tc-bounces@ietf.org Fri Dec 17 08:24:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16496; Fri, 17 Dec 2004 08:24:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfIEa-0004Si-Hh; Fri, 17 Dec 2004 08:33:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfI2H-00070K-Fl; Fri, 17 Dec 2004 08:20:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfHvz-00068v-3i for v6tc@megatron.ietf.org; Fri, 17 Dec 2004 08:14:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15574 for ; Fri, 17 Dec 2004 08:14:14 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfI4b-00048V-Qt for v6tc@ietf.org; Fri, 17 Dec 2004 08:23:11 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iBHDECdt018726 for ; Fri, 17 Dec 2004 06:14:12 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I8V002UKBFOEG@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Fri, 17 Dec 2004 06:14:12 -0700 (MST) Received: from [192.168.1.3] ([83.197.7.222]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I8V003INBFL4E@mail.sun.net> for v6tc@ietf.org; Fri, 17 Dec 2004 06:14:12 -0700 (MST) Date: Fri, 17 Dec 2004 05:14:15 -0800 From: Alain Durand Subject: Re: [v6tc] Issue 1: Could we live with UDP encapsulation always on? In-reply-to: <1103283353.25975.96.camel@firenze.zurich.ibm.com> To: Jeroen Massar Message-id: <8D1569B5-502D-11D9-81E4-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6D2CE1A0-5011-11D9-81E4-00039358A080@sun.com> <1103278369.25975.57.camel@firenze.zurich.ibm.com> <1103281912.25975.87.camel@firenze.zurich.ibm.com> <1103283353.25975.96.camel@firenze.zurich.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT On Dec 17, 2004, at 3:35 AM, Jeroen Massar wrote: >> The issue is not so much speed but money. If there is a 7-10% >> overhead, >> this is not insignificant, regardless of bandwidth. > > In general for 'office/home environments' aka webbrowsing and alike, it > seems the trend is that packet length distribution is that about 40% of > the packets is between the 0-400 size. the other 60% is in between > 400-1200 with only relatively few packetlengths in tehe 1200-1400 > range, > one will have a peak for the 1500 size, thus completely full packets. > On average, from the couple of graphs that I have I would estimate the > packetlength to be around 600 bytes/packet. This is very good data. However, VoIP has the potential to change this picture a lot. From what I'm told, the payload is typically 44 bytes... - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Wed Dec 22 09:50:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28965; Wed, 22 Dec 2004 09:50:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch7yD-0000KD-CI; Wed, 22 Dec 2004 10:00:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch7WV-0006nk-17; Wed, 22 Dec 2004 09:31:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch7Nm-00030q-OJ for v6tc@megatron.ietf.org; Wed, 22 Dec 2004 09:22:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25782 for ; Wed, 22 Dec 2004 09:22:28 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch7XS-0007Wh-3b for v6tc@ietf.org; Wed, 22 Dec 2004 09:32:31 -0500 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 iBMEMRO6031068 for ; Wed, 22 Dec 2004 15:22:27 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Dec 2004 15:22:30 +0100 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZAPCTDZB; Wed, 22 Dec 2004 15:22:27 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Dec 2004 15:22:27 +0100 Message-ID: X-Sybari-Trust: f000b700 96d33411 fa28c42c 00000138 From: "Karen E. Nielsen (AH/LMD)" To: v6tc@ietf.org Subject: RE: [v6tc] Issue 1: Could we live with UDP encapsulation always o n? Date: Wed, 22 Dec 2004 15:22:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 Dec 2004 14:22:30.0809 (UTC) FILETIME=[ABE3C890:01C4E831] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hi - Alain has asked me to sent this to the list. For what it's worth..... In what concerns Ipv6-UDP-IPv4 opposed to Ipv6-Ipv4, there are at least 3 things to consider: - radio overhead - compression mechanisms - implementation aspects Radio link overhead: Obviously radio people always want to have the smallest overhead possible. Having said that then in the worst case VoIP scenarios, that is, lots of packets of 44 bytes payload, this on the radio link results in a difference of packet sizes: With UDP encapsulation, 44 bytes of payload --> Packet size on radio: 44+8+20+8+40 + 12(link overhead) = 124 Without UDP encapsulation, 44 bytes of payload --> Packet size on radio 44+8+20+40 + 12(link overhead) = 116 Thus all in all an worst case excess in 7% in radio resource consumption. Compression mechanisms (e.g. ROCH): Should be investigated. Implementation aspects: I absolutely assume that we are talking about UDP-lite (no checksum calculations) >From an implementation aspects, I don't really like the UDP encapsulation (but it can be done of course). In routers (here tunnel servers) the next header value often determines whether the packet is sent to the control plane for higher layer processing. With UDP encapsulation either an additional UDP filtering step must be implemented in the forwarding plane or the packets will be sent to slow path processing. Neither of these alternatives are really promising (either they result in bad performance or in excessive development costs). In hosts the problem is probably not as bad performance wise. But it still complies badly with modular implementations, i.e. user plane higher layer processing opposed to kernel space interface processing. The stateful aspect is not good, but scalability wise it may not perform any worse than a MIP Home Agent. The business case for making high performance Home Agents may be much better than the corresponding one for transition mechanisms, though. Semi-conclusion: Now worst case 7% "waste" of radio resources is certainly not negligible business wise, but it should not be a showstopper. This especially given that the bandwidths of the radio links are ever increasing AND that preferably only a small portion of the traffic over the link will be tunnelling traffic. Personally, I am much more concerned with the implementation aspects in end-nodes and routers. I cannot say that any of this is show-stopper candidates, but all in all it doesn't make v6-udp-v4 seem very attractive compared to v6-in-v4 the mechanisms we work with today. BR, Karen _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Wed Dec 22 10:18:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02746; Wed, 22 Dec 2004 10:18:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch8Pq-0001Nn-3O; Wed, 22 Dec 2004 10:28:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch8Dd-0005lC-NT; Wed, 22 Dec 2004 10:16:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch7ye-0002ko-QF for v6tc@megatron.ietf.org; Wed, 22 Dec 2004 10:00:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29671 for ; Wed, 22 Dec 2004 10:00:34 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch88K-0000cW-5b for v6tc@ietf.org; Wed, 22 Dec 2004 10:10:37 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBMF02w31083; Wed, 22 Dec 2004 17:00:02 +0200 Date: Wed, 22 Dec 2004 17:00:02 +0200 (EET) From: Pekka Savola To: "Karen E. Nielsen (AH/LMD)" Subject: RE: [v6tc] Issue 1: Could we live with UDP encapsulation always o n? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On Wed, 22 Dec 2004, Karen E. Nielsen (AH/LMD) wrote: > In routers (here tunnel servers) the next header value often > determines whether the packet is sent to the control plane for higher layer processing. > With UDP encapsulation either > an additional UDP filtering step must be implemented in the forwarding > plane or the packets will be sent > to slow path processing. Neither of these alternatives are really > promising (either they result in bad performance or in excessive development costs). I'm not sure if I understand what you're saying. Whether or not the router should process the packet depends on the destination address or if it has router alert hop-by-hop option. Or are you referring to router implementations which perform IPv6-in-IPv4 in hardware (without control plane), but could not do the same to IPv6-in-IPv4[UDP] ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Wed Dec 22 10:36:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05241; Wed, 22 Dec 2004 10:36:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch8h3-000205-Pi; Wed, 22 Dec 2004 10:46:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch8PJ-0004KP-2C; Wed, 22 Dec 2004 10:28:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch8LU-0002m8-Bn for v6tc@megatron.ietf.org; Wed, 22 Dec 2004 10:24:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03606 for ; Wed, 22 Dec 2004 10:24:09 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch8VA-0001YZ-Cx for v6tc@ietf.org; Wed, 22 Dec 2004 10:34:13 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Dec 2004 16:33:56 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBMFNDfi004312; Wed, 22 Dec 2004 16:23:14 +0100 (MET) Received: (from otroan@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA15600; Wed, 22 Dec 2004 15:23:13 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Pekka Savola Subject: Re: [v6tc] Issue 1: Could we live with UDP encapsulation always o n? References: From: Ole Troan Date: Wed, 22 Dec 2004 15:23:13 +0000 In-Reply-To: (Pekka Savola's message of "Wed, 22 Dec 2004 17:00:02 +0200 (EET)") Message-ID: <7t51xdi8ihq.fsf@mrwint.cisco.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 >> In routers (here tunnel servers) the next header value often >> determines whether the packet is sent to the control plane for higher layer processing. >> With UDP encapsulation either >> an additional UDP filtering step must be implemented in the forwarding >> plane or the packets will be sent >> to slow path processing. Neither of these alternatives are really >> promising (either they result in bad performance or in excessive development costs). > > I'm not sure if I understand what you're saying. > > Whether or not the router should process the packet depends on the > destination address or if it has router alert hop-by-hop option. > > Or are you referring to router implementations which perform > IPv6-in-IPv4 in hardware (without control plane), but could not do the > same to IPv6-in-IPv4[UDP] ? I don't see the implementation problem here either. the packets are already channelled off on a branch since those packets are for the router itself. I don't see a big difference in doing IPv6/UDP over IPv4 versus e.g IPv6/GRE over IPv4. /ot _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Wed Dec 22 12:25:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15380; Wed, 22 Dec 2004 12:25:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChAOr-0005MF-Ab; Wed, 22 Dec 2004 12:35:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChABM-0003si-72; Wed, 22 Dec 2004 12:21:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch9vB-0004iq-SV for v6tc@megatron.ietf.org; Wed, 22 Dec 2004 12:05:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13410 for ; Wed, 22 Dec 2004 12:05:06 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChA4s-0004fx-BN for v6tc@ietf.org; Wed, 22 Dec 2004 12:15:12 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iBMH55Vu025099 for ; Wed, 22 Dec 2004 10:05:05 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I9400L7ZVGG8L@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Wed, 22 Dec 2004 10:05:04 -0700 (MST) Received: from [192.168.1.4] ([83.197.5.178]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9400611VGD44@mail.sun.net> for v6tc@ietf.org; Wed, 22 Dec 2004 10:05:04 -0700 (MST) Date: Wed, 22 Dec 2004 09:05:04 -0800 From: Alain Durand To: v6tc@ietf.org Message-id: <9FBFA542-543B-11D9-B08B-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 2.2 (++) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7BIT Subject: [v6tc] background information / potential text for a charter for v6tc X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7BIT Problem statement: -------------------------- Enable ISPs (ISPs are defined as traditional broadband ISP, 3GPP, enterprise IT department, ...) who have upgraded their core network to v6 one way or another (using native links or tunnels) to offer production v6 service to their customers without upgrading all their access network at once (which can be cumbersome, expensive,...) Essentially, it decouples the issue to upgrade the core and the access networks. Automatic transition mechanisms like 6to4, teredo do not really leverage the infrastructure the ISP had put in place and offer little insight on how to gradually introduce native IPv6 in the access network. Configured tunnels are better suited for the job, and a number of deployment have been undertaken using the tunnel broker approach. However, the lack of standard on how to configure those tunnels remains a serious obstacle and manual configuration of all the parameters is out of reach of typical customers. ISP assumptions: ----------------------- It is assumed that the ISP has upgraded its core network so it can have global IPv6 connectivity. It is also assumed that the ISP has obtain its address space, either from the RIRs or an upstream ISP. The ISP can be small, large or extra large and span the entire planet. In that case, it is expected that a number of IPv6 point of presence will be deployed all over the word and that customers will 'connect' to the 'closest' one. Access media assumptions: -------------------------------------- No assumptions are made on the access network. They will have high or low bandwidth, high or low latency, high or low access cost, and there will be more or less secure. Especially in the case of wireless access network, confidentiality of the data cannot always be guaranteed. Address spoofing may or may not be a problem. Although those environment vary widely, it is expected that a single configuration protocol with a number of options can be designed to accommodate all the different cases. Customer assumptions: -------------------------------- Customers connecting with IPv6 to their ISP can have multiple configurations. The most common topologies expected to be encountered are: - a single node, directly attached to the ISP access network - a router, directly attached to the ISP access network - a router, behind an unmodifiable IPv4-only customer owned NAT The IPv4 addresses of the customer may change over time and be dynamically allocated. In the case of NAT environment, both the internal and the external addresses may be dynamically allocated. Another case to consider in the "roaming" user. When the customer is roaming within the ISP network(s), this is not really different than having a dynamic IPv4 address, except that the "nearest" ISP tunnel end point to use may be different. When the customer is roaming in another ISP network that does not offer IPv6 service, the "home" ISP may be willing to still offer tunneling service, however the security implications and the tunnel end point discovery mechanism to use will be different. Work items: ---------------- The problem can be decomposed into two independent areas: a) Having a way for an ISP to indicate that it is offering tunnel services to its direct customers, and how to invoke them. This is also known as tunnel end-point discovery. Due to the large variety of customer configuration expected, classic mechanisms like DHCP or SLP cannot be used (they would have a hard time to work through an unmodified NAT). This mechanism will be limited to the administrative domain controlled by the ISP and thus could not be used by customers roaming in other ISPs networks. b) Setting up of a tunnel, maybe with some negotiation about various parameters. For reasons of efficiency over very high latency networks, minimizing the number of packet exchanges is important, thus it is possible that some parameters that would normally be obtained over a subsequent DHCPv6 exchange (like IPv6 addresses and/or prefixes) would be optionally piggybacked into this configuration negotiation. Focus: --------- This work is not about creating a new transition mechanism, but to offer a standardized way to configure v6 over v4 tunnels, potentially using UDP as an extra layer of encapsulation to work over NAT. The work perform in a) and b) will be made generic but will focus essentially on v6 over v4 case. It is expected that it could be reused to help configuring v4 over v6 tunnels, but this will not be the priority of this working group. Way forward: ------------------ The v6tc working group will do three things in parallel: 1. Merge the three v6Ops requirement documents into a v6tc combined goal document, dropping things that are not necessary and anchoring each goal into characteristics of the different access networks considered. This document would also described targeted customer environments. The outcome of this work item is a Informational RFC. 2. Finalize the tunnel end point discovery mechanism tradeoff analysis document. This work will collect input from other related working groups, mainly DNSop and be published as an Informational RFC. When this will be understood, we'll standardize one solution. This will be published as an Standard Track RFC. 3. Use the issue tracker to document the different tradeoff in the solution space some of the issues initially explored are: - Could we live with UDP encapsulation always on? - Do we need mutual authentication? How strong should this be? - Should some of this authentication mechanism "follow-on" atfer the tunnel set-up phase as finished? - Should we embed some kind of signaling in the tunnel? - How much of the wheel are we going to re-invent? e.g. if we define a new packet exchange and there is a goal to minimize the total number of RTT needed, there is a temptation to piggy-back configuration information in this protocol that could be over wise obtained via DHCP... When those tradeoff will be understood, the v6tc working group will define a configuration protocol that will be published as Standard Track RFC. List of documents to be used originally as input to v6tc: ------------------------------------------------------------------------ -- http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf- reqs-01.txt draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt draft-ietf-v6ops-assisted-tunneling-requirements-01.txt draft-palet-v6ops-tun-auto-disc-02.txt Goals & Milestones: -------------------------- 01/2005: initial merged goals document 01/2005; initial tunnel end point discovery analysis document 01/2005: issue tracker set-up for configuration trade-off analysis 04/2005: initial configuration protocol specification document 06/2005: wg last on tunnel end point discovery analysis document 06/2005: initital tunnel end point discovery specification document 06/2005: wg last call on goals documents 12/2005: wg last call on configuration protocol specification document _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Wed Dec 22 14:46:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26574; Wed, 22 Dec 2004 14:46:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChCbQ-0000p7-WE; Wed, 22 Dec 2004 14:56:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChCKv-0002s7-6a; Wed, 22 Dec 2004 14:39:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChCGe-000752-J6 for v6tc@megatron.ietf.org; Wed, 22 Dec 2004 14:35:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25961 for ; Wed, 22 Dec 2004 14:35:26 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChCQJ-0000Wv-My for v6tc@ietf.org; Wed, 22 Dec 2004 14:45:32 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBMJYoa04931 for ; Wed, 22 Dec 2004 21:34:50 +0200 Date: Wed, 22 Dec 2004 21:34:50 +0200 (EET) From: Pekka Savola To: v6tc@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [v6tc] Tunnel endpoint discovery summary/tradeoffs X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hi, Below is my attempt to briefly summarize the situation with Tunnel endpoint discovery analysis, and some next steps. The most important document is draft-palet-v6ops-tun-auto-disc-02.txt. 1) It analyzes different mechanisms (proposed or existing) for discovering the tunnel endpoint: - anycast address methods - various forms of DNS lookups (reverse DNS to be added) - centralized omniscient brokers (not feasible) - DHCPv4 * not really feasible: oesn't work through NAT boxes, or unmodified DHCP servers - PPP (PPP not always used, ban on new extensions) - SLP * doesn't look promising (can't depend on multicast, etc.) The document maybe needs to better justify why existing solutions are not sufficient (after all, there has been a LOT of work in the IETF for service discovery in general). 2) It tries to describe the different scenarios how endpoint discovery could happen. This needs revision and discussion. In summary there are three options: a) no discovery: always assume the client pre-configures the endpoint information. b) discovery at the visited ISP only (compare to MIPv6 RO), or manually ("home agent" -like tunnel broker). The user/client implemetation will have to pick preference: 1) first try local, if fails, try manual config 2) manual config first, then try local 3) only local or only manual config This is a policy decision by the client, but no rocket science. E.g., Microsoft's 6to4/ISATAP implementations work in a similar manner this way. c) discovery of the endpoint everywhere (like 6to4 anycast address). This is likely very problematic both administratively, financially and technically. c) seems to be out of scope for this discovery mechanism. There are three other relevant documents: - draft-palet-v6ops-solution-tun-auto-disc-01.txt - draft-yamamoto-naptr-service-discovery-00.txt - draft-daniel-dhc-ipv6in4-opt-05.txt The first describes a combination of potential mechanisms for tunnel-endpoint discovery. This likely needs a lot of work and trimming down, to just one mechanism. DNS lookups use forward tree. The second describes using reverse DNS for service discovery. The third describes DHCPv4 based solution, but very likely it won't be a sufficient solution to the whole problem, and it may not be productive to specify multiple ones. At this point, the most important issue wrt. solutions is to understand key implications between using forward DNS (using the DNS search path) and reverse DNS (looking up information at your IP address), but the tradeoffs will be analyzed at more depth in the revision of draft-palet-v6ops-tun-auto-disc. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Wed Dec 22 15:58:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02821; Wed, 22 Dec 2004 15:58:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChDjD-0002z7-Ow; Wed, 22 Dec 2004 16:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChDMO-0006gu-LG; Wed, 22 Dec 2004 15:45:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChDIn-0004UC-Ao for v6tc@megatron.ietf.org; Wed, 22 Dec 2004 15:41:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01397 for ; Wed, 22 Dec 2004 15:41:42 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChDSW-0002If-DX for v6tc@ietf.org; Wed, 22 Dec 2004 15:51:49 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Dec 2004 15:41:09 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 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: [v6tc] Issue 1: Could we live with UDP encapsulation always o n? Date: Wed, 22 Dec 2004 15:41:08 -0500 Message-ID: Thread-Topic: [v6tc] Issue 1: Could we live with UDP encapsulation always o n? Thread-Index: AcToNYo4SWcGxfoTRbicmck4ZR3b6QAMEXrQ From: "Soliman, Hesham" To: "Karen E. Nielsen \(AH/LMD\)" , X-OriginalArrivalTime: 22 Dec 2004 20:41:09.0617 (UTC) FILETIME=[915AC610:01C4E866] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Karen,=20 > Semi-conclusion: > Now worst case 7% "waste" of radio resources=20 > is certainly not negligible business wise, but it should=20 > not be a showstopper. This especially given that the bandwidths=20 > of the radio links are ever increasing AND that preferably=20 > only a small > portion of the traffic over the link will be tunnelling traffic.=20 > Personally, I am much more concerned > with the implementation aspects in end-nodes and routers. =3D> 7 % is a _huge_ overhead. I'm much more concerned about that than implementation issues. Also, depending on the link layer, you might not be able to get the right bearer, given these BW requirements. Additionally, packet classification (if Diffserv is not used in the host) is=20 more difficult. Much worse than that, UDP encapsulation for=20 NAT traversal is very bad in wireless environments because=20 it will usually involve keepalives, which means that a terminal will never go dormant basically....here goes the battery lifetime!=20 Anyway, I think you'll find that 7 % is a showstopper for a lot of people and that they will need to either: - compress it, or=20 - Run native v6.=20 It might be an incentive to run native v6, but until then, it's a problem. Hesham >=20 > I cannot say that any of this is show-stopper candidates,=20 > but all in all > it doesn't make v6-udp-v4 seem very attractive=20 > compared to v6-in-v4 the mechanisms we work with today. > =20 > BR, Karen >=20 > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc >=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 _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Wed Dec 22 16:15:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03982; Wed, 22 Dec 2004 16:15:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChDzd-0003Vo-VG; Wed, 22 Dec 2004 16:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChDhQ-00024l-TP; Wed, 22 Dec 2004 16:07:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChDV5-0003dR-4Z for v6tc@megatron.ietf.org; Wed, 22 Dec 2004 15:54:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02530 for ; Wed, 22 Dec 2004 15:54:24 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChDeo-0002rb-8r for v6tc@ietf.org; Wed, 22 Dec 2004 16:04:31 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iBMKsMVu008587 for ; Wed, 22 Dec 2004 13:54:22 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I9500H8G62LH9@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Wed, 22 Dec 2004 13:54:22 -0700 (MST) Received: from [192.168.1.4] ([83.197.130.167]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I950007X62J7R@mail.sun.net> for v6tc@ietf.org; Wed, 22 Dec 2004 13:54:21 -0700 (MST) Date: Wed, 22 Dec 2004 12:54:22 -0800 From: Alain Durand Subject: Re: [v6tc] Tunnel endpoint discovery summary/tradeoffs In-reply-to: To: Pekka Savola Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Score: 2.2 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7BIT Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7BIT On Dec 22, 2004, at 11:34 AM, Pekka Savola wrote: > At this point, the most important issue wrt. solutions is to > understand key implications between using forward DNS (using the DNS > search path) and reverse DNS (looking up information at your IP > address), but the tradeoffs will be analyzed at more depth in the > revision of draft-palet-v6ops-tun-auto-disc. Another open issue is the re-use of existing RR in the DNS (regardless of the forward/reverse tree issue) or the creation of a new one, as recommended by the IAB. Summarizing the issues with forward DNS: - does not map the physical topology - does not work well for large domain - assume that the local domain configured at the customer site is the ISP one and not a private one Summarizing the issues with reverse DNS: - requires population of large trees, instead of just one record. - does not work well for addresses behind a NAT, some more or less ugly work around exists. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Dec 23 03:03:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16596; Thu, 23 Dec 2004 03:03:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChO68-000355-S5; Thu, 23 Dec 2004 03:13:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChNpX-000460-8T; Thu, 23 Dec 2004 02:56:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChNmf-0003RT-Hz for v6tc@megatron.ietf.org; Thu, 23 Dec 2004 02:53:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15895 for ; Thu, 23 Dec 2004 02:53:15 -0500 (EST) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChNwR-0002o0-UO for v6tc@ietf.org; Thu, 23 Dec 2004 03:03:24 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000670531.msg for ; Thu, 23 Dec 2004 08:59:04 +0100 Message-ID: <002e01c4e8c4$518e4990$1300a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: Subject: Re: [v6tc] Tunnel endpoint discovery summary/tradeoffs Date: Thu, 23 Dec 2004 08:52:13 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-1.2 required=5.0 tests=BAYES_00,MIME_BASE64_LATIN, MIME_BASE64_TEXT,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Thu, 23 Dec 2004 08:59:04 +0100 X-MDAV-Processed: consulintel.es, Thu, 23 Dec 2004 08:59:04 +0100 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1501524266==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 4.2 (++++) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --===============1501524266== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksIA0KDQpJIGFncmVlIHdpdGggUGVra2EncyB2aWV3IGFib3V0IHRoZSB0dW5uZWwgZW5kcG9p bnQgZGlzY292ZXJ5IGFuYWx5c2lzLiBTb21lIG5leHQgc3RlcHMgYXJlIHJlcXVpcmVkIG1haW5s eSB0byBhbmFseXplIGFkdmFudGFnZXMgYW5kIGRyYXdiYWNrcyBmb3IgcmV2ZXJzZS9mb3J3YXJk IEROUyBpbiBvcmRlciB0byBnZXQgYSAid2lubmVyIiBzb2x1dGlvbiwgaWYgcG9zc2libGUuDQoN CkluZGVlZCB3ZSBhcmUgKEpvcmRpIGFuZCBteXNlbGYpIHdvcmtpbmcgb24gdGhhdCBhbmQgaG9w ZWZ1bGx5IHdlJ2xsIGhhdmUgYSBuZXcgdXBkYXRlIG9mICB0aGUgZHJhZnQtcGFsZXQtdjZvcHMt dHVuLWF1dG8tZGlzYyBkb2N1bWVudCBzb29uLg0KDQpXZSB3b3VsZCBhcHByZWNpYXRlIGFueSBz dWdnZXN0aW9uIG9yIGlucHV0Lg0KDQpSZWdhcmRzDQpNaWd1ZWwNCg0KDQotLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBla2thIFNhdm9sYSIgPHBla2thc0BuZXRjb3JlLmZp Pg0KVG86IDx2NnRjQGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAyMiwgMjAw NCA4OjM0IFBNDQpTdWJqZWN0OiBbdjZ0Y10gVHVubmVsIGVuZHBvaW50IGRpc2NvdmVyeSBzdW1t YXJ5L3RyYWRlb2Zmcw0KDQoNCj4gSGksDQo+IA0KPiBCZWxvdyBpcyBteSBhdHRlbXB0IHRvIGJy aWVmbHkgc3VtbWFyaXplIHRoZSBzaXR1YXRpb24gd2l0aCBUdW5uZWwgDQo+IGVuZHBvaW50IGRp c2NvdmVyeSBhbmFseXNpcywgYW5kIHNvbWUgbmV4dCBzdGVwcy4NCj4gDQo+IFRoZSBtb3N0IGlt cG9ydGFudCBkb2N1bWVudCBpcyBkcmFmdC1wYWxldC12Nm9wcy10dW4tYXV0by1kaXNjLTAyLnR4 dC4NCj4gDQo+IDEpIEl0IGFuYWx5emVzIGRpZmZlcmVudCBtZWNoYW5pc21zIChwcm9wb3NlZCBv ciBleGlzdGluZykgZm9yIA0KPiBkaXNjb3ZlcmluZyB0aGUgdHVubmVsIGVuZHBvaW50Og0KPiAg IC0gYW55Y2FzdCBhZGRyZXNzIG1ldGhvZHMNCj4gICAtIHZhcmlvdXMgZm9ybXMgb2YgRE5TIGxv b2t1cHMgKHJldmVyc2UgRE5TIHRvIGJlIGFkZGVkKQ0KPiAgIC0gY2VudHJhbGl6ZWQgb21uaXNj aWVudCBicm9rZXJzIChub3QgZmVhc2libGUpDQo+ICAgLSBESENQdjQNCj4gICAgICogbm90IHJl YWxseSBmZWFzaWJsZTogb2Vzbid0IHdvcmsgdGhyb3VnaCBOQVQgYm94ZXMsIG9yDQo+ICAgICAg IHVubW9kaWZpZWQgREhDUCBzZXJ2ZXJzDQo+ICAgLSBQUFAgKFBQUCBub3QgYWx3YXlzIHVzZWQs IGJhbiBvbiBuZXcgZXh0ZW5zaW9ucykNCj4gICAtIFNMUA0KPiAgICAgKiBkb2Vzbid0IGxvb2sg cHJvbWlzaW5nIChjYW4ndCBkZXBlbmQgb24gbXVsdGljYXN0LCBldGMuKQ0KPiANCj4gVGhlIGRv Y3VtZW50IG1heWJlIG5lZWRzIHRvIGJldHRlciBqdXN0aWZ5IHdoeSBleGlzdGluZyBzb2x1dGlv bnMgYXJlIA0KPiBub3Qgc3VmZmljaWVudCAoYWZ0ZXIgYWxsLCB0aGVyZSBoYXMgYmVlbiBhIExP VCBvZiB3b3JrIGluIHRoZSBJRVRGIA0KPiBmb3Igc2VydmljZSBkaXNjb3ZlcnkgaW4gZ2VuZXJh bCkuDQo+IA0KPiAyKSBJdCB0cmllcyB0byBkZXNjcmliZSB0aGUgZGlmZmVyZW50IHNjZW5hcmlv cyBob3cgZW5kcG9pbnQgZGlzY292ZXJ5IA0KPiBjb3VsZCBoYXBwZW4uICBUaGlzIG5lZWRzIHJl dmlzaW9uIGFuZCBkaXNjdXNzaW9uLiAgSW4gc3VtbWFyeSB0aGVyZSANCj4gYXJlIHRocmVlIG9w dGlvbnM6DQo+IA0KPiAgYSkgbm8gZGlzY292ZXJ5OiBhbHdheXMgYXNzdW1lIHRoZSBjbGllbnQg cHJlLWNvbmZpZ3VyZXMgdGhlIGVuZHBvaW50DQo+ICAgICBpbmZvcm1hdGlvbi4NCj4gIGIpIGRp c2NvdmVyeSBhdCB0aGUgdmlzaXRlZCBJU1Agb25seSAoY29tcGFyZSB0byBNSVB2NiBSTyksDQo+ ICAgICBvciBtYW51YWxseSAoImhvbWUgYWdlbnQiIC1saWtlIHR1bm5lbCBicm9rZXIpLiAgVGhl IHVzZXIvY2xpZW50DQo+ICAgICBpbXBsZW1ldGF0aW9uIHdpbGwgaGF2ZSB0byBwaWNrIHByZWZl cmVuY2U6DQo+ICAgICAgMSkgZmlyc3QgdHJ5IGxvY2FsLCBpZiBmYWlscywgdHJ5IG1hbnVhbCBj b25maWcNCj4gICAgICAyKSBtYW51YWwgY29uZmlnIGZpcnN0LCB0aGVuIHRyeSBsb2NhbA0KPiAg ICAgIDMpIG9ubHkgbG9jYWwgb3Igb25seSBtYW51YWwgY29uZmlnDQo+ICAgICBUaGlzIGlzIGEg cG9saWN5IGRlY2lzaW9uIGJ5IHRoZSBjbGllbnQsIGJ1dCBubyByb2NrZXQgc2NpZW5jZS4NCj4g ICAgIEUuZy4sIE1pY3Jvc29mdCdzIDZ0bzQvSVNBVEFQIGltcGxlbWVudGF0aW9ucyB3b3JrIGlu IGEgc2ltaWxhcg0KPiAgICAgbWFubmVyIHRoaXMgd2F5Lg0KPiAgYykgZGlzY292ZXJ5IG9mIHRo ZSBlbmRwb2ludCBldmVyeXdoZXJlIChsaWtlIDZ0bzQgYW55Y2FzdCBhZGRyZXNzKS4NCj4gICAg IFRoaXMgaXMgbGlrZWx5IHZlcnkgcHJvYmxlbWF0aWMgYm90aCBhZG1pbmlzdHJhdGl2ZWx5LCBm aW5hbmNpYWxseQ0KPiAgICAgYW5kIHRlY2huaWNhbGx5Lg0KPiANCj4gIGMpIHNlZW1zIHRvIGJl IG91dCBvZiBzY29wZSBmb3IgdGhpcyBkaXNjb3ZlcnkgbWVjaGFuaXNtLg0KPiANCj4gDQo+IFRo ZXJlIGFyZSB0aHJlZSBvdGhlciByZWxldmFudCBkb2N1bWVudHM6DQo+ICAtIGRyYWZ0LXBhbGV0 LXY2b3BzLXNvbHV0aW9uLXR1bi1hdXRvLWRpc2MtMDEudHh0DQo+ICAtIGRyYWZ0LXlhbWFtb3Rv LW5hcHRyLXNlcnZpY2UtZGlzY292ZXJ5LTAwLnR4dA0KPiAgLSBkcmFmdC1kYW5pZWwtZGhjLWlw djZpbjQtb3B0LTA1LnR4dA0KPiANCj4gVGhlIGZpcnN0IGRlc2NyaWJlcyBhIGNvbWJpbmF0aW9u IG9mIHBvdGVudGlhbCBtZWNoYW5pc21zIGZvciANCj4gdHVubmVsLWVuZHBvaW50IGRpc2NvdmVy eS4gIFRoaXMgbGlrZWx5IG5lZWRzIGEgbG90IG9mIHdvcmsgYW5kIA0KPiB0cmltbWluZyBkb3du LCB0byBqdXN0IG9uZSBtZWNoYW5pc20uICBETlMgbG9va3VwcyB1c2UgZm9yd2FyZCB0cmVlLg0K PiANCj4gVGhlIHNlY29uZCBkZXNjcmliZXMgdXNpbmcgcmV2ZXJzZSBETlMgZm9yIHNlcnZpY2Ug ZGlzY292ZXJ5Lg0KPiANCj4gVGhlIHRoaXJkIGRlc2NyaWJlcyBESENQdjQgYmFzZWQgc29sdXRp b24sIGJ1dCB2ZXJ5IGxpa2VseSBpdCB3b24ndCBiZSANCj4gYSBzdWZmaWNpZW50IHNvbHV0aW9u IHRvIHRoZSB3aG9sZSBwcm9ibGVtLCBhbmQgaXQgbWF5IG5vdCBiZSANCj4gcHJvZHVjdGl2ZSB0 byBzcGVjaWZ5IG11bHRpcGxlIG9uZXMuDQo+IA0KPiBBdCB0aGlzIHBvaW50LCB0aGUgbW9zdCBp bXBvcnRhbnQgaXNzdWUgd3J0LiBzb2x1dGlvbnMgaXMgdG8gDQo+IHVuZGVyc3RhbmQga2V5IGlt cGxpY2F0aW9ucyBiZXR3ZWVuIHVzaW5nIGZvcndhcmQgRE5TICh1c2luZyB0aGUgRE5TIA0KPiBz ZWFyY2ggcGF0aCkgYW5kIHJldmVyc2UgRE5TIChsb29raW5nIHVwIGluZm9ybWF0aW9uIGF0IHlv dXIgSVAgDQo+IGFkZHJlc3MpLCBidXQgdGhlIHRyYWRlb2ZmcyB3aWxsIGJlIGFuYWx5emVkIGF0 IG1vcmUgZGVwdGggaW4gdGhlIA0KPiByZXZpc2lvbiBvZiBkcmFmdC1wYWxldC12Nm9wcy10dW4t YXV0by1kaXNjLg0KPiANCj4gLS0gDQo+IFBla2thIFNhdm9sYSAgICAgICAgICAgICAgICAgIllv dSBlYWNoIG5hbWUgeW91cnNlbHZlcyBraW5nLCB5ZXQgdGhlDQo+IE5ldGNvcmUgT3kgICAgICAg ICAgICAgICAgICAgIGtpbmdkb20gYmxlZWRzLiINCj4gU3lzdGVtcy4gTmV0d29ya3MuIFNlY3Vy aXR5LiAtLSBHZW9yZ2UgUi5SLiBNYXJ0aW46IEEgQ2xhc2ggb2YgS2luZ3MNCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2dGMgbWFpbGlu ZyBsaXN0DQo+IHY2dGNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZ0Yw0KPg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpN YWRyaWQgMjAwMyBHbG9iYWwgSVB2NiBTdW1taXQNClByZXNlbnRhdGlvbnMgYW5kIHZpZGVvcyBv biBsaW5lIGF0Og0KaHR0cDovL3d3dy5pcHY2LWVzLmNvbQ0KDQpUaGlzIGVsZWN0cm9uaWMgbWVz c2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25m aWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0 cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBpbmNs dWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0ZWQuDQoNCg0K --===============1501524266== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1501524266==--