From v6tc-bounces@ietf.org Wed Feb 9 03:28:02 2005 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 DAA09829; Wed, 9 Feb 2005 03:28:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CynWP-000199-Ae; Wed, 09 Feb 2005 03:48:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CynBf-0006FM-Gk; Wed, 09 Feb 2005 03:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyn81-0004o4-RW for v6tc@megatron.ietf.org; Wed, 09 Feb 2005 03:23:17 -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 DAA09590 for ; Wed, 9 Feb 2005 03:23:16 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CynRn-00014C-3n for v6tc@ietf.org; Wed, 09 Feb 2005 03:43:43 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j198MhN25529 for ; Wed, 9 Feb 2005 10:22:43 +0200 Date: Wed, 9 Feb 2005 10:22:43 +0200 (EET) From: Pekka Savola To: v6tc@ietf.org Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) 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: 10ba05e7e8a9aa6adb025f426bef3a30 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: a2c12dacc0736f14d6b540e805505a86 Folks -- There has been no discussion on this. Please send your comments on it. On Mon, 24 Jan 2005, Pekka Savola wrote: > The analysis/conclusions document on tunnel end-point discovery has been > re-focused and summarized to try to capture the critical discussions better. > > It would be extremely useful if folks, especially those ones which have not > participated in the discussions before, would take a look and send comments > on the list. The document should reflect most of the discussion on discovery > that have taken place both on- and off-list. > > ---------- Forwarded message ---------- > Date: Mon, 24 Jan 2005 15:39:12 -0500 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Analysis of IPv6 Tunnel End-point Discovery > Mechanisms > Author(s) : J. Palet, et al. > Filename : draft-palet-v6ops-tun-auto-disc-03.txt > Pages : 17 > Date : 2005-1-24 > > To be able to automate setting up IPv6-in-IPv4 tunnels, it is > important to be able to automatically determine the tunnel end-point > for the tunneling mechanism. This memo presents a short analysis and > conclusions on the different approaches for discovering the IPv6 > tunnel endpoint on a node. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-palet-v6ops-tun-auto-disc-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-palet-v6ops-tun-auto-disc-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc > -- 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 Feb 9 11:41:45 2005 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 LAA15791; Wed, 9 Feb 2005 11:41:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyvEG-0002yY-PA; Wed, 09 Feb 2005 12:02:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyuu5-0000t6-CV; Wed, 09 Feb 2005 11:41:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyuse-0000fW-JO for v6tc@megatron.ietf.org; Wed, 09 Feb 2005 11:39: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 LAA15700 for ; Wed, 9 Feb 2005 11:39:54 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyvCT-0002vV-7r for v6tc@ietf.org; Wed, 09 Feb 2005 12:00:27 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j19GdrOJ020093 for ; Wed, 9 Feb 2005 09:39:53 -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 <0IBN007RZKYGYL@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Wed, 09 Feb 2005 09:39:53 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBN0067DKYFHO@mail.sun.net> for v6tc@ietf.org; Wed, 09 Feb 2005 09:39:52 -0700 (MST) Date: Wed, 09 Feb 2005 08:39:50 -0800 From: Alain Durand Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) In-reply-to: To: Pekka Savola Message-id: <560530c2ab6bc8bbf983295719f6fc78@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7BIT On Feb 9, 2005, at 12:22 AM, Pekka Savola wrote: > Folks -- > > There has been no discussion on this. Please send your comments on it. > Ok, to get the ball rolling Section 1.1. I think the justification why we even need an automatic discovery mechanism is very weak. If no one can come with a better justification, it will be hard to justify working on this. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Mon Feb 14 08:09:06 2005 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 IAA29975; Mon, 14 Feb 2005 08:09:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0gJD-0001Uu-Ct; Mon, 14 Feb 2005 08:30:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0fvc-0001R6-Uj; Mon, 14 Feb 2005 08:06:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0fpo-0000uG-RT for v6tc@megatron.ietf.org; Mon, 14 Feb 2005 08:00:16 -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 IAA28832 for ; Mon, 14 Feb 2005 08:00: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 1D0gAd-0001CJ-S8 for v6tc@ietf.org; Mon, 14 Feb 2005 08:21:49 -0500 Received: from [10.10.10.100] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000781159.msg for ; Mon, 14 Feb 2005 14:00:55 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 14 Feb 2005 13:58:59 +0100 From: JORDI PALET MARTINEZ To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 217.126.187.160 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, Mon, 14 Feb 2005 14:00:59 +0100 X-MDAV-Processed: consulintel.es, Mon, 14 Feb 2005 14:01:03 +0100 X-Spam-Score: 2.9 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [v6tc] New I-D: Goals for Tunneling Configuration 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: 2.9 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hi, We submitted this morning the document "Goals for Tunneling Configuration". While is officially announced, you can find a copy at: http://www.consulintel.euro6ix.org/ietf/draft-palet-v6tc-goals-tunneling-00. txt It still requires a lot of work, specially in section 5, but comments are very welcome in the rest of the document. Regards, Jordi ************************************ Barcelona 2005 Global IPv6 Summit Call for Papers and information available 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 Feb 16 15:04:09 2005 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 PAA13691; Wed, 16 Feb 2005 15:04:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VkS-0007xe-34; Wed, 16 Feb 2005 15:26:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1UyP-0006x6-QD; Wed, 16 Feb 2005 14:36:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1SuY-00015p-P3 for v6tc@megatron.ietf.org; Wed, 16 Feb 2005 12:24:26 -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 MAA28682 for ; Wed, 16 Feb 2005 12:24:23 -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 1D1TFp-00029v-VW for v6tc@ietf.org; Wed, 16 Feb 2005 12:46:26 -0500 Received: from [10.10.10.100] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000789058.msg for ; Wed, 16 Feb 2005 18:25:11 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 16 Feb 2005 18:23:27 +0100 From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <200502161511.KAA19574@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 217.126.187.160 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, Wed, 16 Feb 2005 18:25:17 +0100 X-MDAV-Processed: consulintel.es, Wed, 16 Feb 2005 18:25:18 +0100 X-Spam-Score: 2.9 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Subject: [v6tc] RV:I-D ACTION:draft-palet-v6tc-goals-tunneling-00.txt 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: 2.9 (++) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit FYI Regards, Jordi ------ Mensaje reenviado De: "Internet-Drafts@ietf.org" Responder a: "Internet-Drafts@ietf.org" Fecha: Wed, 16 Feb 2005 10:11:32 -0500 Para: Asunto: I-D ACTION:draft-palet-v6tc-goals-tunneling-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Goals for Tunneling Configuration Author(s) : J. Palet, et al. Filename : draft-palet-v6tc-goals-tunneling-00.txt Pages : 21 Date : 2005-2-15 This memo describes the set of goals for a tunneling setup protocol that could be used in several network cases to jumpstart its IPv6 offering to its customers by providing them IPv6 connectivity through a simplistic tunneling mechanism. The basic network cases, which may have different sets of goals, are also introduced, including 3GPP and other Service Providers. Two cases are analyzed in the Service Provider scenario, one which apply to simplistic mechanism where the user is already authenticated by other network existing means, and another which also takes care of the user authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-palet-v6tc-goals-tunneling-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-palet-v6tc-goals-tunneling-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-palet-v6tc-goals-tunneling-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2005-2-16102157.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------ Fin del mensaje reenviado ************************************ Barcelona 2005 Global IPv6 Summit Call for Papers and information available 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 Fri Feb 25 15:49:13 2005 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 PAA00617; Fri, 25 Feb 2005 15:49:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4mOt-0002pd-8y; Fri, 25 Feb 2005 15:49:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4mNH-0000SR-Iu; Fri, 25 Feb 2005 15:47:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4mNF-0000SL-JE for v6tc@megatron.ietf.org; Fri, 25 Feb 2005 15:47: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 PAA00480 for ; Fri, 25 Feb 2005 15:47:43 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4mNP-0002nE-DW for v6tc@ietf.org; Fri, 25 Feb 2005 15:47:57 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 996B324061; Fri, 25 Feb 2005 21:47: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 13043-06; Fri, 25 Feb 2005 21:47:30 +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 D13072400D; Fri, 25 Feb 2005 21:47:29 +0100 (CET) Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) From: Jeroen Massar To: Pekka Savola In-Reply-To: References: Organization: Unfix Date: Fri, 25 Feb 2005 21:47:27 +0100 Message-Id: <1109364447.20338.47.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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="===============0287734214==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 --===============0287734214== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Dr81o23GSiBBe+7MZE2F" --=-Dr81o23GSiBBe+7MZE2F Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-02-09 at 10:22 +0200, Pekka Savola wrote: >Folks -- > >There has been no discussion on this. Please send your comments on=20 >it. I'd suggest you remove "Appendix B. Centralized Broker-based Solutions" completely, because that basically says that a setup like SixXS could not exist ("A global centralized broker is completely unfeasible.") I guess we've proven quite well that it works perfectly fine... And as it (trying to throw out of the window solutions that already work) is totally unrelated to the subject there really is no need to have it in there anyway. Btw, I'd like to again hint the authors of the document to well known and two tools used on the large scale: TSP & AICCU. Then some other nits: page 6: 8<-------- The drawbacks are: o Setting up an internal anycast route advertisement (e.g., in an enterprise) is likely a little bit more difficult than adding a name in the DNS or configuring DHCP. -------->8 If someone can't administer a network, they can't, that is logical. But that does not make it a drawback 8<---------- o The failure modes are a bit more complex than, e.g., just looking up a domain name, as one will have to send 1-2 packets to the anycast address to see if a working tunnel server is found or not. ----------->8 Ever ran a 'dig +trace ' ? Gee, how many packets are that? And remember that there are a lot of DNS servers, especially root and cctld that are anycasted already, now that leaves to wonder why the above is named as a drawback. See also Randy Bush's recent very early results on his anycast data gathering experiment. Why doesn't the DNS section have a 'advantages/drawbacks' section? Drawbacks: - see anycast, as it uses anycast with most DNS servers - Unpredictable that the ISP is able to configure it (same silly thing as = with the anycast one :) "3.4 PPP-based Solutions", I hope you do realize that many DSL providers already offer this solution to their paying customers? In general the client will make two PPP sessions: one for IPv4, the other for IPv6. And this works(tm). 8<-------- SLP has a number of drawbacks: * SLP is not really widely implemented or deployed. --------->8 Please speak to Novell and quite a number of other users of this very nice = protocol. Ever used a storage tank ? :) "Centralized brokers are a non-starter."..... see my note above. Also, as it is moved by to the Appendix it would need at least a reference = if you want to keep it in. Nevertheless Anycast is a clear winner, but I guess everybody already figur= ed that out even before somebody started putting his name in the above draft. You might have simply copied the text from the 6to4 anycast RFC... The security section should simply include the well known items: - networks are insecure - do ingress filtering - use SSL/TLS where possible "This work has been partially funded by the European Commission under the E= uro6IX project." There went my tax money.... Appendix A: 8<----------- a. A new server starts advertising the address but is refusing to serve the users: established tunnels continue to work, new tunnels cannot be established; tracerouting to the server identifies where the culprit is. ---------->8 Any broken setup of course breaks it. Greets, Jeroen --=-Dr81o23GSiBBe+7MZE2F Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCH47fKaooUjM+fCMRAnpUAKCYJaeMsh4VMZ9aAedIUVujFMUx5wCbBL8f em2mq1vvfx05Od1AUVAkZGo= =qjEu -----END PGP SIGNATURE----- --=-Dr81o23GSiBBe+7MZE2F-- --===============0287734214== 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 --===============0287734214==-- From v6tc-bounces@ietf.org Sat Feb 26 01:32:46 2005 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 BAA11984; Sat, 26 Feb 2005 01:32:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4vVg-0004kw-P9; Sat, 26 Feb 2005 01:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4vRI-0002UY-Jm; Sat, 26 Feb 2005 01:28:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4vRG-0002UT-90 for v6tc@megatron.ietf.org; Sat, 26 Feb 2005 01:28: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 BAA11158 for ; Sat, 26 Feb 2005 01:28:29 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4vRV-0004Xl-Qh for v6tc@ietf.org; Sat, 26 Feb 2005 01:28:47 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1Q6S9119561; Sat, 26 Feb 2005 08:28:11 +0200 Date: Sat, 26 Feb 2005 08:28:09 +0200 (EET) From: Pekka Savola To: Jeroen Massar Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) In-Reply-To: <1109364447.20338.47.camel@firenze.zurich.ibm.com> Message-ID: References: <1109364447.20338.47.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: 42e3ed3f10a1d8bef690f09da16f507a 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: d2b46e3b2dfbff2088e0b72a54104985 Thanks for comments -- inline... On Fri, 25 Feb 2005, Jeroen Massar wrote: > I'd suggest you remove "Appendix B. Centralized Broker-based Solutions" > completely, because that basically says that a setup like SixXS could > not exist ("A global centralized broker is completely unfeasible.") > > I guess we've proven quite well that it works perfectly fine... What works for a thousand users, informally, without any(?) service agreements with the main broker and PoPs does not scale up for hundreds of thousands of users and real usage throughout the Internet. It's just simply operationally and administratively unfeasible to consider there to be a single broker like tunnel-broker.net in the Internet to which _all_ the users would be directed to (owned and managed by someone). Nobody would want to create a serious business dependency on the continuity and correctness of such service. Do you agree with this? The draft is not saying that sixxs.net does not work. It's just saying that that model cannot be scaled up for the whole Internet and as such is not an interesting way to discover the broker at the local ISP. > Btw, I'd like to again hint the authors of the document to well known > and two tools used on the large scale: TSP & AICCU. At least TSP is compatible with this model. The point just is, how do you automatically discover the TSP broker? > Then some other nits: > > page 6: > 8<-------- > The drawbacks are: > > o Setting up an internal anycast route advertisement (e.g., in an > enterprise) is likely a little bit more difficult than adding a > name in the DNS or configuring DHCP. > -------->8 > > If someone can't administer a network, they can't, that is logical. > But that does not make it a drawback I personally agree with this -- as a routing operator, I don't see this as an issue, but some others do.. > 8<---------- > o The failure modes are a bit more complex than, e.g., just looking > up a domain name, as one will have to send 1-2 packets to the > anycast address to see if a working tunnel server is found or not. > ----------->8 > > Ever ran a 'dig +trace ' ? Gee, how many packets are that? Regular users who need to do debugging over the phone (who hardly know how to start a command prompt in their Windows) with their ISP don't :). They can, at the advise of the helpdesk, run 'nslookup', plus 'ping' and 'traceroute' if their firewalls don't block them. But personally, again, I agree with you. For expert users, this isn't all that difficult to debug at all. Maybe these drawbacks need to be put in a better perspective of the novice usage. > Why doesn't the DNS section have a 'advantages/drawbacks' section? > Drawbacks: > - see anycast, as it uses anycast with most DNS servers > - Unpredictable that the ISP is able to configure it (same silly thing as with the anycast one :) Because the drawbacks and advantages are listed under the subsections for two different DNS approaches. If some advantages or drawbacks would be generic for both of them, they could be put under 3.2. I'm not sure how relevant the anycast use with DNS is in this context. (The failure model with anycast DNS root and anycast, initial handshake TEP is a little bit different -- anycast DNS root has about 10 alternatives if one fails, this has none.) > "3.4 PPP-based Solutions", I hope you do realize that many DSL > providers already offer this solution to their paying customers? > In general the client will make two PPP sessions: one for IPv4, the > other for IPv6. And this works(tm). Sure, but as said, PPP is far from common denominator in configuring IPv4 connectivity, even if we could add options there (which we might not be able to do). > 8<-------- > SLP has a number of drawbacks: > * SLP is not really widely implemented or deployed. > --------->8 > > Please speak to Novell and quite a number of other users of this very nice protocol. > Ever used a storage tank ? :) The sentence lacks context, it should have said "deployed in ISP networks". > Nevertheless Anycast is a clear winner, but I guess everybody already figured that out > even before somebody started putting his name in the above draft. > You might have simply copied the text from the 6to4 anycast RFC... Sometimes folks have to run a full circle to arrive at the beginning. At least the analysis is now somewhere :) FWIW, I was personally convinced of search-path prefixes DNS first, but it seems to have more drawbacks than I thought, so the only IMHO option seems to be doing it with anycast, or not at all (e.g., manually). By the way, the use of anycast is different from 6to4 anycast RFC. We propose to use it for initial handshake only. > The security section should simply include the well known items: > - networks are insecure > - do ingress filtering > - use SSL/TLS where possible The generic insecurities of the networks are probably irrelevant for this draft. > "This work has been partially funded by the European Commission under the Euro6IX project." > There went my tax money.... Mine as well :) > Appendix A: > 8<----------- > a. A new server starts advertising the address but is refusing to > serve the users: established tunnels continue to work, new > tunnels cannot be established; tracerouting to the server > identifies where the culprit is. > ---------->8 > Any broken setup of course breaks it. Could you expand a bit? Would you suggest a rewording? -- 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 Sun Feb 27 12:08:09 2005 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 MAA13509; Sun, 27 Feb 2005 12:08:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5RuP-0001O9-SK; Sun, 27 Feb 2005 12:08:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Rnb-0004Xk-4h; Sun, 27 Feb 2005 12:01:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5RnZ-0004XY-Pa for v6tc@megatron.ietf.org; Sun, 27 Feb 2005 12:01:41 -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 MAA12789 for ; Sun, 27 Feb 2005 12:01:39 -0500 (EST) Received: from mariehamn.kurtis.pp.se ([213.204.46.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Ro9-0001F8-3p for v6tc@ietf.org; Sun, 27 Feb 2005 12:02:17 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mariehamn.kurtis.pp.se (Postfix) with ESMTP id 04656308F33; Sun, 27 Feb 2005 19:01:32 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <36C6B5D0-88E1-11D9-AC0B-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) Date: Sun, 27 Feb 2005 18:01:25 +0100 To: Pekka Savola X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-01-24, at 22.33, Pekka Savola wrote: > The analysis/conclusions document on tunnel end-point discovery has > been re-focused and summarized to try to capture the critical > discussions better. > > It would be extremely useful if folks, especially those ones which > have not participated in the discussions before, would take a look and > send comments on the list. The document should reflect most of the > discussion on discovery that have taken place both on- and off-list. Ok, so some comments. o Anycast I am far from convinced that anycast is useful for what we want to do. Mostly from a security POV. First of all, anyone could more or less insert a well-known prefix and then either snoop or spoof the traffic sent through it. Or it could spoof a TEP server for some advertised technology. Or it could effectively DoS out the service. The only way to protect against this is for the ISP to filter properly, or to use some sort of authentication in the discovery protocol. However, in order for the authentication to work, we would need to know who to authenticate to in the first place, which kind of does away with the automatic part. Second, a well-known anycast prefix is also easy to hijack. And this is being done with anycast prefixes today, and we rarely know of it. So what is the difference between this and what we for example do with the roots? Well, first of all, DNS is inherently more robust. If one of the 13 servers where to time-out, we can pick the next one. As for spoofing, they are as vulnerable as a TEP anycast prefix as I describe above. And this has happened(*), and is documented. The difference is that the TLD and/or root-servers being anycasted are monitored closely (partly because of this reason), and for this we also have a solution in DNSSEC. Another difference is that in DNS I can't know which server a resolver/end-system will query beforehand (although that is a bug and not a feature from DNS perspective). In general I think the security aspects of using anycast for this is poorly understood and documented and should be included. I actually worry enough about this to think this would be a show-stopper. o DNS I agree with the conclusions that has been discussed there that using forward lookups is to complex, and finding what to actually look up is inherently hard. Originally I was also very sceptical about the use of the reverse tree, but I am slowly changing my mind here. First of all, DNSSEC would/will actually prevent data protection and authentication (given the client supports it). Second, (from a selfish root-server perspective) it would force providers to populate the reverse tree with data, even for RFC118 addresses. o The problem in general The arguments have been brought forward that there are CPEs that run their own DNS-server on the CPE and that the boxes behind the CPE might be NATed (again) and therefor could not do the proper revers lookup. First of all, if the user is clever enough to run his own DNS server and whatnot on the CPE, he can sort out the manual configuration him-self. I would argue that Jeroen's home-network is out of scope. We can't solve everything. Second, the ISP can only reasonable be expected to solve the problem for resources that he can control. And I would also expect that the ISPs need to be able to authenticate the service one way or the other (but that is for the TEPD protocol), and that they would like to limit the number of queries they get to addresses they can trace. To me this means that the ISP should only reply to TEPD from addresses it has handed out. So how do we solve the CPEs that does NAT to a single ISP address? To me those boxes would have to do (in my preference) service discovery through reverse DNS on the ISP assigned address, and then act as a TEPD proxy (or server) to clients they are acting as NAT for. This could be as simple as populating the reverse tree that they have handed out to the clients and act as the resolver for those clients. Again, I think the automatic configuration scenario has to be limited to exactly that. Automatic clients. Using this in an environment where there is "some" automation and some static configuration is bound to make it way to complex. Perhaps I am oversimplifying. Best regards, - - kurtis - (*) One example that comes to mind was the "helpful" IXP operator that wanted to give better performance to the connected ISPs and announced some of the root-server prefixes to the member ISPs pointing to a local server that answered as root-server. Same could be done for TEPD. -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiH86qarNKXTPFCVEQKjYACePUxe6Cbqsfqxf8iYy4Ynqv1SKmYAn0Dy KR6BA9Y3+secpGVGj+gb/CUJ =Kd35 -----END PGP SIGNATURE----- _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Sun Feb 27 12:24:43 2005 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 MAA14754; Sun, 27 Feb 2005 12:24:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5SAT-0001fa-VI; Sun, 27 Feb 2005 12:25:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5S78-0002ya-FH; Sun, 27 Feb 2005 12:21:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5S77-0002yS-CK for v6tc@megatron.ietf.org; Sun, 27 Feb 2005 12:21:53 -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 MAA14566 for ; Sun, 27 Feb 2005 12:21:50 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5S7g-0001cv-BN for v6tc@ietf.org; Sun, 27 Feb 2005 12:22:29 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1RHLce08389; Sun, 27 Feb 2005 19:21:38 +0200 Date: Sun, 27 Feb 2005 19:21:38 +0200 (EET) From: Pekka Savola To: Kurt Erik Lindqvist Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) In-Reply-To: <36C6B5D0-88E1-11D9-AC0B-000A95928574@kurtis.pp.se> Message-ID: References: <36C6B5D0-88E1-11D9-AC0B-000A95928574@kurtis.pp.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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: 10ba05e7e8a9aa6adb025f426bef3a30 Thanks for your comments -- some responses inline. On Sun, 27 Feb 2005, Kurt Erik Lindqvist wrote: > o Anycast > > I am far from convinced that anycast is useful for what we want to do. > Mostly from a security POV. First of all, anyone could more or less > insert a well-known prefix and then either snoop or spoof the traffic > sent through it. Or it could spoof a TEP server for some advertised > technology. Or it could effectively DoS out the service. The only way > to protect against this is for the ISP to filter properly, [...] > > Second, a well-known anycast prefix is also easy to hijack. And this is > being done with anycast prefixes today, and we rarely know of it. Yes, a well-known anycast addresses have these issues for _interdomain_ routing, but there are at least two mitigating factors: - this is not meant to be [primarily] an _interdomain_ anycast address, just a well known anycast address (compare the scope to Masataka Ohta's well known DNS server address proposal -- not exactly the same but closer than e.g. 6to4 anycast address). The expectation is that whoever would be providing this service, it would typically _NOT_ be advertised out to the Internet (but only to its own customers), and likewise the operators would filter out the prefix in inbound if they have a server of their own. If they don't have a server of their own, they don't filter it of course -- but I doubt the user would get the service from anyone except close by, so I'm not sure if this is a big problem. - the anycast address is just used for initial handshake, to obtain the unicast address of the tunnel server. That is, even with route hijacking, you would not get the existing tunnels -- only those which were created after the hijacking. > In general I think the security aspects of using anycast for this is > poorly understood and documented and should be included. I actually > worry enough about this to think this would be a show-stopper. I agree that the security properties can be troublesome, and should probably be spelled out a bit better, but (in my personal opinion, at least), the above two factors shouldn't make this a really big problem. Does that change your evaluation ? > o The problem in general > > The arguments have been brought forward that there are CPEs that run > their own DNS-server on the CPE and that the boxes behind the CPE might > be NATed (again) and therefor could not do the proper revers lookup. > First of all, if the user is clever enough to run his own DNS server > and whatnot on the CPE, he can sort out the manual configuration > him-self. I would argue that Jeroen's home-network is out of scope. We > can't solve everything. I've personally argued the same way myself. Alain Durand, however, showed that at least some boxes (he mentioned Apple's wireless AP) would be, by default, advertising different names (e.g., search path of "lan") or doing NAT. I'm not sure whether this is true or how commonplace it is... > To me this means that the ISP should only reply to TEPD from > addresses it has handed out. Obviously, but clients behind NAT belong tot hat category as well. (In Section 2.1, second point, we exclude ISPs advertising TEP to other ISPs from scope) > So how do we solve the CPEs that does NAT > to a single ISP address? To me those boxes would have to do (in my > preference) service discovery through reverse DNS on the ISP assigned > address, and then act as a TEPD proxy (or server) to clients they are > acting as NAT for. This could be as simple as populating the reverse > tree that they have handed out to the clients and act as the resolver > for those clients. But that would require TEPD proxy support in the (NAT box) -- an upgrade. That seems like a non-starter? -- 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 Sun Feb 27 12:45:49 2005 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 MAA16558; Sun, 27 Feb 2005 12:45:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5SUu-00022f-82; Sun, 27 Feb 2005 12:46:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5STE-00023z-At; Sun, 27 Feb 2005 12:44:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5STC-00022I-Qa for v6tc@megatron.ietf.org; Sun, 27 Feb 2005 12:44:42 -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 MAA16502 for ; Sun, 27 Feb 2005 12:44:40 -0500 (EST) Received: from mariehamn.kurtis.pp.se ([213.204.46.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5STm-00021Y-Gt for v6tc@ietf.org; Sun, 27 Feb 2005 12:45:19 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mariehamn.kurtis.pp.se (Postfix) with ESMTP id 1BA92308F33; Sun, 27 Feb 2005 19:44:39 +0200 (EET) In-Reply-To: References: <36C6B5D0-88E1-11D9-AC0B-000A95928574@kurtis.pp.se> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <3AD39016-88E7-11D9-AC0B-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) Date: Sun, 27 Feb 2005 18:44:28 +0100 To: Pekka Savola X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-02-27, at 18.21, Pekka Savola wrote: > On Sun, 27 Feb 2005, Kurt Erik Lindqvist wrote: > Yes, a well-known anycast addresses have these issues for > _interdomain_ routing, but there are at least two mitigating factors: > > - this is not meant to be [primarily] an _interdomain_ anycast > address, just a well known anycast address (compare the scope to > Masataka Ohta's well known DNS server address proposal -- not exactly > the same but closer than e.g. 6to4 anycast address). > > The expectation is that whoever would be providing this service, it > would typically _NOT_ be advertised out to the Internet (but only to > its own customers), and likewise the operators would filter out the > prefix in inbound if they have a server of their own. If they don't > have a server of their own, they don't filter it of course -- but I > doubt the user would get the service from anyone except close by, so > I'm not sure if this is a big problem. I understand this is primarily for intradomain use, but I think my assertion still holds. By using a well-defined prefix that could be hijacked I have moved the trust of the forwarding plane to a single instance. This is what worries me. In a native world this is much harder to achieve as there is more or less an entire chain you need to modify (although that has been done). Also, you have provided a single attack-point needed in order to intercept/redirect all user traffic. I am still scared. > - the anycast address is just used for initial handshake, to obtain > the unicast address of the tunnel server. That is, even with route > hijacking, you would not get the existing tunnels -- only those which > were created after the hijacking. Agreed. >> In general I think the security aspects of using anycast for this is >> poorly understood and documented and should be included. I actually >> worry enough about this to think this would be a show-stopper. > > I agree that the security properties can be troublesome, and should > probably be spelled out a bit better, but (in my personal opinion, at > least), the above two factors shouldn't make this a really big > problem. Does that change your evaluation ? They definitely need to be spelled out, and I don't think that a "you shall filter" line will cut it in this case. >> o The problem in general >> >> The arguments have been brought forward that there are CPEs that run >> their own DNS-server on the CPE and that the boxes behind the CPE >> might >> be NATed (again) and therefor could not do the proper revers lookup. >> First of all, if the user is clever enough to run his own DNS server >> and whatnot on the CPE, he can sort out the manual configuration >> him-self. I would argue that Jeroen's home-network is out of scope. We >> can't solve everything. > > I've personally argued the same way myself. Alain Durand, however, > showed that at least some boxes (he mentioned Apple's wireless AP) > would be, by default, advertising different names (e.g., search path > of "lan") or doing NAT. I'm not sure whether this is true or how > commonplace it is... Uhm isn't the .lan for forward lookups? Still, if they would - their product simply doesn't support this... >> To me this means that the ISP should only reply to TEPD from >> addresses it has handed out. > > Obviously, but clients behind NAT belong tot hat category as well. > (In Section 2.1, second point, we exclude ISPs advertising TEP to > other ISPs from scope) No. It does belong to the ISP customer category, but it does not belong to the "equipment that has received configuration information from ISP" category. In Verbier I have a DSL line and a DSL router. My DSL router get's a single IP address from the ISP, default route, DNS-servers etc. That in turn will (through DHCP) provide my NATed boxes with the configuration information, effectively acting as an information proxy. >> So how do we solve the CPEs that does NAT >> to a single ISP address? To me those boxes would have to do (in my >> preference) service discovery through reverse DNS on the ISP assigned >> address, and then act as a TEPD proxy (or server) to clients they are >> acting as NAT for. This could be as simple as populating the reverse >> tree that they have handed out to the clients and act as the resolver >> for those clients. > > But that would require TEPD proxy support in the (NAT box) -- an > upgrade. That seems like a non-starter? We will need code deployed for any solution anyway. So we are now debating if it is more likely users upgrade their Windows boxes or their DSL routers. And we all know the majority updates neither, so then let's stick to manual configuration :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiIHA6arNKXTPFCVEQI4ywCgyaoWAtO85IOPVQM8hWhXMsUTfyUAniMg +GQdWNNS8gulef0nKxkHsRxx =i3en -----END PGP SIGNATURE----- _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Sun Feb 27 14:38:51 2005 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 OAA25125; Sun, 27 Feb 2005 14:38:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5UGH-00047I-L5; Sun, 27 Feb 2005 14:39:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5UDY-0004HB-WC; Sun, 27 Feb 2005 14:36:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5UDT-0004Gh-Pv; Sun, 27 Feb 2005 14:36: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 OAA24789; Sun, 27 Feb 2005 14:36:34 -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 1D5UE3-00044R-O4; Sun, 27 Feb 2005 14:37:12 -0500 Received: from [10.10.10.100] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000813143.msg; Sun, 27 Feb 2005 20:38:04 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 27 Feb 2005 20:35:47 +0100 From: JORDI PALET MARTINEZ To: "ietf@ietf.org" , "v6ops@ops.ietf.org" , "ipv6@ietf.org" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.2 required=5.0 tests=BAYES_00, NO_COST autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Sun, 27 Feb 2005 20:38:09 +0100 X-MDAV-Processed: consulintel.es, Sun, 27 Feb 2005 20:38:09 +0100 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: quoted-printable Subject: [v6tc] RV:Call for Papers - Next Global IPv6 Summit in Spain 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: 3.9 (+++) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable Hi all, Several people requested an extension of the deadline for the submission of the short abstracts for their presentations. So we decided to extend the deadline until midnight of March 4th. Please make sure to not miss it this time. We only require a title for your presentation and 3-4 lines short abstract. The final agenda will be announced at the end of the following week. Regards, Jordi Hi all, As indicated in the email below, the next Global IPv6 Summit in Spain, the bigger IPv6 European event, in its 4th edition (after a very successful organization and broad international attendance in 2001, 2002 and 2003), will be organized this time in Barcelona, next June 2005, with a expected audience over 2.600 key decisions makers from ICT sectors. The main target of the event is business oriented talks, as well as talks oriented to policy makers, information/knowledge society, education and public sectors. This Call for Papers doesn't require that you submit a complete paper (which is welcome also), but instead, a short plain text abstract of your presentation topic, by email. Talks regarding deployment experiences, new services and applications will be of key interest for the expected attendance, and hence highly encouraged. We believe that key topics will be also those regarding: 1) IPv6 and business 2) IPv6 and Broadband 3) New IPv6-based services and applications 4) IPv6 and the Digital Home 5) IPv6 and Multimedia, Voice/Video applications 6) IPv6, Mobility, Wireless and 3G 7) IPv6 and Ambient Intelligence/Ubiquitous Computing/Distributed Systems 8) IPv6 and GRIDs 9) IPv6 and logistics, transport and eSafety 10) IPv6 for eHealth, eGoverment, eLearning and other "e-whatever" 11) IPv6 and gamming 12) IPv6 and peer-to-peer 13) IPv6 and security 14) IPv6 and Open Source 15) IPv6 and marketing/branding Also topics regarding Standards, Research, Development and Innovation experiences are welcome, including R&D projects results. The Agenda will be drafted early in March, so the dead-line for submitting your topic is only until 25th February, but as said only a short abstract is required. If you're interested in participating, or you have any special idea, even if your topic is not in the list above, please don't hesitate to contact me (jordi.palet@consulintel.es) ASAP, so we can work out any options. Regards, Jordi PS: Please, feel free to circulate this email among your contacts. ------ Mensaje reenviado De: JORDI PALET MARTINEZ Responder a: Fecha: Mon, 07 Feb 2005 18:25:42 +0100 Para: "members@ipv6forum.com" , Asunto: Next Global IPv6 Summit in Spain Hi all, As I already informed a few weeks ago, the next Global IPv6 Summit in Spain will be held this time in Barcelona next June (instead of Madrid in March as previously forecasted). This will happen starting on June 6th, with a tutorial in the morning, the opening ceremony in the afternoon, with some keynotes and then 2-3 days of IPv6 conference, depending on the success of the call for papers. If required we can extend our event up to Friday 10th (total 4 days, plus opening ceremony, plus half day tutorial). In this occasion, we will try a completely new model, integrating the IPv6 conference in a bigger event, more business oriented, even when technical sessions will be still present. The "umbrella" event is Internet Global Congress (IGC), with has been organized in Barcelona already during the 6 previous years. The Internet Global Congress, the leading Internet and New Technologies congress in Spain, is organized by the Fundaci=F3 Barcelona Digital, a non-profit organization, which also provides space for exhibition and delivers the IGC awards for Digital Innovation (aimed to students and professionals with embryonic Internet projects, aims to be a launch platform for all those people involved in research and innovation in the field of Internet and the New Technologies). IGC provides us all the infrastructure for organizing the Global IPv6 Summit track, and we only need to manage our own agenda, and consequently our own call for papers (see next email). They also they care about all the issues related to registration, proceedings and publicity, at no cost for us. We expect that this will be the bigger IPv6 event in Europe during 2005, with an expected attendance over 2.600 people, which of course, will be able to attend not just to the IPv6 track but also to other IT tracks (already depicted at http://www.igcweb.net, then click at Program). The attendance is mainly CTOs, CEOs and other key decision makers related to ICT, so its a very nice opportunity for IPv6 in Europe to meet a large audience which probably has not been in touch with IPv6 until now. I count with the support from all of you, and please do not hesitate to let me know any ideas that you may have to make an even more successful event that what for sure we will have in a so nice city as Barcelona. More information will be soon available at http://www.ipv6-es.com and http://www.igcweb.net. Regards, Jordi ------ Fin del mensaje reenviado ************************************ Barcelona 2005 Global IPv6 Summit Call for Papers and information available 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 Mon Feb 28 05:24:25 2005 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 FAA00882; Mon, 28 Feb 2005 05:24:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5i5Q-0003Ia-AV; Mon, 28 Feb 2005 05:25:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5i3c-0003qY-8I; Mon, 28 Feb 2005 05:23:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5i3Z-0003qT-IY for v6tc@megatron.ietf.org; Mon, 28 Feb 2005 05:23: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 FAA00730 for ; Mon, 28 Feb 2005 05:23:14 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5i4H-0003Gf-Cg for v6tc@ietf.org; Mon, 28 Feb 2005 05:24:02 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 2FB77240D8; Mon, 28 Feb 2005 11:23:08 +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 04780-03; Mon, 28 Feb 2005 11:23:06 +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 A224C2400D; Mon, 28 Feb 2005 11:23:04 +0100 (CET) Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) From: Jeroen Massar To: Pekka Savola In-Reply-To: References: <1109364447.20338.47.camel@firenze.zurich.ibm.com> Organization: Unfix Date: Mon, 28 Feb 2005 11:20:53 +0100 Message-Id: <1109586053.9918.56.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 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="===============1749421011==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 --===============1749421011== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oJVmyp47DSy/xcUgFcnw" --=-oJVmyp47DSy/xcUgFcnw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2005-02-26 at 08:28 +0200, Pekka Savola wrote: >Thanks for comments -- inline... > >On Fri, 25 Feb 2005, Jeroen Massar wrote: >> I'd suggest you remove "Appendix B. Centralized Broker-based Solutions" >> completely, because that basically says that a setup like SixXS could >> not exist ("A global centralized broker is completely unfeasible.") >> >> I guess we've proven quite well that it works perfectly fine... > >What works for a thousand users, informally, without any(?) service=20 >agreements with the main broker and PoPs does not scale up for=20 >hundreds of thousands of users and real usage throughout the Internet. One does not have a SLA as one does not pay, if people pay, they get a SLA. Which is why not all the POPs are 'public' and open for everybody. Though that SLA lies at the ISP providing the PoP. Discovery should simply pick the 'best' available provider of a tunnel, whoever that might be. Due note: I really can't care less who provides it, as long as the enduser gets quality IPv6 connectivity :) This is why SixXS exists, to give an ISP the ability to provide IPv6 connectivity for free, they only have to make sure that the box is up and routing works, SixXS provisions the config with our standard tools. If they need SLA's and other things then we can arrange that. That is up to the provider.... >It's just simply operationally and administratively unfeasible to=20 >consider there to be a single broker like tunnel-broker.net in the=20 >Internet to which _all_ the users would be directed to (owned and=20 >managed by someone). Nobody would want to create a serious business=20 >dependency on the continuity and correctness of such service. > >Do you agree with this? One single source indeed can't, most likely, be done globally. Then again the IETF is also one instance, IANA is one instance and so are many other organization, who simply have subsections, providing the same service around the world without any problems. It would just need a lot of manpower and support. And as ISP's tend to be quite selfish and want to keep everything for themselves, indeed that won't work out, it is already a wonder that the complete IANA->RIR->LIR setup works for that matter. Though that more has to do with age I guess. So it really depends on the organization of such a thing if it can work... The internet seems to work and BGP really is without any certificates:) >The draft is not saying that sixxs.net does not work. It's just=20 >saying that that model cannot be scaled up for the whole Internet and=20 >as such is not an interesting way to discover the broker at the local=20 >ISP. And what about the case where you discovered (initial couple of packets) a TSP and did TSP/TIC or whatever method to build up your tunnel? With anycast this would really scale. >> Btw, I'd like to again hint the authors of the document to well known >> and two tools used on the large scale: TSP & AICCU. > >At least TSP is compatible with this model. The point just is, how do=20 >you automatically discover the TSP broker? Anycast :) See below. >> 8<---------- >> o The failure modes are a bit more complex than, e.g., just looking >> up a domain name, as one will have to send 1-2 packets to the >> anycast address to see if a working tunnel server is found or not. >> ----------->8 >> >> Ever ran a 'dig +trace ' ? Gee, how many packets are that? > >Regular users who need to do debugging over the phone (who hardly know=20 >how to start a command prompt in their Windows) with their ISP don't=20 >:). They can, at the advise of the helpdesk, run 'nslookup', plus=20 >'ping' and 'traceroute' if their firewalls don't block them. That was not my point. The point is that a full DNS lookup of anything will cause way more packets to be sent than the 1-2 packets to the anycast address. Then taking into account the fact that DNS is already anycasted, the above is quite bogos IMHO. Anycast is just a cool hip term of saying you have multiple servers servicing hosts on the same IP, nothing else. >> "3.4 PPP-based Solutions", I hope you do realize that many DSL >> providers already offer this solution to their paying customers? >> In general the client will make two PPP sessions: one for IPv4, the >> other for IPv6. And this works(tm). > >Sure, but as said, PPP is far from common denominator in configuring=20 >IPv4 connectivity, even if we could add options there (which we might=20 >not be able to do). Quite a large number of ISP's are using PPPoE to provision their DSL users. I know from experience that this at least is done in the Netherlands, Germany, France and Switzerland, there are bound to be more countries using this standard. >> Nevertheless Anycast is a clear winner, but I guess everybody already fi= gured that out >> even before somebody started putting his name in the above draft. >> You might have simply copied the text from the 6to4 anycast RFC... > >Sometimes folks have to run a full circle to arrive at the beginning.=20 >At least the analysis is now somewhere :) > >FWIW, I was personally convinced of search-path prefixes DNS first,=20 >but it seems to have more drawbacks than I thought, so the only IMHO=20 >option seems to be doing it with anycast, or not at all (e.g.,=20 >manually). > >By the way, the use of anycast is different from 6to4 anycast RFC. We=20 >propose to use it for initial handshake only. Which is also my idea ;) My current complete idea of doing the _discovery_ is currently the following: - DNS lookup tsp.ipv6.transition.service. to get the IP address (which could be anycasted) of the TSP/TIC whatever protocol we are going to use server. The DNS lookup could be secured using DNSSEC to make Kurtis (and also me) happy. If an ISP does not have the above zone in it's resolvers, or the user has configured itself to use the root servers, these will return NXDOMAIN and it will be game over here, as the service is not available anyway. If the user configured something wrong then that is his/her/it's mistake, can't change that in the same way that we don't want to automatically reconfigure ones firewall. We could then always fallback to a well-known address. - Talk to the well known or just resolved IP address, which may be anycasted. - Get a referal to the TSP/TIC whatever service that contains the configuration information. We know where we have to be .... on to another document which specifies what the, just discovered endpoint actually does, that is most likely providing the configuration information, using eg TSP or TIC. (Now... why can a tunnelbroker model not work? Do note that this is not the original 'website' model anymore, it is just a configuration service) >> Appendix A: >> 8<----------- >> a. A new server starts advertising the address but is refusing to >> serve the users: established tunnels continue to work, new >> tunnels cannot be established; tracerouting to the server >> identifies where the culprit is. >> ---------->8 >> Any broken setup of course breaks it. > >Could you expand a bit? Would you suggest a rewording? Just like the above, if one misconfigures something, then it is broken. If you turn off the box running your website, then indeed, the uberstable Apache does not work ;) On Sun, 2005-02-27 at 18:01 +0100, Kurt Erik Lindqvist wrote:=20 >o DNS > >I agree with the conclusions that has been discussed there that using=20 >forward lookups is to complex, and finding what to actually look up is=20 >inherently hard. Originally I was also very sceptical about the use of=20 >the reverse tree, but I am slowly changing my mind here. First of all,=20 >DNSSEC would/will actually prevent data protection and authentication=20 >(given the client supports it). Second, (from a selfish root-server=20 >perspective) it would force providers to populate the reverse tree with=20 >data, even for RFC118 addresses. You missed a 9: RFC1918. Next to that DNSSEC would indeed help a lot here, see the above. But if you want to be secure, one would really need SBGP or something similar too IMHO. Greets, Jeroen --=-oJVmyp47DSy/xcUgFcnw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCIvCFKaooUjM+fCMRAvvfAKCk+i++nRFWw35Ygtn/eLt6Bqe7WACffuaJ 1uil1Xundl6yHsp3rgtGKuc= =mzUO -----END PGP SIGNATURE----- --=-oJVmyp47DSy/xcUgFcnw-- --===============1749421011== 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 --===============1749421011==-- From v6tc-bounces@ietf.org Mon Feb 28 05:58:24 2005 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 FAA04937; Mon, 28 Feb 2005 05:58:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5icJ-00042b-2k; Mon, 28 Feb 2005 05:59:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5iYy-0003Fu-66; Mon, 28 Feb 2005 05:55:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5iYk-00038g-4V for v6tc@megatron.ietf.org; Mon, 28 Feb 2005 05:55: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 FAA04635 for ; Mon, 28 Feb 2005 05:55:27 -0500 (EST) Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5iZS-0003yN-2u for v6tc@ietf.org; Mon, 28 Feb 2005 05:56:15 -0500 Received: (qmail 15307 invoked by uid 1007); 28 Feb 2005 10:55:26 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=Kbr5lfZdXk0JSjLjQq7y5DGItpIGTAG1hErlI51vztvjcAGb+E/TW/ItLd5TZUj5 ; Date: Mon, 28 Feb 2005 11:55:26 +0100 From: Gert Doering To: Jeroen Massar Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) Message-ID: <20050228105526.GD84850@Space.Net> References: <1109364447.20338.47.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109364447.20338.47.camel@firenze.zurich.ibm.com> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: ea4ac80f790299f943f0a53be7e1a21a Hi, On Fri, Feb 25, 2005 at 09:47:27PM +0100, Jeroen Massar wrote: > "3.4 PPP-based Solutions", I hope you do realize that many DSL > providers already offer this solution to their paying customers? > In general the client will make two PPP sessions: one for IPv4, the > other for IPv6. And this works(tm). Please do not call this solution "in general". Our Dialup customers (ISDN or DSL with PPPoE/L2TP) run *one* PPP session, with IPCP and IPv6CP nicely coexisting. Of course it's possible to do DSL/PPPoE with two PPP sessions, possibly even to two different ISPs, but that's more a "niche" solution than using PPP the way it's designed - multiprotocol in a single session. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Mon Feb 28 06:05:30 2005 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 GAA05665; Mon, 28 Feb 2005 06:05:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5ijC-0004D7-6N; Mon, 28 Feb 2005 06:06:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5igo-0005SM-I1; Mon, 28 Feb 2005 06:03:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ign-0005SC-SW for v6tc@megatron.ietf.org; Mon, 28 Feb 2005 06:03: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 GAA05499 for ; Mon, 28 Feb 2005 06:03:47 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5ihV-0004AD-A4 for v6tc@ietf.org; Mon, 28 Feb 2005 06:04:35 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 290B42400D; Mon, 28 Feb 2005 12:03:44 +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 12965-06; Mon, 28 Feb 2005 12:03:43 +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 650BF24110; Mon, 28 Feb 2005 12:02:56 +0100 (CET) Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) From: Jeroen Massar To: Gert Doering In-Reply-To: <20050228105526.GD84850@Space.Net> References: <1109364447.20338.47.camel@firenze.zurich.ibm.com> <20050228105526.GD84850@Space.Net> Organization: Unfix Date: Mon, 28 Feb 2005 12:00:37 +0100 Message-Id: <1109588437.9918.80.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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="===============2074894145==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c --===============2074894145== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aNdnR5YlFPD2jUaC4emH" --=-aNdnR5YlFPD2jUaC4emH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-02-28 at 11:55 +0100, Gert Doering wrote: >Hi, > >On Fri, Feb 25, 2005 at 09:47:27PM +0100, Jeroen Massar wrote: >> "3.4 PPP-based Solutions", I hope you do realize that many DSL >> providers already offer this solution to their paying customers? >> In general the client will make two PPP sessions: one for IPv4, the >> other for IPv6. And this works(tm). > >Please do not call this solution "in general". Our Dialup customers=20 >(ISDN or DSL with PPPoE/L2TP) run *one* PPP session, with IPCP and IPv6CP=20 >nicely coexisting. Ah, thanks for the update, but the point is that you are using PPP, while the document says that nobody does. BTW, there are no problems anymore with CPE's that could not handle the IPv6 options? At least I recall something like this when doing it in the same session, which was the reason for the two separate sessions. Greets, Jeroen --=-aNdnR5YlFPD2jUaC4emH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCIvnVKaooUjM+fCMRArG/AJ4uC/Ans/WxgFWbNpJ1c1wXCk8DfACgkFKv iZPzhbwQQib7DWm1TvePkp4= =AFVn -----END PGP SIGNATURE----- --=-aNdnR5YlFPD2jUaC4emH-- --===============2074894145== 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 --===============2074894145==-- From v6tc-bounces@ietf.org Mon Feb 28 06:19:46 2005 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 GAA06731; Mon, 28 Feb 2005 06:19:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5ix0-0004Rr-Nt; Mon, 28 Feb 2005 06:20:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5itZ-0000PH-Vw; Mon, 28 Feb 2005 06:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5itY-0000PB-7w for v6tc@megatron.ietf.org; Mon, 28 Feb 2005 06:17:00 -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 GAA06489 for ; Mon, 28 Feb 2005 06:16:57 -0500 (EST) Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5iuH-0004Nt-HT for v6tc@ietf.org; Mon, 28 Feb 2005 06:17:45 -0500 Received: (qmail 21918 invoked by uid 1007); 28 Feb 2005 11:16:58 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=txERSMEU2TahX5FZ4dVm9m+ctCf25aZF0zqe360hXnh+/7GyT1Wofr9WHSs44Zt/ ; Date: Mon, 28 Feb 2005 12:16:58 +0100 From: Gert Doering To: Jeroen Massar Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) Message-ID: <20050228111658.GE84850@Space.Net> References: <1109364447.20338.47.camel@firenze.zurich.ibm.com> <20050228105526.GD84850@Space.Net> <1109588437.9918.80.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109588437.9918.80.camel@firenze.zurich.ibm.com> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: v6tc@ietf.org, Gert Doering 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: 9ed51c9d1356100bce94f1ae4ec616a9 Hi, On Mon, Feb 28, 2005 at 12:00:37PM +0100, Jeroen Massar wrote: > >Please do not call this solution "in general". Our Dialup customers > >(ISDN or DSL with PPPoE/L2TP) run *one* PPP session, with IPCP and IPv6CP > >nicely coexisting. > > Ah, thanks for the update, but the point is that you are using PPP, > while the document says that nobody does. Yeah. But in this specific scenario (ISP offering native v6 and PPP access), most of the transition worries are moot anyway - you just hook up your CPE and IPv6 works. > BTW, there are no problems anymore with CPE's that could not handle the > IPv6 options? At least I recall something like this when doing it in the > same session, which was the reason for the two separate sessions. I'm not sure. We enable IPv6 only on customer request, because we are worried about "confused CPEs that do not know how to handle IPv6CP" - so in our case, the CPE always knows how to handle it (and if not, the customer is expecting to beat it into submission). OTOH I know of at least one other german large-scale dial/l2tp ISP who has "just" enabled IPv6CP on all (!) dial-in sessions, and I haven't heard anything about large numbers of failed client sessions. So most PPP implementations around seem to be able to handle unknown protocol requests correctly (send PROTREJ, go on with IPv4). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Mon Feb 28 06:57:53 2005 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 GAA09873; Mon, 28 Feb 2005 06:57:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5jXt-00054a-Eb; Mon, 28 Feb 2005 06:58:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5jVQ-0001do-Al; Mon, 28 Feb 2005 06:56:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5jVP-0001dj-4N for v6tc@megatron.ietf.org; Mon, 28 Feb 2005 06:56:07 -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 GAA09709 for ; Mon, 28 Feb 2005 06:56:04 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5jW7-00052W-Gd for v6tc@ietf.org; Mon, 28 Feb 2005 06:56:53 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1SBtf829992; Mon, 28 Feb 2005 13:55:44 +0200 Date: Mon, 28 Feb 2005 13:55:41 +0200 (EET) From: Pekka Savola To: Jeroen Massar Subject: use of PPP [Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd)] In-Reply-To: <1109588437.9918.80.camel@firenze.zurich.ibm.com> Message-ID: References: <1109364447.20338.47.camel@firenze.zurich.ibm.com> <20050228105526.GD84850@Space.Net> <1109588437.9918.80.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: 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 On Mon, 28 Feb 2005, Jeroen Massar wrote: > On Mon, 2005-02-28 at 11:55 +0100, Gert Doering wrote: >> Hi, >> >> On Fri, Feb 25, 2005 at 09:47:27PM +0100, Jeroen Massar wrote: >>> "3.4 PPP-based Solutions", I hope you do realize that many DSL >>> providers already offer this solution to their paying customers? >>> In general the client will make two PPP sessions: one for IPv4, the >>> other for IPv6. And this works(tm). [...] > > Ah, thanks for the update, but the point is that you are using PPP, > while the document says that nobody does. The document says nothing ot that sort. There are multiple reasons why PPP has been discounted. A very important one is that PPP is not _sufficiently generic_ mechanism. There are lots of PPP users out there, yes. But there are even more those users that _don't_ use PPP. That makes the use of PPP a non-starter in this kind of scanario, where we want the mechanism to work whether or not PPP is being used. The other issues w/ PPP are: - PPP is not good if there is a NAT box in the middle. - there has been procedural resistance to extending PPP with new options The same considerations (except for willingness for extentions) apply to DHCPv4. -- 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 Mon Feb 28 07:40:43 2005 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 HAA14256; Mon, 28 Feb 2005 07:40:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5kDK-0005uz-DZ; Mon, 28 Feb 2005 07:41:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5kBR-00043I-Mb; Mon, 28 Feb 2005 07:39:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5kBP-00043D-Mn for v6tc@megatron.ietf.org; Mon, 28 Feb 2005 07:39:31 -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 HAA14071 for ; Mon, 28 Feb 2005 07:39:30 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5kC7-0005t1-AY for v6tc@ietf.org; Mon, 28 Feb 2005 07:40:18 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1SCdA430961; Mon, 28 Feb 2005 14:39:10 +0200 Date: Mon, 28 Feb 2005 14:39:10 +0200 (EET) From: Pekka Savola To: Jeroen Massar Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) In-Reply-To: <1109586053.9918.56.camel@firenze.zurich.ibm.com> Message-ID: References: <1109364447.20338.47.camel@firenze.zurich.ibm.com> <1109586053.9918.56.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: c83ccb5cc10e751496398f1233ca9c3a 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: 825e642946eda55cd9bc654a36dab8c2 On Mon, 28 Feb 2005, Jeroen Massar wrote: > One does not have a SLA as one does not pay, if people pay, they get a > SLA. Which is why not all the POPs are 'public' and open for everybody. > Though that SLA lies at the ISP providing the PoP. But in your model, the non-public ISPs will also have to depend on _your_ service, even if they don't pay anything for it? If _your_ server would be down, the ISP's business would be disrupted. Correct? This would be simply an unacceptable operational and administrative model for _real_ use. I hope you can see that. [...] > So it really depends on the organization of such a thing if it can > work... > > The internet seems to work and BGP really is without any certificates:) No, this does not work. What you're proposing, I think, is something similar to DNS root servers. Some people would be in charge of keeping up-to-date synchronized "tunnel broker root", to which you would be required to register all the other tunnel servers. Such a model has zero practical chance of being actually deployable within the next 10 years or so. This is not AFAICS comparable to BGP with or without certificates. >> The draft is not saying that sixxs.net does not work. It's just >> saying that that model cannot be scaled up for the whole Internet and >> as such is not an interesting way to discover the broker at the local >> ISP. > > And what about the case where you discovered (initial couple of packets) > a TSP and did TSP/TIC or whatever method to build up your tunnel? > With anycast this would really scale. With anycast used to discover the tunnel endpoint, and the TSP/TIC as "tunnel configuration" protocol, this might (or might not) fulfill the requirements for the solution. But that model is completely different from what sixxs.net and "one centralized broker in the Internet" models, because we don't assume there is a broker that knows everything about everything. >>> Btw, I'd like to again hint the authors of the document to well known >>> and two tools used on the large scale: TSP & AICCU. >> >> At least TSP is compatible with this model. The point just is, how do >> you automatically discover the TSP broker? > > Anycast :) See below. So, as anycast is already being described here, mentioning TSP or AICCU (whatever that is) is out of scope for this draft. Those describe the _configuration protocol_, not _tunnel end-point discovery_ mechanism. >> Regular users who need to do debugging over the phone (who hardly know >> how to start a command prompt in their Windows) with their ISP don't >> :). They can, at the advise of the helpdesk, run 'nslookup', plus >> 'ping' and 'traceroute' if their firewalls don't block them. > > That was not my point. The point is that a full DNS lookup of anything > will cause way more packets to be sent than the 1-2 packets to the > anycast address. The situation is different. DNS (w/UDP, without fragmentation) is stateless. If you send 2 DNS UDP packets to an anycast address and the first gets to server A and the second gets to server B, it still works. This would _not_ work. So (AFAIK) it has not been demonstrated that an anycast TEP discovery would simply "just work" as well as DNS roots. In addition, as Kurtis said, the model is a bit different. If one DNS root (which is anycasted) fails, there are about 12 others to try. Here, there would be no alternative. (Don't get me wrong, personally I believe the anycast issues are not really issues at all, but just trying to express the concerns the others have said.) > > - DNS lookup tsp.ipv6.transition.service. to get the IP address (which > could be anycasted) of the TSP/TIC whatever protocol we are going to use > server. The DNS lookup could be secured using DNSSEC to make Kurtis (and > also me) happy. > If an ISP does not have the above zone in it's resolvers, or the user > has configured itself to use the root servers, these will return > NXDOMAIN and it will be game over here, as the service is not available > anyway. If the user configured something wrong then that is his/her/it's > mistake, can't change that in the same way that we don't want to > automatically reconfigure ones firewall. > We could then always fallback to a well-known address. > This kind of generic approach is probably better proposed in somewhere like DNSOP. It has some .. issues. It could be used to redirect the users from a well-known anycast address to a local address (at the cost of 1-2 roundtrips or even more), but what's the point if you're able to do the same by just using anycast as well? (The only difference would be that instead of having to configure a prefix advertisement, you'd have to configure a DNS server as authorative, and be sure all the clients actually use that server and not implementa a caching server of their own -- i.e., not good.) -- 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 Mon Feb 28 10:22:31 2005 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 KAA00437; Mon, 28 Feb 2005 10:22:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5mjv-0000wI-SH; Mon, 28 Feb 2005 10:23:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5miS-0007Cx-BV; Mon, 28 Feb 2005 10:21:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5miR-0007CK-E7 for v6tc@megatron.ietf.org; Mon, 28 Feb 2005 10:21:47 -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 KAA00341 for ; Mon, 28 Feb 2005 10:21:45 -0500 (EST) Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=laptop2.kurtis.pp.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5mjC-0000uv-3R for v6tc@ietf.org; Mon, 28 Feb 2005 10:22:35 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id A415D7CC74D; Mon, 28 Feb 2005 16:21:34 +0100 (CET) In-Reply-To: <1109586053.9918.56.camel@firenze.zurich.ibm.com> References: <1109364447.20338.47.camel@firenze.zurich.ibm.com> <1109586053.9918.56.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <6AC79F9B-899C-11D9-94B3-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) Date: Mon, 28 Feb 2005 16:21:28 +0100 To: Jeroen Massar X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-02-28, at 11.20, Jeroen Massar wrote: > - DNS lookup tsp.ipv6.transition.service. to get the IP address (which > could be anycasted) of the TSP/TIC whatever protocol we are going to > use > server. The DNS lookup could be secured using DNSSEC to make Kurtis > (and > also me) happy. My concern is that you still have no idea if you are talking to the TSP server you think you are talking to. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiM2/aarNKXTPFCVEQLCBgCg9qHrue4AQ57DawCgJySIFwniHNgAoJUo lIRh5Yj+xTWq29XM6rhnuuwE =xxJ3 -----END PGP SIGNATURE----- _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Mon Feb 28 11:17:12 2005 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 LAA05184; Mon, 28 Feb 2005 11:17:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5nar-000295-N5; Mon, 28 Feb 2005 11:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5nXC-0006gZ-QL; Mon, 28 Feb 2005 11:14:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5nXB-0006gU-Fw for v6tc@megatron.ietf.org; Mon, 28 Feb 2005 11:14:13 -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 LAA04962 for ; Mon, 28 Feb 2005 11:14:11 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5nXw-000251-0R for v6tc@ietf.org; Mon, 28 Feb 2005 11:15:01 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 327EC2411D; Mon, 28 Feb 2005 17:14:06 +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 10075-01; Mon, 28 Feb 2005 17:13:59 +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 6E4572400D; Mon, 28 Feb 2005 17:10:26 +0100 (CET) Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) From: Jeroen Massar To: Kurt Erik Lindqvist In-Reply-To: <6AC79F9B-899C-11D9-94B3-000A95928574@kurtis.pp.se> References: <1109364447.20338.47.camel@firenze.zurich.ibm.com> <1109586053.9918.56.camel@firenze.zurich.ibm.com> <6AC79F9B-899C-11D9-94B3-000A95928574@kurtis.pp.se> Organization: Unfix Date: Mon, 28 Feb 2005 17:10:08 +0100 Message-Id: <1109607008.9918.149.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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="===============1827013558==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 --===============1827013558== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9Gc8hmz8pmu18ILZBmbU" --=-9Gc8hmz8pmu18ILZBmbU Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-02-28 at 16:21 +0100, Kurt Erik Lindqvist wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >On 2005-02-28, at 11.20, Jeroen Massar wrote: > >> - DNS lookup tsp.ipv6.transition.service. to get the IP address (which >> could be anycasted) of the TSP/TIC whatever protocol we are going to=20 >> use >> server. The DNS lookup could be secured using DNSSEC to make Kurtis=20 >> (and >> also me) happy. > >My concern is that you still have no idea if you are talking to the TSP=20 >server you think you are talking to. There is quite a funny problem here ;) The TEP server gets automatically discovered, thus everybody who deploys one would need to have the same cert, otherwise the client can't verify it being the 'correct' TEP. But with everybody having the cert, everybody can setup a bogus one... Maybe we should have shim6 finished before this ? Then one could use the identifier as the verification mechanism... Greets, Jeroen --=-9Gc8hmz8pmu18ILZBmbU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCI0JgKaooUjM+fCMRAq56AJ92ni6iCMOT9mvLk8IVf3nxW8p+7wCfT5Kt yPczxklNZPZRmx3KLwD1Rz4= =F0Oy -----END PGP SIGNATURE----- --=-9Gc8hmz8pmu18ILZBmbU-- --===============1827013558== 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 --===============1827013558==-- From v6tc-bounces@ietf.org Mon Feb 28 14:21:02 2005 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 OAA25260; Mon, 28 Feb 2005 14:21:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qSn-0006dm-EV; Mon, 28 Feb 2005 14:21:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qR5-0000OX-Pq; Mon, 28 Feb 2005 14:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qR4-0000OS-7f for v6tc@megatron.ietf.org; Mon, 28 Feb 2005 14:20: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 OAA25001 for ; Mon, 28 Feb 2005 14:20:05 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qRq-0006bn-Ib for v6tc@ietf.org; Mon, 28 Feb 2005 14:20:56 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1SJJf007770; Mon, 28 Feb 2005 21:19:43 +0200 Date: Mon, 28 Feb 2005 21:19:40 +0200 (EET) From: Pekka Savola To: Jeroen Massar Subject: server authentication? [Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd)] In-Reply-To: <1109607008.9918.149.camel@firenze.zurich.ibm.com> Message-ID: References: <1109364447.20338.47.camel@firenze.zurich.ibm.com> <1109586053.9918.56.camel@firenze.zurich.ibm.com> <6AC79F9B-899C-11D9-94B3-000A95928574@kurtis.pp.se> <1109607008.9918.149.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: c1c65599517f9ac32519d043c37c5336 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 On Mon, 28 Feb 2005, Jeroen Massar wrote: > On Mon, 2005-02-28 at 16:21 +0100, Kurt Erik Lindqvist wrote: >> My concern is that you still have no idea if you are talking to the TSP >> server you think you are talking to. > > There is quite a funny problem here ;) > > The TEP server gets automatically discovered, thus everybody who deploys > one would need to have the same cert, otherwise the client can't verify > it being the 'correct' TEP. But with everybody having the cert, > everybody can setup a bogus one... > > Maybe we should have shim6 finished before this ? Then one could use the > identifier as the verification mechanism... This issue is somewhat offtopic from _discovery_, but was mentioned briefly earlier under "mutual authentication", without much discussion. One can indeed raise a question how strongly the server should authenticate the client, and how strongly the client should authenticate the server. If the discovery mechanism has potential for giving ambiguous responses, it can be argued that the need for the client to authenticate the server is greater (but probably only slightly). There can be a number of authentication methods in the _configuration protocol_ (and not necessarily the endpoint discovery), but a major question is how many roundtrips the clients want to waste in the authentication. At least in some scenarios, doing this may not be all that interesting. As an example of configuration protocol client<->server authentication, draft-parent-v6tc-protocol-exploration-01.txt gives an overview how to use SEND or DHCPv6 + authentication. Both can guarantee that you are talking to the server you think you're talking to. So, this does not necessarily need to be addressed in the end-point discovery part of the solution, though the properties of the discovery may affect the requirements level of the authentication. -- 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 Mon Feb 28 19:14:57 2005 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 TAA24846; Mon, 28 Feb 2005 19:14:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5v3I-0004jJ-PD; Mon, 28 Feb 2005 19:15:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5v1y-0002rP-IT; Mon, 28 Feb 2005 19:14:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5v1w-0002rH-QG for v6tc@megatron.ietf.org; Mon, 28 Feb 2005 19:14:29 -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 TAA24813 for ; Mon, 28 Feb 2005 19:14:25 -0500 (EST) Received: from dsl093-039-075.pdx1.dsl.speakeasy.net ([66.93.39.75] helo=smtp-e.tycool.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5v2l-0004iw-M6 for v6tc@ietf.org; Mon, 28 Feb 2005 19:15:21 -0500 Received: from [192.168.1.2] (unknown [192.168.1.2]) by smtp-e.tycool.net (Postfix) with ESMTP id C7F41C; Mon, 28 Feb 2005 16:15:11 -0800 (PST) In-Reply-To: <3AD39016-88E7-11D9-AC0B-000A95928574@kurtis.pp.se> References: <36C6B5D0-88E1-11D9-AC0B-000A95928574@kurtis.pp.se> <3AD39016-88E7-11D9-AC0B-000A95928574@kurtis.pp.se> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <36bc4cc97467cd3905639298ccf72603@tycool.net> Content-Transfer-Encoding: 7bit From: Alain Durand Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) Date: Mon, 28 Feb 2005 16:14:20 -0800 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit On Feb 27, 2005, at 9:44 AM, Kurt Erik Lindqvist wrote: > mation proxy. > >>> So how do we solve the CPEs that does NAT >>> to a single ISP address? To me those boxes would have to do (in my >>> preference) service discovery through reverse DNS on the ISP assigned >>> address, and then act as a TEPD proxy (or server) to clients they are >>> acting as NAT for. This could be as simple as populating the reverse >>> tree that they have handed out to the clients and act as the resolver >>> for those clients. >> >> But that would require TEPD proxy support in the (NAT box) -- an >> upgrade. That seems like a non-starter? > > We will need code deployed for any solution anyway. So we are now > debating if it is more likely users upgrade their Windows boxes or > their DSL routers. And we all know the majority updates neither, so > then let's stick to manual configuration :-) The scenario here is a customer, behind a v4 NAT that will not be upgraded, add a $10 additional box to his home network. That box dig the tunnel to the ISP using TEPD and then advertise locally an IPv6 global prefix so all the other devices in the home get connectivity. It is still not clear to me if that box need to be fully automatically configured and why good old manual configuration of a DNS name pointing to the ISP TEP is not enough. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Mon Feb 28 20:22:08 2005 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 UAA29924; Mon, 28 Feb 2005 20:22:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5w6J-0005wP-0N; Mon, 28 Feb 2005 20:23:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5w3j-0004dv-Lo; Mon, 28 Feb 2005 20:20:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5w3f-0004cq-Ig for v6tc@megatron.ietf.org; Mon, 28 Feb 2005 20:20:22 -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 UAA29756 for ; Mon, 28 Feb 2005 20:20:16 -0500 (EST) Received: from dsl093-039-075.pdx1.dsl.speakeasy.net ([66.93.39.75] helo=smtp-e.tycool.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5w4T-0005ta-Ao for v6tc@ietf.org; Mon, 28 Feb 2005 20:21:10 -0500 Received: from [192.168.1.100] (unknown [192.168.1.100]) by smtp-e.tycool.net (Postfix) with ESMTP id 4748EC; Mon, 28 Feb 2005 17:20:57 -0800 (PST) In-Reply-To: References: <1109364447.20338.47.camel@firenze.zurich.ibm.com> <20050228105526.GD84850@Space.Net> <1109588437.9918.80.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <867bc1398ca9e29b510cc3c5136af882@tycool.net> Content-Transfer-Encoding: 7bit From: Alain Durand Subject: Re: use of PPP [Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd)] Date: Mon, 28 Feb 2005 17:20:02 -0800 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit PPP is L2 technology. If the box that wants v6 connectivity has access to it, great, problem solved, if not, this is simply not an option, unless you are talking about ppp over TCP, which is a whole different beast.` - Alain. On Feb 28, 2005, at 3:55 AM, Pekka Savola wrote: > On Mon, 28 Feb 2005, Jeroen Massar wrote: > >> On Mon, 2005-02-28 at 11:55 +0100, Gert Doering wrote: >>> Hi, >>> >>> On Fri, Feb 25, 2005 at 09:47:27PM +0100, Jeroen Massar wrote: >>>> "3.4 PPP-based Solutions", I hope you do realize that many DSL >>>> providers already offer this solution to their paying customers? >>>> In general the client will make two PPP sessions: one for IPv4, the >>>> other for IPv6. And this works(tm). > [...] >> >> Ah, thanks for the update, but the point is that you are using PPP, >> while the document says that nobody does. > > The document says nothing ot that sort. > > There are multiple reasons why PPP has been discounted. A very > important one is that PPP is not _sufficiently generic_ mechanism. > There are lots of PPP users out there, yes. But there are even more > those users that _don't_ use PPP. That makes the use of PPP a > non-starter in this kind of scanario, where we want the mechanism to > work whether or not PPP is being used. > > The other issues w/ PPP are: > - PPP is not good if there is a NAT box in the middle. > - there has been procedural resistance to extending PPP with new > options > > The same considerations (except for willingness for extentions) apply > to DHCPv4. > > -- > 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 > _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc