From mailman-bounces@ietf.org Sat Jan 1 06:00:50 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 GAA09119 for ; Sat, 1 Jan 2005 06:00:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkhBr-00079Z-VJ for v6tc-archive@ietf.org; Sat, 01 Jan 2005 06:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgFj-0007dY-1f for v6tc-archive@ietf.org; Sat, 01 Jan 2005 05:12:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: v6tc-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:03:27 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for v6tc-archive@ietf.org: List Password // URL ---- -------- v6tc@ietf.org uredbu https://www1.ietf.org/mailman/options/v6tc/v6tc-archive%40ietf.org From v6tc-bounces@ietf.org Tue Jan 11 05:48: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 FAA10930; Tue, 11 Jan 2005 05:48:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoJn9-0001nm-NC; Tue, 11 Jan 2005 06:02:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoJWu-0005fX-Rc; Tue, 11 Jan 2005 05:45:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoJV7-0005H0-5J for v6tc@megatron.ietf.org; Tue, 11 Jan 2005 05:43: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 FAA10602 for ; Tue, 11 Jan 2005 05:43:47 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoJir-0001ha-Pz for v6tc@ietf.org; Tue, 11 Jan 2005 05:58:05 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0BAhfdt024046 for ; Tue, 11 Jan 2005 03:43:41 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IA500ALJF4SJI@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Tue, 11 Jan 2005 03:43:41 -0700 (MST) Received: from [192.168.1.2] ([83.193.69.12]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA5005XBF4PUN@mail.sun.net> for v6tc@ietf.org; Tue, 11 Jan 2005 03:43:40 -0700 (MST) Date: Tue, 11 Jan 2005 02:43:37 -0800 From: Alain Durand To: v6tc@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7BIT Subject: [v6tc] Issue 2: service discovery: automatic or manual? 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: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7BIT Hi all, and happy new year! I'd like to start 2005 discussions with a new thread on service discovery. From the potential charter I sent last year: > Work items: > ---------------- > The problem can be decomposed into two independent areas: > a) Having a way for an ISP to indicate that it is offering tunnel services to its direct customers, > and how to invoke them. This is also known as tunnel end-point discovery. > Due to the large variety of customer configuration expected, classic mechanisms > like DHCP or SLP cannot be used (they would have a hard time to work through > an unmodified NAT). > This mechanism will be limited to the administrative domain controlled by the ISP > and thus could not be used by customers roaming in other ISPs networks. > > b) Setting up of a tunnel, maybe with some negotiation about various parameters. > For reasons of efficiency over very high latency networks, minimizing the number > of packet exchanges is important, thus it is possible that some parameters > that would normally be obtained over a subsequent DHCPv6 exchange > (like IPv6 addresses and/or prefixes) would be optionally piggybacked into this > configuration negotiation. It is clear that we want to make b) as automatic as possible, i.e. without any user intervention. The reason is that there are many parameters to negotiate and any manual intervention will be cumbersome and error prone and will inevitably result in stale entries. Now, it is not as clear, at least to me, that we need the same for a). - This is an instance of the general issue of ISP service discovery from the customer nodes that are potentially behind a NAT box. This problem has not been solved yet, maybe because it is too difficult, or because there is not enough incentive and manual configuration works just fine. If one look at other ISP-offered services, like email, web cache, SIP,... they are all configured manually by the users by entering simple names like smtp.myISP.com in the relevant boxes. And if this is too complex for the average user, the ISP is offering a CD-rom that contains a set-up program that does that for you. In the 3GPP case, many things are simply pre-configured and there is no discovery involved. - The various solutions that have been explored so far all have fatal flaws: - PPP/DHCP: does not work over the customer owned NAT - Well Known Global Anycast IPv4 address: can leak, requires non participating ISPs to actively filter out that address - Forward DNS: does not match physical topology; ISP domain name is not re-advertised by the customer owned NAT - Reverse DNS: does not work well for RFC1918 addresses. I know that there is a desire in the v6 community to provide fully automatic IPv6 service that gets activated transparently to the final users, but I'm wondering, in the context we are looking at: > Enable ISPs (ISPs are defined as traditional broadband ISP, 3GPP, enterprise IT department, ...) > who have upgraded their core network to v6 one way or another (using native links or tunnels) > to offer production v6 service to their customers without upgrading all their access network > at once (which can be cumbersome, expensive,...) if this is a realistic expectation or not... In other words, could we live with a solution where the user will have to manually input on its v6 host or router an address of the form v6TEP.myISP.com in the relevant form? (provided that would be the ONLY thing to input) - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Wed Jan 12 06:17:04 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 GAA02318; Wed, 12 Jan 2005 06:17:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cogip-0002CF-Ob; Wed, 12 Jan 2005 06:31:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CogN6-0001dc-9K; Wed, 12 Jan 2005 06:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CogGM-0008Lj-FJ for v6tc@megatron.ietf.org; Wed, 12 Jan 2005 06:02: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 GAA01314 for ; Wed, 12 Jan 2005 06:02:04 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CogUJ-0001rM-Kw for v6tc@ietf.org; Wed, 12 Jan 2005 06:16:35 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0CB1T223902; Wed, 12 Jan 2005 13:01:29 +0200 Date: Wed, 12 Jan 2005 13:01:29 +0200 (EET) From: Pekka Savola To: Alain Durand Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: 52f7a77164458f8c7b36b66787c853da I was hoping someone else would comment, but as that has not happened yet... On Tue, 11 Jan 2005, Alain Durand wrote: > - This is an instance of the general issue of ISP service discovery > from the customer > nodes that are potentially behind a NAT box. This problem has not > been solved yet, > maybe because it is too difficult, or because there is not enough > incentive and > manual configuration works just fine. The two last reasons seem likely. > If one look at other ISP-offered services, > like email, web cache, SIP,... they are all configured manually by > the users > by entering simple names like smtp.myISP.com in the relevant > boxes. Yes, while there exist a technical mechanism, SRV records, to do this already -- this is probably what SRV was intended for. It just hasn't been used by apps, or maybe the service names have not been "standardized" sufficiently, or the ISPs don't bother putting in SRV records, or this is deemed too marginal. > - Well Known Global Anycast IPv4 address: can leak, requires non participating > ISPs to actively filter out that address > - Forward DNS: does not match physical topology; ISP domain name > is not re-advertised by the customer owned NAT ISP domain name is not advertised, AFAICS, only if the customer manually configures his/her own domain name. Such user is probably sufficiently knowledgeable, one we might not need to care about (97% instead of 100% solution). Global anycast address might also be an option, but it might be more difficult to set up at ISPs, and the failure mode might be more difficult to manage. (If a DNS lookup fails, you get the failure immediately, but you have to wait for some kind of reply from the anycast address..) > In other words, could we live with a solution where the user will > have to manually input on its v6 host or router an address of the > form v6TEP.myISP.com in the relevant form? (provided that would be > the ONLY thing to input) I believe automatically discovering the tunneling capability is the most important part about the solution and it would not be good to have to leave it out. However, as you said earlier, this is orthogonal to the protocol/set-up procedure itself, so these can be worked in parallel, and if nothing comes up from this discovery, one could just decide to go for manual configuration instead. -- 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 Jan 12 08:26:05 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 IAA11256; Wed, 12 Jan 2005 08:26:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coijj-0005OV-BJ; Wed, 12 Jan 2005 08:40:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoiMQ-000872-0F; Wed, 12 Jan 2005 08:16:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoiBx-00052A-HN for v6tc@megatron.ietf.org; Wed, 12 Jan 2005 08:05: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 IAA08908 for ; Wed, 12 Jan 2005 08:05:40 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoiPx-0004gR-TM for v6tc@ietf.org; Wed, 12 Jan 2005 08:20:11 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0CD5dVu028013 for ; Wed, 12 Jan 2005 06:05:39 -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 <0IA700FAQGDEJS@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Wed, 12 Jan 2005 06:05:38 -0700 (MST) Received: from [192.168.1.2] ([83.193.70.251]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA7002A1GDBKC@mail.sun.net> for v6tc@ietf.org; Wed, 12 Jan 2005 06:05:38 -0700 (MST) Date: Wed, 12 Jan 2005 05:05:35 -0800 From: Alain Durand Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-reply-to: To: Pekka Savola Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Score: 2.2 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7BIT Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7BIT On Jan 12, 2005, at 3:01 AM, Pekka Savola wrote: > ISP domain name is not advertised, AFAICS, only if the customer > manually configures his/her own domain name. Such user is probably > sufficiently knowledgeable, one we might not need to care about (97% > instead of 100% solution). I just installed a Apple Airport network. By default, the DHCP server advertise internally the DNS domain "lan". Thus any DNS methods (using SRV or other record types) will look for things like _TEP.lan and fail miserably. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Wed Jan 12 09:47:58 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 JAA17515; Wed, 12 Jan 2005 09:47:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cok0w-0007Td-7B; Wed, 12 Jan 2005 10:02:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cojl2-00005O-9x; Wed, 12 Jan 2005 09:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CojbT-0006Ao-Mh for v6tc@megatron.ietf.org; Wed, 12 Jan 2005 09:36: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 JAA16863 for ; Wed, 12 Jan 2005 09:36:06 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CojpT-0007Eb-LV for v6tc@ietf.org; Wed, 12 Jan 2005 09:50:38 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0CEa4Vu018037 for ; Wed, 12 Jan 2005 07:36:04 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IA700FV7KK3PU@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Wed, 12 Jan 2005 07:36:03 -0700 (MST) Received: from [192.168.1.2] ([83.193.70.251]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA7007A3KK0OK@mail.sun.net> for v6tc@ietf.org; Wed, 12 Jan 2005 07:36:03 -0700 (MST) Date: Wed, 12 Jan 2005 06:35:58 -0800 From: Alain Durand Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-reply-to: To: Pekka Savola Message-id: <4642E1C0-64A7-11D9-8C90-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Score: 2.2 (++) 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: 2.2 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7BIT On Jan 12, 2005, at 3:01 AM, Pekka Savola wrote: >> If one look at other ISP-offered services, >> like email, web cache, SIP,... they are all configured manually >> by the users >> by entering simple names like smtp.myISP.com in the relevant >> boxes. > > Yes, while there exist a technical mechanism, SRV records, to do this > already -- this is probably what SRV was intended for. It just hasn't > been used by apps, or maybe the service names have not been > "standardized" sufficiently, or the ISPs don't bother putting in SRV > records, or this is deemed too marginal. Essentially the whole discovery issue is a bootstrapping one: How do you find the first anchor? To make my previous point clearer, in order to use SRV records in the DNS, you first need to know what the ISP domain name is. This information is NOT necessarily propagated to the customer nodes, especially in the case where a customer owned NAT is present in the picture. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Jan 13 04:27:33 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 EAA20398; Thu, 13 Jan 2005 04:27:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp1Ud-0006XO-6l; Thu, 13 Jan 2005 04:42:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp1Ex-00055r-BW; Thu, 13 Jan 2005 04:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp19d-0003pN-7x for v6tc@megatron.ietf.org; Thu, 13 Jan 2005 04:20:33 -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 EAA19996 for ; Thu, 13 Jan 2005 04:20:30 -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 1Cp1Nn-0006Nt-Lz for v6tc@ietf.org; Thu, 13 Jan 2005 04:35:13 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000705396.msg for ; Thu, 13 Jan 2005 10:20:42 +0100 Message-ID: <026001c4f951$255967e0$0a00a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <4642E1C0-64A7-11D9-8C90-00039358A080@sun.com> Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? Date: Thu, 13 Jan 2005 10:20:37 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Thu, 13 Jan 2005 10:20:45 +0100 X-MDAV-Processed: consulintel.es, Thu, 13 Jan 2005 10:20:45 +0100 X-Spam-Score: 2.2 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1005816845==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 --===============1005816845== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQp3ZSAoSm9yZGkgYW5kIG1lKSBhcmUgd29ya2luZyBpbiBhIG1ldGhvZCB0byBk aXNjb3ZlciB0aGUgSVNQIGRvbWFpbiBuYW1lIGluIG9yZGVyIHRvIHVzZSBTUlYgcmVjb3Jkcy4g VGhlIG1ldGhvZCBpcyBzaW1wbGUgYW5kIGl0IGNvdWxkIHdvcmsgaW4gYWxsIHRoZSBwb3NzaWJs ZSBzY2VuYXJpb3Mgd2hlcmUgdGhlIHVzZXIgbWlnaHQgYmUuDQoNCldlIG5lZWQgdG8gcmVmaW5l IGl0IGJlZm9yZSB0byBhbm5vdW5jZSBpdCwgYnV0IGluIHRoZSBuZXh0IGRheXMgd2Ugd2lsbCBo b3BlZnVsbHkgaGF2ZSBhIGRyYWZ0IHZlcnNpb24gdG8gc2hhcmUgd2l0aCBhbGwgb2YgeW91IGFu ZCByZWFkeSB0byByZWNlaXZlIGNvbW1lbnRzIGZyb20gYWxsIG9mIHlvdS4NCg0KUmVnYXJkcw0K TWlndWVsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQWxhaW4gRHVy YW5kIiA8QWxhaW4uRHVyYW5kQFN1bi5DT00+DQpUbzogIlBla2thIFNhdm9sYSIgPHBla2thc0Bu ZXRjb3JlLmZpPg0KQ2M6IDx2NnRjQGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5 IDEyLCAyMDA1IDM6MzUgUE0NClN1YmplY3Q6IFJlOiBbdjZ0Y10gSXNzdWUgMjogc2VydmljZSBk aXNjb3Zlcnk6IGF1dG9tYXRpYyBvciBtYW51YWw/DQoNCg0KPiANCj4gT24gSmFuIDEyLCAyMDA1 LCBhdCAzOjAxIEFNLCBQZWtrYSBTYXZvbGEgd3JvdGU6DQo+Pj4gSWYgb25lIGxvb2sgYXQgb3Ro ZXIgSVNQLW9mZmVyZWQgc2VydmljZXMsDQo+Pj4gICAgbGlrZSBlbWFpbCwgd2ViIGNhY2hlLCBT SVAsLi4uIHRoZXkgYXJlIGFsbCBjb25maWd1cmVkIG1hbnVhbGx5IA0KPj4+IGJ5IHRoZSB1c2Vy cw0KPj4+ICAgIGJ5IGVudGVyaW5nIHNpbXBsZSBuYW1lcyBsaWtlIHNtdHAubXlJU1AuY29tIGlu IHRoZSByZWxldmFudCANCj4+PiBib3hlcy4NCj4+DQo+PiBZZXMsIHdoaWxlIHRoZXJlIGV4aXN0 IGEgdGVjaG5pY2FsIG1lY2hhbmlzbSwgU1JWIHJlY29yZHMsIHRvIGRvIHRoaXMgDQo+PiBhbHJl YWR5IC0tIHRoaXMgaXMgcHJvYmFibHkgd2hhdCBTUlYgd2FzIGludGVuZGVkIGZvci4gIEl0IGp1 c3QgaGFzbid0IA0KPj4gYmVlbiB1c2VkIGJ5IGFwcHMsIG9yIG1heWJlIHRoZSBzZXJ2aWNlIG5h bWVzIGhhdmUgbm90IGJlZW4gDQo+PiAic3RhbmRhcmRpemVkIiBzdWZmaWNpZW50bHksIG9yIHRo ZSBJU1BzIGRvbid0IGJvdGhlciBwdXR0aW5nIGluIFNSViANCj4+IHJlY29yZHMsIG9yIHRoaXMg aXMgZGVlbWVkIHRvbyBtYXJnaW5hbC4NCj4gDQo+IEVzc2VudGlhbGx5IHRoZSB3aG9sZSBkaXNj b3ZlcnkgaXNzdWUgaXMgYSBib290c3RyYXBwaW5nIG9uZToNCj4gSG93IGRvIHlvdSBmaW5kIHRo ZSBmaXJzdCBhbmNob3I/DQo+IA0KPiBUbyBtYWtlIG15IHByZXZpb3VzIHBvaW50IGNsZWFyZXIs IGluIG9yZGVyIHRvIHVzZSBTUlYgcmVjb3JkcyBpbiB0aGUgDQo+IEROUywgeW91IGZpcnN0IG5l ZWQgdG8ga25vdw0KPiB3aGF0IHRoZSBJU1AgZG9tYWluIG5hbWUgaXMuIFRoaXMgaW5mb3JtYXRp b24gaXMgTk9UIG5lY2Vzc2FyaWx5IA0KPiBwcm9wYWdhdGVkDQo+IHRvIHRoZSBjdXN0b21lciBu b2RlcywgZXNwZWNpYWxseSBpbiB0aGUgY2FzZSB3aGVyZSBhIGN1c3RvbWVyIG93bmVkICANCj4g TkFUIGlzIHByZXNlbnQgaW4gdGhlIHBpY3R1cmUuDQo+IA0KPiAtIEFsYWluLg0KPiANCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2dGMg bWFpbGluZyBsaXN0DQo+IHY2dGNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZ0Yw0KPg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqDQpNYWRyaWQgMjAwMyBHbG9iYWwgSVB2NiBTdW1taXQNClByZXNlbnRhdGlvbnMgYW5kIHZp ZGVvcyBvbiBsaW5lIGF0Og0KaHR0cDovL3d3dy5pcHY2LWVzLmNvbQ0KDQpUaGlzIGVsZWN0cm9u aWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBv ciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5n LCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9u LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0ZWQuDQoNCg0K --===============1005816845== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1005816845==-- From v6tc-bounces@ietf.org Thu Jan 13 05:24:33 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 FAA23481; Thu, 13 Jan 2005 05:24:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp2NQ-0007au-Ei; Thu, 13 Jan 2005 05:39:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp261-0006HN-Eh; Thu, 13 Jan 2005 05:20:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp1yn-0004pf-VK for v6tc@megatron.ietf.org; Thu, 13 Jan 2005 05:13: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 FAA22973 for ; Thu, 13 Jan 2005 05:13:22 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp2Cp-0007OS-3T for v6tc@ietf.org; Thu, 13 Jan 2005 05:28:06 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 96F459118C; Thu, 13 Jan 2005 11:12:56 +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 04430-08; Thu, 13 Jan 2005 11:12:55 +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 54C8B9118B; Thu, 13 Jan 2005 11:12:54 +0100 (CET) Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: miguelangel.diaz@consulintel.es In-Reply-To: <026001c4f951$255967e0$0a00a8c0@consulintel.es> References: <4642E1C0-64A7-11D9-8C90-00039358A080@sun.com> <026001c4f951$255967e0$0a00a8c0@consulintel.es> Organization: Unfix Date: Thu, 13 Jan 2005 11:12:52 +0100 Message-Id: <1105611172.3310.138.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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="===============0741690520==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 --===============0741690520== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5a+2oCMJUe9iCNSbUSgS" --=-5a+2oCMJUe9iCNSbUSgS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-01-13 at 10:20 +0100, Miguel Angel Diaz wrote: > Hi all, >=20 > we (Jordi and me) are working in a method to discover > the ISP domain name in order to use SRV records. > The method is simple and it could work in all the possible > scenarios where the user might be. Let's take my simple home network: { ADSL provider } <-------> { Router } <------> {Hosts} Router is in this case a Linux box doing IPv4 NAT + IPv6 routing + DNS + DHCP for Hosts. Everything behind and including my Router has a reverse of unfix.org. (router=3Dpurgatory.unfix.org, hell.unfix.org, heaven.unfix.org) My (now former ISP) uses cistron.net for all it's routers, thus a traceroute would look like: hell.unfix.org (localhost) purgatory.unfix.org (router) blabla-dsl.cistron.net What is the "ISP domain name" in this scenario? Also, even though they have an IPv6 allocation, they do not provide it to their clients for several hardware/software reasons. So even if you could find out the correct domain name of the ISP, there would be no SRV records there anyway. Thus I am really wondering how you will try to make this work 'for all cases'. I am still convinced that anycast is the way and that a 'anycast service' prefix would be the best thing to have. Greets, Jeroen --=-5a+2oCMJUe9iCNSbUSgS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB5kmkKaooUjM+fCMRAk6zAJ4t6icR/iQro9KKSZh96v94TOmilACfQbE0 YoHlyYkLVRmvlgZvHoB7G8A= =kZ8C -----END PGP SIGNATURE----- --=-5a+2oCMJUe9iCNSbUSgS-- --===============0741690520== 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 --===============0741690520==-- From v6tc-bounces@ietf.org Thu Jan 13 05:44:16 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 FAA24519; Thu, 13 Jan 2005 05:44:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp2gu-0007y9-22; Thu, 13 Jan 2005 05:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp2NG-0000ZE-JU; Thu, 13 Jan 2005 05:38:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp2Hx-0008EF-7E for v6tc@megatron.ietf.org; Thu, 13 Jan 2005 05:33: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 FAA23929 for ; Thu, 13 Jan 2005 05:33:10 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp2W9-0007lM-4F for v6tc@ietf.org; Thu, 13 Jan 2005 05:47:54 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0DAXAdt005379 for ; Thu, 13 Jan 2005 03:33:10 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IA900AXJ3ZAER@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Thu, 13 Jan 2005 03:33:10 -0700 (MST) Received: from [192.168.1.2] ([83.193.2.220]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA9005C93Z7UN@mail.sun.net> for v6tc@ietf.org; Thu, 13 Jan 2005 03:33:10 -0700 (MST) Date: Thu, 13 Jan 2005 02:33:06 -0800 From: Alain Durand Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-reply-to: <1105611172.3310.138.camel@firenze.zurich.ibm.com> To: Jeroen Massar Message-id: <8347AA2C-654E-11D9-96E4-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4642E1C0-64A7-11D9-8C90-00039358A080@sun.com> <026001c4f951$255967e0$0a00a8c0@consulintel.es> <1105611172.3310.138.camel@firenze.zurich.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT On Jan 13, 2005, at 2:12 AM, Jeroen Massar wrote: > I am still convinced that anycast is the way and that a 'anycast > service' prefix would be the best thing to have. Don't forget that well known global anycast has problems too... If you are customer of an ISP that does not offer the v6 tunneling service, chances are that it will not filter out that well known address either and your packets will simply follow the default route and end up in a random places. Very difficult to debug. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Jan 13 05:56:04 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 FAA25528; Thu, 13 Jan 2005 05:56:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp2sL-0008Hp-3t; Thu, 13 Jan 2005 06:10:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp2Zg-0003Hr-MY; Thu, 13 Jan 2005 05:51:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp2TI-0001zH-8k for v6tc@megatron.ietf.org; Thu, 13 Jan 2005 05:44: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 FAA24569 for ; Thu, 13 Jan 2005 05:44:52 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp2hI-0007yW-6U for v6tc@ietf.org; Thu, 13 Jan 2005 05:59:36 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 48D379118F; Thu, 13 Jan 2005 11:44:41 +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 04551-03; Thu, 13 Jan 2005 11:44:41 +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 D2B839118E; Thu, 13 Jan 2005 11:44:40 +0100 (CET) Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: Alain Durand In-Reply-To: <8347AA2C-654E-11D9-96E4-00039358A080@sun.com> References: <4642E1C0-64A7-11D9-8C90-00039358A080@sun.com> <026001c4f951$255967e0$0a00a8c0@consulintel.es> <1105611172.3310.138.camel@firenze.zurich.ibm.com> <8347AA2C-654E-11D9-96E4-00039358A080@sun.com> Organization: Unfix Date: Thu, 13 Jan 2005 11:44:39 +0100 Message-Id: <1105613079.3310.142.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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="===============1082788345==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 --===============1082788345== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6+Qi/SeLnI1JkOqVew1T" --=-6+Qi/SeLnI1JkOqVew1T Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-01-13 at 02:33 -0800, Alain Durand wrote: > On Jan 13, 2005, at 2:12 AM, Jeroen Massar wrote: >=20 > > I am still convinced that anycast is the way and that a 'anycast > > service' prefix would be the best thing to have. >=20 > Don't forget that well known global anycast has problems too... >=20 > If you are customer of an ISP that does not offer the v6 tunneling=20 > service, > chances are that it will not filter out that well known address either > and your packets will simply follow the default route and end up > in a random places. Very difficult to debug. What is so difficult about: traceroute 2001:db8::1 (or 192.0.2.1 or whatever it gets). And what is so hard to debug about BGP anyway? Isn't this what happens daily when routing problems occur? It works for the a number of root DNS servers too. I made a long proposal once already but that was silently ignored, too bad as it would solve a *lot* of autoconfiguration, al in one go. Greets, Jeroen --=-6+Qi/SeLnI1JkOqVew1T Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB5lEXKaooUjM+fCMRAtZCAJ4+6zA7VU+jPTtS/2uFBFhbAPshaQCgnFUr 7sjCutL2UAvxIUoJ5DYfz10= =JZ5v -----END PGP SIGNATURE----- --=-6+Qi/SeLnI1JkOqVew1T-- --===============1082788345== 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 --===============1082788345==-- From v6tc-bounces@ietf.org Thu Jan 13 06:22:35 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 GAA28142; Thu, 13 Jan 2005 06:22:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp3Hx-0000Vm-SL; Thu, 13 Jan 2005 06:37:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp2ua-0000Yo-Hk; Thu, 13 Jan 2005 06:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp2ts-00008D-P0 for v6tc@megatron.ietf.org; Thu, 13 Jan 2005 06:12:24 -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 GAA26986 for ; Thu, 13 Jan 2005 06:12:21 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp382-0000E4-KD for v6tc@ietf.org; Thu, 13 Jan 2005 06:27:06 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0DBBes24262; Thu, 13 Jan 2005 13:11:42 +0200 Date: Thu, 13 Jan 2005 13:11:40 +0200 (EET) From: Pekka Savola To: Jeroen Massar Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-Reply-To: <1105611172.3310.138.camel@firenze.zurich.ibm.com> Message-ID: References: <4642E1C0-64A7-11D9-8C90-00039358A080@sun.com> <026001c4f951$255967e0$0a00a8c0@consulintel.es> <1105611172.3310.138.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: 7d33c50f3756db14428398e2bdedd581 Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Thu, 13 Jan 2005, Jeroen Massar wrote: > I am still convinced that anycast is the way and that a 'anycast > service' prefix would be the best thing to have. Considering the tradeoffs, this may be a feasible option. The main differences are in: 1) detecting if the service does not exist: i.e., how does the tunnel negotiation/set-up code detect if there is no service (e.g., the ISP might have a Null0 defalt route). A ping6 might be possible. (DNS is easier, because if you don't get an address back, you know it immediately.) 2) how to set it up: a DNS (or similar) solution does not require setting up the anycast address. The DNS approach would be slightly simpler in some circumstances, e.g., enterprises. -- 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 Thu Jan 13 07:33:15 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 HAA03238; Thu, 13 Jan 2005 07:33:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp4ON-0001zq-8Y; Thu, 13 Jan 2005 07:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp47C-00005L-UI; Thu, 13 Jan 2005 07:30:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp42m-0007V0-OQ for v6tc@megatron.ietf.org; Thu, 13 Jan 2005 07:25: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 HAA02373 for ; Thu, 13 Jan 2005 07:25:39 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp4Gz-0001mV-Ky for v6tc@ietf.org; Thu, 13 Jan 2005 07:40:23 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0DCPcdt024123 for ; Thu, 13 Jan 2005 05:25:38 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IA900AE696PER@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Thu, 13 Jan 2005 05:25:38 -0700 (MST) Received: from [192.168.1.2] ([83.193.2.220]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA90051Q96NUK@mail.sun.net> for v6tc@ietf.org; Thu, 13 Jan 2005 05:25:37 -0700 (MST) Date: Thu, 13 Jan 2005 04:25:34 -0800 From: Alain Durand Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-reply-to: <1105613079.3310.142.camel@firenze.zurich.ibm.com> To: Jeroen Massar Message-id: <38EF5E30-655E-11D9-916B-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4642E1C0-64A7-11D9-8C90-00039358A080@sun.com> <026001c4f951$255967e0$0a00a8c0@consulintel.es> <1105611172.3310.138.camel@firenze.zurich.ibm.com> <8347AA2C-654E-11D9-96E4-00039358A080@sun.com> <1105613079.3310.142.camel@firenze.zurich.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7BIT On Jan 13, 2005, at 2:44 AM, Jeroen Massar wrote: > What is so difficult about: > traceroute 2001:db8::1 (or 192.0.2.1 or whatever it gets). > > And what is so hard to debug about BGP anyway? Isn't this what happens > daily when routing problems occur? This is what is used by ISPs, not end user... If there is a problem with a user trying to get a tunnel with an ISP not offering the service, it is very hard for that end user to get effective help. > It works for the a number of root DNS servers too. There is a fundamental difference between global anycast used for some root DNS servers and what we want to do here. In the case of the root DNS servers, they are all semantically equivalent, i.e. your query can go to any one of them and you'll get the very same answer. Here, this is not the case. The semantic of the anycast address would be: "find the the closest tunnel server within my ISP range. If this leaks out of the ISP, it will go in random places, and you will get different services depending on your luck: - you can reach the bit bucket - you can reach a tunnel server asking for pre-registration but have no association with it - or you can even reach an open relay and things would work What would be needed actually would be a ISP-locally scoped well known anycast address and not a globally scoped well known address, but there is no such thing! And it is not sure at all it would really work either, we know what happened to site local addresses... The anycast address defined for 6to4 relays falls in the same category as the root DNS server, i.e. it is globally scoped and you can end up using any of the relays and get the same service. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Jan 13 09:23:42 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 JAA13402; Thu, 13 Jan 2005 09:23:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp67E-0005KA-IE; Thu, 13 Jan 2005 09:38:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp5q5-0005X6-MK; Thu, 13 Jan 2005 09:20:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp5d5-0001TT-Kn for v6tc@megatron.ietf.org; Thu, 13 Jan 2005 09:07:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11545 for ; Thu, 13 Jan 2005 09:07:13 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp5rH-0004qz-AH for v6tc@ietf.org; Thu, 13 Jan 2005 09:21:58 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 1244F911A1; Thu, 13 Jan 2005 15:06:59 +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 29277-09; Thu, 13 Jan 2005 15:06:58 +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 B0AD2911A0; Thu, 13 Jan 2005 15:06:56 +0100 (CET) Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: Alain Durand In-Reply-To: <38EF5E30-655E-11D9-916B-00039358A080@sun.com> References: <4642E1C0-64A7-11D9-8C90-00039358A080@sun.com> <026001c4f951$255967e0$0a00a8c0@consulintel.es> <1105611172.3310.138.camel@firenze.zurich.ibm.com> <8347AA2C-654E-11D9-96E4-00039358A080@sun.com> <1105613079.3310.142.camel@firenze.zurich.ibm.com> <38EF5E30-655E-11D9-916B-00039358A080@sun.com> Organization: Unfix Date: Thu, 13 Jan 2005 15:06:48 +0100 Message-Id: <1105625208.3310.159.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 1.8 (+) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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="===============1128063177==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 --===============1128063177== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8cQ1qu4o2TdJtvXavcwZ" --=-8cQ1qu4o2TdJtvXavcwZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-01-13 at 04:25 -0800, Alain Durand wrote: > On Jan 13, 2005, at 2:44 AM, Jeroen Massar wrote: >=20 > > What is so difficult about: > > traceroute 2001:db8::1 (or 192.0.2.1 or whatever it gets). > > > > And what is so hard to debug about BGP anyway? Isn't this what happens > > daily when routing problems occur? >=20 > This is what is used by ISPs, not end user... > If there is a problem with a user trying to get a tunnel > with an ISP not offering the service, it is very hard for that > end user to get effective help. "Hi, do you have IPv6", try that with most ISP's, 90% or most likely more will say say "no" "ehhhh what" or similar stupid answers. > > It works for the a number of root DNS servers too. >=20 > There is a fundamental difference between global anycast > used for some root DNS servers and what we want to do here. >=20 > In the case of the root DNS servers, they are all semantically=20 > equivalent, > i.e. your query can go to any one of them and you'll get the very same=20 > answer. I am quite sure that when I query for the hostname.bind or the hostname or a "dig +norec @tld1.ultradns.net whoareyou.ultradns.net in a" that I will get different responses telling me to which node and from who, I am talking too. BGP is not *that* flaky that you will swap over every n seconds. > Here, this is not the case. The semantic of the anycast address would=20 > be: > "find the the closest tunnel server within my ISP range. If this leaks=20 > out of > the ISP, it will go in random places, and you will get different=20 > services You will get the service which is closest by. Isn't this *exactly* what you where looking for? > depending on your luck: > - you can reach the bit bucket Which would do no harm, though it would not work. > - you can reach a tunnel server asking for pre-registration > but have no association with it Which would do no harm, and it will work if you want. > - or you can even reach an open relay and things would work Which is what we want ;) > What would be needed actually would be a ISP-locally scoped > well known anycast address and not a globally scoped well known address, > but there is no such thing! And it is not sure at all it would really=20 > work either, we know what happened to site local addresses... That is why I say: "Service Prefix", a prefix which can be announced by ISP's, maybe limited in export by not announcing it globally etc. This prefix could then have a couple of simple things: 2001:db8::53 / 192.0.2.53 =3D DNS 2001:db8::25 / 192.0.2.25 =3D SMTP (outgoing) 2001:db8::110 / 192.0.2.110 =3D POP3 2001:db8::80 / 192.0.2.80 =3D HTTP, showing a nice descriptive site of this service etc, which would solve all autoconfiguration issues as every box can be preconfigured with the above. Other approach, could be stuck into DNS: make a .service domain and let ISP's host that themselves. People can then use that. Or we could of course go for SLP. But why the heck invent yet another protocol? ISP's who do not want such a thing could filter the prefix in BGP, ISP's who want to announce it to their neighbors could do so. BGP is the trick. No prefix, then no announcement and you will nicely get a ICMP network unreachable. Some 'nice institute', like the RIRs, could announce announce a default service prefix with only a HTTP service saying "your ISP does not provide autoconfig" if one really wanted. ISP's not peering with the RIR's are really sick anyway and ISP's not wanting to give service to others should not do it. "I have a problem", then traceroute to 2001:db8::53 and find out where it leads to. If you want to be nice to the routing tables you could even reuse one of the existing anycast prefixes. Now we have one for 6to4, who uses that? But we want one for proto-x and proto-z and they all have the same target: providing nearest service. > The anycast address defined for 6to4 relays falls in the same category=20 > as the root DNS server, i.e. it is globally scoped and you can end up=20 > using any of the relays and get the same service. Which is the good thing of 6to4 as you want _service_. If you wanted quality service you would get native IPv6 or you would get yourself signed up at a better service. Greets, Jeroen --=-8cQ1qu4o2TdJtvXavcwZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB5oB4KaooUjM+fCMRAheAAJ4kPfE+tOTNHkSXpIrhzCcZazqXzgCdE7U7 w/J/EFDLton57X81Rvr4HsQ= =jYkw -----END PGP SIGNATURE----- --=-8cQ1qu4o2TdJtvXavcwZ-- --===============1128063177== 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 --===============1128063177==-- From v6tc-bounces@ietf.org Thu Jan 13 09:55: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 JAA15930; Thu, 13 Jan 2005 09:55:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp6cM-00068v-Th; Thu, 13 Jan 2005 10:10:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp6DH-00079R-Lt; Thu, 13 Jan 2005 09:44:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp63p-0002Kj-IY for v6tc@megatron.ietf.org; Thu, 13 Jan 2005 09:34: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 JAA14431 for ; Thu, 13 Jan 2005 09:34:51 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp6I3-0005cT-AO for v6tc@ietf.org; Thu, 13 Jan 2005 09:49:37 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0DEYoVu019602 for ; Thu, 13 Jan 2005 07:34:50 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IA900A5IF61GH@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Thu, 13 Jan 2005 07:34:50 -0700 (MST) Received: from [192.168.1.2] ([83.193.2.220]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA9007E0F5ZOK@mail.sun.net> for v6tc@ietf.org; Thu, 13 Jan 2005 07:34:49 -0700 (MST) Date: Thu, 13 Jan 2005 06:34:45 -0800 From: Alain Durand Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-reply-to: <1105625208.3310.159.camel@firenze.zurich.ibm.com> To: Jeroen Massar Message-id: <45644D74-6570-11D9-916B-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4642E1C0-64A7-11D9-8C90-00039358A080@sun.com> <026001c4f951$255967e0$0a00a8c0@consulintel.es> <1105611172.3310.138.camel@firenze.zurich.ibm.com> <8347AA2C-654E-11D9-96E4-00039358A080@sun.com> <1105613079.3310.142.camel@firenze.zurich.ibm.com> <38EF5E30-655E-11D9-916B-00039358A080@sun.com> <1105625208.3310.159.camel@firenze.zurich.ibm.com> X-Spam-Score: 4.0 (++++) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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: 4.0 (++++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7BIT On Jan 13, 2005, at 6:06 AM, Jeroen Massar wrote: >> In the case of the root DNS servers, they are all semantically >> equivalent, >> i.e. your query can go to any one of them and you'll get the very same >> answer. > > I am quite sure that when I query for the hostname.bind or the hostname > or a "dig +norec @tld1.ultradns.net whoareyou.ultradns.net in a" that I > will get different responses telling me to which node and from who, I > am > talking too. BGP is not *that* flaky that you will swap over every n > seconds. So? What does you example shows? That one can configure specific DNS servers to return specific information depending on who is querying them? So? All the anycast root servers that you contact to know who .com is today return a semantically equivalent information. The point being that global anycast addresses for global service work, but we cannot extrapolate that global anycast addresses would work for ISP-scoped services. >> the ISP, it will go in random places, and you will get different >> services > > You will get the service which is closest by. Isn't this *exactly* what > you where looking for? No. I want to go the the closest tunnel server of _my_ ISP. Not any tunnel server from any random ISP. And if my ISP does not offer the service, I want to know it asap. >> What would be needed actually would be a ISP-locally scoped >> well known anycast address and not a globally scoped well known >> address, >> but there is no such thing! And it is not sure at all it would really >> work either, we know what happened to site local addresses... > > That is why I say: "Service Prefix", a prefix which can be announced by > ISP's, maybe limited in export by not announcing it globally etc. > This prefix could then have a couple of simple things: > > 2001:db8::53 / 192.0.2.53 = DNS > 2001:db8::25 / 192.0.2.25 = SMTP (outgoing) > 2001:db8::110 / 192.0.2.110 = POP3 > 2001:db8::80 / 192.0.2.80 = HTTP, showing a nice descriptive site of > this service Ok, so you invent those ISP-scoped anycast addresses. Now I have a PC connected to two ISPs. What do I do? As I cannot tell from the address on which interface to send it too, I need to re-introduce all the complexity in the code that we hoped to avoid when we deprecated site local addresses... I need to remember, this is a 'special' address, I should not look-up my normal routing table, but 'remember' it is associated with a specific ISP, and this with a specific outgoing interface... Now makes the scenario a bit more complex, and introduce the multi-ISP router, and you have a interesting problem... > etc, which would solve all autoconfiguration issues as every box can be > preconfigured with the above. Other approach, could be stuck into DNS: > make a .service domain That could technically work, with the same objections as the ones described above. However, looking at the controversy over the .local domain, I doubt it would be quickly adopted... > and let ISP's host that themselves. People can > then use that. Or we could of course go for SLP. But why the heck > invent > yet another protocol? > > ISP's who do not want such a thing could filter the prefix in BGP This is exactly where I see a problem... The question is for ISP who do not care at all, i.e., who do not run the service internally and do not filter out the prefix. Then random, unpredictable things may happen. > , ISP's > who want to announce it to their neighbors could do so. BGP is the > trick. No prefix, then no announcement and you will nicely get a ICMP > network unreachable. > > Some 'nice institute', like the RIRs, could announce announce a default > service prefix with only a HTTP service saying "your ISP does not > provide autoconfig" if one really wanted. ISP's not peering with the > RIR's are really sick anyway and ISP's not wanting to give service to > others should not do it. How can you guaranty that no one else is injecting the same prefix? - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Jan 13 10:51: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 KAA20751; Thu, 13 Jan 2005 10:51:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp7Tx-0007Hm-GD; Thu, 13 Jan 2005 11:05:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp77e-00064X-Jd; Thu, 13 Jan 2005 10:42:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp6x1-000353-5J for v6tc@megatron.ietf.org; Thu, 13 Jan 2005 10:31:55 -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 KAA19423 for ; Thu, 13 Jan 2005 10:31:52 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp7BE-0006tD-H4 for v6tc@ietf.org; Thu, 13 Jan 2005 10:46:39 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id AF034911A4; Thu, 13 Jan 2005 16:31:41 +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 32270-05; Thu, 13 Jan 2005 16:31:40 +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 5A85C911A6; Thu, 13 Jan 2005 16:31:38 +0100 (CET) Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: Alain Durand In-Reply-To: <45644D74-6570-11D9-916B-00039358A080@sun.com> References: <4642E1C0-64A7-11D9-8C90-00039358A080@sun.com> <026001c4f951$255967e0$0a00a8c0@consulintel.es> <1105611172.3310.138.camel@firenze.zurich.ibm.com> <8347AA2C-654E-11D9-96E4-00039358A080@sun.com> <1105613079.3310.142.camel@firenze.zurich.ibm.com> <38EF5E30-655E-11D9-916B-00039358A080@sun.com> <1105625208.3310.159.camel@firenze.zurich.ibm.com> <45644D74-6570-11D9-916B-00039358A080@sun.com> Organization: Unfix Date: Thu, 13 Jan 2005 16:30:48 +0100 Message-Id: <1105630248.3310.169.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 1.8 (+) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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="===============1802267803==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 --===============1802267803== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6zCwBwMFBJ1MykbPu6iE" --=-6zCwBwMFBJ1MykbPu6iE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-01-13 at 06:34 -0800, Alain Durand wrote: > On Jan 13, 2005, at 6:06 AM, Jeroen Massar wrote: > >> In the case of the root DNS servers, they are all semantically > >> equivalent, > >> i.e. your query can go to any one of them and you'll get the very same > >> answer. > > > > I am quite sure that when I query for the hostname.bind or the hostname > > or a "dig +norec @tld1.ultradns.net whoareyou.ultradns.net in a" that I > > will get different responses telling me to which node and from who, I=20 > > am > > talking too. BGP is not *that* flaky that you will swap over every n > > seconds. >=20 > So? What does you example shows? That one can configure specific DNS=20 > servers > to return specific information depending on who is querying them? So? >=20 > All the anycast root servers that you contact to know who > .com is today return a semantically equivalent information. > The point being that global anycast addresses for global service work, > but we cannot extrapolate that global anycast addresses > would work for ISP-scoped services. Any reasons why this would not be the case? Have you experimented with this or are there known problems? > >> the ISP, it will go in random places, and you will get different > >> services > > > > You will get the service which is closest by. Isn't this *exactly* what > > you where looking for? >=20 > No. I want to go the the closest tunnel server of _my_ ISP. > Not any tunnel server from any random ISP. > And if my ISP does not offer the service, I want to know it asap. Then the draft for such a service prefix should include: - Do not redistribute this prefix globally. Pronto presto done. > >> What would be needed actually would be a ISP-locally scoped > >> well known anycast address and not a globally scoped well known=20 > >> address, > >> but there is no such thing! And it is not sure at all it would really > >> work either, we know what happened to site local addresses... > > > > That is why I say: "Service Prefix", a prefix which can be announced by > > ISP's, maybe limited in export by not announcing it globally etc. > > This prefix could then have a couple of simple things: > > > > 2001:db8::53 / 192.0.2.53 =3D DNS > > 2001:db8::25 / 192.0.2.25 =3D SMTP (outgoing) > > 2001:db8::110 / 192.0.2.110 =3D POP3 > > 2001:db8::80 / 192.0.2.80 =3D HTTP, showing a nice descriptive site of > > this service >=20 > Ok, so you invent those ISP-scoped anycast addresses. >=20 > Now I have a PC connected to two ISPs. What do I do? How does normal multihoming work, at least assuming that you are talking about L3/IP-layer multihoming and not about L2 multihoming. > As I cannot tell from the address on which interface to send it too, > I need to re-introduce all the complexity in the code > that we hoped to avoid when we deprecated site local addresses... > I need to remember, this is a 'special' address, I should not look-up > my normal routing table, but 'remember' it is associated with > a specific ISP, and this with a specific outgoing interface... What is the difference with configuring your multihomed router? If you are in the first place able to do so, then I really see no issue. And more likely, if you have such an advanced network that you are multihomed you are quite easily able to set this up to. > Now makes the scenario a bit more complex, and introduce > the multi-ISP router, and you have a interesting problem... I do not know a single organisation that is multihomed with different source IP's. In the cases they are multihomed on L3, they simply tend to have multiple upstreams. The person/organization who configured this is most likely quite capable of configuring the service prefix too in too cases. Any further issues? Or to put the question differently: how is this different from the proposal of looking it up from DNS SRV records? I think routing is easier to fix in those cases ;) > > etc, which would solve all autoconfiguration issues as every box can be > > preconfigured with the above. Other approach, could be stuck into DNS: > > make a .service domain >=20 > That could technically work, with the same objections as the ones=20 > described above. > However, looking at the controversy over the .local domain, > I doubt it would be quickly adopted... >=20 >=20 > > and let ISP's host that themselves. People can > > then use that. Or we could of course go for SLP. But why the heck=20 > > invent > > yet another protocol? > > > > ISP's who do not want such a thing could filter the prefix in BGP >=20 > This is exactly where I see a problem... > The question is for ISP who do not care at all, i.e., who do > not run the service internally and do not filter out the prefix. > Then random, unpredictable things may happen. Thus like I mentioned above "thou shalt not announce the service prefix globally". > > , ISP's > > who want to announce it to their neighbors could do so. BGP is the > > trick. No prefix, then no announcement and you will nicely get a ICMP > > network unreachable. > > > > Some 'nice institute', like the RIRs, could announce announce a default > > service prefix with only a HTTP service saying "your ISP does not > > provide autoconfig" if one really wanted. ISP's not peering with the > > RIR's are really sick anyway and ISP's not wanting to give service to > > others should not do it. >=20 > How can you guaranty that no one else is injecting the same prefix? If you do not trust your peers then you should not be peering with them. There are many methods of filtering, if you do not know them you should not be in the ISP business. Greets, Jeroen --=-6zCwBwMFBJ1MykbPu6iE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB5pQoKaooUjM+fCMRAgwqAKCYGUnfOu1jyDePMcziuX8gQG4AVACgohUh SfaAD9/BRDPiGLfMCIBUIJo= =ykpc -----END PGP SIGNATURE----- --=-6zCwBwMFBJ1MykbPu6iE-- --===============1802267803== 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 --===============1802267803==-- From v6tc-bounces@ietf.org Fri Jan 14 08:58: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 IAA15221; Fri, 14 Jan 2005 08:58:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpSCL-0003YG-VO; Fri, 14 Jan 2005 09:13:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpRtN-0000AQ-9z; Fri, 14 Jan 2005 08:53:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpRlR-0006zQ-67 for v6tc@megatron.ietf.org; Fri, 14 Jan 2005 08:45:21 -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 IAA14415 for ; Fri, 14 Jan 2005 08:45:19 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpRzr-0003Hq-O1 for v6tc@ietf.org; Fri, 14 Jan 2005 09:00:17 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0EDjIVu029101 for ; Fri, 14 Jan 2005 06:45:18 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IAB00EOP7JIMX@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Fri, 14 Jan 2005 06:45:18 -0700 (MST) Received: from [192.168.1.2] ([83.193.196.106]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAB006P57JF44@mail.sun.net> for v6tc@ietf.org; Fri, 14 Jan 2005 06:45:18 -0700 (MST) Date: Fri, 14 Jan 2005 05:45:13 -0800 From: Alain Durand Subject: refocusing: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-reply-to: To: Alain Durand Message-id: <8457F87A-6632-11D9-A440-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7BIT Well, the discussion on this topic has a bit rat-holing into anycast deployment issues, when the question I intended to discuss was: > In other words, could we live with a solution where the user will have > to manually > input on its v6 host or router an address of the form v6TEP.myISP.com > in the relevant > form? (provided that would be the ONLY thing to input) ... or do we absolutely require an automatic discovery mechanism? I would like to invite those who haven't expressed themselves on this very point to participate in the debate. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Jan 14 14:03: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 OAA04991; Fri, 14 Jan 2005 14:03:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpWxp-0001D6-Va; Fri, 14 Jan 2005 14:18:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpWdZ-0002on-GI; Fri, 14 Jan 2005 13:57:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpWW5-00011U-6j for v6tc@megatron.ietf.org; Fri, 14 Jan 2005 13:49: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 NAA04238 for ; Fri, 14 Jan 2005 13:49:46 -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 1CpWkZ-0000vQ-2K for v6tc@ietf.org; Fri, 14 Jan 2005 14:04:47 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000709237.msg for ; Fri, 14 Jan 2005 19:49:53 +0100 Message-ID: <01c601c4fa69$d35cf050$0a00a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <4642E1C0-64A7-11D9-8C90-00039358A080@sun.com> <026001c4f951$255967e0$0a00a8c0@consulintel.es> <1105611172.3310.138.camel@firenze.zurich.ibm.com> Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? Date: Fri, 14 Jan 2005 19:49:48 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1419345573==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 --===============1419345573== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpFdmVuIGluIHlvdXIgY2FzZSB0aGUgZGlzY292ZXJ5IG1ldGhvZCB3ZSBhcmUgZ29pbmcgdG8g cHJvcG9zZSB3aWxsIHdvcmsuIEJhc2ljYWxseSB3ZSBvbmx5IHN1cHBvc2Ugb25lIHRoaW5nOiB0 aGUgbG9jYWwgSVNQIGlzIHRoZSBlbnRpdHkgdGhhdCBkZXBsb3lzIHRoZSBURVAgdGhhdCB0aGUg dXNlciAocmF0aGVyIHRoZSBPUykgaXMgbG9va2luZyBmb3IuDQoNCldpdGggdGhhdCBwcmVtaXNl IHdlIHByb3Bvc2UgdG8gdXNlIFNSViBSUiBiZWNhdXNlIHRoZSBhZHZhbnRhZ2VzIHNob3duIGlu IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXBhbGV0LXY2b3BzLXNv bHV0aW9uLXR1bi1hdXRvLWRpc2MtMDEudHh0LiBIb3dldmVyIHRvIHVzZSBlZmZlY3RpdmVseSB0 aGF0IGFwcHJvYWNoIGl0IGlzIG5lY2Vzc2FyeSB0byBrbm93IHRoZSBJU1AgZG9tYWluIG5hbWUg d2hpY2ggaXMgbm90IHRyaXZpYWwgYmVjYXVzZSBpdCBpcyBub3QgdXN1YWxseSBwcm9wYWdhdGVk Lg0KDQpUaGUgbmV3IGRyYWZ0IHZlcnNpb24gb2YgZHJhZnQtcGFsZXQtdjZvcHMtc29sdXRpb24t dHVuLWF1dG8tZGlzYyB3aWxsIHByb3Bvc2UgYSBtZXRob2QgdG8gZGlzY292ZXIgbm90IG9ubHkg dGhlIElTUCBkb21haW4gbmFtZSBidXQgYWxzbyB0aGUgRE5TIHNlcnZlciB0byBtYWtlIHRoZSBT UlYgcXVlcmllcy4gVG8gZG8gdGhhdCB0aGUgb25seSB0aGluZyBpcyB0byBmaW5kIG91dCB0aGUg YXV0aG9yaXRhdGl2ZSBETlMgc2VydmVyIG9uIHRoZSBJU1AgZG9tYWluIGFuZCB0aGVuIHlvdSds bCBoYXZlIGFsbC4NCg0KSW4gdGhpcyB3YXkgdGhlIHF1ZXJpZXMgd2lsbCBiZSBzZW50IG5vdCB0 byB5b3VyIGxvY2FsIEROUyBzZXJ2ZXIgYnV0IHRoZSBhdXRob3JpdGF0aXZlIEROUyBzZXJ2ZXIg b2YgeW91ciBJU1Agd2hvIGlzIGluIGNoYXJnZSBvZiB0aGUgVEVQIGRlcGxveW1lbnQsIHNvIGl0 IHdpbGwgd29yayBldmVuIGluIHlvdXIgbmV0d29yay4NCg0KTW9yZSBpbmZvcm1hdGlvbiBzb29u Li4uLg0KDQpSZWdhcmRzDQpNaWd1ZWwNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAN CkZyb206ICJKZXJvZW4gTWFzc2FyIiA8amVyb2VuQHVuZml4Lm9yZz4NClRvOiA8bWlndWVsYW5n ZWwuZGlhekBjb25zdWxpbnRlbC5lcz4NCkNjOiA8djZ0Y0BpZXRmLm9yZz4NClNlbnQ6IFRodXJz ZGF5LCBKYW51YXJ5IDEzLCAyMDA1IDExOjEyIEFNDQpTdWJqZWN0OiBSZTogW3Y2dGNdIElzc3Vl IDI6IHNlcnZpY2UgZGlzY292ZXJ5OiBhdXRvbWF0aWMgb3IgbWFudWFsPw0KDQo+IE9uIFRodSwg MjAwNS0wMS0xMyBhdCAxMDoyMCArMDEwMCwgTWlndWVsIEFuZ2VsIERpYXogd3JvdGU6DQo+PiBI aSBhbGwsDQo+PiANCj4+IHdlIChKb3JkaSBhbmQgbWUpIGFyZSB3b3JraW5nIGluIGEgbWV0aG9k IHRvIGRpc2NvdmVyDQo+PiB0aGUgSVNQIGRvbWFpbiBuYW1lIGluIG9yZGVyIHRvIHVzZSBTUlYg cmVjb3Jkcy4NCj4+IFRoZSBtZXRob2QgaXMgc2ltcGxlIGFuZCBpdCBjb3VsZCB3b3JrIGluIGFs bCB0aGUgcG9zc2libGUNCj4+IHNjZW5hcmlvcyB3aGVyZSB0aGUgdXNlciBtaWdodCBiZS4NCj4g DQo+IExldCdzIHRha2UgbXkgc2ltcGxlIGhvbWUgbmV0d29yazoNCj4gDQo+IHsgQURTTCBwcm92 aWRlciB9IDwtLS0tLS0tPiB7IFJvdXRlciB9IDwtLS0tLS0+IHtIb3N0c30NCj4gDQo+IFJvdXRl ciBpcyBpbiB0aGlzIGNhc2UgYSBMaW51eCBib3ggZG9pbmcgSVB2NCBOQVQgKyBJUHY2IHJvdXRp bmcgKyBETlMgKw0KPiBESENQIGZvciBIb3N0cy4gRXZlcnl0aGluZyBiZWhpbmQgYW5kIGluY2x1 ZGluZyBteSBSb3V0ZXIgaGFzIGEgcmV2ZXJzZQ0KPiBvZiB1bmZpeC5vcmcuIChyb3V0ZXI9cHVy Z2F0b3J5LnVuZml4Lm9yZywgaGVsbC51bmZpeC5vcmcsDQo+IGhlYXZlbi51bmZpeC5vcmcpDQo+ IA0KPiBNeSAobm93IGZvcm1lciBJU1ApIHVzZXMgY2lzdHJvbi5uZXQgZm9yIGFsbCBpdCdzIHJv dXRlcnMsIHRodXMgYQ0KPiB0cmFjZXJvdXRlIHdvdWxkIGxvb2sgbGlrZToNCj4gDQo+IGhlbGwu dW5maXgub3JnIChsb2NhbGhvc3QpDQo+IHB1cmdhdG9yeS51bmZpeC5vcmcgKHJvdXRlcikNCj4g YmxhYmxhLWRzbC5jaXN0cm9uLm5ldA0KPiANCj4gV2hhdCBpcyB0aGUgIklTUCBkb21haW4gbmFt ZSIgaW4gdGhpcyBzY2VuYXJpbz8NCj4gDQo+IEFsc28sIGV2ZW4gdGhvdWdoIHRoZXkgaGF2ZSBh biBJUHY2IGFsbG9jYXRpb24sIHRoZXkgZG8gbm90IHByb3ZpZGUgaXQNCj4gdG8gdGhlaXIgY2xp ZW50cyBmb3Igc2V2ZXJhbCBoYXJkd2FyZS9zb2Z0d2FyZSByZWFzb25zLg0KPiANCj4gU28gZXZl biBpZiB5b3UgY291bGQgZmluZCBvdXQgdGhlIGNvcnJlY3QgZG9tYWluIG5hbWUgb2YgdGhlIElT UCwgdGhlcmUNCj4gd291bGQgYmUgbm8gU1JWIHJlY29yZHMgdGhlcmUgYW55d2F5Lg0KPiANCj4g VGh1cyBJIGFtIHJlYWxseSB3b25kZXJpbmcgaG93IHlvdSB3aWxsIHRyeSB0byBtYWtlIHRoaXMg d29yayAnZm9yIGFsbA0KPiBjYXNlcycuDQo+IA0KPiBJIGFtIHN0aWxsIGNvbnZpbmNlZCB0aGF0 IGFueWNhc3QgaXMgdGhlIHdheSBhbmQgdGhhdCBhICdhbnljYXN0DQo+IHNlcnZpY2UnIHByZWZp eCB3b3VsZCBiZSB0aGUgYmVzdCB0aGluZyB0byBoYXZlLg0KPiANCj4gR3JlZXRzLA0KPiBKZXJv ZW4NCg== --===============1419345573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1419345573==-- From v6tc-bounces@ietf.org Fri Jan 14 14:04:19 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 OAA05052; Fri, 14 Jan 2005 14:04:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpWyc-0001Dk-5y; Fri, 14 Jan 2005 14:19:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpWda-0002p8-4D; Fri, 14 Jan 2005 13:57:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpWWD-000168-2o for v6tc@megatron.ietf.org; Fri, 14 Jan 2005 13:49:57 -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 NAA04254 for ; Fri, 14 Jan 2005 13:49:54 -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 1CpWkh-0000vt-7l for v6tc@ietf.org; Fri, 14 Jan 2005 14:04:55 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000709238.msg for ; Fri, 14 Jan 2005 19:50:08 +0100 Message-ID: <01c701c4fa69$da1b0350$0a00a8c0@consulintel.es> From: "Miguel Angel Diaz" To: Subject: Fw: [v6tc] Issue 2: service discovery: automatic or manual? Date: Fri, 14 Jan 2005 19:49:59 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0603027947==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 --===============0603027947== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKZXJvZW4gTWFzc2FyIiA8amVy b2VuQHVuZml4Lm9yZz4NClRvOiA8bWlndWVsYW5nZWwuZGlhekBjb25zdWxpbnRlbC5lcz4NCkNj OiA8djZ0Y0BpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDEzLCAyMDA1IDExOjEy IEFNDQpTdWJqZWN0OiBSZTogW3Y2dGNdIElzc3VlIDI6IHNlcnZpY2UgZGlzY292ZXJ5OiBhdXRv bWF0aWMgb3IgbWFudWFsPw0KDQpbLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLl0NCg0KPiBJIGFtIHN0aWxsIGNvbnZpbmNlZCB0aGF0IGFueWNhc3QgaXMgdGhlIHdh eSBhbmQgdGhhdCBhICdhbnljYXN0DQo+IHNlcnZpY2UnIHByZWZpeCB3b3VsZCBiZSB0aGUgYmVz dCB0aGluZyB0byBoYXZlLg0KPiANCj4gR3JlZXRzLA0KPiBKZXJvZW4NCj4gDQoNCkkgcGFydGlh bGx5IGFncmVlIHdpdGggeW91ciBwb2ludC4gSSBhbHNvIHN1cHBvcnQgdGhlIGlkZWEgb2YgYW4g YW55Y2FzdCBhZGRyZXNzIGlmOg0KDQoxKSBlYWNoIHRyYW5zaXRpb24gbWVjaGFuaXNtIGhhcyBp dHMgb3duIGFueWNhc3QgYWRkcmVzcw0KMikgdGhlIGFueWNhc3QgYWRkcmVzcyBzY29wZSBpcyBn bG9iYWwsIEkgbWVhbiwgaXQgaXMgYXBwbGllZCBub3Qgb25seSB0byB0aGUgSVNQIGRvbWFpbiBi dXQgdGhlIHdob2xlIEludGVybmV0Lg0KDQpldmVuIHVuZGVyIHRoaXMgYXNzdW1wdGlvbnMgdGhl cmUgYXJlIHNldmVyYWwgYmFycmllcnMgd2hpY2ggd291bGQgcHJldmVudCB0aGF0IHRoZSBhbnlj YXN0IHNlcnZpY2Ugd2lsbCB3b3JrIG9uIHRoZSB3aG9sZSBJbnRlcm5ldCBhbmQgZm9yIGFsbCB0 aGUgdHJhbnNpdGlvbiBtZWNoYW5pc21zIChzZWUgaHR0cDovL3d3dy5jb25zdWxpbnRlbC5ldXJv Nml4Lm9yZy9pZXRmL2FwcGxpY2F0aW9uX29mX2FueWNhc3RfZm9yX3RiX2ltcGxlbWVudGF0aW9u X3YxXzAucGRmKS4gSG93ZXZlciBpZiB3ZSBjb21wYXJlIHRoZSBhZHZhbnRhZ2VzIHZzLiB0aGUg ZHJhd2JhY2tzLCBJTUhPIHRoZSBiYWxhbmNlIHdpbGwgYmUgcG9zaXRpdmUgaW4gZmF2b3Igb2Yg YWR2YW50YWdlcy4NCg0KSG93ZXZlciBpZiB0aGUgYW55Y2FzdCBzY29wZSBpcyBvbmx5IGxvY2Fs LCB0aGF0IGlzIG9ubHkgaW50byB0aGUgSVNQIGRvbWFpbiwgdGhlbiBvdGhlciBhcHByb2FjaGVz IGxpa2UgZm9yd2FyZCBETlMgaGFzIGxlc3MgZHJhd2JhY2tzIGFuZCB0aGVuIGl0IHNob3VsZCBi ZSBjb25zaWRlcmVkIHJhdGhlciB0aGFuIGFueWNhc3QuIA0KDQpSZWdhcmRzDQpNaWd1ZWw= --===============0603027947== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============0603027947==-- From v6tc-bounces@ietf.org Fri Jan 14 14:10: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 OAA05454; Fri, 14 Jan 2005 14:10:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpX4D-0001Ld-BM; Fri, 14 Jan 2005 14:25:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpWdc-0002qv-Hu; Fri, 14 Jan 2005 13:57:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpWWN-00018Q-2A for v6tc@megatron.ietf.org; Fri, 14 Jan 2005 13:50: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 NAA04279 for ; Fri, 14 Jan 2005 13:50:04 -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 1CpWkr-0000wC-6I for v6tc@ietf.org; Fri, 14 Jan 2005 14:05:05 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000709239.msg for ; Fri, 14 Jan 2005 19:50:18 +0100 Message-ID: <01c801c4fa69$dfeabeb0$0a00a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <8457F87A-6632-11D9-A440-00039358A080@sun.com> Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automatic ormanual? Date: Fri, 14 Jan 2005 19:50:09 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0347791729==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 --===============0347791729== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Pj4gSW4gb3RoZXIgd29yZHMsIGNvdWxkIHdlIGxpdmUgd2l0aCBhIHNvbHV0aW9uIHdoZXJlIHRo ZSB1c2VyIHdpbGwgaGF2ZSANCj4+IHRvIG1hbnVhbGx5DQo+PiBpbnB1dCBvbiBpdHMgdjYgaG9z dCBvciByb3V0ZXIgYW4gYWRkcmVzcyBvZiB0aGUgZm9ybSB2NlRFUC5teUlTUC5jb20gDQo+PiBp biB0aGUgcmVsZXZhbnQNCj4+IGZvcm0/IChwcm92aWRlZCB0aGF0IHdvdWxkIGJlIHRoZSBPTkxZ IHRoaW5nIHRvIGlucHV0KQ0KPiANCj4gLi4uIG9yIGRvIHdlIGFic29sdXRlbHkgcmVxdWlyZSBh biBhdXRvbWF0aWMgZGlzY292ZXJ5IG1lY2hhbmlzbT8NCj4gDQoNCklNSE8gaWYgd2Ugd2lzaCBh IGJyb2FkIGFuZCBmYXN0IGRlcGxveW1lbnQgb2YgSVB2NiB0aGUgYW5zd2VyIGlzIHRoYXQgYW4g YXV0b21hdGljIGRpc2NvdmVyeSBtZWNoYW5pc20gaXMgZGVmaW5pdGl2ZWx5IHJlcXVpcmVkLiAN Cg0KVG9kYXkgbWFueSBJU1BzIGFyZSB3b25kZXJpbmcgd2h5IHNob3VsZCB0aGV5IGRlcGxveSBJ UHY2IGluIHRoZWlyIGNvcmUgbmV0d29ya3Mgb3IgaW4gdGhlaXIgYWNjZXNzIG5ldHdvcmtzIGlm IG5vIElQdjYgdHJhZmZpYyBpcyBkZXRlY3RlZC4NCg0KT24gdGhlIG90aGVyIGhhbmQsIGhhcmR3 YXJlIG1hbnVmYWN0dXJlcnMsIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgYW5kIHVzZXJzIGluIGdl bmVyYWwgYXJlIHdvbmRlcmluZyB3aHkgc2hvdWxkIHRoZXkgbmVlZCBJUHY2IGluIHRoZSBwcm9k dWN0cyB0aGF0IHRoZXkgZGV2ZWxvcC91c2UgaWYgdXNlcnMgZG9uJ3QgaGF2ZSBJUHY2IGNvbm5l Y3Rpdml0eSBlaXRoZXIgbmF0aXZlIG9yIGJ5IG1lYW4gb2YgYW4gZWFzeS9hdXRvbWF0aWMgdHJh bnNpdGlvbiBtZWNoYW5pc20uDQoNCkluIHRoZXNlIGNpcmN1bXN0YW5jZXMsIElTUCB3aWxsIG5l dmVyIGRldGVjdCBJUHY2IHRyYWZmaWMgYmVjYXVzZSB1c2VycyAobm9ybWFsIHVzZXJzKSBkb24n dCBrbm93IChhbmQgbGlrZWx5IGRvbid0IHdhbnQgdG8pIGhvdyB0byBmaW5kIFRFUHMgYW5kIGhv dyB0byBjb25maWd1cmUgSVB2NiB0dW5uZWxzLCBhbmQgcHJvZHVjdCBkZXZlbG9wZXJzIGFyZW4n dCBwdXNoZWQgbmVpdGhlciB0byBkZXZlbG9wIElQdjYgcHJvZHVjdHMvYXBwbGljYXRpb24gKHdo aWNoIHdvdWxkIGdlbmVyYXRlIHRoZSBJUHY2IHRyYWZmaWMpIGJlY2F1c2UgdGhleSBkZXBlbmQg b24gdGhlIHRlY2huaWNhbCBrbm93bGVkZ2Ugb2YgdXNlcnMgKHVzdWFsbHkgbWluaW1hbCBpZiBh bnkpLg0KDQpUaGlzIGlzIGEgYm9vdHN0cmFwcGluZyBhbmQgdGhlIG9ubHkgd2F5IHRvIHNvbHZl IGl0IGlzIGJ5IGVhc2luZyB0aGUgSVB2NiB0cmFuc2l0aW9uLiBPbmUgZWZmaWNpZW50IG1lYW4g aXMgYW4gYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIHRoYXQgZmluZHMgdGhlIFRFUCBieSBpdHNl bGYgYW5kIHVzZXJzIGRvbid0IGhhdmUgdG8gYmUgd29ycmllZCBhYm91dCBpdC4NCg0KTGV0J3Mg dGhpbmsgdGhhdCB0aGVyZSBjb3VsZCBiZSBhIGxvdCBvZiBJUHY2IGRldmljZXMgbGlrZSBjYW1l cmFzLCBob21lIGF1dG9tYXRpb24gZGV2aWNlcywgY2FycywgZXRjIHRoYXQgY291bGQgdGFrZSBh ZHZhbnRhZ2Ugb2YgYW4gYXV0b21hdGljIGRpc2NvdmVyeSBtZXRob2QgdG8gZmluZCBJUHY2IGNv bm5lY3Rpdml0eSB3aXRob3V0IGh1bWFuIGludGVydmVudGlvbi4NCg0KU28sIElNSE8gdGhlIGFu c3dlciBpcyB0aGF0IHdlIGNhbid0IGxpdmUgd2l0aCBtZXRob2RzIHRoYXQgcmVxdWlyZSB1c2Vy cyB0byBlbnRlciBhbnkgVVJMIG9yIGRhdGEuDQoNClJlZ2FyZHMNCk1pZ3VlbA== --===============0347791729== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============0347791729==-- From v6tc-bounces@ietf.org Sun Jan 16 22:41:17 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 WAA11294; Sun, 16 Jan 2005 22:41:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqO0W-0000hM-6y; Sun, 16 Jan 2005 22:56:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqNkS-0005mq-DB; Sun, 16 Jan 2005 22:40:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqNcH-0005Bt-E3 for v6tc@megatron.ietf.org; Sun, 16 Jan 2005 22:31: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 WAA10628 for ; Sun, 16 Jan 2005 22:31:42 -0500 (EST) Received: from modemcable006.77-203-24.mc.videotron.ca ([24.203.77.6] helo=rtr6) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqNrF-0000X7-DQ for v6tc@ietf.org; Sun, 16 Jan 2005 22:47:13 -0500 Received: from [192.168.31.28] ([192.168.31.28]) by rtr6 (8.12.9p1/8.12.9) with ESMTP id j0H3VaOt013797 for ; Sun, 16 Jan 2005 22:31:38 -0500 (EST) Date: Sun, 16 Jan 2005 22:30:45 -0500 From: Florent Parent To: v6tc@ietf.org Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automatic or manual? Message-ID: In-Reply-To: <8457F87A-6632-11D9-A440-00039358A080@sun.com> References: <8457F87A-6632-11D9-A440-00039358A080@sun.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 2.6 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit -- On Friday, January 14, 2005 05:45:13 -0800, Alain Durand wrote: > Well, the discussion on this topic has a bit rat-holing into anycast > deployment issues, > when the question I intended to discuss was: > >> In other words, could we live with a solution where the user will have >> to manually >> input on its v6 host or router an address of the form v6TEP.myISP.com >> in the relevant >> form? (provided that would be the ONLY thing to input) > > ... or do we absolutely require an automatic discovery mechanism? > > I would like to invite those who haven't expressed themselves on > this very point to participate in the debate. > > - Alain. Automatic discovery should be focused within an "autonomous system" (enterprise/ISP/etc.). For example, if anycast is used, such address should be confined to the autonomous system routing system. How it's done (anycast, DNS, etc.) is left to be defined. I think automatic discovery should be done in order to cover the zero-conf. tunneling goals. In the roaming scenario (or getting service across an IPv4 only ISP), some manually configured parameter would be required from the user (e.g. tunnel service FQDN of your IPv6 provider). This manual configuration isn't alien to users and is done in many client software. Florent _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Mon Jan 17 10:36:11 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 KAA15663; Mon, 17 Jan 2005 10:36:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZAR-0007Ni-KY; Mon, 17 Jan 2005 10:51:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqYsL-0003dm-EJ; Mon, 17 Jan 2005 10:33:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqYkS-0002KK-VA for v6tc@megatron.ietf.org; Mon, 17 Jan 2005 10:24:57 -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 KAA14383 for ; Mon, 17 Jan 2005 10:24:54 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqYzW-00077S-JV for v6tc@ietf.org; Mon, 17 Jan 2005 10:40:31 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 18E7189D3F; Mon, 17 Jan 2005 16:24:43 +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 02250-01; Mon, 17 Jan 2005 16:24:42 +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 348AC8945E; Mon, 17 Jan 2005 16:24:41 +0100 (CET) Subject: Re: Fw: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: miguelangel.diaz@consulintel.es In-Reply-To: <01c701c4fa69$da1b0350$0a00a8c0@consulintel.es> References: <01c701c4fa69$da1b0350$0a00a8c0@consulintel.es> Organization: Unfix Date: Mon, 17 Jan 2005 16:24:40 +0100 Message-Id: <1105975480.8582.101.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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="===============0262242296==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 --===============0262242296== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2eUAAVuYAd3JJNsnBJ8s" --=-2eUAAVuYAd3JJNsnBJ8s Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-01-14 at 19:49 +0100, Miguel Angel Diaz wrote: > From: "Jeroen Massar" >=20 > > I am still convinced that anycast is the way and that a 'anycast > > service' prefix would be the best thing to have. > >=20 > > Greets, > > Jeroen > >=20 >=20 > I partially agree with your point. I also support the idea of an anycast = address if: >=20 > 1) each transition mechanism has its own anycast address Why? Just setup a Transition Mechanism Server or whatever, eg a simple webserver and a special URL on that box would retrieve the information which allows the client utility to figure out what to do or where to get the real information. Don't waste resources, there 'might' be enough, but then still you don't have to waste it. Reread what I wrote (and also wrote last year in april): Service Anycast Prefix. Which is just so you can reach a box which can tell you 'there is the service for you' and from then on you can do anything possible. > 2) the anycast address scope is global, I mean, it is applied not only > to the ISP domain but the whole Internet. Why? If the service prefix is only announced to the local ISP, then only those will receive service from that instance. Announce it to the world and you give the world service. That is how anycast works, simple and easy. > even under this assumptions there are several barriers which would Which barriers? > prevent that the anycast service will work on the whole Internet and > for all the transition mechanisms (see > http://www.consulintel.euro6ix.org/ietf/application_of_anycast_for_tb_imple= mentation_v1_0.pdf).=20 A few comments: Defining anycast address as a tunnel endpoint for traditional Tunnel Brokers is silly, especially because that is simply a normal, well established use of server failover. If you meant to do global anycast deployment, please stick to 6to4 as you do not want the hassle of managing that. Next to that you might be interrested in an alternative approach as presented by XS26 (http://www.xs26.net) who use multiple tunnel servers and allow people to use multiple tunnels, thus giving them complete failover possibilities. Btw, when was this paper written, because it mentions 'current' a couple of times, but there is no publication date in the paper. And please be free to translate to spanish on page 9 and I won't fall over the various broken sentences (it actually reads like it has been translated by babelfish or something similar). I am also quite sure that there is no TB around that changes the users forward DNS zone, even though that is implied on the first page. Reverse in some cases, but even that is not likely. The reason btw that TB's are around and used, is that that is the only way to get IPv6 at the moment in most cases that is not severely broken, like 6to4 is in most cases. Also do remember that most users use IPv6 for two simple reasons IRC (because reverse DNS can be configured most of the time for IPv6 prefixes they get allocated) + NNTP. Only a fractional number of people tend to use it for stuff like webservers, ssh and other somewhat normal protocols. Scene 1 mentions that "most of the TB's belong to the academic or research scope". FreeNet6 _was_ indeed Canarie, but is now fully commercial based at Hexago, Hurricane Electric is a commercial company as well, and out of the 13 SixXS POPs only 2 are 'academic'. From this small and quite complete list, I think the majority is thus actually commercial unlike what you are mentioning in your paper. Though they do offer free service, that is correct. But why not? It is for getting people going with IPv6. As for a TB with 'poor performance', as long as you don't pick one on the other side of the ocean you should be fine. I've not encountered one which was congested yet. There is not that much IPv6 traffic yet anyways. You also imagine that people get everything for free. The reason why there are free TB's is because of the fact that giving a good TB service the users will value the ISP and are likely to maybe buy other services from them. Scene 1 is thus quite bogus because it is based on false assumptions and a lot of missing background. Scene 2 assumes that people want to roam. This is normally solved with MIPv6 thus should also be in the cases of TB's. It is then of course not so odd to see Figure 2 matching the standard Mobile IPv6 figure ;) I can also tell you that I can very easily solve Scene 2 with a tool like AICCU. Freenet6's TSP client can also do it, but they do not have that many POPs. Scene 3 is already done by several deployed Tunnel Brokering systems. Without the need for the word anycast, though as mentioned the Tunnel Server or the Tunnel Broker could easily be anycasted as a normal form of loadbalancing/failover. The solution mentioned in 3.1 is what SixXS does and guess what it works very well. The only people that I know of who complain are the ones who can't make use of the service anymore after they tried to abuse it. The users who use it normally though are very happy. 3.2 mentions that DNS is not centralized, tell that to the panix.com people ;) Also in any case if you want to do it, it will need a special application made for your great solution. Thus do not claim that "it would avoid that users would run special applications..." as that is not true. If this application is a script or some other magic it is still something which is not commonly available, thus don't claim that. I wonder why you even mention the Cisco DistributedDirector as it is a device targetted at something completely different as you mention in the paper yourself and then you also mention that it is not good for your purpose because it is proprietary. I don't like Cisco that much either but putting it in a document in that way, nah. In 3.3 you mention www.tunnel-broker.net though you are talking about anycast, should that part not go under 3.2, where you just mentioned that it will not work for your purpose because of caching? Rounding section 3, called solutions, you fail to mention any solutions as you try to describe them and then directly put them down without any evidence. The rest I only skimmed because I actually got a bit tired of reading the broken english and thus having to reread the sentences multiple times before they where understandable. If I had any knowledge of spanish I would ask for the most likely original spanish version, which I guess is much better to read than this version. I did notice a lot of loose references to things that totally made no relation at all to the subject and a lot of misassumptions. Routing for instance does not change every 5 seconds when staying inside the same ISP. You might be interested in taking a look at RIS (http://ris.ripe.net) or maybe playing around on the real internet with some BGP tools. Next to all of that, ever thought how much overhead reconfiguration of say 10k tunnels on say 50 TS's will be when you really want to keep it tight the way you specify? The overhead of all of that really is not the worth the trouble. Simply setting up 50 boxes in clusters of 2 with a standard VRRP failover protocol and you are done(tm). No new problems and it will just magically work(tm). Even one box can work perfectly fine until some hardware parts fail. MTBF is your friend here. The biggest point you are missing btw is the problem of abuse. How are you going to trace abuse in the setups you propose. Remember that you are proposing a service which grants anonymous IP connectivity to anonymous users. Guess which service will not have access long to several key parts of the internet as the abuse from that service becomes to large to even bother yelling at the abuse line of that service... The newest fun of these people seem to be hacking a box, getting a IPv6 in IPv4 tunnel, or just 6to4 and then playing the anonymous bastard from there. Welcome to the world of Anonymous Cybernet ;) Btw, already checked how much valid traffic/non-bogus is going over your open relay? > However if we compare the advantages vs. the drawbacks, IMHO > the balance will be positive in favor of advantages. > However if the anycast scope is only local, that is only into the > ISP domain, then other approaches like forward DNS has less drawbacks > and then it should be considered rather than anycast.=20 Thus, if the anycast scope is local, it is worse than DNS? I am quite sure it is the other way around. Greets, Jeroen PS: I wonder why your paper misses out two of the largest and oldest TB's in the world, it's not that it is a big list or something, but those two do a lot more than the ones you named and actually solve the concerns you mention in your paper, though that could be just me. --=-2eUAAVuYAd3JJNsnBJ8s Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB69i4KaooUjM+fCMRAm0+AJ9FbHpR/GZ8aKbkhemAkOaDDhrJRgCgrZY0 uCzwOgk1f9OD0pOwPhqRm3k= =3BZh -----END PGP SIGNATURE----- --=-2eUAAVuYAd3JJNsnBJ8s-- --===============0262242296== 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 --===============0262242296==-- From v6tc-bounces@ietf.org Mon Jan 17 11:08:04 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 LAA18817; Mon, 17 Jan 2005 11:08:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZfJ-00089B-8M; Mon, 17 Jan 2005 11:23:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZJ7-00014R-Hk; Mon, 17 Jan 2005 11:00:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZEe-00008p-NS for v6tc@megatron.ietf.org; Mon, 17 Jan 2005 10:56:08 -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 KAA17861 for ; Mon, 17 Jan 2005 10:56:06 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZTj-0007su-7Z for v6tc@ietf.org; Mon, 17 Jan 2005 11:11:43 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 55FDF89D3F; Mon, 17 Jan 2005 16:56: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 02900-08; Mon, 17 Jan 2005 16:56:05 +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 80C8A8945E; Mon, 17 Jan 2005 16:56:05 +0100 (CET) Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automatic ormanual? From: Jeroen Massar To: miguelangel.diaz@consulintel.es In-Reply-To: <01c801c4fa69$dfeabeb0$0a00a8c0@consulintel.es> References: <8457F87A-6632-11D9-A440-00039358A080@sun.com> <01c801c4fa69$dfeabeb0$0a00a8c0@consulintel.es> Organization: Unfix Date: Mon, 17 Jan 2005 16:56:03 +0100 Message-Id: <1105977363.8582.123.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 2.5 (++) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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="===============0090912803==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f --===============0090912803== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bdKFmjgMrnMrbPhKg7Op" --=-bdKFmjgMrnMrbPhKg7Op Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-01-14 at 19:50 +0100, Miguel Angel Diaz wrote: > >> In other words, could we live with a solution where the user will have= =20 > >> to manually > >> input on its v6 host or router an address of the form v6TEP.myISP.com=20 > >> in the relevant > >> form? (provided that would be the ONLY thing to input) > >=20 > > ... or do we absolutely require an automatic discovery mechanism? > >=20 >=20 > IMHO if we wish a broad and fast deployment of IPv6 the answer is that an > automatic discovery mechanism is definitively required.=20 There is already Teredo and 6to4, what more is needed? Teredo on it's own already solves most if not all problems. The only issue with Teredo _could_ be that one does not get the most local relay. But I think M$ can be easily pursuade to add a update to windowsupdate that will reconfigure the default teredoserver to an anycast address. The point more is: who uses it? > Today many ISPs are wondering why should they deploy IPv6 in their core n= etworks > or in their access networks if no IPv6 traffic is detected. How can they claim they don't see traffic if they don't have any connectivity. This is really a weird and invalid assumption. The thing has to do with one simple thing: Money. And IPv6 as connectivity does not get them extra cash in their pockets why would they even bother with it? Tell them that they can generate revenue and how and they will focus on it. But getting a re-schooling for their, most likely already, under- educated helpdesk and the many other parts of their organization is really not where they are going to invest money into. As the moment the provide it they also need to provide support. "Hi this is Grandma, my internet does not work" > On the other hand, hardware manufacturers, application developers and use= rs in > general are wondering why should they need IPv6 in the products that > they develop/use if users don't have IPv6 connectivity either native > or by mean of an easy/automatic transition mechanism. Users don't know what IP is, what version it is, they don't care nor do they want to care. To put it bluntly: they want ass, tits and a lot of killing in their virtual warfields. Does Doom3 support IPv6? Does Halo2 support IPv6? Does Half Life support it? =3D> No. Should somebody as a being a normal user care? No? Does their porn work over IPv4? =3D> Yes, so do they care for IPv6? =3D> No= . There is this nice blonde girl singing a nice song: It is all about the money. And even though in the US the DoD claim to invest billions for IPv6, there is no such thing toward the enduser. Thus should the provider for endusers care? =3D> No. > In these circumstances, ISP will never detect IPv6 traffic because users = (normal > users) don't know (and likely don't want to) how to find TEPs and how to = configure > IPv6 tunnels They apparently know very well how to do all this. Google for newsserver and IPv6 and free and similar wordings. Tutorials are there for the grab and then you don't even see the backroom chats where the trading is going on. > , and product developers aren't pushed neither to develop IPv6 > products/application (which would generate the IPv6 traffic) because they= depend > on the technical knowledge of users (usually minimal if any). Product developers don't see money in IPv6 so why would they care? > This is a bootstrapping and the only way to solve it is by easing the IPv= 6 transition. > One efficient mean is an auto-discovery mechanism that finds the TEP by i= tself and users don't have to be worried about it. Ever considered Teredo ? > Let's think that there could be a lot of IPv6 devices like cameras, home = automation devices, cars, etc that > could take advantage of an automatic discovery method to find IPv6 connec= tivity without human intervention. Now if I would live in Tokio I could live with this assumption, but unfortunately, unless I go to Akibara myself or import the stuff I will not be able to buy these cool toys (yet). Also, the router in the house should provide this, not the camera, that should simply RA. Next to that does the word 'security' say anything? > So, IMHO the answer is that we can't live with methods that require users= to enter any URL or data. I know of almost 3500 happy users who lived with this perfectly fine and there are a number of other organizations who claim to have way more users. Greets, Jeroen --=-bdKFmjgMrnMrbPhKg7Op Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB6+ATKaooUjM+fCMRAtR7AJ937R0TsDCiGJo8AtU0E98rupwk2ACfca6J lGCBAghxDHn0zDeJR0mnYss= =QQvL -----END PGP SIGNATURE----- --=-bdKFmjgMrnMrbPhKg7Op-- --===============0090912803== 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 --===============0090912803==-- From v6tc-bounces@ietf.org Mon Jan 17 11:24: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 LAA20342; Mon, 17 Jan 2005 11:24:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZvZ-00008d-Gf; Mon, 17 Jan 2005 11:40:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZYE-0005Mt-Bs; Mon, 17 Jan 2005 11:16:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZOv-0002mi-Mz for v6tc@megatron.ietf.org; Mon, 17 Jan 2005 11:06: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 LAA18680 for ; Mon, 17 Jan 2005 11:06:42 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZdy-00086V-2d for v6tc@ietf.org; Mon, 17 Jan 2005 11:22:18 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 29B558B763; Mon, 17 Jan 2005 17:06:41 +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 03890-07; Mon, 17 Jan 2005 17:06:39 +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 4DA0E8B766; Mon, 17 Jan 2005 17:06:12 +0100 (CET) Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: miguelangel.diaz@consulintel.es In-Reply-To: <01c601c4fa69$d35cf050$0a00a8c0@consulintel.es> References: <4642E1C0-64A7-11D9-8C90-00039358A080@sun.com> <026001c4f951$255967e0$0a00a8c0@consulintel.es> <1105611172.3310.138.camel@firenze.zurich.ibm.com> <01c601c4fa69$d35cf050$0a00a8c0@consulintel.es> Organization: Unfix Date: Mon, 17 Jan 2005 17:06:10 +0100 Message-Id: <1105977970.8582.133.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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="===============1146655996==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --===============1146655996== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Pn3+08fytyxbn9PpRVWn" --=-Pn3+08fytyxbn9PpRVWn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-01-14 at 19:49 +0100, Miguel Angel Diaz wrote: > Even in your case the discovery method we are going to propose will work. Can you please explain me how it would work? Because I really can't see how it can because there is absolutely no information that makes you able to figure out the nameservers of the ISP with the information I gave below ;) > Basically we only suppose one thing: the local ISP is the entity that de= ploys the TEP that the user (rather the OS) is looking for. > > With that premise we propose to use SRV RR because the advantages shown > in http://www.ietf.org/internet-drafts/draft-palet-v6ops-solution-tun-aut= o-disc-01.txt. > However to use effectively that approach it is necessary to know the ISP = domain > name which is not trivial because it is not usually propagated. That was the question I asked you, how are you going to figure out in which domain you need to look for those records? > The new draft version of draft-palet-v6ops-solution-tun-auto-disc will pr= opose a > method to discover not only the ISP domain name but also the DNS server t= o make the SRV queries. You think that my DNS server has a relation to the DNS server of my upstream ISP? No way, they don't do IPv6 nor DNSSEC and mine does. > To do that the only thing is to find out the authoritative DNS server on = the ISP domain and then you'll have all. And _how_ are you going to do it? that you want to do it is clear, but how? :) > In this way the queries will be sent not to your local DNS server but the > authoritative DNS server of your ISP who is in charge of the TEP deployme= nt, so it will work even in your network. Please look again at the situation that I depicted as there really is no way to find out the domain name of my upstream ISP :) It is not even possible to do it manually unless you simply assume certain things, but that is done by the human brain, not by the computer. Greets, Jeroen --=-Pn3+08fytyxbn9PpRVWn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB6+JyKaooUjM+fCMRAq84AKCb6WBULYuWJfXRuR61df1v5i91tQCguD++ wn7EpJo/oLMg+LoVV4T2UO4= =ARjj -----END PGP SIGNATURE----- --=-Pn3+08fytyxbn9PpRVWn-- --===============1146655996== 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 --===============1146655996==-- From v6tc-bounces@ietf.org Mon Jan 17 11:25:10 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 LAA20381; Mon, 17 Jan 2005 11:25:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZvs-00008w-GV; Mon, 17 Jan 2005 11:40:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZYI-0005O7-3V; Mon, 17 Jan 2005 11:16:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZPm-0003T0-IZ for v6tc@megatron.ietf.org; Mon, 17 Jan 2005 11:07:38 -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 LAA18774 for ; Mon, 17 Jan 2005 11:07:35 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZeq-00088e-FB for v6tc@ietf.org; Mon, 17 Jan 2005 11:23:13 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j0HG7Li3007726 for ; Mon, 17 Jan 2005 16:07:21 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA02127 for ; Mon, 17 Jan 2005 16:07:31 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j0HG7VG30646 for v6tc@ietf.org; Mon, 17 Jan 2005 16:07:31 GMT Date: Mon, 17 Jan 2005 16:07:31 +0000 From: Tim Chown To: v6tc@ietf.org Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automatic ormanual? Message-ID: <20050117160731.GO22108@login.ecs.soton.ac.uk> Mail-Followup-To: v6tc@ietf.org References: <8457F87A-6632-11D9-A440-00039358A080@sun.com> <01c801c4fa69$dfeabeb0$0a00a8c0@consulintel.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c801c4fa69$dfeabeb0$0a00a8c0@consulintel.es> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Fri, Jan 14, 2005 at 07:50:09PM +0100, Miguel Angel Diaz wrote: > > IMHO if we wish a broad and fast deployment of IPv6 the answer is that an automatic discovery mechanism is definitively required. I do tend to agree, despite the hurdles that this poses. The sort of scenario Jeroen paints is one where the local user/admin has a specific customisation beyond where the typical Joe Boradband user would be, so I think that sort of power user could manually configure their IPv6 connectivity. > So, IMHO the answer is that we can't live with methods that require users to enter any URL or data. Well, at home I still have trouble finding what SMTP server to use for my ADSL service. Luckily I use a remote service via ssh so I don't need to know, but the problem exists for other settings, as has been pointed out here already. Tim _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Mon Jan 17 11:26:18 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 LAA20459; Mon, 17 Jan 2005 11:26:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZwy-0000AL-K9; Mon, 17 Jan 2005 11:41:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZgQ-0007dD-9o; Mon, 17 Jan 2005 11:24:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZWW-00057v-5W for v6tc@megatron.ietf.org; Mon, 17 Jan 2005 11:14:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19417 for ; Mon, 17 Jan 2005 11:14:33 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZlb-0008LI-8P for v6tc@ietf.org; Mon, 17 Jan 2005 11:30:11 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j0HGENi3007846 for ; Mon, 17 Jan 2005 16:14:23 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA02638 for ; Mon, 17 Jan 2005 16:14:32 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j0HGEWj30770 for v6tc@ietf.org; Mon, 17 Jan 2005 16:14:32 GMT Date: Mon, 17 Jan 2005 16:14:32 +0000 From: Tim Chown To: v6tc@ietf.org Subject: Re: Fw: [v6tc] Issue 2: service discovery: automatic or manual? Message-ID: <20050117161432.GP22108@login.ecs.soton.ac.uk> Mail-Followup-To: v6tc@ietf.org References: <01c701c4fa69$da1b0350$0a00a8c0@consulintel.es> <1105975480.8582.101.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1105975480.8582.101.camel@firenze.zurich.ibm.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: 69a74e02bbee44ab4f8eafdbcedd94a1 On Mon, Jan 17, 2005 at 04:24:40PM +0100, Jeroen Massar wrote: > > Scene 1 mentions that "most of the TB's belong to the academic or > research scope". FreeNet6 _was_ indeed Canarie, but is now fully > commercial based at Hexago, Hurricane Electric is a commercial company > as well, and out of the 13 SixXS POPs only 2 are 'academic'. From this > small and quite complete list, I think the majority is thus actually > commercial unlike what you are mentioning in your paper. Though they do > offer free service, that is correct. But why not? It is for getting > people going with IPv6. As for a TB with 'poor performance', as long as > you don't pick one on the other side of the ocean you should be fine. > I've not encountered one which was congested yet. There is not that much > IPv6 traffic yet anyways. You also imagine that people get everything > for free. The reason why there are free TB's is because of the fact that > giving a good TB service the users will value the ISP and are likely to > maybe buy other services from them. Scene 1 is thus quite bogus because > it is based on false assumptions and a lot of missing background. For info, when we surveyed European NRENs in 2004, 75% operated a 6to4 relay while 25% operated a tunnel broker. One NREN has turned its broker off (UNINETT). [Ref: D2.2.3 at www.6net.org] But I don't think we're suggesting that (say) UKERNA would expect home DSL users to pick its broker by the automated TEP discovery method, you'd expect to find the broker of the home DSL ISP (e.g. BT Openworld). However, the "go to a web page and execute a script" method works well enough for the clueful existing TB users, and thus we've muddled through on that basis until now. I guess some users would want to use a named TEP though, rather than an autodiscovered one. Tim _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Mon Jan 17 12:44:28 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 MAA27684; Mon, 17 Jan 2005 12:44:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqbAd-0002Bq-Nm; Mon, 17 Jan 2005 13:00:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqaqD-0005gn-E9; Mon, 17 Jan 2005 12:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqah5-0003zj-EZ for v6tc@megatron.ietf.org; Mon, 17 Jan 2005 12:29:37 -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 MAA26364 for ; Mon, 17 Jan 2005 12:29:31 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqaw9-0001mW-Rr for v6tc@ietf.org; Mon, 17 Jan 2005 12:45:10 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id CBD6989D3F; Mon, 17 Jan 2005 18:29:26 +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 08794-03; Mon, 17 Jan 2005 18:29:26 +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 561318945E; Mon, 17 Jan 2005 18:29:26 +0100 (CET) Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automatic ormanual? From: Jeroen Massar To: Tim Chown In-Reply-To: <20050117160731.GO22108@login.ecs.soton.ac.uk> References: <8457F87A-6632-11D9-A440-00039358A080@sun.com> <01c801c4fa69$dfeabeb0$0a00a8c0@consulintel.es> <20050117160731.GO22108@login.ecs.soton.ac.uk> Organization: Unfix Date: Mon, 17 Jan 2005 18:29:25 +0100 Message-Id: <1105982965.8582.166.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 3.7 (+++) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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="===============0056248737==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 --===============0056248737== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mitAtsJA2+CM4SA54B4M" --=-mitAtsJA2+CM4SA54B4M Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-01-17 at 16:07 +0000, Tim Chown wrote: > On Fri, Jan 14, 2005 at 07:50:09PM +0100, Miguel Angel Diaz wrote: > >=20 > > IMHO if we wish a broad and fast deployment of IPv6 the answer is that = an automatic discovery mechanism is definitively required.=20 >=20 > I do tend to agree, despite the hurdles that this poses. =20 >=20 > The sort of scenario Jeroen paints is one where the local user/admin has > a specific customisation beyond where the typical Joe Boradband user woul= d > be, so I think that sort of power user could manually configure their IPv= 6 > connectivity. Fortunately you see my point, but I do have to note that you should not underestimate Joe Broadband user and his/her need for the newest movies/music and other goodies which will let the RIAA turn over in their graves even before they go into it. Pick up Joe Broadband's PC magazine and check which nice tutorials are in there in you will get what I mean, they are usually to low-tech but otherwise they could point quite interesting even for people who are in the industry. But even if I did not customize that much. Finding the DNS name of "my ISP" would already be undoable in the following very standard situation: +-------+ +---------+ | ISP |--------| NAT Box |-------{ hosts } +-------+ +---------+ If I would configure my home network like this, then still there is no way to figure out that my ISP actually uses cistron.nl and not .net as in the traceroutes or as the reverse of services etc. SOA's are pointing to .net, reverses are .net, but the services reside in the .nl domain. And I am not even mentioning the various Virtual ISP's who actually outsource everything. That is why I wonder how Miguel et al are going to use these nice DNS SRV records ;) Also assuming that you can figure it out, if there is no DNS SRV record in the upstream, what then? No service for that user? There is nothing automatic in this setup then as there are almost no ISP's doing IPv6 in the first place, that is why there is 6to4 and Teredo, who fit the bill perfectly as I already mentioned. > > So, IMHO the answer is that we can't live with methods that require use= rs to enter any URL or data. >=20 > Well, at home I still have trouble finding what SMTP server to use for my > ADSL service. Luckily I use a remote service via ssh so I don't need to > know, but the problem exists for other settings, as has been pointed out = here > already. Which can be solved easily as I mentioned before: Service Prefix. 2001:db8::25 =3D smtp. No configuration no nothing. Or do it wpad (http://www.wlug.org.nz/WPAD) style. Aka have a common known url where the configuration settings can be fetched. Thus http://2001:db8::4170/autoconfiguration/ and tada your sweet little computer will receive: SMTP: smtp.example.net POP3: pop3.outsourced.example.com TEP: miguels.uber.tep.example.net etc.... whatever you want. Oh and please, don't forget SLP (RFC2608). Don't think about failover to much, if your upstream ISP is dead then you can't reach it either. Just like when they don't fix such services you can't use them, simple. If you want resilience: pay for it. Like Meja says: It's all about the money ;) Greets, Jeroen --=-mitAtsJA2+CM4SA54B4M Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB6/X1KaooUjM+fCMRAqHXAKCWoulH053Sx0UmSTKMtbVT39LZuACaAzgn FhjMNieuAAXYMGLWNLj2OCk= =ymaK -----END PGP SIGNATURE----- --=-mitAtsJA2+CM4SA54B4M-- --===============0056248737== 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 --===============0056248737==-- From v6tc-bounces@ietf.org Mon Jan 17 12:51:17 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 MAA28614; Mon, 17 Jan 2005 12:51:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqbHE-0002Sb-MF; Mon, 17 Jan 2005 13:06:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqaxR-0006p0-FV; Mon, 17 Jan 2005 12:46:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqar4-0005sN-IK for v6tc@megatron.ietf.org; Mon, 17 Jan 2005 12:39:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27385 for ; Mon, 17 Jan 2005 12:39:51 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqb69-00024z-Ec for v6tc@ietf.org; Mon, 17 Jan 2005 12:55:31 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id B5D9C89D3F; Mon, 17 Jan 2005 18:39:51 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09368-06; Mon, 17 Jan 2005 18:39:51 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id 3EF258945E; Mon, 17 Jan 2005 18:39:51 +0100 (CET) Subject: Re: Fw: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: Tim Chown In-Reply-To: <20050117161432.GP22108@login.ecs.soton.ac.uk> References: <01c701c4fa69$da1b0350$0a00a8c0@consulintel.es> <1105975480.8582.101.camel@firenze.zurich.ibm.com> <20050117161432.GP22108@login.ecs.soton.ac.uk> Organization: Unfix Date: Mon, 17 Jan 2005 18:39:49 +0100 Message-Id: <1105983589.8582.172.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 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: , Content-Type: multipart/mixed; boundary="===============1832030349==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 --===============1832030349== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NdNdYpAA1wheTjfQLqdT" --=-NdNdYpAA1wheTjfQLqdT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-01-17 at 16:14 +0000, Tim Chown wrote: > On Mon, Jan 17, 2005 at 04:24:40PM +0100, Jeroen Massar wrote: > >=20 > > Scene 1 mentions that "most of the TB's belong to the academic or > > research scope". FreeNet6 _was_ indeed Canarie, but is now fully > > commercial based at Hexago, Hurricane Electric is a commercial company > > as well, and out of the 13 SixXS POPs only 2 are 'academic'. From this > > small and quite complete list, I think the majority is thus actually > > commercial unlike what you are mentioning in your paper. Though they do > > offer free service, that is correct. But why not? It is for getting > > people going with IPv6. As for a TB with 'poor performance', as long as > > you don't pick one on the other side of the ocean you should be fine. > > I've not encountered one which was congested yet. There is not that muc= h > > IPv6 traffic yet anyways. You also imagine that people get everything > > for free. The reason why there are free TB's is because of the fact tha= t > > giving a good TB service the users will value the ISP and are likely to > > maybe buy other services from them. Scene 1 is thus quite bogus because > > it is based on false assumptions and a lot of missing background. >=20 > For info, when we surveyed European NRENs in 2004, 75% operated a 6to4 > relay while 25% operated a tunnel broker. The doc mentions that there are 25+ NREN's in total, of which 18 where connected to 6net. out of that 75% had a 6to4 relay, thus for the complete European community (how many connections are that?) there where 12 NREN's with 6to4 relays, which is thus only a low 50%. Not bad but I wonder if 1Gbit/s is enough for such a large community, assuming that each box only has a 100mbit card. > One NREN has turned its broker off (UNINETT). NREN's are of course all non-commercial and politically are not to deliver to endusers, and wasn't this what the automatic discovery was intended for ? :) Next to that 6net is now fortunately getting turned off, only few countries left, which saves a lot of problems in the IPv6 world ;) Btw, funny that none of the 6net participants ever had linerate (Gig and up) native IPv6, one would have hoped that the various hardware vendors would have done playtesting by now. 6to4 has one problem, which Teredo does not have: NAT's. > [Ref: D2.2.3 at www.6net.org] >=20 > But I don't think we're suggesting that (say) UKERNA would expect home > DSL users to pick its broker by the automated TEP discovery method, you'd > expect to find the broker of the home DSL ISP (e.g. BT Openworld). > However, the "go to a web page and execute a script" method works well > enough for the clueful existing TB users, and thus we've muddled through > on that basis until now. I guess some users would want to use a named > TEP though, rather than an autodiscovered one. Indeed. Thus a 'if configured don't touch' but otherwise try to do it, is very useful. And we already have that in Windows XP for instance ;) Thus why invent the wheel again? Or is this just another 'it has a MS stamp and that ain't good enough for the world' kind of thing? Greets, Jeroen --=-NdNdYpAA1wheTjfQLqdT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB6/hlKaooUjM+fCMRAg0cAJ0RD1EibLUovz3fRHQp0Ms1uDnlHwCcCi/v TOj0KAawqV0CgFvEhjsLCTs= =KMTT -----END PGP SIGNATURE----- --=-NdNdYpAA1wheTjfQLqdT-- --===============1832030349== 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 --===============1832030349==-- From v6tc-bounces@ietf.org Tue Jan 18 04:23: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 EAA04034; Tue, 18 Jan 2005 04:23:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqpp9-0002KD-2n; Tue, 18 Jan 2005 04:38:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqpT3-00010P-Hg; Tue, 18 Jan 2005 04:16:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqpR4-0000fZ-Ne for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 04:14:02 -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 EAA03524 for ; Tue, 18 Jan 2005 04:14:00 -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 1CqpgI-000270-4G for v6tc@ietf.org; Tue, 18 Jan 2005 04:29:47 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000713502.msg for ; Tue, 18 Jan 2005 10:14:14 +0100 Message-ID: <013601c4fd3e$125f4650$1100a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <00a801c4fd30$4baad180$1100a8c0@consulintel.es> Subject: Re: Fw: [v6tc] Issue 2: service discovery: automatic or manual? Date: Tue, 18 Jan 2005 10:14:08 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Tue, 18 Jan 2005 10:14:19 +0100 X-MDAV-Processed: consulintel.es, Tue, 18 Jan 2005 10:14:20 +0100 X-Spam-Score: 2.2 (++) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1503298922==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab --===============1503298922== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQo+PiBJIHBhcnRpYWxseSBhZ3JlZSB3aXRoIHlvdXIgcG9pbnQuIEkgYWxzbyBzdXBwb3J0IHRo ZSBpZGVhIG9mIGFuIGFueWNhc3QgYWRkcmVzcyBpZjoNCj4+IA0KPj4gMSkgZWFjaCB0cmFuc2l0 aW9uIG1lY2hhbmlzbSBoYXMgaXRzIG93biBhbnljYXN0IGFkZHJlc3MNCj4gDQo+IFdoeT8gSnVz dCBzZXR1cCBhIFRyYW5zaXRpb24gTWVjaGFuaXNtIFNlcnZlciBvciB3aGF0ZXZlciwgZWcgYSBz aW1wbGUNCj4gd2Vic2VydmVyIGFuZCBhIHNwZWNpYWwgVVJMIG9uIHRoYXQgYm94IHdvdWxkIHJl dHJpZXZlIHRoZSBpbmZvcm1hdGlvbg0KPiB3aGljaCBhbGxvd3MgdGhlIGNsaWVudCB1dGlsaXR5 IHRvIGZpZ3VyZSBvdXQgd2hhdCB0byBkbyBvciB3aGVyZSB0byBnZXQNCj4gdGhlIHJlYWwgaW5m b3JtYXRpb24uIERvbid0IHdhc3RlIHJlc291cmNlcywgdGhlcmUgJ21pZ2h0JyBiZSBlbm91Z2gs DQo+IGJ1dCB0aGVuIHN0aWxsIHlvdSBkb24ndCBoYXZlIHRvIHdhc3RlIGl0Lg0KDQpXZWxsLCBJ J20gdGhpbmtpbmcgb2YgYSBkaWZmZXJlbnQgYXBwcm9hY2guIElmIGV2ZXJ5IHRyYW5zaXRpb24g bWVjaGFuaXNtIGhhcyBpdHMgb3duIGFueWNhc3QgYWRkcmVzcyB0byBkaXNjb3ZlciBhIFRFUCB0 aGlzIGFsbG93cyB0aGF0IGFueSBhcHBsaWNhdGlvbiBpbXBsZW1lbnRpbmcgYSBzcGVjaWZpYyB0 cmFuc2l0aW9uIG1lY2hhbmlzbSBjYW4gY29udGFjdCB0aGUgVEVQIGRpcmVjdGx5Lg0KDQpJZiB0 aGVyZSBpcyBvbmx5IGFuIGFueWNhc3QgYWRkcmVzcyBmb3IgYSBzZXJ2ZXIgdGhlbiB0aGVyZSBp cyBhIG5lZWQgZm9yIGhhbmRzaGFraW5nLCB0aGF0IGlzLCBjbGllbnQgaGFzIHRvIGFzayB0aGUg YW55Y2FzdCBzZXJ2ZXIgIldoYXQga2luZCBvZiBURVAgZG8geW91IHN1cHBvcnQ/IiBhbmQgdGhl biBvbmNlIHRoZSBjbGllbnQgaGFzIHRoZSBzZXJ2ZXIgcmVwbHkgaXQgd2lsbCBkZWNpZGUgaWYg aXQgY2FuIHVzZSBpdC4gVGhpcyBhcHByb2FjaCByZXF1aXJlcyBtb3JlIHN0YW5kYXJkaXphdGlv biBmb3IgdGhlIGhhbmRzaGFrZS4NCg0KSWYgZXZlcnkgdHJhbnNpdGlvbiBtZWNoYW5pc20gaGFz IGl0cyBvd24gYW55Y2FzdCBhZGRyZXNzLCB0aGUgY2xpZW50IG9ubHkgY29udGFjdCB0aGUgVEVQ IGFuZCBhbGwgdGhlIGNvbW11bmljYXRpb25zIGJldHdlZW4gYm90aCBob3N0cyBiZWxvbmdzIHRv IHRoZSBwcm90b2NvbCBzY29wZS4gTm8gbW9yZSBzdGFuZGFyZGl6YXRpb24gaXMgcmVxdWlyZWQu IFRoaXMgd2lsbCBhbGxvdyB0aGF0IGRpZmZlcmVudCB0cmFuc2l0aW9uIG1lY2hhbmlzbSBpbXBs ZW1lbnRhdGlvbiBjb3VsZCBiZSBkaXJlY3RseSBhbmQgZWFzaWx5IGludGVncmF0ZWQgb24gdGhl IE9TLg0KDQoNCj4gDQo+IFJlcmVhZCB3aGF0IEkgd3JvdGUgKGFuZCBhbHNvIHdyb3RlIGxhc3Qg eWVhciBpbiBhcHJpbCk6IFNlcnZpY2UgQW55Y2FzdA0KPiBQcmVmaXguIFdoaWNoIGlzIGp1c3Qg c28geW91IGNhbiByZWFjaCBhIGJveCB3aGljaCBjYW4gdGVsbCB5b3UgJ3RoZXJlDQo+IGlzIHRo ZSBzZXJ2aWNlIGZvciB5b3UnIGFuZCBmcm9tIHRoZW4gb24geW91IGNhbiBkbyBhbnl0aGluZyBw b3NzaWJsZS4NCj4gDQo+PiAyKSB0aGUgYW55Y2FzdCBhZGRyZXNzIHNjb3BlIGlzIGdsb2JhbCwg SSBtZWFuLCBpdCBpcyBhcHBsaWVkIG5vdCBvbmx5DQo+PiB0byB0aGUgSVNQIGRvbWFpbiBidXQg dGhlIHdob2xlIEludGVybmV0Lg0KPiANCj4gV2h5PyBJZiB0aGUgc2VydmljZSBwcmVmaXggaXMg b25seSBhbm5vdW5jZWQgdG8gdGhlIGxvY2FsIElTUCwgdGhlbiBvbmx5DQo+IHRob3NlIHdpbGwg cmVjZWl2ZSBzZXJ2aWNlIGZyb20gdGhhdCBpbnN0YW5jZS4gQW5ub3VuY2UgaXQgdG8gdGhlIHdv cmxkDQo+IGFuZCB5b3UgZ2l2ZSB0aGUgd29ybGQgc2VydmljZS4gVGhhdCBpcyBob3cgYW55Y2Fz dCB3b3Jrcywgc2ltcGxlIGFuZA0KPiBlYXN5Lg0KPiANCj4+IGV2ZW4gdW5kZXIgdGhpcyBhc3N1 bXB0aW9ucyB0aGVyZSBhcmUgc2V2ZXJhbCBiYXJyaWVycyB3aGljaCB3b3VsZA0KPiANCj4gV2hp Y2ggYmFycmllcnM/DQo+IA0KPj4gcHJldmVudCB0aGF0IHRoZSBhbnljYXN0IHNlcnZpY2Ugd2ls bCB3b3JrIG9uIHRoZSB3aG9sZSBJbnRlcm5ldCBhbmQNCj4+IGZvciBhbGwgdGhlIHRyYW5zaXRp b24gbWVjaGFuaXNtcyAoc2VlDQo+Pg0KPiBodHRwOi8vd3d3LmNvbnN1bGludGVsLmV1cm82aXgu b3JnL2lldGYvYXBwbGljYXRpb25fb2ZfYW55Y2FzdF9mb3JfdGJfaW1wbGVtZW50YXRpb25fdjFf MC5wZGYpLiANCj4gDQo+IEEgZmV3IGNvbW1lbnRzOg0KPiANCj4gRGVmaW5pbmcgYW55Y2FzdCBh ZGRyZXNzIGFzIGEgdHVubmVsIGVuZHBvaW50IGZvciB0cmFkaXRpb25hbCBUdW5uZWwNCj4gQnJv a2VycyBpcyBzaWxseSwgZXNwZWNpYWxseSBiZWNhdXNlIHRoYXQgaXMgc2ltcGx5IGEgbm9ybWFs LCB3ZWxsDQo+IGVzdGFibGlzaGVkIHVzZSBvZiBzZXJ2ZXIgZmFpbG92ZXIuIElmIHlvdSBtZWFu dCB0byBkbyBnbG9iYWwgYW55Y2FzdA0KPiBkZXBsb3ltZW50LCBwbGVhc2Ugc3RpY2sgdG8gNnRv NCBhcyB5b3UgZG8gbm90IHdhbnQgdGhlIGhhc3NsZSBvZg0KPiBtYW5hZ2luZyB0aGF0LiBOZXh0 IHRvIHRoYXQgeW91IG1pZ2h0IGJlIGludGVycmVzdGVkIGluIGFuIGFsdGVybmF0aXZlDQo+IGFw cHJvYWNoIGFzIHByZXNlbnRlZCBieSBYUzI2IChodHRwOi8vd3d3LnhzMjYubmV0KSB3aG8gdXNl IG11bHRpcGxlDQo+IHR1bm5lbCBzZXJ2ZXJzIGFuZCBhbGxvdyBwZW9wbGUgdG8gdXNlIG11bHRp cGxlIHR1bm5lbHMsIHRodXMgZ2l2aW5nDQo+IHRoZW0gY29tcGxldGUgZmFpbG92ZXIgcG9zc2li aWxpdGllcy4NCj4gDQoNClsuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uXQ0KDQo+IEJ0dywgd2hlbiB3YXMgdGhpcyBwYXBlciB3cml0dGVuLCBiZWNhdXNlIGl0IG1l bnRpb25zICdjdXJyZW50JyBhIGNvdXBsZQ0KPiBvZiB0aW1lcywgYnV0IHRoZXJlIGlzIG5vIHB1 YmxpY2F0aW9uIGRhdGUgaW4gdGhlIHBhcGVyLiANCg0KVGhhdCBwYXBlciB3YXMgd3JpdHRlbiB0 d28geWVhcnMgYWdvIGJ1dCBvbmx5IGZvciBpbnRlcm5hbCBwcm9wb3Nlcywgc28gaXQgaXMgbm90 IHB1YmxpYyBub3IgYW5ub3VuY2VkIGFueXdoZXJlLiBJIHJlZmVyZW5jZWQgaXQgb24gdGhlIG1h aWwgb25seSB0byBoaWdobGlnaHQgc2V2ZXJhbCBkb2N1bWVudGVkIGlzc3VlcyB3aGVuIGRlcGxv eWluZyBhbnljYXN0IHNlcnZpY2VzIChub3Qgb25seSBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9m IFRFUCBkZXBsb3ltZW50KToNCg0KLSBwYWNrZXQgZGVsaXZlcnkgb24gbW9yZSB0aGFuIG9uZSBh bnljYXN0IGhvc3Qgd2hlbiBlc3RhYmxpc2hpbmcgdGhlIGNvbW11bmljYXRpb24gKFRDUCBTWU4v QUNLIHBhY2tldHMpDQotIHBhY2tldHMgYmVsb25naW5nIHRvIGEgYnVyc3QgYmVpbmcgZGVsaXZl cmVkIG9uIGRpZmZlcmVudCBhbnljYXN0IGhvc3RzDQotIElTUHMgZmlsdGVyIGJncCByb3V0ZXMg dGhhdCBhcmVuJ3QgbmV0d29ya3MgYnV0IGhvc3RzLiBUaGlzIGlzIG1hZGUgdG8gcHJldmVudCB0 aGF0IHJvdXRpbmcgdGFibGVzIGJlY29tZSB0b28gYmlnLg0KLSBJU1BzIHVzdWFsbHkgZmlsdGVy IHRyYWZmaWMgd2hpY2ggdGhlIHNvdXJjZSBhZGRyZXNzIGRvZXNuJ3QgYmVsb25nIHRvIGl0cyBv d24gYWRkcmVzcyBzcGFjZS4gVGhpcyBpcyBhbiBpc3N1ZSB3aGVuIHRoZSB0cmFmZmljIGlzIG9y aWdpbmF0ZWQgb24gdGhlIGFueWNhc3Qgbm9kZS4NCg0KVGhlcmUgYXJlIGxvdHMgb2YgaW5mbyBh Ym91dCBhbnljYXN0IGlzc3VlczoNCg0KKiBSb2JlcnQgRW5nZWwsIFZpbm9kIFBlcmRpcywgRGVi YW5qYW4gU2FoYS4gIlVzaW5nIElQIGFueWNhc3QgZm9yIGxvYWQgZGlzdHJpYnV0aW9uIGFuZCBz ZXJ2ZXIgbG9jYXRpb24iICBodHRwOi8vd3d3Lnp1cmljaC5pYm0uY29tL35yaGEvcGFwZXJzL2Fu eWNhc3QtZ2k5OC5wZGYNCiogQy4gUGF0cmlkZ2UsIFQuIE1lbmRleiwgVy4gTWlsbGlrZW4uICJI b3N0IEFueWNhc3RpbmcgU2VydmljZSIuIFJGQyAxNTQ2LiBOb3ZpZW1icmUgMTk5My4NCiogQ2hy aXMgTWV0ei4gIklQIEFueWNhc3Q6IFBvaW50IHRvIChBbnkpIFBvaW50IENvbW11bmljYXRpb25z IiBodHRwOi8vd3d3LmNpc2NvLmNvbS9wdWJsaWMvY29ucy9pc3AvZXNzZW50aWFscy9pcC1hbnlj YXN0LWNtZXR6LTAzLnBkZiANCiogUy4gQmhhdHRhY2hhcmplZSwgTS4gQW1tYXIsIEUuIFplZ3Vy YSwgVi4gU2hhaCBhbmQgWi4gRmVpLiAiQXBwbGljYXRpb24tTGF5ZXIgQW55Y2FzdGluZyIgSUVF RSBJbmZvY29tIDE5OTcuIEtvYmUgSmFwYW4uDQoqIEQuIERpYXMsIFcuIEtpc2gsIFIuIE11aGtl cmplZSwgUi4gVGV3YXJpLiAiQSBzY2FsYWJsZSBhbmQgaGlnaGx5IGF2YWlsYWJsZSB3ZWIgc2Vy dmVyIi4gUHJvY2VlZGluZ3Mgb2YgdGhlIElFRUUgQ29tcHV0ZXIgQ29uZmVyZW5jZSAoQ09NUENP TikiLiBTYW50YSBDbGFyYS4gTWFyem8gMTk5Ni4NCg0KDQo+QW5kIHBsZWFzZSBiZQ0KPiBmcmVl IHRvIHRyYW5zbGF0ZSB0byBzcGFuaXNoIG9uIHBhZ2UgOSBhbmQgSSB3b24ndCBmYWxsIG92ZXIg dGhlIHZhcmlvdXMNCj4gYnJva2VuIHNlbnRlbmNlcyAoaXQgYWN0dWFsbHkgcmVhZHMgbGlrZSBp dCBoYXMgYmVlbiB0cmFuc2xhdGVkIGJ5DQo+IGJhYmVsZmlzaCBvciBzb21ldGhpbmcgc2ltaWxh cikuIEkgYW0gYWxzbyBxdWl0ZSBzdXJlIHRoYXQgdGhlcmUgaXMgbm8NCj4gVEIgYXJvdW5kIHRo YXQgY2hhbmdlcyB0aGUgdXNlcnMgZm9yd2FyZCBETlMgem9uZSwgZXZlbiB0aG91Z2ggdGhhdCBp cw0KPiBpbXBsaWVkIG9uIHRoZSBmaXJzdCBwYWdlLiBSZXZlcnNlIGluIHNvbWUgY2FzZXMsIGJ1 dCBldmVuIHRoYXQgaXMgbm90DQo+IGxpa2VseS4NCj4gDQoNClRoZSBwYXBlciB3YXMgdHJhbnNs YXRlZCB3aXRoIE0kIHRyYW5zbGF0b3IgdG9vbHMgYW5kIGl0IGlzbid0IGFzIGdvb2QgYXMgSSB3 aGlzaC4gOi0oDQoNClsuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uXSANCg0KPiBUaGUgcmVzdCBJIG9ubHkgc2tpbW1lZCBiZWNhdXNlIEkgYWN0dWFsbHkgZ290 IGEgYml0IHRpcmVkIG9mIHJlYWRpbmcNCj4gdGhlIGJyb2tlbiBlbmdsaXNoIGFuZCB0aHVzIGhh dmluZyB0byByZXJlYWQgdGhlIHNlbnRlbmNlcyBtdWx0aXBsZQ0KPiB0aW1lcyBiZWZvcmUgdGhl eSB3aGVyZSB1bmRlcnN0YW5kYWJsZS4gSWYgSSBoYWQgYW55IGtub3dsZWRnZSBvZg0KPiBzcGFu aXNoIEkgd291bGQgYXNrIGZvciB0aGUgbW9zdCBsaWtlbHkgb3JpZ2luYWwgc3BhbmlzaCB2ZXJz aW9uLCB3aGljaA0KPiBJIGd1ZXNzIGlzIG11Y2ggYmV0dGVyIHRvIHJlYWQgdGhhbiB0aGlzIHZl cnNpb24uIEkgZGlkIG5vdGljZSBhIGxvdCBvZg0KPiBsb29zZSByZWZlcmVuY2VzIHRvIHRoaW5n cyB0aGF0IHRvdGFsbHkgbWFkZSBubyByZWxhdGlvbiBhdCBhbGwgdG8gdGhlDQo+IHN1YmplY3Qg YW5kIGEgbG90IG9mIG1pc2Fzc3VtcHRpb25zLiBSb3V0aW5nIGZvciBpbnN0YW5jZSBkb2VzIG5v dA0KPiBjaGFuZ2UgZXZlcnkgNSBzZWNvbmRzIHdoZW4gc3RheWluZyBpbnNpZGUgdGhlIHNhbWUg SVNQLiBZb3UgbWlnaHQgYmUNCj4gaW50ZXJlc3RlZCBpbiB0YWtpbmcgYSBsb29rIGF0IFJJUyAo aHR0cDovL3Jpcy5yaXBlLm5ldCkgb3IgbWF5YmUNCj4gcGxheWluZyBhcm91bmQgb24gdGhlIHJl YWwgaW50ZXJuZXQgd2l0aCBzb21lIEJHUCB0b29scy4NCg0KVGhlIHBhcGVyIHdhcyBvbmx5IGFu IHN0YXJ0aW5nIHBvaW50IHdoaWNoIGJlY2FtZSBvbiB0aGUgZmlyc3QgZHJhZnQgdmVyc2lvbiBv ZiB0aGUgdGVwLWRpc2NvdmVyeSBhbmFseXNpcywgc28gaXQgaXNuJ3Qgd29ydGggdG8gZGlzY3Vz cyBhYm91dCB0aGUgc2NlbmFyaW9zIGRlc2NyaWJlZCBvbiB0aGUgcGFwZXIuDQoNClJlZ2FyZHMN Ck1pZ3VlbA0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpNYWRyaWQgMjAw MyBHbG9iYWwgSVB2NiBTdW1taXQNClByZXNlbnRhdGlvbnMgYW5kIHZpZGVvcyBvbiBsaW5lIGF0 Og0KaHR0cDovL3d3dy5pcHY2LWVzLmNvbQ0KDQpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250 YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwu IFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbChzKSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24g b3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgYXR0 YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0ZWQuDQoNCg0K --===============1503298922== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1503298922==-- From v6tc-bounces@ietf.org Tue Jan 18 04:23:26 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 EAA04058; Tue, 18 Jan 2005 04:23:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqppQ-0002KT-Hw; Tue, 18 Jan 2005 04:39:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqpT3-00010V-Pj; Tue, 18 Jan 2005 04:16:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqpRN-0000iJ-E5 for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 04:14: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 EAA03533 for ; Tue, 18 Jan 2005 04:14:19 -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 1Cqpgb-000278-98 for v6tc@ietf.org; Tue, 18 Jan 2005 04:30:06 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000713503.msg for ; Tue, 18 Jan 2005 10:14:40 +0100 Message-ID: <013701c4fd3e$1fae41d0$1100a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <00b501c4fd30$5e598880$1100a8c0@consulintel.es> Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automaticormanual? Date: Tue, 18 Jan 2005 10:14:30 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.3 required=5.0 tests=BAYES_00,EXTRA_CASH, MIME_BASE64_LATIN,MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Tue, 18 Jan 2005 10:14:40 +0100 X-MDAV-Processed: consulintel.es, Tue, 18 Jan 2005 10:14:41 +0100 X-Spam-Score: 4.7 (++++) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1096941912==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 4.7 (++++) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c --===============1096941912== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQo+PiBJTUhPIGlmIHdlIHdpc2ggYSBicm9hZCBhbmQgZmFzdCBkZXBsb3ltZW50IG9mIElQdjYg dGhlIGFuc3dlciBpcyB0aGF0IGFuDQo+PiBhdXRvbWF0aWMgZGlzY292ZXJ5IG1lY2hhbmlzbSBp cyBkZWZpbml0aXZlbHkgcmVxdWlyZWQuIA0KPiANCj4gVGhlcmUgaXMgYWxyZWFkeSBUZXJlZG8g YW5kIDZ0bzQsIHdoYXQgbW9yZSBpcyBuZWVkZWQ/DQo+IFRlcmVkbyBvbiBpdCdzIG93biBhbHJl YWR5IHNvbHZlcyBtb3N0IGlmIG5vdCBhbGwgcHJvYmxlbXMuDQo+IFRoZSBvbmx5IGlzc3VlIHdp dGggVGVyZWRvIF9jb3VsZF8gYmUgdGhhdCBvbmUgZG9lcyBub3QgZ2V0IHRoZSBtb3N0DQo+IGxv Y2FsIHJlbGF5LiBCdXQgSSB0aGluayBNJCBjYW4gYmUgZWFzaWx5IHB1cnN1YWRlIHRvIGFkZCBh IHVwZGF0ZSB0bw0KPiB3aW5kb3dzdXBkYXRlIHRoYXQgd2lsbCByZWNvbmZpZ3VyZSB0aGUgZGVm YXVsdCB0ZXJlZG9zZXJ2ZXIgdG8gYW4NCj4gYW55Y2FzdCBhZGRyZXNzLg0KPiANCg0KVGhvdXNh bmRzIChldmVuIG1pbGxpb25zKSBvZiB1c2VycyBvdmVyIHRoZSB3b3JsZCBjYW4ndCB1c2UgdGhl IGN1cnJlbnQgc2VydmVycyB0aGF0IE0kIGhhcyBwcmUtY29uZmlndXJlZCBmb3IgNnRvNCBhbmQg VGVyZWRvIGltcGxlbWVudGF0aW9ucyBvbiB0aGUgT1MsIHdoaWNoIGFyZSA2dG80LmlwdjYubWlj cm9zb2Z0LmNvbSBhbmQgdGVyZWRvLmlwdjYubWljcm9zb2Z0LmNvbS4gSXQgaXMgYXNzdW1lZCB0 aGF0IGV2ZXJ5IElTUCB3aWxsaW5nIHRvIG9mZmVyIElQdjYgc2VydmljZXMgdG8gdGhlaXIgY3Vz dG9tZXJzIHdpbGwgZGVwbG95IGEgVEVQIGluZnJhc3RydWN0dXJlIG9uIGl0cyBvd24gbmV0d29y aywgZWl0aGVyIFRlcmVkbywgNnRvNCwgb3Igd2hhdGV2ZXIuIFRoZSBURVAgZGlzY292ZXJ5IG9u IHRoZSBJU1AgbmV0d29yayBpcyB0aGUgcG9pbnQuDQoNCg0KPiBUaGUgcG9pbnQgbW9yZSBpczog d2hvIHVzZXMgaXQ/DQo+IA0KPj4gVG9kYXkgbWFueSBJU1BzIGFyZSB3b25kZXJpbmcgd2h5IHNo b3VsZCB0aGV5IGRlcGxveSBJUHY2IGluIHRoZWlyIGNvcmUgbmV0d29ya3MNCj4+IG9yIGluIHRo ZWlyIGFjY2VzcyBuZXR3b3JrcyBpZiBubyBJUHY2IHRyYWZmaWMgaXMgZGV0ZWN0ZWQuDQo+IA0K PiBIb3cgY2FuIHRoZXkgY2xhaW0gdGhleSBkb24ndCBzZWUgdHJhZmZpYyBpZiB0aGV5IGRvbid0 IGhhdmUgYW55DQo+IGNvbm5lY3Rpdml0eS4gVGhpcyBpcyByZWFsbHkgYSB3ZWlyZCBhbmQgaW52 YWxpZCBhc3N1bXB0aW9uLg0KPiBUaGUgdGhpbmcgaGFzIHRvIGRvIHdpdGggb25lIHNpbXBsZSB0 aGluZzogTW9uZXkuDQo+IEFuZCBJUHY2IGFzIGNvbm5lY3Rpdml0eSBkb2VzIG5vdCBnZXQgdGhl bSBleHRyYSBjYXNoIGluIHRoZWlyIHBvY2tldHMNCj4gd2h5IHdvdWxkIHRoZXkgZXZlbiBib3Ro ZXIgd2l0aCBpdD8NCj4gDQoNCkkgbWVhbnQgdGhhdCBJU1BzIGRvbid0IGRldGVjdCBJUHY2IHR1 bm5lbGVkIHRyYWZmaWMgKElQdjYtSVB2NCwgSVB2Ni1VRFAsIGV0YykgYmVjYXVzZSBvYnZpb3Vs c3kgdGhleSBhcmVuJ3QgZGVwbG95ZWQgbmF0aXZlIElQdjYgb24gdGhlIGFjY2VzcyBuZXR3b3Jr IHlldCA7LSkNCg0KDQo+IFRlbGwgdGhlbSB0aGF0IHRoZXkgY2FuIGdlbmVyYXRlIHJldmVudWUg YW5kIGhvdyBhbmQgdGhleSB3aWxsIGZvY3VzIG9uDQo+IGl0LiBCdXQgZ2V0dGluZyBhIHJlLXNj aG9vbGluZyBmb3IgdGhlaXIsIG1vc3QgbGlrZWx5IGFscmVhZHksIHVuZGVyLQ0KPiBlZHVjYXRl ZCBoZWxwZGVzayBhbmQgdGhlIG1hbnkgb3RoZXIgcGFydHMgb2YgdGhlaXIgb3JnYW5pemF0aW9u IGlzDQo+IHJlYWxseSBub3Qgd2hlcmUgdGhleSBhcmUgZ29pbmcgdG8gaW52ZXN0IG1vbmV5IGlu dG8uDQo+IEFzIHRoZSBtb21lbnQgdGhlIHByb3ZpZGUgaXQgdGhleSBhbHNvIG5lZWQgdG8gcHJv dmlkZSBzdXBwb3J0Lg0KPiANCj4gIkhpIHRoaXMgaXMgR3JhbmRtYSwgbXkgaW50ZXJuZXQgZG9l cyBub3Qgd29yayINCj4gDQo+PiBPbiB0aGUgb3RoZXIgaGFuZCwgaGFyZHdhcmUgbWFudWZhY3R1 cmVycywgYXBwbGljYXRpb24gZGV2ZWxvcGVycyBhbmQgdXNlcnMgaW4NCj4+IGdlbmVyYWwgYXJl IHdvbmRlcmluZyB3aHkgc2hvdWxkIHRoZXkgbmVlZCBJUHY2IGluIHRoZSBwcm9kdWN0cyB0aGF0 DQo+PiB0aGV5IGRldmVsb3AvdXNlIGlmIHVzZXJzIGRvbid0IGhhdmUgSVB2NiBjb25uZWN0aXZp dHkgZWl0aGVyIG5hdGl2ZQ0KPj4gb3IgYnkgbWVhbiBvZiBhbiBlYXN5L2F1dG9tYXRpYyB0cmFu c2l0aW9uIG1lY2hhbmlzbS4NCj4gDQo+IFVzZXJzIGRvbid0IGtub3cgd2hhdCBJUCBpcywgd2hh dCB2ZXJzaW9uIGl0IGlzLCB0aGV5IGRvbid0IGNhcmUgbm9yIGRvDQo+IHRoZXkgd2FudCB0byBj YXJlLg0KPiANCj4gVG8gcHV0IGl0IGJsdW50bHk6IHRoZXkgd2FudCBhc3MsIHRpdHMgYW5kIGEg bG90IG9mIGtpbGxpbmcgaW4gdGhlaXINCj4gdmlydHVhbCB3YXJmaWVsZHMuDQo+IA0KPiBEb2Vz IERvb20zIHN1cHBvcnQgSVB2Nj8gRG9lcyBIYWxvMiBzdXBwb3J0IElQdjY/IERvZXMgSGFsZiBM aWZlIHN1cHBvcnQNCj4gaXQ/ID0+IE5vLiBTaG91bGQgc29tZWJvZHkgYXMgYSBiZWluZyBhIG5v cm1hbCB1c2VyIGNhcmU/IE5vPw0KPiBEb2VzIHRoZWlyIHBvcm4gd29yayBvdmVyIElQdjQ/ID0+ IFllcywgc28gZG8gdGhleSBjYXJlIGZvciBJUHY2PyA9PiBOby4NCj4gDQo+IFRoZXJlIGlzIHRo aXMgbmljZSBibG9uZGUgZ2lybCBzaW5naW5nIGEgbmljZSBzb25nOiBJdCBpcyBhbGwgYWJvdXQg dGhlDQo+IG1vbmV5LiBBbmQgZXZlbiB0aG91Z2ggaW4gdGhlIFVTIHRoZSBEb0QgY2xhaW0gdG8g aW52ZXN0IGJpbGxpb25zIGZvcg0KPiBJUHY2LCB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIHRvd2Fy ZCB0aGUgZW5kdXNlci4gVGh1cyBzaG91bGQgdGhlDQo+IHByb3ZpZGVyIGZvciBlbmR1c2VycyBj YXJlPyA9PiBOby4NCj4gDQo+IA0KPiANCj4+IEluIHRoZXNlIGNpcmN1bXN0YW5jZXMsIElTUCB3 aWxsIG5ldmVyIGRldGVjdCBJUHY2IHRyYWZmaWMgYmVjYXVzZSB1c2VycyAobm9ybWFsDQo+PiB1 c2VycykgZG9uJ3Qga25vdyAoYW5kIGxpa2VseSBkb24ndCB3YW50IHRvKSBob3cgdG8gZmluZCBU RVBzIGFuZCBob3cgdG8gY29uZmlndXJlDQo+PiBJUHY2IHR1bm5lbHMNCj4gDQo+IFRoZXkgYXBw YXJlbnRseSBrbm93IHZlcnkgd2VsbCBob3cgdG8gZG8gYWxsIHRoaXMuIEdvb2dsZSBmb3IgbmV3 c3NlcnZlcg0KPiBhbmQgSVB2NiBhbmQgZnJlZSBhbmQgc2ltaWxhciB3b3JkaW5ncy4gVHV0b3Jp YWxzIGFyZSB0aGVyZSBmb3IgdGhlIGdyYWINCj4gYW5kIHRoZW4geW91IGRvbid0IGV2ZW4gc2Vl IHRoZSBiYWNrcm9vbSBjaGF0cyB3aGVyZSB0aGUgdHJhZGluZyBpcw0KPiBnb2luZyBvbi4NCj4g DQo+PiAsIGFuZCBwcm9kdWN0IGRldmVsb3BlcnMgYXJlbid0IHB1c2hlZCBuZWl0aGVyIHRvIGRl dmVsb3AgSVB2Ng0KPj4gcHJvZHVjdHMvYXBwbGljYXRpb24gKHdoaWNoIHdvdWxkIGdlbmVyYXRl IHRoZSBJUHY2IHRyYWZmaWMpIGJlY2F1c2UgdGhleSBkZXBlbmQNCj4+IG9uIHRoZSB0ZWNobmlj YWwga25vd2xlZGdlIG9mIHVzZXJzICh1c3VhbGx5IG1pbmltYWwgaWYgYW55KS4NCj4gDQo+IFBy b2R1Y3QgZGV2ZWxvcGVycyBkb24ndCBzZWUgbW9uZXkgaW4gSVB2NiBzbyB3aHkgd291bGQgdGhl eSBjYXJlPw0KPiANCj4+IFRoaXMgaXMgYSBib290c3RyYXBwaW5nIGFuZCB0aGUgb25seSB3YXkg dG8gc29sdmUgaXQgaXMgYnkgZWFzaW5nIHRoZSBJUHY2IHRyYW5zaXRpb24uDQo+PiBPbmUgZWZm aWNpZW50IG1lYW4gaXMgYW4gYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIHRoYXQgZmluZHMgdGhl IFRFUCBieSBpdHNlbGYgYW5kIHVzZXJzIGRvbid0IGhhdmUgdG8gYmUgd29ycmllZCBhYm91dCBp dC4NCj4gDQo+IEV2ZXIgY29uc2lkZXJlZCBUZXJlZG8gPw0KPiANCj4+IExldCdzIHRoaW5rIHRo YXQgdGhlcmUgY291bGQgYmUgYSBsb3Qgb2YgSVB2NiBkZXZpY2VzIGxpa2UgY2FtZXJhcywgaG9t ZSBhdXRvbWF0aW9uIGRldmljZXMsIGNhcnMsIGV0YyB0aGF0DQo+PiBjb3VsZCB0YWtlIGFkdmFu dGFnZSBvZiBhbiBhdXRvbWF0aWMgZGlzY292ZXJ5IG1ldGhvZCB0byBmaW5kIElQdjYgY29ubmVj dGl2aXR5IHdpdGhvdXQgaHVtYW4gaW50ZXJ2ZW50aW9uLg0KPiANCj4gTm93IGlmIEkgd291bGQg bGl2ZSBpbiBUb2tpbyBJIGNvdWxkIGxpdmUgd2l0aCB0aGlzIGFzc3VtcHRpb24sIGJ1dA0KPiB1 bmZvcnR1bmF0ZWx5LCB1bmxlc3MgSSBnbyB0byBBa2liYXJhIG15c2VsZiBvciBpbXBvcnQgdGhl IHN0dWZmIEkgd2lsbA0KPiBub3QgYmUgYWJsZSB0byBidXkgdGhlc2UgY29vbCB0b3lzICh5ZXQp Lg0KPiANCj4gQWxzbywgdGhlIHJvdXRlciBpbiB0aGUgaG91c2Ugc2hvdWxkIHByb3ZpZGUgdGhp cywgbm90IHRoZSBjYW1lcmEsIHRoYXQNCj4gc2hvdWxkIHNpbXBseSBSQS4gTmV4dCB0byB0aGF0 IGRvZXMgdGhlIHdvcmQgJ3NlY3VyaXR5JyBzYXkgYW55dGhpbmc/DQoNClRoZSBwb2ludCBpcyB0 aGF0ICJ0b2RheSIgd2UgYXJlIHdvcmtpbmcgb24gdGhlIG5ldHdvcmtzIGZvciAidG9tb3Jyb3ci IGFuZCBpbiB0aGUgbmVhciBmdXR1cmUsIEkgdGhpbmsgd2UgYWxsIGFyZSBhZ3JlZSB0aGF0IG1h bnkgaG9tZSBkZXZpY2VzIHdpbGwgc3VwcG9ydCBJUHY2LiBTdWNoIGRldmljZXMgY291bGQgaW1w bGVtZW50IG1ldGhvZHMgdG8gd29yayB3aXRoIElQdjYgZXZlbiBhbHRob3VnaCBvbmx5IElQdjQg KHNvIG5vdCBSQSBhdmFpbGFibGUpIGlzIGF2YWlsYWJsZSBvbiB0aGUgaG9tZSBuZXR3b3JrIGR1 cmluZyB0aGUgZWFybHkgZGVwbG95bWVudHMuIEluIHRoaXMgc2NlbmFyaW8gYW4gYXV0b21hdGlj IGRpc2NvdmVyeSBtZXRob2QgaXMgcmVxdWlyZWQuDQoNCg0KPiANCj4+IFNvLCBJTUhPIHRoZSBh bnN3ZXIgaXMgdGhhdCB3ZSBjYW4ndCBsaXZlIHdpdGggbWV0aG9kcyB0aGF0IHJlcXVpcmUgdXNl cnMgdG8gZW50ZXIgYW55IFVSTCBvciBkYXRhLg0KPiANCj4gSSBrbm93IG9mIGFsbW9zdCAzNTAw IGhhcHB5IHVzZXJzIHdobyBsaXZlZCB3aXRoIHRoaXMgcGVyZmVjdGx5IGZpbmUgYW5kDQo+IHRo ZXJlIGFyZSBhIG51bWJlciBvZiBvdGhlciBvcmdhbml6YXRpb25zIHdobyBjbGFpbSB0byBoYXZl IHdheSBtb3JlDQo+IHVzZXJzLg0KPiANCg0KSSBndWVzcyB3ZSBhcmUgdGhpbmtpbmcgb2YgZGlm ZmVyZW50IHR5cGUgb2YgdXNlcnMuIEkgc3VyZSB0aGF0IGV4cGVydCB1c2VycyAoYXQgbGVhc3Qg d2l0aCBzb21lIHRlY2huaWNhbCBrbm93bGVkZ2UpIGFyZSBoYXBweSB3aXRoIHRoYXQgc2l0dWF0 aW9uLCBidXQgSSdtIHRoaW5raW5nIG9mIHRob3VzYW5kcyBvZiB1c2VycyB0aGF0IGFyZW4ndCBU SSBleHBlcnRzLiBNeSBmYXRoZXIgbWlnaHQgYmUgYSBnb29kIGV4YW1wbGU6IGhlIGxpa2VzIGp1 c3QgcGx1Zy1hbmQtcGxheSBkZXZpY2VzIGJlY2F1c2UgaGUgaGFzIG5vIHRlY2huaWNhbCBrbm93 bGVkZ2UgYXQgYWxsLCBzbyBoZSB3b3VsZCBsaWtlIGp1c3QgcGx1ZyBpdHMgSVB2NiBjYW1lcmEg KHdpdGggdHJhbnNpdGlvbiBtZWNoYW5pc21zIGltcGxlbWVudGVkKSBvbiB0aGUgaG9tZSBuZXR3 b3JrIChJUHY0KSBhbmQgc2VlIGl0cyBob3VzZSB3aGlsZSB0cmF2ZWxpbmcgYXJvdW5kIHRoZSB3 b3JsZC4gSGUgd2FudHMgdGhhdCB0aGUgY2FtZXJhIGl0c2VsZiBpcyBpbiBjaGFyZ2Ugb2YgYWxs IHRoZSByZXF1aXJlZCBjb25maWd1cmF0aW9uIChURVAgZGlzY292ZXJ5IGluY2x1ZGVkKSB0byB3 b3JrLg0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KTWFkcmlkIDIw MDMgR2xvYmFsIElQdjYgU3VtbWl0DQpQcmVzZW50YXRpb25zIGFuZCB2aWRlb3Mgb24gbGluZSBh dDoNCmh0dHA6Ly93d3cuaXB2Ni1lcy5jb20NCg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29u dGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFs LiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9u IG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0 dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KDQoNCi== --===============1096941912== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1096941912==-- From v6tc-bounces@ietf.org Tue Jan 18 04:25:10 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 EAA04206; Tue, 18 Jan 2005 04:25:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqpr6-0002NN-K5; Tue, 18 Jan 2005 04:40:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqpaf-00020j-C6; Tue, 18 Jan 2005 04:23:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqpTo-00014u-CA for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 04:16:59 -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 EAA03643 for ; Tue, 18 Jan 2005 04:16:50 -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 1Cqpj2-0002Aw-EB for v6tc@ietf.org; Tue, 18 Jan 2005 04:32:37 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000713512.msg for ; Tue, 18 Jan 2005 10:17:10 +0100 Message-ID: <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? Date: Tue, 18 Jan 2005 10:17:03 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Tue, 18 Jan 2005 10:17:11 +0100 X-MDAV-Processed: consulintel.es, Tue, 18 Jan 2005 10:17:12 +0100 X-Spam-Score: 2.2 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1979572034==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --===============1979572034== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 PiBPbiBGcmksIDIwMDUtMDEtMTQgYXQgMTk6NDkgKzAxMDAsIE1pZ3VlbCBBbmdlbCBEaWF6IHdy b3RlOg0KPj4gRXZlbiBpbiB5b3VyIGNhc2UgdGhlIGRpc2NvdmVyeSBtZXRob2Qgd2UgYXJlIGdv aW5nIHRvIHByb3Bvc2Ugd2lsbCB3b3JrLg0KPiANCj4gQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbiBt ZSBob3cgaXQgd291bGQgd29yaz8gQmVjYXVzZSBJIHJlYWxseSBjYW4ndCBzZWUNCj4gaG93IGl0 IGNhbiBiZWNhdXNlIHRoZXJlIGlzIGFic29sdXRlbHkgbm8gaW5mb3JtYXRpb24gdGhhdCBtYWtl cyB5b3UNCj4gYWJsZSB0byBmaWd1cmUgb3V0IHRoZSBuYW1lc2VydmVycyBvZiB0aGUgSVNQIHdp dGggdGhlIGluZm9ybWF0aW9uIEkNCj4gZ2F2ZSBiZWxvdyA7KQ0KPiANCg0KV2UgYXJlIGdvaW5n IHRvIGdpdmUgYWxsIHRoZSBkZXRhaWxzIGluIHRoZSBuZXcgZHJhZnQgdmVyc2lvbiwgYnV0IG1l YW53aGlsZSBqdXN0IHRoaW5rIHRoYXQgaXQgaXNuJ3QgZGlmZmljdWx0IHRvIGV4dHJhY3QgdGhl IElTUCBkb21haW4gbmFtZSAoYXQgbGVhc3Qgb25lIHZhbGlkKSB0byBtYWtlIHRoZSBETlMgcXVl cmllcy4gVGhlIG9ubHkgcmVxdWlyZW1lbnQgaXMgdGhhdCB0aGUgSVNQIGRlcGxveXMgdGhlIFRF UCBvbiBpdHMgb3duIG5ldHdvcmsgYW5kIGl0IGNvbmZpZ3VyZXMgcHJvcGVybHkgaXRzIGF1dG9y aXRhdGl2ZSBETlMgc2VydmVyLg0KDQpJbiB5b3VyIGNhc2UsIGlmIHdlIGFzc3VtZSB0aGF0IHlv dXIgSVNQIGhhcyBkaWZmZXJlbnQgVEVQcywgdGhlIFNSViBETlMgcXVlcmllcyB0byBkaXNjb3Zl ciB0aGVtIGNvdWxkIGJlOg0KDQpfdGVyZWRvLl91ZHAuY2lzdHJvbi5ubA0KXzZ0bzQuX2lwdjYu Y2lzdHJvbi5ubA0KZXRjLg0KDQpIb3cgdG8gZmluZCBvdXQgeW91ciBJU1AgZG9tYWluIG5hbWU/ IEl0IGlzIHNpbXBsZSwganVzdCB0eXBlOg0KDQpkaWcgc29hIC14IDE5NS42NC45Mi4xMzYgK25v YWxsICthdXRob3JpdHkNCg0KYW5kIGV4dHJhY3QgdGhlIGRvbWFpbiBmcm9tIHRoZSBhdXRob3Jp dGF0aXZlIEROUyBzZXJ2ZXIgKG5zLmNpc3Ryb24ubmwpICA6LSkNCg0KUmVtZW1iZXIgdGhhdCBp dCBpcyBuZWNlc3NhcnkgdGhhdCBJU1AgaXMgaW4gY2hhcmdlIG9mIHNldHVwIHRoZSBETlMgc2Vy dmVycyB0aGF0IG1hbmFnZSB0aGUgY2lzdHJvbi5ubCBkb21haW4gd2l0aCB0aGUgcHJvcGVyIGVu dHJpZXMgZm9yIF90ZXJlZG8udWRwLCBfNnRvNC5faXB2NiwgZXRjIFNSViBSUi4gDQoNCj4+ICBC YXNpY2FsbHkgd2Ugb25seSBzdXBwb3NlIG9uZSB0aGluZzogdGhlIGxvY2FsIElTUCBpcyB0aGUg ZW50aXR5IHRoYXQgZGVwbG95cyB0aGUgVEVQIHRoYXQgdGhlIHVzZXIgKHJhdGhlciB0aGUgT1Mp IGlzIGxvb2tpbmcgZm9yLg0KPj4NCj4+IFdpdGggdGhhdCBwcmVtaXNlIHdlIHByb3Bvc2UgdG8g dXNlIFNSViBSUiBiZWNhdXNlIHRoZSBhZHZhbnRhZ2VzIHNob3duDQo+PiBpbiBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wYWxldC12Nm9wcy1zb2x1dGlvbi10dW4t YXV0by1kaXNjLTAxLnR4dC4NCj4+IEhvd2V2ZXIgdG8gdXNlIGVmZmVjdGl2ZWx5IHRoYXQgYXBw cm9hY2ggaXQgaXMgbmVjZXNzYXJ5IHRvIGtub3cgdGhlIElTUCBkb21haW4NCj4+IG5hbWUgd2hp Y2ggaXMgbm90IHRyaXZpYWwgYmVjYXVzZSBpdCBpcyBub3QgdXN1YWxseSBwcm9wYWdhdGVkLg0K PiANCj4gVGhhdCB3YXMgdGhlIHF1ZXN0aW9uIEkgYXNrZWQgeW91LCBob3cgYXJlIHlvdSBnb2lu ZyB0byBmaWd1cmUgb3V0IGluDQo+IHdoaWNoIGRvbWFpbiB5b3UgbmVlZCB0byBsb29rIGZvciB0 aG9zZSByZWNvcmRzPw0KPiANCj4+IFRoZSBuZXcgZHJhZnQgdmVyc2lvbiBvZiBkcmFmdC1wYWxl dC12Nm9wcy1zb2x1dGlvbi10dW4tYXV0by1kaXNjIHdpbGwgcHJvcG9zZSBhDQo+PiBtZXRob2Qg dG8gZGlzY292ZXIgbm90IG9ubHkgdGhlIElTUCBkb21haW4gbmFtZSBidXQgYWxzbyB0aGUgRE5T IHNlcnZlciB0byBtYWtlIHRoZSBTUlYgcXVlcmllcy4NCj4gDQo+IFlvdSB0aGluayB0aGF0IG15 IEROUyBzZXJ2ZXIgaGFzIGEgcmVsYXRpb24gdG8gdGhlIEROUyBzZXJ2ZXIgb2YgbXkNCj4gdXBz dHJlYW0gSVNQPyBObyB3YXksIHRoZXkgZG9uJ3QgZG8gSVB2NiBub3IgRE5TU0VDIGFuZCBtaW5l IGRvZXMuDQo+IA0KPj4gVG8gZG8gdGhhdCB0aGUgb25seSB0aGluZyBpcyB0byBmaW5kIG91dCB0 aGUgYXV0aG9yaXRhdGl2ZSBETlMgc2VydmVyIG9uIHRoZSBJU1AgZG9tYWluIGFuZCB0aGVuIHlv dSdsbCBoYXZlIGFsbC4NCj4gDQo+IEFuZCBfaG93XyBhcmUgeW91IGdvaW5nIHRvIGRvIGl0PyB0 aGF0IHlvdSB3YW50IHRvIGRvIGl0IGlzIGNsZWFyLCBidXQNCj4gaG93PyA6KQ0KPiANCj4+IElu IHRoaXMgd2F5IHRoZSBxdWVyaWVzIHdpbGwgYmUgc2VudCBub3QgdG8geW91ciBsb2NhbCBETlMg c2VydmVyIGJ1dCB0aGUNCj4+IGF1dGhvcml0YXRpdmUgRE5TIHNlcnZlciBvZiB5b3VyIElTUCB3 aG8gaXMgaW4gY2hhcmdlIG9mIHRoZSBURVAgZGVwbG95bWVudCwgc28gaXQgd2lsbCB3b3JrIGV2 ZW4gaW4geW91ciBuZXR3b3JrLg0KPiANCj4gUGxlYXNlIGxvb2sgYWdhaW4gYXQgdGhlIHNpdHVh dGlvbiB0aGF0IEkgZGVwaWN0ZWQgYXMgdGhlcmUgcmVhbGx5IGlzIG5vDQo+IHdheSB0byBmaW5k IG91dCB0aGUgZG9tYWluIG5hbWUgb2YgbXkgdXBzdHJlYW0gSVNQIDopDQo+IEl0IGlzIG5vdCBl dmVuIHBvc3NpYmxlIHRvIGRvIGl0IG1hbnVhbGx5IHVubGVzcyB5b3Ugc2ltcGx5IGFzc3VtZQ0K PiBjZXJ0YWluIHRoaW5ncywgYnV0IHRoYXQgaXMgZG9uZSBieSB0aGUgaHVtYW4gYnJhaW4sIG5v dCBieSB0aGUNCj4gY29tcHV0ZXIuDQo+IA0KPiBHcmVldHMsDQo+IEplcm9lbg0KPiANCj4gDQo+ IA0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IE1hZHJpZCAyMDAzIEds b2JhbCBJUHY2IFN1bW1pdA0KPiBQcmVzZW50YXRpb25zIGFuZCB2aWRlb3Mgb24gbGluZSBhdDoN Cj4gaHR0cDovL3d3dy5pcHY2LWVzLmNvbQ0KPiANCj4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2Ug Y29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50 aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0 aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgaW5jbHVkaW5n IGF0dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KPiANCj4gDQo+DQoNCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCk1hZHJpZCAyMDAzIEdsb2JhbCBJUHY2IFN1bW1pdA0K UHJlc2VudGF0aW9ucyBhbmQgdmlkZW9zIG9uIGxpbmUgYXQ6DQpodHRwOi8vd3d3LmlwdjYtZXMu Y29tDQoNClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNo IG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGlu dGVuZGVkIHRvIGJlIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3Zl LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55 IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRz IG9mIHRoaXMgaW5mb3JtYXRpb24sIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgcHJvaGli aXRlZC4NCg0KDQp= --===============1979572034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1979572034==-- From v6tc-bounces@ietf.org Tue Jan 18 04:45:44 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 EAA06526; Tue, 18 Jan 2005 04:45:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqqAz-000332-KH; Tue, 18 Jan 2005 05:01:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqpuV-0005NR-R2; Tue, 18 Jan 2005 04:44:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqpec-0002lD-Qe for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 04:28:02 -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 EAA04633 for ; Tue, 18 Jan 2005 04:28:00 -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 1Cqpto-0002S6-Vf for v6tc@ietf.org; Tue, 18 Jan 2005 04:43:47 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000713559.msg for ; Tue, 18 Jan 2005 10:28:17 +0100 Message-ID: <013d01c4fd40$0908ea50$1100a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <00d801c4fd30$8f7c92e0$1100a8c0@consulintel.es> Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automaticormanual? Date: Tue, 18 Jan 2005 10:28:12 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-1.2 required=5.0 tests=BAYES_00,DOMAIN_BODY, MIME_BASE64_LATIN,MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Tue, 18 Jan 2005 10:28:20 +0100 X-MDAV-Processed: consulintel.es, Tue, 18 Jan 2005 10:28:20 +0100 X-Spam-Score: 4.0 (++++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1837646250==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 4.0 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 --===============1837646250== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpbLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uXQ0KDQo+IA0KPiAr LS0tLS0tLSsgICAgICAgICstLS0tLS0tLS0rDQo+IHwgIElTUCAgfC0tLS0tLS0tfCBOQVQgQm94 IHwtLS0tLS0teyBob3N0cyB9DQo+ICstLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tLSsNCj4gDQo+ IElmIEkgd291bGQgY29uZmlndXJlIG15IGhvbWUgbmV0d29yayBsaWtlIHRoaXMsIHRoZW4gc3Rp bGwgdGhlcmUgaXMgbm8NCj4gd2F5IHRvIGZpZ3VyZSBvdXQgdGhhdCBteSBJU1AgYWN0dWFsbHkg dXNlcyBjaXN0cm9uLm5sIGFuZCBub3QgLm5ldCBhcw0KPiBpbiB0aGUgdHJhY2Vyb3V0ZXMgb3Ig YXMgdGhlIHJldmVyc2Ugb2Ygc2VydmljZXMgZXRjLiBTT0EncyBhcmUgcG9pbnRpbmcNCj4gdG8g Lm5ldCwgcmV2ZXJzZXMgYXJlIC5uZXQsIGJ1dCB0aGUgc2VydmljZXMgcmVzaWRlIGluIHRoZSAu bmwgZG9tYWluLg0KPiBBbmQgSSBhbSBub3QgZXZlbiBtZW50aW9uaW5nIHRoZSB2YXJpb3VzIFZp cnR1YWwgSVNQJ3Mgd2hvIGFjdHVhbGx5DQo+IG91dHNvdXJjZSBldmVyeXRoaW5nLiBUaGF0IGlz IHdoeSBJIHdvbmRlciBob3cgTWlndWVsIGV0IGFsIGFyZSBnb2luZyB0bw0KPiB1c2UgdGhlc2Ug bmljZSBETlMgU1JWIHJlY29yZHMgOykNCj4gDQoNCg0KV2l0aCByZXZlcnNlIEROUyB3ZSBjYW4g Z2V0IHRoZSBkb21haW4gbmFtZSwgYXQgbGVhc3Qgb25lIHZhbGlkIHRvIG1ha2UgdGhlIEROUyBx dWVyeS4NCg0KZGlnIHNvYSAteCAxOTUuNjQuOTIuMTM2ICtub2FsbCArYXV0aG9yaXR5DQoNCmFu ZCBleHRyYWN0IHRoZSBkb21haW4gZnJvbSB0aGUgYXV0aG9yaXRhdGl2ZSBETlMgc2VydmVyLg0K DQpSZW1lbWJlciB0aGF0IGl0IGlzIG5lY2Vzc2FyeSB0aGF0IHRoZSBJU1AgaXMgaW4gY2hhcmdl IG9mIHNldHVwIHRoZSBETlMgc2VydmVycyB0aGF0IG1hbmFnZSB0aGUgZG9tYWluIGV4dHJhY3Rl ZCB3aXRoIHRoaXMgbWV0aG9kIChjaXN0cm9uLm5sKSB3aXRoIHRoZSBwcm9wZXIgZW50cmllcyBm b3IgX3RlcmVkby51ZHAsIF82dG80Ll9pcHY2LCBldGMgU1JWIFJSLCBidXQgdGhpcyBpcyB3aGF0 IHdlIHByb3Bvc2U6IGEgbWV0aG9kIHNvIHRoYXQgSVNQcyBhbm5vdW5jZSBURVBzIG9uIHRoZWly IG5ldHdvcmtzIGFuZCBhIG1ldGhvZCBzbyB0aGF0IGFwcGxpY2F0aW9ucyBjYW4gZGlzY292ZXIg c3VjaCBURVBzIG9uIHRoZSBJU1BzJyBuZXR3b3JrcyBieSB1c2luZyBETlMuDQoNCj4gQWxzbyBh c3N1bWluZyB0aGF0IHlvdSBjYW4gZmlndXJlIGl0IG91dCwgaWYgdGhlcmUgaXMgbm8gRE5TIFNS ViByZWNvcmQNCj4gaW4gdGhlIHVwc3RyZWFtLCB3aGF0IHRoZW4/IE5vIHNlcnZpY2UgZm9yIHRo YXQgdXNlcj8gVGhlcmUgaXMgbm90aGluZw0KPiBhdXRvbWF0aWMgaW4gdGhpcyBzZXR1cCB0aGVu IGFzIHRoZXJlIGFyZSBhbG1vc3Qgbm8gSVNQJ3MgZG9pbmcgSVB2NiBpbg0KPiB0aGUgZmlyc3Qg cGxhY2UsIHRoYXQgaXMgd2h5IHRoZXJlIGlzIDZ0bzQgYW5kIFRlcmVkbywgd2hvIGZpdCB0aGUg YmlsbA0KPiBwZXJmZWN0bHkgYXMgSSBhbHJlYWR5IG1lbnRpb25lZC4NCg0KSWYgdGhlIElTUCBk ZXBsb3lzIG9uZSBvciBzZXZlcmFsIFRFUHMgb24gaXRzIG5ldHdvcmsgaXQgd291bGQgaGF2ZSB0 byBzZXR1cCBpdHMgYXV0aG9yaXRhdGl2ZSBETlMgc2VydmVycyB0byBzdXBwb3J0IHRoZSBkaXNj b3ZlcnkgbWV0aG9kLCBvbiB0aGUgY29udHJhcnkgdXNlciAocmF0aGVyIGhpcyBPUywgYXBwbGlj YXRpb24sIGV0YykgY291bGRuJ3QgZmluZCB0aGUgVEVQLg0KDQpUaGUgZGlzY292ZXJ5IG1ldGhv ZCBpcyBwb2ludGVkIHRvIGJvdGggdGhlIElTUHMgYW5kIHRoZSBhcHBsaWNhdGlvbiBkZXZlbG9w ZXJzLg0KDQpUaGVyZSBpcyBubyBtdWNoIG5ldyBpbiB0aGlzIGFwcHJvYWNoLiBUaGluayBpbiBJ U0FUQVAgZGlzY292ZXJ5IG1ldGhvZCwgaXMgc2ltaWxhciBhbmQgaXQgcmVxdWlyZXMgdGhhdCB0 aGUgRE5TIHNlcnZlciBpcyBjb2ZpZ3VyZWQgcHJvcGVybHkgYW5kIHRoZSBpbXBsZW1lbnRhdGlv biBtYWtlcyB0aGUgRE5TIHF1ZXJ5IHRvIHRoZSBzZXJ2ZXIuDQoNClJlZ2FyZHMNCk1pZ3VlbA0K DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpNYWRyaWQgMjAwMyBHbG9iYWwg SVB2NiBTdW1taXQNClByZXNlbnRhdGlvbnMgYW5kIHZpZGVvcyBvbiBsaW5lIGF0Og0KaHR0cDov L3d3dy5pcHY2LWVzLmNvbQ0KDQpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZv cm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZv cm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChz KSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBh d2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9m IHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgYXR0YWNoZWQgZmls ZXMsIGlzIHByb2hpYml0ZWQuDQoNCg0K --===============1837646250== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1837646250==-- From v6tc-bounces@ietf.org Tue Jan 18 04:53:19 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 EAA06961; Tue, 18 Jan 2005 04:53:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqqIN-0003Cq-1d; Tue, 18 Jan 2005 05:09:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqq14-0006k2-1O; Tue, 18 Jan 2005 04:51:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqq0Y-0006Ye-VI for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 04:50:43 -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 EAA06823 for ; Tue, 18 Jan 2005 04:50:39 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqqFl-00039T-Cr for v6tc@ietf.org; Tue, 18 Jan 2005 05:06:26 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0I9odVu003476 for ; Tue, 18 Jan 2005 02:50:39 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IAI0084GBCESD@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Tue, 18 Jan 2005 02:50:39 -0700 (MST) Received: from [192.168.1.2] ([83.193.203.50]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAI005OQBCBUK@mail.sun.net> for v6tc@ietf.org; Tue, 18 Jan 2005 02:50:38 -0700 (MST) Date: Tue, 18 Jan 2005 01:50:35 -0800 From: Alain Durand Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-reply-to: <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> To: miguelangel.diaz@consulintel.es Message-id: <66E788C6-6936-11D9-91AD-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7BIT On Jan 18, 2005, at 1:17 AM, Miguel Angel Diaz wrote: > How to find out your ISP domain name? It is simple, just type: > > dig soa -x 195.64.92.136 +noall +authority > > and extract the domain from the authoritative DNS server > (ns.cistron.nl) :-) Can you tell us how this will work for host behind a NAT which address is 192.168.1.2? - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Jan 18 05:44:07 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 FAA10902; Tue, 18 Jan 2005 05:44:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqr5W-0004Gp-Ud; Tue, 18 Jan 2005 05:59:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqqnT-0006hS-AC; Tue, 18 Jan 2005 05:41:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqqlG-0006C4-MG for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 05:38:59 -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 FAA10550 for ; Tue, 18 Jan 2005 05:38:55 -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 1Cqr0U-00048i-Hj for v6tc@ietf.org; Tue, 18 Jan 2005 05:54:44 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000713872.msg for ; Tue, 18 Jan 2005 11:39:12 +0100 Message-ID: <002401c4fd49$f062e730$a100000a@consulintel.es> From: "Miguel Angel Diaz" To: References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? Date: Tue, 18 Jan 2005 11:39:07 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 10.0.0.161 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Tue, 18 Jan 2005 11:39:14 +0100 X-MDAV-Processed: consulintel.es, Tue, 18 Jan 2005 11:39:14 +0100 X-Spam-Score: 2.2 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1463389914==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 --===============1463389914== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQoNCj4gT24gSmFuIDE4LCAyMDA1LCBhdCAxOjE3IEFNLCBNaWd1ZWwgQW5nZWwgRGlheiB3cm90 ZToNCj4gDQo+PiBIb3cgdG8gZmluZCBvdXQgeW91ciBJU1AgZG9tYWluIG5hbWU/IEl0IGlzIHNp bXBsZSwganVzdCB0eXBlOg0KPj4NCj4+IGRpZyBzb2EgLXggMTk1LjY0LjkyLjEzNiArbm9hbGwg K2F1dGhvcml0eQ0KPj4NCj4+IGFuZCBleHRyYWN0IHRoZSBkb21haW4gZnJvbSB0aGUgYXV0aG9y aXRhdGl2ZSBETlMgc2VydmVyIA0KPj4gKG5zLmNpc3Ryb24ubmwpICA6LSkNCj4gDQo+IENhbiB5 b3UgdGVsbCB1cyBob3cgdGhpcyB3aWxsIHdvcmsgZm9yIGhvc3QgYmVoaW5kIGEgTkFUIHdoaWNo IGFkZHJlc3MgDQo+IGlzIDE5Mi4xNjguMS4yPw0KPiANCg0Kb2YgY291cnNlLCB5b3UgZmlyc3Qg aGFzIHRvIGtub3cgeW91ciBwdWJsaWMgSVB2NCBhZGRyZXNzIDstKSBJdCBkb2Vzbid0IG1hdHRl ciBpZiB5b3UgaGF2ZSBvbmUgb3IgbW9yZSBOQVQgbGV2ZWxzLCB0aGUgb25seSB0aGluZyBpcyB0 byBmaW5kIG91dCB5b3VyIGZpbmFsIHB1YmxpYyBhZGRyZXNzLiBUaGVyZSBhcmUgc2V2ZXJhbCB3 YXlzIHRvIGRvIGl0IGFuZCBvbmUgb2YgdGhlIG1vc3QgdXNlZCBpcyB0aGUgU1RVTiBwcm90b2Nv bCwgUkZDIDM0ODkuDQoNCk90aGVyIGFwcHJvYWNoIG1pZ2h0IGJlIHRoZSBvbmUgeW91IHBvaW50 ZWQgdGltZSBhZ286IElTUCBoYXMgdG8gcHVibGljIHJldmVyc2UgRE5TIGZvciB0aGUgcHJpdmF0 ZSBhZGRyZXNzZXMsIGJ1dCBJIGd1ZXNzIGl0IHdvbid0IHdvcmsgd2VsbCBpbiBuZXR3b3JrcyB3 aXRoIGxvY2FsIEROUyBzZXJ2ZXIgbGlrZSB0aGUgSmVyb2VuJ3MgY2FzZS4gVGhlIG9ubHkgZWZm ZWN0aXZlIHNvbHV0aW9uIHRoYXQgZml0cyB0aGUgbW9zdCBvZiB0aGUgc2NlbmFyaW9zIGlzIHRv IHRha2UgdGhlIHB1YmxpYyBhZGRyZXNzLg0KDQpSZWdhcmRzDQpNaWd1ZWwNCg0KDQoNCioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCk1hZHJpZCAyMDAzIEdsb2JhbCBJUHY2IFN1 bW1pdA0KUHJlc2VudGF0aW9ucyBhbmQgdmlkZW9zIG9uIGxpbmUgYXQ6DQpodHRwOi8vd3d3Lmlw djYtZXMuY29tDQoNClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9u IHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9u IGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVk IGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRo YXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNv bnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMg cHJvaGliaXRlZC4NCg0KDQo= --===============1463389914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1463389914==-- From v6tc-bounces@ietf.org Tue Jan 18 06:25:07 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 GAA13510; Tue, 18 Jan 2005 06:25:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqrjE-00057D-Al; Tue, 18 Jan 2005 06:40:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqrPa-0005lB-M4; Tue, 18 Jan 2005 06:20:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqrKS-0003YU-Mt for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 06:15:20 -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 GAA12685 for ; Tue, 18 Jan 2005 06:15:13 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqrZd-0004sw-Oy for v6tc@ietf.org; Tue, 18 Jan 2005 06:31:02 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id D229EC2247; Tue, 18 Jan 2005 12:15:03 +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 17994-06; Tue, 18 Jan 2005 12:15:01 +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 BB12DC222A; Tue, 18 Jan 2005 12:15:00 +0100 (CET) Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automaticormanual? From: Jeroen Massar To: miguelangel.diaz@consulintel.es In-Reply-To: <013701c4fd3e$1fae41d0$1100a8c0@consulintel.es> References: <00b501c4fd30$5e598880$1100a8c0@consulintel.es> <013701c4fd3e$1fae41d0$1100a8c0@consulintel.es> Organization: Unfix Date: Tue, 18 Jan 2005 12:14:58 +0100 Message-Id: <1106046898.14179.58.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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="===============0489154793==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 --===============0489154793== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qryn0lt3Uff3LEZNv8K+" --=-qryn0lt3Uff3LEZNv8K+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-01-18 at 10:14 +0100, Miguel Angel Diaz wrote: > >> IMHO if we wish a broad and fast deployment of IPv6 the answer is that= an > >> automatic discovery mechanism is definitively required.=20 > >=20 > > There is already Teredo and 6to4, what more is needed? > > Teredo on it's own already solves most if not all problems. > > The only issue with Teredo _could_ be that one does not get the most > > local relay. But I think M$ can be easily pursuade to add a update to > > windowsupdate that will reconfigure the default teredoserver to an > > anycast address. > >=20 >=20 > Thousands (even millions) of users over the world can't use the > current servers that M$ has pre-configured for 6to4 and Teredo > implementations on the OS, which are 6to4.ipv6.microsoft.com and > teredo.ipv6.microsoft.com. Did you notice the following: 6to4.ipv6.microsoft.com has address 192.88.99.1 6to4.ipv6.microsoft.com has address 131.107.33.60 6to4.ipv6.microsoft.com has IPv6 address 2002:836b:213c:1:e0:8f08:f020:8 If it isn't known, that first one is the 6to4 anycast address, which is also the first thing that XP tries, after that it might fall back to the microsoft provided relay. They (6to4 and Teredo) work perfectly fine from the several places where I have tried them. The only thing was the latency and throughput, which is logical as the Teredo box is hosted in the US, which is not where I am, but fortunately it uses those nice bubbles to locate a more local server which then causes the traffic to be optimized a bit. Any real argument why these millions of users can't use Teredo according to you? > It is assumed that every ISP willing to offer IPv6 services to their > customers will deploy a TEP infrastructure on its own network, either Ter= edo, > 6to4, or whatever. The TEP discovery on the ISP network is the point. Of course they want that, just like this is expected from 6to4. There is a very simple solution if you want this: anycast prefix for Teredo. Does not require any weird mechanisms, no weird stuff in DNS nothing. But to call this 'discovery', why bother with that ? > > Now if I would live in Tokio I could live with this assumption, but > > unfortunately, unless I go to Akibara myself or import the stuff I will > > not be able to buy these cool toys (yet). > >=20 > > Also, the router in the house should provide this, not the camera, that > > should simply RA. Next to that does the word 'security' say anything? >=20 > The point is that "today" we are working on the networks for "tomorrow" a= nd in the near future, In the future there will be native IPv6 to the home, today there is need for some tunneling. But in ~5 years it will be mostly native. > I think we all are agree that many home devices will support IPv6. Such d= evices could implement > methods to work with IPv6 even although only IPv4 (so not RA available) i= s available on the > home network during the early deployments. In this scenario an automatic = discovery method is required. Thus you want every small device to implement tunneling and thus create how many security holes in how many places? You'd better start writing the security section of the draft like 3 years ago if you want to cover all the possible problems you will be creating here. Remember the following very simple thing: There will most likely be at least one computer (XP, BSD, Linux, other 'router') that supports IPv6 in such networks. These are more than capable handling this and are also way easier to make centrally secure/firewalled. If you really want that you can plug in a IPv6 camera, which will then also do IPv4 for the tunneling even though it is a IPv6-only cam, then also remember the security problems. > >> So, IMHO the answer is that we can't live with methods that require us= ers to enter any URL or data. > >=20 > > I know of almost 3500 happy users who lived with this perfectly fine an= d > > there are a number of other organizations who claim to have way more > > users. > >=20 >=20 > I guess we are thinking of different type of users. I sure that expert us= ers (at least with some > technical knowledge) are happy with that situation, but I'm thinking of t= housands of users that > aren't TI experts. I am quite sure that most of those happy users are completely clueless in what they are doing and just followed that nice article they found on the internet or in that Computing Magazine For Dumbo's and are happily downloading the newest movies/music and other warez they can find. This is where the internet is used for and this already works. > My father might be a good example: he likes just plug-and-play devices be= cause > he has no technical knowledge at all, so he would like just plug its IPv6= camera (with transition > mechanisms implemented) on the home network (IPv4) and see its house whil= e traveling around the world. > He wants that the camera itself is in charge of all the required configur= ation (TEP discovery included) to work. He is quite likely to not even want to know how it works, he wants it to work, but without having his neighbor and that Brazilian kid and the burglar watching his house for him too... or are you going to explain him what security is? ;) Next to that, implementors of small devices don't like to implement multiple IP stacks and replicate work which should be done by other equipment. Note that all the current IPv6 toys are IPv6-only and do not have anything to do with IPv4. There is a reason for this: they don't want to be bothered with IPv4 in the first place as those devices could not communicate globally in the first place and they where sick of building NAT workarounds. Maybe a picture helps to illustrate this all: http://www.ibiblio.org/Dave/Dr-Fun/df200306/df20030604.jpg Greets, Jeroen --=-qryn0lt3Uff3LEZNv8K+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB7O+yKaooUjM+fCMRAgR4AJ9KZ/iaNrlUdisgZrLNkPb2fJqnJgCeJotx TjZbOrRNOZYm2+UsfAIHRC8= =TZjZ -----END PGP SIGNATURE----- --=-qryn0lt3Uff3LEZNv8K+-- --===============0489154793== 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 --===============0489154793==-- From v6tc-bounces@ietf.org Tue Jan 18 06:25:26 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 GAA13551; Tue, 18 Jan 2005 06:25:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqrjX-00058Y-47; Tue, 18 Jan 2005 06:41:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqrPa-0005lG-RK; Tue, 18 Jan 2005 06:20:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqrNh-0004mS-MY for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 06:18: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 GAA12763 for ; Tue, 18 Jan 2005 06:18:38 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqrcw-0004vj-1u for v6tc@ietf.org; Tue, 18 Jan 2005 06:34:27 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0IBIcdt028124 for ; Tue, 18 Jan 2005 04:18:38 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IAI0061DFF2A0@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Tue, 18 Jan 2005 04:18:38 -0700 (MST) Received: from [192.168.1.2] ([83.193.203.50]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAI000XWFEY87@mail.sun.net> for v6tc@ietf.org; Tue, 18 Jan 2005 04:18:38 -0700 (MST) Date: Tue, 18 Jan 2005 03:18:33 -0800 From: Alain Durand Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-reply-to: <002401c4fd49$f062e730$a100000a@consulintel.es> To: miguelangel.diaz@consulintel.es Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7BIT On Jan 18, 2005, at 2:39 AM, Miguel Angel Diaz wrote: > > >> On Jan 18, 2005, at 1:17 AM, Miguel Angel Diaz wrote: >> >>> How to find out your ISP domain name? It is simple, just type: >>> >>> dig soa -x 195.64.92.136 +noall +authority >>> >>> and extract the domain from the authoritative DNS server >>> (ns.cistron.nl) :-) >> >> Can you tell us how this will work for host behind a NAT which address >> is 192.168.1.2? >> > > of course, you first has to know your public IPv4 address ;-) It > doesn't matter if you have one or more NAT levels, the only thing is > to find out your final public address. There are several ways to do it > and one of the most used is the STUN protocol, RFC 3489. I was expecting this answer. Can you now tell how to discover which stun server to use? - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Jan 18 06:27:16 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 GAA13682; Tue, 18 Jan 2005 06:27:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqrlI-0005AL-DS; Tue, 18 Jan 2005 06:43:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqrV1-0006ce-0T; Tue, 18 Jan 2005 06:26:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqrQv-0005w6-11 for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 06:22:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12923 for ; Tue, 18 Jan 2005 06:21:57 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqrg9-0004zO-1x for v6tc@ietf.org; Tue, 18 Jan 2005 06:37:46 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j0IBLki3001664 for ; Tue, 18 Jan 2005 11:21:46 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA05551 for ; Tue, 18 Jan 2005 11:21:54 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j0IBLsj07549 for v6tc@ietf.org; Tue, 18 Jan 2005 11:21:54 GMT Date: Tue, 18 Jan 2005 11:21:54 +0000 From: Tim Chown To: v6tc@ietf.org Subject: Re: Fw: [v6tc] Issue 2: service discovery: automatic or manual? Message-ID: <20050118112154.GL4476@login.ecs.soton.ac.uk> Mail-Followup-To: v6tc@ietf.org References: <01c701c4fa69$da1b0350$0a00a8c0@consulintel.es> <1105975480.8582.101.camel@firenze.zurich.ibm.com> <20050117161432.GP22108@login.ecs.soton.ac.uk> <1105983589.8582.172.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1105983589.8582.172.camel@firenze.zurich.ibm.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: 4b800b1eab964a31702fa68f1ff0e955 On Mon, Jan 17, 2005 at 06:39:49PM +0100, Jeroen Massar wrote: > > The doc mentions that there are 25+ NREN's in total, of which 18 where > connected to 6net. out of that 75% had a 6to4 relay, thus for the > complete European community (how many connections are that?) there where > 12 NREN's with 6to4 relays, which is thus only a low 50%. Not bad but I > wonder if 1Gbit/s is enough for such a large community, assuming that > each box only has a 100mbit card. Hmm, 12 of 18 is 75% not 50% :) The points herea re that 6to4 relays were three times as popular as brokers, but of course that's on the provider end, there may be far more users of brokers, using services like freenet6 (even with a huge RTT). But we just don't know. Regarding throughout, as you've said most usage is for chat-type apps, rather than streaming/mirroring/etc and the types of sites running that would probably have a manual tunnel or native link. Home users would be limited to 512K or similar anyway. > > One NREN has turned its broker off (UNINETT). > > NREN's are of course all non-commercial and politically are not to > deliver to endusers, and wasn't this what the automatic discovery was > intended for ? :) They are there to support their users, so yes they should offer 6to4 or brokers, but it's hard to control access to 6to4 outside your domain. I, personally, would rather use my university's broker than whichever "random" one appeared to me when in a hotspot or home network, at least while in the UK/Europe and knowing the latency is low. I guess our target "market" with v6tc is the Joe Broadband user though. > Next to that 6net is now fortunately getting turned off, only few > countries left, which saves a lot of problems in the IPv6 world ;) What do you mean "fortunately", I don't understand? > Btw, funny that none of the 6net participants ever had linerate (Gig and > up) native IPv6, one would have hoped that the various hardware vendors > would have done playtesting by now. I don't understand again. We had native 1Gig to our door. We were not alone in that. The lines used between 6NET PoPs were 155Mbit/s due to budget reasons, but the GEANT links that were established maybe 18 months ahead of schedule due to 6NET work of course are 10Gig+. Not that anyone is generating Gigs of v6 :) > 6to4 has one problem, which Teredo does not have: NAT's. Our users running 6to4 at home use proto41 forwarding to get around that, but Joe Broadband wouldn't. > Indeed. Thus a 'if configured don't touch' but otherwise try to do it, > is very useful. And we already have that in Windows XP for instance ;) > Thus why invent the wheel again? Or is this just another 'it has a MS > stamp and that ain't good enough for the world' kind of thing? I don't understand again where you're coming from here, sorry. -- Tim _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Jan 18 06:35: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 GAA14155; Tue, 18 Jan 2005 06:35:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqrsp-0005J2-C7; Tue, 18 Jan 2005 06:50:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqrdG-0007ZQ-Kt; Tue, 18 Jan 2005 06:34:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqrbc-0007SL-Ou for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 06:33:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13995 for ; Tue, 18 Jan 2005 06:33:01 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqrqq-0005Gk-77 for v6tc@ietf.org; Tue, 18 Jan 2005 06:48:50 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 175578B768; Tue, 18 Jan 2005 12:33:01 +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 20823-05; Tue, 18 Jan 2005 12:33:00 +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 7CE2D8B760; Tue, 18 Jan 2005 12:33:00 +0100 (CET) Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: Alain Durand In-Reply-To: References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> Organization: Unfix Date: Tue, 18 Jan 2005 12:32:58 +0100 Message-Id: <1106047978.14179.64.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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="===============1232533351==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --===============1232533351== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XCEWJesJvBp0IaddjMVN" --=-XCEWJesJvBp0IaddjMVN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-01-18 at 03:18 -0800, Alain Durand wrote: > On Jan 18, 2005, at 2:39 AM, Miguel Angel Diaz wrote: >=20 > > > > > >> On Jan 18, 2005, at 1:17 AM, Miguel Angel Diaz wrote: > >> > >>> How to find out your ISP domain name? It is simple, just type: > >>> > >>> dig soa -x 195.64.92.136 +noall +authority > >>> > >>> and extract the domain from the authoritative DNS server > >>> (ns.cistron.nl) :-) > >> > >> Can you tell us how this will work for host behind a NAT which address > >> is 192.168.1.2? > >> > > > > of course, you first has to know your public IPv4 address ;-) It=20 > > doesn't matter if you have one or more NAT levels, the only thing is=20 > > to find out your final public address. There are several ways to do it=20 > > and one of the most used is the STUN protocol, RFC 3489. >=20 > I was expecting this answer. Can you now tell how to discover which=20 > stun server to use? That is why I offered him the traceroute option, to at least get the IP's and then the reverses of the ISP, not that it would be really visible and quite hard to find out then where a) to trace to and b) which hop actually belongs to the ISP, but still ;) Also miguel, you really think that I did not have a special reverse on my box? At least internally 195.64.92.136 is also nicely known as purgatory.unfix.org and thus the SOA is also inside unfix.org, the NS records are at purgatory.unfix.org and ns1/ns2.mediadesign.nl. Does this lead you to cistron.nl? I also have to note that: - many ISP's don't do reverse at all - the ISP's that usually do not use the same domain name as they use for their services. - custom reverses exist too. Greets, Jeroen /me whispers: anycast ;) --=-XCEWJesJvBp0IaddjMVN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB7PPqKaooUjM+fCMRAtTwAJ0ZE8MCfrgpDcRZuTT7ZAcvJevq/ACbBfdg 3RQgrWT7i3Y0oZPxaefg0hE= =rLia -----END PGP SIGNATURE----- --=-XCEWJesJvBp0IaddjMVN-- --===============1232533351== 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 --===============1232533351==-- From v6tc-bounces@ietf.org Tue Jan 18 06:45: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 GAA14732; Tue, 18 Jan 2005 06:45:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqs3G-0005WU-US; Tue, 18 Jan 2005 07:01:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqriN-00089B-AT; Tue, 18 Jan 2005 06:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqrhL-0007uq-GZ for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 06:38:59 -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 GAA14394 for ; Tue, 18 Jan 2005 06:38:56 -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 1CqrwY-0005N7-Pt for v6tc@ietf.org; Tue, 18 Jan 2005 06:54:45 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000714173.msg for ; Tue, 18 Jan 2005 12:39:12 +0100 Message-ID: <009b01c4fd52$53384a00$a100000a@consulintel.es> From: "Miguel Angel Diaz" To: References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? Date: Tue, 18 Jan 2005 12:39:09 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 192.168.11.11 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Tue, 18 Jan 2005 12:39:16 +0100 X-MDAV-Processed: consulintel.es, Tue, 18 Jan 2005 12:39:16 +0100 X-Spam-Score: 2.2 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2102471038==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 --===============2102471038== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Pj4+PiBIb3cgdG8gZmluZCBvdXQgeW91ciBJU1AgZG9tYWluIG5hbWU/IEl0IGlzIHNpbXBsZSwg anVzdCB0eXBlOg0KPj4+Pg0KPj4+PiBkaWcgc29hIC14IDE5NS42NC45Mi4xMzYgK25vYWxsICth dXRob3JpdHkNCj4+Pj4NCj4+Pj4gYW5kIGV4dHJhY3QgdGhlIGRvbWFpbiBmcm9tIHRoZSBhdXRo b3JpdGF0aXZlIEROUyBzZXJ2ZXINCj4+Pj4gKG5zLmNpc3Ryb24ubmwpICA6LSkNCj4+Pg0KPj4+ IENhbiB5b3UgdGVsbCB1cyBob3cgdGhpcyB3aWxsIHdvcmsgZm9yIGhvc3QgYmVoaW5kIGEgTkFU IHdoaWNoIGFkZHJlc3MNCj4+PiBpcyAxOTIuMTY4LjEuMj8NCj4+Pg0KPj4NCj4+IG9mIGNvdXJz ZSwgeW91IGZpcnN0IGhhcyB0byBrbm93IHlvdXIgcHVibGljIElQdjQgYWRkcmVzcyA7LSkgSXQg DQo+PiBkb2Vzbid0IG1hdHRlciBpZiB5b3UgaGF2ZSBvbmUgb3IgbW9yZSBOQVQgbGV2ZWxzLCB0 aGUgb25seSB0aGluZyBpcyANCj4+IHRvIGZpbmQgb3V0IHlvdXIgZmluYWwgcHVibGljIGFkZHJl c3MuIFRoZXJlIGFyZSBzZXZlcmFsIHdheXMgdG8gZG8gaXQgDQo+PiBhbmQgb25lIG9mIHRoZSBt b3N0IHVzZWQgaXMgdGhlIFNUVU4gcHJvdG9jb2wsIFJGQyAzNDg5Lg0KPiANCj4gSSB3YXMgZXhw ZWN0aW5nIHRoaXMgYW5zd2VyLiBDYW4geW91IG5vdyB0ZWxsIGhvdyB0byBkaXNjb3ZlciB3aGlj aCANCj4gc3R1biBzZXJ2ZXIgdG8gdXNlPw0KPiANCg0KSSBzZWUgd2hlcmUgeW91IHdhbnQgdG8g YXJyaXZlOiB0aGUgc3R1biBzZXJ2ZXIgZGlzY292ZXJ5IGlzIGFuIGlzc3VlIGl0c2VsZiwgYnV0 IGN1cnJlbnRseSB0aGVyZSBhcmUgc2V2ZXJhbCBwdWJsaWMgc3R1biBzZXJ2ZXJzIGRlcGxveWVk IGFsbCBvdmVyIHRoZSB3b3JsZCBhbmQgdGhleSBhcmUgYXZhaWxhYmxlIGZvciBmcmVlIHRvIGFs bCB0aGUgdXNlcnMuIEp1c3Qgc29tZSBvZiB0aGVtOg0KICANCnN0dW4wMS5zaXBwaG9uZS5jb20s DQpzdHVuLnZveGdyYXRpYS5vcmcsDQpzdHVuMS52b3ZpZGEub3JnLA0Kc3R1bi5md2RuZXQubmV0 LA0Kc3R1bi5pbnRlcnZpdm8ubmV0DQogDQpXaHkgZG9uJ3QgdXNlIHRoZW0/DQogDQogUmVnYXJk cw0KTWlndWVsDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KTWFkcmlk IDIwMDMgR2xvYmFsIElQdjYgU3VtbWl0DQpQcmVzZW50YXRpb25zIGFuZCB2aWRlb3Mgb24gbGlu ZSBhdDoNCmh0dHA6Ly93d3cuaXB2Ni1lcy5jb20NCg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2Ug Y29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50 aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0 aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgaW5jbHVkaW5n IGF0dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KDQoNCm== --===============2102471038== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============2102471038==-- From v6tc-bounces@ietf.org Tue Jan 18 06:50:26 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 GAA14986; Tue, 18 Jan 2005 06:50:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqs7g-0005bv-QS; Tue, 18 Jan 2005 07:06:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqrr1-0000lT-Jk; Tue, 18 Jan 2005 06:48:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqrq0-0000Qy-FS for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 06:47: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 GAA14821 for ; Tue, 18 Jan 2005 06:47:53 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqs5G-0005Yi-1P for v6tc@ietf.org; Tue, 18 Jan 2005 07:03:42 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id E092BC2249; Tue, 18 Jan 2005 12:47:54 +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 22548-03; Tue, 18 Jan 2005 12:47:54 +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 47358C2248; Tue, 18 Jan 2005 12:47:54 +0100 (CET) Subject: Re: Fw: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: miguelangel.diaz@consulintel.es In-Reply-To: <013601c4fd3e$125f4650$1100a8c0@consulintel.es> References: <00a801c4fd30$4baad180$1100a8c0@consulintel.es> <013601c4fd3e$125f4650$1100a8c0@consulintel.es> Organization: Unfix Date: Tue, 18 Jan 2005 12:47:53 +0100 Message-Id: <1106048873.14179.77.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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="===============1384674088==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 --===============1384674088== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5N9tmx6iqhI2Qd0jpqWn" --=-5N9tmx6iqhI2Qd0jpqWn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-01-18 at 10:14 +0100, Miguel Angel Diaz wrote: > >> I partially agree with your point. I also support the idea of an anyca= st address if: > >>=20 > >> 1) each transition mechanism has its own anycast address > >=20 > > Why? Just setup a Transition Mechanism Server or whatever, eg a simple > > webserver and a special URL on that box would retrieve the information > > which allows the client utility to figure out what to do or where to ge= t > > the real information. Don't waste resources, there 'might' be enough, > > but then still you don't have to waste it. >=20 > Well, I'm thinking of a different approach. If every transition mechanism > has its own anycast address to discover a TEP this allows that any applic= ation > implementing a specific transition mechanism can contact the TEP directly= . >=20 > If there is only an anycast address for a server then there is a need for > handshaking, that is, client has to ask the anycast server > "What kind of TEP do you support?" and then once the client has the serve= r > reply it will decide if it can use it. This approach requires more standa= rdization for the handshake. What is the problem with this? Isn't the IETF about _standardizing_ methods and making them generic so that everybody can enjoy the fun? As you are mentioning 'no handshaking', you are not going to negotiate anything at all ? > If every transition mechanism has its own anycast address, the client onl= y > contact the TEP and all the communications between both hosts belongs to = the > protocol scope. No more standardization is required.=20 What is the reason then for even bothering into making such a mechanism into a standard if it is not a standardized method of doing it in the first place? (now that is an ugly sentence, no MS Word translator needed for that one ;) > This will allow that > different transition mechanism implementation could be directly and easil= y integrated on the OS. To take your 'home device', you really expect those vendors to implement, say, 10 methods to be able to get IPv6 in the air? There is not that much hardware available in those devices. Next to that, how does the vendor automatically pick the best one? And how can you be sure that one out of 10 is actually available at all ? > > Btw, when was this paper written, because it mentions 'current' a coupl= e > > of times, but there is no publication date in the paper.=20 >=20 > That paper was written two years ago but only for internal proposes, so i= t is not public nor announced anywhere. > I referenced it on the mail only to highlight several documented issues w= hen deploying anycast services > (not only from the point of view of TEP deployment): You referenced it but it doesn't contain anything which is actually related to the solution you are proposing neither does it contain anything what you actually value yourself? Why did you then reference it, let alone write it? > - packet delivery on more than one anycast host when establishing the com= munication (TCP SYN/ACK packets) Which is why most usages of anycast only use UDP, but as have been proven with the various root and GTLD servers, TCP works quite well too for eg EDNS. > - packets belonging to a burst being delivered on different anycast hosts BGP routing is not that flaky. This might occur when you have two routes with the same metric, but I am still to see this happening in any case but loadbalanced servers which can handle these cases anyway. > - ISPs filter bgp routes that aren't networks but hosts. This is made to = prevent that routing tables become too big. Usually ISP's filter >/24. That is why anycast prefixes are /24 also, see for instance the 6to4 prefix. This does not get filtered. This is also the reason why I propose a _single_ service anycast prefix, as that would avoid the problem that for every single mechanism, as you are apparently targeting at, there would be the need for a /24, while one would suffice with ease. > - ISPs usually filter traffic which the source address doesn't belong to = its own address space. They should *always* be doing this. If they are not doing any source filtering they should be shot by the anti-DDOS folks on the spot. > This is an issue when the traffic is originated on the anycast node. I hope you are aware that most ISP's are actually capable of configuring networks correctly. > There are lots of info about anycast issues: >=20 > * Robert Engel, Vinod Perdis, Debanjan Saha. "Using IP anycast for load d= istribution and server location" http://www.zurich.ibm.com/~rha/papers/any= cast-gi98.pdf I know Robert Haas, who also one of the authors, and he does not think it to be an issue at all, at least the way I am proposing the usage of an anycast service prefix. The above paper though is targeted at something completely different than what this WG should be trying to accomplish. Note also that the above paper is from 1998 and a lot of experience has been gained in the meanwhile in the field that was mentioned then, which was then research and now is used by common people every day, even your dad, even though he does not know it and could not care less. Greets, Jeroen --=-5N9tmx6iqhI2Qd0jpqWn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB7PdpKaooUjM+fCMRApHIAJ9ecOjkwTgCWwJMGQsyw4G8ZonE/QCglasp kOviJLdw+2kXM2no5QX/Dy4= =lGI/ -----END PGP SIGNATURE----- --=-5N9tmx6iqhI2Qd0jpqWn-- --===============1384674088== 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 --===============1384674088==-- From v6tc-bounces@ietf.org Tue Jan 18 07:03:38 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 HAA15879; Tue, 18 Jan 2005 07:03:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqsKS-0005sY-OI; Tue, 18 Jan 2005 07:19:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqs3X-0002fr-OL; Tue, 18 Jan 2005 07:01:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqs2z-0002Ym-3o for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 07:01:21 -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 HAA15690 for ; Tue, 18 Jan 2005 07:01:17 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqsID-0005pq-HF for v6tc@ietf.org; Tue, 18 Jan 2005 07:17:06 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j0IC16i3004081 for ; Tue, 18 Jan 2005 12:01:06 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA08928 for ; Tue, 18 Jan 2005 12:01:13 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j0IC1DC08597 for v6tc@ietf.org; Tue, 18 Jan 2005 12:01:13 GMT Date: Tue, 18 Jan 2005 12:01:13 +0000 From: Tim Chown To: v6tc@ietf.org Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? Message-ID: <20050118120113.GA8511@login.ecs.soton.ac.uk> Mail-Followup-To: v6tc@ietf.org References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> <009b01c4fd52$53384a00$a100000a@consulintel.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009b01c4fd52$53384a00$a100000a@consulintel.es> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: 79899194edc4f33a41f49410777972f8 On Tue, Jan 18, 2005 at 12:39:09PM +0100, Miguel Angel Diaz wrote: > > I see where you want to arrive: the stun server discovery is an issue itself, but currently there are several public stun servers deployed all over the world and they are available for free to all the users. Just some of them: > > stun01.sipphone.com, > stun.voxgratia.org, > stun1.vovida.org, > stun.fwdnet.net, > stun.intervivo.net > > Why don't use them? How deep a hole are we digging here? :) Tim _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Jan 18 07:26:15 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 HAA17230; Tue, 18 Jan 2005 07:26:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqsgM-0006Ku-Ly; Tue, 18 Jan 2005 07:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqsO8-0005xD-Hj; Tue, 18 Jan 2005 07:23:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqsMe-0005dv-34 for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 07:21:40 -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 HAA16987 for ; Tue, 18 Jan 2005 07:21:38 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqsbt-0006FH-3r for v6tc@ietf.org; Tue, 18 Jan 2005 07:37:26 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0ICLbdt024358 for ; Tue, 18 Jan 2005 05:21:37 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IAI007MEIC1IF@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Tue, 18 Jan 2005 05:21:37 -0700 (MST) Received: from [192.168.1.2] ([83.193.1.160]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAI005AGIBYUK@mail.sun.net> for v6tc@ietf.org; Tue, 18 Jan 2005 05:21:37 -0700 (MST) Date: Tue, 18 Jan 2005 04:21:32 -0800 From: Alain Durand Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-reply-to: <008e01c4fd52$1b678050$a100000a@consulintel.es> To: miguelangel.diaz@consulintel.es Message-id: <7D435C3F-694B-11D9-9E6D-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> <008e01c4fd52$1b678050$a100000a@consulintel.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7BIT On Jan 18, 2005, at 3:37 AM, Miguel Angel Diaz wrote: >>> of course, you first has to know your public IPv4 address ;-) It >>> doesn't matter if you have one or more NAT levels, the only thing is >>> to find out your final public address. There are several ways to do >>> it >>> and one of the most used is the STUN protocol, RFC 3489. >> >> I was expecting this answer. Can you now tell how to discover which >> stun server to use? >> > > I see where you want to arrive: the stun server discovery is an issue > itself, but currently there are several public stun servers deployed > all over the world and they are available for free to all the users. > Just some of them: > > stun01.sipphone.com, > stun.voxgratia.org, > stun1.vovida.org, > stun.fwdnet.net, > stun.intervivo.net > > Why don't use them? Simply because hardcoding names like that in implementations that need to be maintained for 10-20 years is a bad thing. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Jan 18 07:32: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 HAA17698; Tue, 18 Jan 2005 07:32:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqsmK-0006Tx-BK; Tue, 18 Jan 2005 07:48:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqsTN-0006kn-R8; Tue, 18 Jan 2005 07:28:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqsQW-0006NR-HM for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 07:25:40 -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 HAA17159 for ; Tue, 18 Jan 2005 07:25:38 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqsfk-0006Iy-RH for v6tc@ietf.org; Tue, 18 Jan 2005 07:41:26 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0ICP2w08144; Tue, 18 Jan 2005 14:25:02 +0200 Date: Tue, 18 Jan 2005 14:25:02 +0200 (EET) From: Pekka Savola To: Miguel Angel Diaz Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-Reply-To: <002401c4fd49$f062e730$a100000a@consulintel.es> Message-ID: References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi, On Tue, 18 Jan 2005, Miguel Angel Diaz wrote: >> Can you tell us how this will work for host behind a NAT which address >> is 192.168.1.2? > > of course, you first has to know your public IPv4 address ;-) It > doesn't matter if you have one or more NAT levels, the only thing is > to find out your final public address. There are several ways to do > it and one of the most used is the STUN protocol, RFC 3489. This would create a dependency on STUN (the client has is, the ISP has deployed it) or similar method, and would create additional roundtrips. This seems unacceptable to me. What seems left on the table from the generic solutions is an IPv4 anycast address. It has some problems, but maybe these problems are smaller than with others. Or, one could just state that the discovery method is not intended to work under every situation (e.g., forward DNS works if the NAT box doesn't advertise it's own domain name). We'll see. -- 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 Tue Jan 18 07:38:33 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 HAA18011; Tue, 18 Jan 2005 07:38:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqssG-0006bA-T8; Tue, 18 Jan 2005 07:54:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqsXe-0007P1-Gi; Tue, 18 Jan 2005 07:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqsWW-00079O-ND for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 07:31:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17657 for ; Tue, 18 Jan 2005 07:31:50 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqsll-0006T5-KU for v6tc@ietf.org; Tue, 18 Jan 2005 07:47:38 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 88282C2248; Tue, 18 Jan 2005 13:31: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 24309-04; Tue, 18 Jan 2005 13:31:39 +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 DF3BB24062; Tue, 18 Jan 2005 13:31:37 +0100 (CET) Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: Alain Durand In-Reply-To: <7D435C3F-694B-11D9-9E6D-00039358A080@sun.com> References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> <008e01c4fd52$1b678050$a100000a@consulintel.es> <7D435C3F-694B-11D9-9E6D-00039358A080@sun.com> Organization: Unfix Date: Tue, 18 Jan 2005 13:30:31 +0100 Message-Id: <1106051431.14179.83.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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="===============1559046704==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 --===============1559046704== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vfInWF7WDMr45jmpea64" --=-vfInWF7WDMr45jmpea64 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-01-18 at 04:21 -0800, Alain Durand wrote: > On Jan 18, 2005, at 3:37 AM, Miguel Angel Diaz wrote: > >>> of course, you first has to know your public IPv4 address ;-) It > >>> doesn't matter if you have one or more NAT levels, the only thing is > >>> to find out your final public address. There are several ways to do=20 > >>> it > >>> and one of the most used is the STUN protocol, RFC 3489. > >> > >> I was expecting this answer. Can you now tell how to discover which > >> stun server to use? > >> > > > > I see where you want to arrive: the stun server discovery is an issue=20 > > itself, but currently there are several public stun servers deployed=20 > > all over the world and they are available for free to all the users.=20 > > Just some of them: > > > > stun01.sipphone.com, > > stun.voxgratia.org, > > stun1.vovida.org, > > stun.fwdnet.net, > > stun.intervivo.net > > > > Why don't use them? >=20 > Simply because hardcoding names like that in implementations that need=20 > to be > maintained for 10-20 years is a bad thing. Not even mentioning the abuse of resources provided by others. And what is the use of using a STUN in the first place, if it cannot be reached you are dead in the water. Greets, Jeroen /me whispers some more things about anycast... ;) --=-vfInWF7WDMr45jmpea64 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB7QFnKaooUjM+fCMRAhVcAKC0CrBlfd+ige91GkxMDq70R4DpWQCgiwvW yLZkFQQx3rPIZkb0j4ypR5E= =m9BF -----END PGP SIGNATURE----- --=-vfInWF7WDMr45jmpea64-- --===============1559046704== 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 --===============1559046704==-- From v6tc-bounces@ietf.org Tue Jan 18 08:57:58 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 IAA23659; Tue, 18 Jan 2005 08:57:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqu79-000056-44; Tue, 18 Jan 2005 09:13:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqtow-00024y-RZ; Tue, 18 Jan 2005 08:54:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqtmg-0001gV-75 for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 08:52:38 -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 IAA23467 for ; Tue, 18 Jan 2005 08:52:36 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqu1x-0008Rm-29 for v6tc@ietf.org; Tue, 18 Jan 2005 09:08:25 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0IDqaVu023366 for ; Tue, 18 Jan 2005 06:52:36 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IAI007K7MJNIF@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Tue, 18 Jan 2005 06:52:36 -0700 (MST) Received: from [192.168.1.2] ([83.193.1.160]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAI007JHMJLOP@mail.sun.net> for v6tc@ietf.org; Tue, 18 Jan 2005 06:52:35 -0700 (MST) Date: Tue, 18 Jan 2005 05:52:30 -0800 From: Alain Durand Subject: Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-reply-to: To: v6tc@ietf.org Message-id: <326DFB69-6958-11D9-9E6D-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7BIT 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: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7BIT On Jan 18, 2005, at 4:25 AM, Pekka Savola wrote: > What seems left on the table from the generic solutions is an IPv4 > anycast address. It has some problems, but maybe these problems are > smaller than with others. I think the discussion from the last few days has shown few things: a) DNS based solutions (forward or reverse) do not work in all situations and in particular do not work well in the case where a NAT box is present, which seems to be a show stopper. b) Some have pointed that it is ok if particular solutions do not work in some cases, as those concern allegedly "power user" who do not need help to set up tunnels... I disagree deeply with this assertion. Whatever we will do will be in use for many years, and things have to be done right and just works in any kind of environments. Relying on strong assumptions on how things are configured at customers place is, IMHO, a recipe for failure. c) Anycast based solution are workable in theory but there are operational concerns. More feedback from the ISP community and the rest of the IETF is necessary. It may be the case that this should be the focus of a dedicated wg. It seems, to me at least, that the logical conclusion is that we need to dissociate this service discovery mechanism from the rest of the discussions and, for now, consider that there is an out-of-band mechanism to find out the tunnel end points. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Jan 18 11:04:33 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 LAA06023; Tue, 18 Jan 2005 11:04:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqw5f-0003h2-AC; Tue, 18 Jan 2005 11:20:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqvmY-0001bT-Ez; Tue, 18 Jan 2005 11:00:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqvby-000707-3e for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 10:49:43 -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 KAA04442 for ; Tue, 18 Jan 2005 10:49:39 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqvrF-00039z-8T for v6tc@ietf.org; Tue, 18 Jan 2005 11:05:29 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 3F3698B768; Tue, 18 Jan 2005 16:49:30 +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 04932-03; Tue, 18 Jan 2005 16:49:29 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id C8FF78B760; Tue, 18 Jan 2005 16:49:29 +0100 (CET) Subject: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: Alain Durand In-Reply-To: <326DFB69-6958-11D9-9E6D-00039358A080@sun.com> References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> <326DFB69-6958-11D9-9E6D-00039358A080@sun.com> Organization: Unfix Date: Tue, 18 Jan 2005 16:49:28 +0100 Message-Id: <1106063368.14179.149.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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="===============0921981601==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 --===============0921981601== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fUZ2UV27+lHY5O/O1Du+" --=-fUZ2UV27+lHY5O/O1Du+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-01-18 at 05:52 -0800, Alain Durand wrote: > On Jan 18, 2005, at 4:25 AM, Pekka Savola wrote: > > What seems left on the table from the generic solutions is an IPv4=20 > > anycast address. It has some problems, but maybe these problems are=20 > > smaller than with others. >=20 > I think the discussion from the last few days has shown few things: >=20 > a) DNS based solutions (forward or reverse) do not work in all=20 > situations and in particular do not work well in the case where a NAT box= is=20 > present, which seems to be a show stopper. Especially when thinking of the fact that without a NAT box one can easily use 6to4, this 'solution' is really unnecessary. > b) Some have pointed that it is ok if particular solutions do not work=20 > in some cases, as those concern allegedly "power user" who do not need he= lp to=20 > set up tunnels... I disagree deeply with this assertion. Whatever we will= do will be=20 > in use for many years, and things have to be done right and just works in= any kind of=20 > environments. As long as there is a 'knob' to turn automatic on/off, or at least a simple 'if there is IPv6 on the wire don't do a thing' this should be fine with most if not all people. It should work in most (nearing 99%) of the situations of course. > Relying on strong assumptions on how things are configured at=20 > customers place is, IMHO, a recipe for failure. This is indeed the biggest point to learn from it all. There is simply no way one can assume that a certain setup is available. We thus can only assume there is IP and that we can send packets from A to B. > c) Anycast based solution are workable in theory but there are=20 > operational concerns. > More feedback from the ISP community and the rest of the IETF is=20 > necessary. It may be the case that this should be the focus of a dedicate= d wg. Splitting up this, not even really started* WG into another WG is a bit silly isn't it ? :) (especially when counting the number of _active_ participants) > It seems, to me at least, that the logical conclusion is that we need=20 > to dissociate this service discovery mechanism from the rest of the discu= ssions and,=20 > for now, consider that there is an out-of-band mechanism to find out the = tunnel=20 > end points. Thus, if I am correct, the focus of this WG should be (in short): - the fully automatic discovery of the best possible TEP - the configuration of the addresses of the tunnel - the protocol used for the transport of the IPv6 packets over IPv4. Maybe thus have 3 topics? - Endpoint Discovery - Configuration - Tunneling Though I think that the discovery and the configuration could sometimes come together. Though usage of eg DHCP and other standard methods could solve these issues. Do note that there is little vendor support for this. Thus maybe simple prefix subjects with correct part (T,C,E) and done? Greets, Jeroen * =3D there is still no official IETF WG charter.... --=-fUZ2UV27+lHY5O/O1Du+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB7TAIKaooUjM+fCMRAiN9AJsFvmv5ivKANzuV2P5XZ+lbFc1zIgCfUgkk d4J1smq4QVNImtOPg4VA8EQ= =Xq7K -----END PGP SIGNATURE----- --=-fUZ2UV27+lHY5O/O1Du+-- --===============0921981601== 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 --===============0921981601==-- From v6tc-bounces@ietf.org Tue Jan 18 11:33:47 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 LAA08584; Tue, 18 Jan 2005 11:33:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqwXx-0004hL-BS; Tue, 18 Jan 2005 11:49:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqwEy-00007C-TD; Tue, 18 Jan 2005 11:30:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqw3k-0005e9-98 for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 11:18:24 -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 LAA07196 for ; Tue, 18 Jan 2005 11:18:21 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqwJ1-00049h-Jk for v6tc@ietf.org; Tue, 18 Jan 2005 11:34:12 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j0IGI5i3013235 for ; Tue, 18 Jan 2005 16:18:05 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA29052 for ; Tue, 18 Jan 2005 16:18:14 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j0IGIDs16327 for v6tc@ietf.org; Tue, 18 Jan 2005 16:18:13 GMT Date: Tue, 18 Jan 2005 16:18:13 +0000 From: Tim Chown To: v6tc@ietf.org Subject: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or manual? Message-ID: <20050118161813.GL11621@login.ecs.soton.ac.uk> Mail-Followup-To: v6tc@ietf.org References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> <326DFB69-6958-11D9-9E6D-00039358A080@sun.com> <1106063368.14179.149.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1106063368.14179.149.camel@firenze.zurich.ibm.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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: 34d35111647d654d033d58d318c0d21a I agree with Jeroen. I think though that originally we left the tunnelling protocol itself out of scope, i.e. v6tc is tunnel *configuration* ? Tim On Tue, Jan 18, 2005 at 04:49:28PM +0100, Jeroen Massar wrote: > On Tue, 2005-01-18 at 05:52 -0800, Alain Durand wrote: > > On Jan 18, 2005, at 4:25 AM, Pekka Savola wrote: > > > What seems left on the table from the generic solutions is an IPv4 > > > anycast address. It has some problems, but maybe these problems are > > > smaller than with others. > > > > I think the discussion from the last few days has shown few things: > > > > a) DNS based solutions (forward or reverse) do not work in all > > situations and in particular do not work well in the case where a NAT box is > > present, which seems to be a show stopper. > > Especially when thinking of the fact that without a NAT box one can > easily use 6to4, this 'solution' is really unnecessary. > > > b) Some have pointed that it is ok if particular solutions do not work > > in some cases, as those concern allegedly "power user" who do not need help to > > set up tunnels... I disagree deeply with this assertion. Whatever we will do will be > > in use for many years, and things have to be done right and just works in any kind of > > environments. > > As long as there is a 'knob' to turn automatic on/off, or at least a > simple 'if there is IPv6 on the wire don't do a thing' this should be > fine with most if not all people. It should work in most (nearing 99%) > of the situations of course. > > > Relying on strong assumptions on how things are configured at > > customers place is, IMHO, a recipe for failure. > > This is indeed the biggest point to learn from it all. There is simply > no way one can assume that a certain setup is available. We thus can > only assume there is IP and that we can send packets from A to B. > > > c) Anycast based solution are workable in theory but there are > > operational concerns. > > More feedback from the ISP community and the rest of the IETF is > > necessary. It may be the case that this should be the focus of a dedicated wg. > > Splitting up this, not even really started* WG into another WG is a bit > silly isn't it ? :) (especially when counting the number of _active_ > participants) > > > It seems, to me at least, that the logical conclusion is that we need > > to dissociate this service discovery mechanism from the rest of the discussions and, > > for now, consider that there is an out-of-band mechanism to find out the tunnel > > end points. > > Thus, if I am correct, the focus of this WG should be (in short): > - the fully automatic discovery of the best possible TEP > - the configuration of the addresses of the tunnel > - the protocol used for the transport of the IPv6 packets over IPv4. > > Maybe thus have 3 topics? > - Endpoint Discovery > - Configuration > - Tunneling > > Though I think that the discovery and the configuration could sometimes > come together. Though usage of eg DHCP and other standard methods could > solve these issues. Do note that there is little vendor support for > this. > > Thus maybe simple prefix subjects with correct part (T,C,E) and done? > > Greets, > Jeroen > > * = there is still no official IETF WG charter.... > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc -- Tim _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Jan 18 11:51:01 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 LAA10332; Tue, 18 Jan 2005 11:51:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqwod-0005JX-Bb; Tue, 18 Jan 2005 12:06:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqwTh-0003sN-5T; Tue, 18 Jan 2005 11:45:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqwR1-0002yZ-Sm for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 11:42:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09671 for ; Tue, 18 Jan 2005 11:42:25 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqwgJ-00052V-3k for v6tc@ietf.org; Tue, 18 Jan 2005 11:58:16 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0IGgPVu014289 for ; Tue, 18 Jan 2005 09:42:25 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IAI008F4UEPSD@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Tue, 18 Jan 2005 09:42:25 -0700 (MST) Received: from [192.168.1.2] ([83.193.1.160]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAI000JTUEM8A@mail.sun.net> for v6tc@ietf.org; Tue, 18 Jan 2005 09:42:25 -0700 (MST) Date: Tue, 18 Jan 2005 08:42:20 -0800 From: Alain Durand Subject: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-reply-to: <20050118161813.GL11621@login.ecs.soton.ac.uk> To: Tim Chown Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> <326DFB69-6958-11D9-9E6D-00039358A080@sun.com> <1106063368.14179.149.camel@firenze.zurich.ibm.com> <20050118161813.GL11621@login.ecs.soton.ac.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7BIT On Jan 18, 2005, at 8:18 AM, Tim Chown wrote: > I agree with Jeroen. > > I think though that originally we left the tunnelling protocol itself > out of scope, i.e. v6tc is tunnel *configuration* ? Thank you Tim for introducing the next issue I want to discuss... - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Jan 18 11:58:54 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 LAA11093; Tue, 18 Jan 2005 11:58:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqwwF-0005WM-PV; Tue, 18 Jan 2005 12:14:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqwZp-0004un-U4; Tue, 18 Jan 2005 11:51:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqwVE-0003v3-6v for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 11:46:48 -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 LAA10028 for ; Tue, 18 Jan 2005 11:46:45 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqwkV-0005D2-MN for v6tc@ietf.org; Tue, 18 Jan 2005 12:02:37 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0IGkjdt028578 for ; Tue, 18 Jan 2005 09:46:45 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IAI006EDULXA0@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Tue, 18 Jan 2005 09:46:45 -0700 (MST) Received: from [192.168.1.2] ([83.193.1.160]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAI000BOULO7R@mail.sun.net> for v6tc@ietf.org; Tue, 18 Jan 2005 09:46:45 -0700 (MST) Date: Tue, 18 Jan 2005 08:46:34 -0800 From: Alain Durand To: v6tc@ietf.org Message-id: <83782093-6970-11D9-9E6D-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7BIT Subject: [v6tc] Issue 3: authentication & signaling 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: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7BIT From the list of issues I introduced a while back, I've grouped the ones about authentication, security & signaling. - Do we need mutual authentication? How strong should this be? - Should some of this authentication mechanism "follow-on" atfer the tunnel set-up phase is finished? - Should we embed some kind of signaling in the tunnel? Keep in mind we need to be realistic. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Jan 18 14:28:07 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 OAA22599; Tue, 18 Jan 2005 14:28:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqzGg-0000oE-Q4; Tue, 18 Jan 2005 14:43:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqyyi-0005V5-AC; Tue, 18 Jan 2005 14:25:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqys6-0003ta-DV for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 14:18:34 -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 OAA21782 for ; Tue, 18 Jan 2005 14:18:32 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqz7O-0000Vh-RR for v6tc@ietf.org; Tue, 18 Jan 2005 14:34:24 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0IJHoc19807; Tue, 18 Jan 2005 21:17:52 +0200 Date: Tue, 18 Jan 2005 21:17:50 +0200 (EET) From: Pekka Savola To: Jeroen Massar Subject: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-Reply-To: <1106063368.14179.149.camel@firenze.zurich.ibm.com> Message-ID: References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> <326DFB69-6958-11D9-9E6D-00039358A080@sun.com> <1106063368.14179.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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Alain Durand , v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Tue, 18 Jan 2005, Jeroen Massar wrote: > On Tue, 2005-01-18 at 05:52 -0800, Alain Durand wrote: >> On Jan 18, 2005, at 4:25 AM, Pekka Savola wrote: >>> What seems left on the table from the generic solutions is an IPv4 >>> anycast address. It has some problems, but maybe these problems are >>> smaller than with others. >> >> I think the discussion from the last few days has shown few things: >> >> a) DNS based solutions (forward or reverse) do not work in all >> situations and in particular do not work well in the case where a NAT box is >> present, which seems to be a show stopper. > > Especially when thinking of the fact that without a NAT box one can > easily use 6to4, this 'solution' is really unnecessary. You can use 6to4 in this situation, yes, but you cannot use IPv6 addresses from your service provider's v6 prefix. 6to4's return-path quality is always a bit questionable, and v6tc might allow one to get a stable prefix when 6to4 prefix could be dynamic. So, while "you can use 6to4 in that scenario" is an answer, it is not a complete answer. -- 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 Jan 19 02:57:05 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 CAA19313; Wed, 19 Jan 2005 02:57:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrAxa-0002gE-Fy; Wed, 19 Jan 2005 03:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrAgN-0006DY-O8; Wed, 19 Jan 2005 02:55:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrAe6-0005cQ-Eu for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 02:52:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18917 for ; Wed, 19 Jan 2005 02:52:50 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrAtT-0002au-2K for v6tc@ietf.org; Wed, 19 Jan 2005 03:08:48 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 2C19422C391; Wed, 19 Jan 2005 08:52:43 +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 03852-08; Wed, 19 Jan 2005 08:52:42 +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 0883722C390; Wed, 19 Jan 2005 08:52:41 +0100 (CET) Subject: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: Pekka Savola In-Reply-To: References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> <326DFB69-6958-11D9-9E6D-00039358A080@sun.com> <1106063368.14179.149.camel@firenze.zurich.ibm.com> Organization: Unfix Date: Wed, 19 Jan 2005 08:52:40 +0100 Message-Id: <1106121160.18807.3.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Alain Durand , v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1570380438==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 --===============1570380438== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QoqU9OUAkGqbxDausGWL" --=-QoqU9OUAkGqbxDausGWL Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-01-18 at 21:17 +0200, Pekka Savola wrote: > On Tue, 18 Jan 2005, Jeroen Massar wrote: > > On Tue, 2005-01-18 at 05:52 -0800, Alain Durand wrote: > >> On Jan 18, 2005, at 4:25 AM, Pekka Savola wrote: > >>> What seems left on the table from the generic solutions is an IPv4 > >>> anycast address. It has some problems, but maybe these problems are > >>> smaller than with others. > >> > >> I think the discussion from the last few days has shown few things: > >> > >> a) DNS based solutions (forward or reverse) do not work in all > >> situations and in particular do not work well in the case where a NAT = box is > >> present, which seems to be a show stopper. > > > > Especially when thinking of the fact that without a NAT box one can > > easily use 6to4, this 'solution' is really unnecessary. >=20 > You can use 6to4 in this situation, yes, but you cannot use IPv6=20 > addresses from your service provider's v6 prefix. 6to4's return-path=20 > quality is always a bit questionable, and v6tc might allow one to get=20 > a stable prefix when 6to4 prefix could be dynamic. >=20 > So, while "you can use 6to4 in that scenario" is an answer, it is not=20 > a complete answer. Ack. Isn't the best and already working route Teredo then: - NAT capable if needed - uses providers prefix - automatically configured The only piece missing is the anycast prefix... Greets, Jeroen --=-QoqU9OUAkGqbxDausGWL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB7hHHKaooUjM+fCMRAiHZAKC5SUfAmTz2vcluLx2hRGJkYsJ+LQCeIEdX DLunhUQYl7uVvl8ZAxGDWxw= =UETQ -----END PGP SIGNATURE----- --=-QoqU9OUAkGqbxDausGWL-- --===============1570380438== 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 --===============1570380438==-- From v6tc-bounces@ietf.org Wed Jan 19 03:10:40 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 DAA20104; Wed, 19 Jan 2005 03:10:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrBAk-0002xk-1u; Wed, 19 Jan 2005 03:26:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrApV-000829-U6; Wed, 19 Jan 2005 03:04:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrAoJ-0007qw-Gk for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 03:03:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19665 for ; Wed, 19 Jan 2005 03:03:26 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrB3k-0002nn-1P for v6tc@ietf.org; Wed, 19 Jan 2005 03:19:24 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id E7B9589D3E; Wed, 19 Jan 2005 09:03:25 +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 05164-04; Wed, 19 Jan 2005 09:03:25 +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 4846D24044; Wed, 19 Jan 2005 09:03:25 +0100 (CET) Subject: Re: [v6tc] Issue 3: authentication & signaling From: Jeroen Massar To: Alain Durand In-Reply-To: <83782093-6970-11D9-9E6D-00039358A080@sun.com> References: <83782093-6970-11D9-9E6D-00039358A080@sun.com> Organization: Unfix Date: Wed, 19 Jan 2005 09:03:24 +0100 Message-Id: <1106121804.18807.11.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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="===============2031832960==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 --===============2031832960== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MoOebT1qkZR3SnD5fFwX" --=-MoOebT1qkZR3SnD5fFwX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-01-18 at 08:46 -0800, Alain Durand wrote: > From the list of issues I introduced a while back, I've grouped > the ones about authentication, security & signaling. >=20 > - Do we need mutual authentication? How strong should this be? In case one does authentication it should be at least a handshake, thus one which cannot be replayed nor contains any clear text passwords. > - Should some of this authentication mechanism "follow-on" atfer the=20 > tunnel set-up phase > is finished? This depends more on what you want of course. If you want a generic "it should always work" solution, then you do not need authentication. If you want a solution that is at least able to verify user/pass If you think of any security at all, outside of simply ingress filtering, you are going to end up with a user/pass or other secret combo and thus you will have to do some handshake somewhere. > - Should we embed some kind of signaling in the tunnel? For me both signaling with the purpose of authentication and signaling that the endpoint is still alive* Though, the first can be dropped if you only want this to be deployed inside the same ISP's real, and thus full ingress filtering is in effect. When there is a small assumption that there might somewhere be a hole in the ingress filtering, authentication of each packet becomes a MUST. That is of course if there is this requirement to create a new protocol at all. Greets, Jeroen * =3D You do not want to receive a huge amount of Firewall logs suddenly in your abuse@ mailbox... --=-MoOebT1qkZR3SnD5fFwX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB7hRLKaooUjM+fCMRAuNIAJ9YupyPe4nYXvPVJJxLoVzK2tz0MwCdF9CQ ynGDMGz/QPNga2inb+c8OkQ= =sbNn -----END PGP SIGNATURE----- --=-MoOebT1qkZR3SnD5fFwX-- --===============2031832960== 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 --===============2031832960==-- From v6tc-bounces@ietf.org Wed Jan 19 03:37: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 DAA21412; Wed, 19 Jan 2005 03:37:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrBaG-0003Wy-GA; Wed, 19 Jan 2005 03:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBFx-0004fY-91; Wed, 19 Jan 2005 03:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBEH-00041h-0J for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 03:30: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 DAA21055 for ; Wed, 19 Jan 2005 03:30: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 1CrBTh-0003MW-Bz for v6tc@ietf.org; Wed, 19 Jan 2005 03:46:14 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000716302.msg for ; Wed, 19 Jan 2005 09:30:28 +0100 Message-ID: <01c901c4fe01$20892de0$1100a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <004601c4fdf8$65804b80$1100a8c0@consulintel.es> Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery:automaticormanual? Date: Wed, 19 Jan 2005 09:30:24 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Wed, 19 Jan 2005 09:30:32 +0100 X-MDAV-Processed: consulintel.es, Wed, 19 Jan 2005 09:30:32 +0100 X-Spam-Score: 2.2 (++) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1852920895==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 --===============1852920895== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 PiBPbiBUdWUsIDIwMDUtMDEtMTggYXQgMTA6MTQgKzAxMDAsIE1pZ3VlbCBBbmdlbCBEaWF6IHdy b3RlOg0KPj4gPj4gSU1ITyBpZiB3ZSB3aXNoIGEgYnJvYWQgYW5kIGZhc3QgZGVwbG95bWVudCBv ZiBJUHY2IHRoZSBhbnN3ZXIgaXMgdGhhdCBhbg0KPj4gPj4gYXV0b21hdGljIGRpc2NvdmVyeSBt ZWNoYW5pc20gaXMgZGVmaW5pdGl2ZWx5IHJlcXVpcmVkLiANCj4+ID4gDQo+PiA+IFRoZXJlIGlz IGFscmVhZHkgVGVyZWRvIGFuZCA2dG80LCB3aGF0IG1vcmUgaXMgbmVlZGVkPw0KPj4gPiBUZXJl ZG8gb24gaXQncyBvd24gYWxyZWFkeSBzb2x2ZXMgbW9zdCBpZiBub3QgYWxsIHByb2JsZW1zLg0K Pj4gPiBUaGUgb25seSBpc3N1ZSB3aXRoIFRlcmVkbyBfY291bGRfIGJlIHRoYXQgb25lIGRvZXMg bm90IGdldCB0aGUgbW9zdA0KPj4gPiBsb2NhbCByZWxheS4gQnV0IEkgdGhpbmsgTSQgY2FuIGJl IGVhc2lseSBwdXJzdWFkZSB0byBhZGQgYSB1cGRhdGUgdG8NCj4+ID4gd2luZG93c3VwZGF0ZSB0 aGF0IHdpbGwgcmVjb25maWd1cmUgdGhlIGRlZmF1bHQgdGVyZWRvc2VydmVyIHRvIGFuDQo+PiA+ IGFueWNhc3QgYWRkcmVzcy4NCj4+ID4gDQo+PiANCj4+IFRob3VzYW5kcyAoZXZlbiBtaWxsaW9u cykgb2YgdXNlcnMgb3ZlciB0aGUgd29ybGQgY2FuJ3QgdXNlIHRoZQ0KPj4gY3VycmVudCBzZXJ2 ZXJzIHRoYXQgTSQgaGFzIHByZS1jb25maWd1cmVkIGZvciA2dG80IGFuZCBUZXJlZG8NCj4+IGlt cGxlbWVudGF0aW9ucyBvbiB0aGUgT1MsIHdoaWNoIGFyZSA2dG80LmlwdjYubWljcm9zb2Z0LmNv bSBhbmQNCj4+IHRlcmVkby5pcHY2Lm1pY3Jvc29mdC5jb20uDQo+IA0KPiBEaWQgeW91IG5vdGlj ZSB0aGUgZm9sbG93aW5nOg0KPiA2dG80LmlwdjYubWljcm9zb2Z0LmNvbSBoYXMgYWRkcmVzcyAx OTIuODguOTkuMQ0KPiA2dG80LmlwdjYubWljcm9zb2Z0LmNvbSBoYXMgYWRkcmVzcyAxMzEuMTA3 LjMzLjYwDQo+IDZ0bzQuaXB2Ni5taWNyb3NvZnQuY29tIGhhcyBJUHY2IGFkZHJlc3MgMjAwMjo4 MzZiOjIxM2M6MTplMDo4ZjA4OmYwMjA6OA0KPiANCj4gSWYgaXQgaXNuJ3Qga25vd24sIHRoYXQg Zmlyc3Qgb25lIGlzIHRoZSA2dG80IGFueWNhc3QgYWRkcmVzcywgd2hpY2ggaXMNCj4gYWxzbyB0 aGUgZmlyc3QgdGhpbmcgdGhhdCBYUCB0cmllcywgYWZ0ZXIgdGhhdCBpdCBtaWdodCBmYWxsIGJh Y2sgdG8gdGhlDQo+IG1pY3Jvc29mdCBwcm92aWRlZCByZWxheS4NCj4gDQo+IFRoZXkgKDZ0bzQg YW5kIFRlcmVkbykgd29yayBwZXJmZWN0bHkgZmluZSBmcm9tIHRoZSBzZXZlcmFsIHBsYWNlcyB3 aGVyZQ0KPiBJIGhhdmUgdHJpZWQgdGhlbS4gVGhlIG9ubHkgdGhpbmcgd2FzIHRoZSBsYXRlbmN5 IGFuZCB0aHJvdWdocHV0LCB3aGljaA0KPiBpcyBsb2dpY2FsIGFzIHRoZSBUZXJlZG8gYm94IGlz IGhvc3RlZCBpbiB0aGUgVVMsIHdoaWNoIGlzIG5vdCB3aGVyZSBJDQo+IGFtLCBidXQgZm9ydHVu YXRlbHkgaXQgdXNlcyB0aG9zZSBuaWNlIGJ1YmJsZXMgdG8gbG9jYXRlIGEgbW9yZSBsb2NhbA0K PiBzZXJ2ZXIgd2hpY2ggdGhlbiBjYXVzZXMgdGhlIHRyYWZmaWMgdG8gYmUgb3B0aW1pemVkIGEg Yml0Lg0KPiANCj4gQW55IHJlYWwgYXJndW1lbnQgd2h5IHRoZXNlIG1pbGxpb25zIG9mIHVzZXJz IGNhbid0IHVzZSBUZXJlZG8gYWNjb3JkaW5nDQo+IHRvIHlvdT8NCj4gDQoNCkkgbWVhbiB0aGF0 IGN1cnJlbnRseSBvbmx5IGEgZmV3IFRlcmVkbyBzZXJ2ZXJzIGFyZSBkZXBsb3llZCBvdmVyIHRo ZSB3b3JsZCwgYmVpbmcgdGhlIG1vc3Qga25vd24gdGhlIG9uZXMgZGVwbG95ZWQgYnkgTWljcm9z b2Z0IHdoaWNoIGFyZSB0aGUgZGVmYXVsdCBvbmVzIG9uIFdpZG93cyBYUC4gSXQgZG9lc24ndCBz ZWVtIHRvIGJlIGxpa2VseSB0aGF0IG9ubHkgYSBmZXcgdGhlbSBjYW4gbWFuYWdlIHRob3VzYW5k cyBvZiBjb25uZWN0aW9ucyBjdW5jdXJyZW50bHkuDQoNCg0KPj4gSXQgaXMgYXNzdW1lZCB0aGF0 IGV2ZXJ5IElTUCB3aWxsaW5nIHRvIG9mZmVyIElQdjYgc2VydmljZXMgdG8gdGhlaXINCj4+IGN1 c3RvbWVycyB3aWxsIGRlcGxveSBhIFRFUCBpbmZyYXN0cnVjdHVyZSBvbiBpdHMgb3duIG5ldHdv cmssIGVpdGhlciBUZXJlZG8sDQo+PiA2dG80LCBvciB3aGF0ZXZlci4gVGhlIFRFUCBkaXNjb3Zl cnkgb24gdGhlIElTUCBuZXR3b3JrIGlzIHRoZSBwb2ludC4NCj4gDQo+IE9mIGNvdXJzZSB0aGV5 IHdhbnQgdGhhdCwganVzdCBsaWtlIHRoaXMgaXMgZXhwZWN0ZWQgZnJvbSA2dG80Lg0KPiBUaGVy ZSBpcyBhIHZlcnkgc2ltcGxlIHNvbHV0aW9uIGlmIHlvdSB3YW50IHRoaXM6IGFueWNhc3QgcHJl Zml4IGZvcg0KPiBUZXJlZG8uIERvZXMgbm90IHJlcXVpcmUgYW55IHdlaXJkIG1lY2hhbmlzbXMs IG5vIHdlaXJkIHN0dWZmIGluIEROUw0KPiBub3RoaW5nLiBCdXQgdG8gY2FsbCB0aGlzICdkaXNj b3ZlcnknLCB3aHkgYm90aGVyIHdpdGggdGhhdCA/DQo+IA0KPj4gPiBOb3cgaWYgSSB3b3VsZCBs aXZlIGluIFRva2lvIEkgY291bGQgbGl2ZSB3aXRoIHRoaXMgYXNzdW1wdGlvbiwgYnV0DQo+PiA+ IHVuZm9ydHVuYXRlbHksIHVubGVzcyBJIGdvIHRvIEFraWJhcmEgbXlzZWxmIG9yIGltcG9ydCB0 aGUgc3R1ZmYgSSB3aWxsDQo+PiA+IG5vdCBiZSBhYmxlIHRvIGJ1eSB0aGVzZSBjb29sIHRveXMg KHlldCkuDQo+PiA+IA0KPj4gPiBBbHNvLCB0aGUgcm91dGVyIGluIHRoZSBob3VzZSBzaG91bGQg cHJvdmlkZSB0aGlzLCBub3QgdGhlIGNhbWVyYSwgdGhhdA0KPj4gPiBzaG91bGQgc2ltcGx5IFJB LiBOZXh0IHRvIHRoYXQgZG9lcyB0aGUgd29yZCAnc2VjdXJpdHknIHNheSBhbnl0aGluZz8NCj4+ IA0KPj4gVGhlIHBvaW50IGlzIHRoYXQgInRvZGF5IiB3ZSBhcmUgd29ya2luZyBvbiB0aGUgbmV0 d29ya3MgZm9yICJ0b21vcnJvdyIgYW5kIGluIHRoZSBuZWFyIGZ1dHVyZSwNCj4gDQo+IEluIHRo ZSBmdXR1cmUgdGhlcmUgd2lsbCBiZSBuYXRpdmUgSVB2NiB0byB0aGUgaG9tZSwgdG9kYXkgdGhl cmUgaXMgbmVlZA0KPiBmb3Igc29tZSB0dW5uZWxpbmcuIEJ1dCBpbiB+NSB5ZWFycyBpdCB3aWxs IGJlIG1vc3RseSBuYXRpdmUuDQo+IA0KPj4gSSB0aGluayB3ZSBhbGwgYXJlIGFncmVlIHRoYXQg bWFueSBob21lIGRldmljZXMgd2lsbCBzdXBwb3J0IElQdjYuIFN1Y2ggZGV2aWNlcyBjb3VsZCBp bXBsZW1lbnQNCj4+IG1ldGhvZHMgdG8gd29yayB3aXRoIElQdjYgZXZlbiBhbHRob3VnaCBvbmx5 IElQdjQgKHNvIG5vdCBSQSBhdmFpbGFibGUpIGlzIGF2YWlsYWJsZSBvbiB0aGUNCj4+IGhvbWUg bmV0d29yayBkdXJpbmcgdGhlIGVhcmx5IGRlcGxveW1lbnRzLiBJbiB0aGlzIHNjZW5hcmlvIGFu IGF1dG9tYXRpYyBkaXNjb3ZlcnkgbWV0aG9kIGlzIHJlcXVpcmVkLg0KPiANCj4gVGh1cyB5b3Ug d2FudCBldmVyeSBzbWFsbCBkZXZpY2UgdG8gaW1wbGVtZW50IHR1bm5lbGluZyBhbmQgdGh1cyBj cmVhdGUNCj4gaG93IG1hbnkgc2VjdXJpdHkgaG9sZXMgaW4gaG93IG1hbnkgcGxhY2VzPw0KPiAN Cg0KU2VjdXJpdHkgaXMgYW4gaXNzdWUgbm90IG9ubHkgd2l0aCBzbWFsbCBkZXZpY2VzIG9uIHRo ZSBuZXR3b3JrIGJ1dCBhbHNvIG9uIG9wZXJhdGluZyBzeXN0ZW1zIHJ1bm5pbmcgb24gdGhlIGNv bXB1dGVycyBhbmQgSSBndWVzcyBpdCBkb2Vzbid0IGRlcGVuZCBvbiB0aGUgZGlzY292ZXJ5IG1l Y2FuaXNtIHVzZWQgdG8gZ2V0IElQdjYgY29ubmVjdGVkIDopDQoNCg0KPiBZb3UnZCBiZXR0ZXIg c3RhcnQgd3JpdGluZyB0aGUgc2VjdXJpdHkgc2VjdGlvbiBvZiB0aGUgZHJhZnQgbGlrZSAzDQo+ IHllYXJzIGFnbyBpZiB5b3Ugd2FudCB0byBjb3ZlciBhbGwgdGhlIHBvc3NpYmxlIHByb2JsZW1z IHlvdSB3aWxsIGJlDQo+IGNyZWF0aW5nIGhlcmUuDQo+IA0KPiBSZW1lbWJlciB0aGUgZm9sbG93 aW5nIHZlcnkgc2ltcGxlIHRoaW5nOiBUaGVyZSB3aWxsIG1vc3QgbGlrZWx5IGJlIGF0DQo+IGxl YXN0IG9uZSBjb21wdXRlciAoWFAsIEJTRCwgTGludXgsIG90aGVyICdyb3V0ZXInKSB0aGF0IHN1 cHBvcnRzIElQdjYNCj4gaW4gc3VjaCBuZXR3b3Jrcy4gVGhlc2UgYXJlIG1vcmUgdGhhbiBjYXBh YmxlIGhhbmRsaW5nIHRoaXMgYW5kIGFyZSBhbHNvDQo+IHdheSBlYXNpZXIgdG8gbWFrZSBjZW50 cmFsbHkgc2VjdXJlL2ZpcmV3YWxsZWQuDQo+IA0KPiBJZiB5b3UgcmVhbGx5IHdhbnQgdGhhdCB5 b3UgY2FuIHBsdWcgaW4gYSBJUHY2IGNhbWVyYSwgd2hpY2ggd2lsbCB0aGVuDQo+IGFsc28gZG8g SVB2NCBmb3IgdGhlIHR1bm5lbGluZyBldmVuIHRob3VnaCBpdCBpcyBhIElQdjYtb25seSBjYW0s IHRoZW4NCj4gYWxzbyByZW1lbWJlciB0aGUgc2VjdXJpdHkgcHJvYmxlbXMuDQo+IA0KPj4gPj4g U28sIElNSE8gdGhlIGFuc3dlciBpcyB0aGF0IHdlIGNhbid0IGxpdmUgd2l0aCBtZXRob2RzIHRo YXQgcmVxdWlyZSB1c2VycyB0byBlbnRlciBhbnkgVVJMIG9yIGRhdGEuDQo+PiA+IA0KPj4gPiBJ IGtub3cgb2YgYWxtb3N0IDM1MDAgaGFwcHkgdXNlcnMgd2hvIGxpdmVkIHdpdGggdGhpcyBwZXJm ZWN0bHkgZmluZSBhbmQNCj4+ID4gdGhlcmUgYXJlIGEgbnVtYmVyIG9mIG90aGVyIG9yZ2FuaXph dGlvbnMgd2hvIGNsYWltIHRvIGhhdmUgd2F5IG1vcmUNCj4+ID4gdXNlcnMuDQo+PiA+IA0KPj4g DQo+PiBJIGd1ZXNzIHdlIGFyZSB0aGlua2luZyBvZiBkaWZmZXJlbnQgdHlwZSBvZiB1c2Vycy4g SSBzdXJlIHRoYXQgZXhwZXJ0IHVzZXJzIChhdCBsZWFzdCB3aXRoIHNvbWUNCj4+IHRlY2huaWNh bCBrbm93bGVkZ2UpIGFyZSBoYXBweSB3aXRoIHRoYXQgc2l0dWF0aW9uLCBidXQgSSdtIHRoaW5r aW5nIG9mIHRob3VzYW5kcyBvZiB1c2VycyB0aGF0DQo+PiBhcmVuJ3QgVEkgZXhwZXJ0cy4NCj4g DQo+IEkgYW0gcXVpdGUgc3VyZSB0aGF0IG1vc3Qgb2YgdGhvc2UgaGFwcHkgdXNlcnMgYXJlIGNv bXBsZXRlbHkgY2x1ZWxlc3MNCj4gaW4gd2hhdCB0aGV5IGFyZSBkb2luZyBhbmQganVzdCBmb2xs b3dlZCB0aGF0IG5pY2UgYXJ0aWNsZSB0aGV5IGZvdW5kIG9uDQo+IHRoZSBpbnRlcm5ldCBvciBp biB0aGF0IENvbXB1dGluZyBNYWdhemluZSBGb3IgRHVtYm8ncyBhbmQgYXJlIGhhcHBpbHkNCj4g ZG93bmxvYWRpbmcgdGhlIG5ld2VzdCBtb3ZpZXMvbXVzaWMgYW5kIG90aGVyIHdhcmV6IHRoZXkg Y2FuIGZpbmQuDQo+IFRoaXMgaXMgd2hlcmUgdGhlIGludGVybmV0IGlzIHVzZWQgZm9yIGFuZCB0 aGlzIGFscmVhZHkgd29ya3MuDQo+IA0KPj4gTXkgZmF0aGVyIG1pZ2h0IGJlIGEgZ29vZCBleGFt cGxlOiBoZSBsaWtlcyBqdXN0IHBsdWctYW5kLXBsYXkgZGV2aWNlcyBiZWNhdXNlDQo+PiBoZSBo YXMgbm8gdGVjaG5pY2FsIGtub3dsZWRnZSBhdCBhbGwsIHNvIGhlIHdvdWxkIGxpa2UganVzdCBw bHVnIGl0cyBJUHY2IGNhbWVyYSAod2l0aCB0cmFuc2l0aW9uDQo+PiBtZWNoYW5pc21zIGltcGxl bWVudGVkKSBvbiB0aGUgaG9tZSBuZXR3b3JrIChJUHY0KSBhbmQgc2VlIGl0cyBob3VzZSB3aGls ZSB0cmF2ZWxpbmcgYXJvdW5kIHRoZSB3b3JsZC4NCj4+IEhlIHdhbnRzIHRoYXQgdGhlIGNhbWVy YSBpdHNlbGYgaXMgaW4gY2hhcmdlIG9mIGFsbCB0aGUgcmVxdWlyZWQgY29uZmlndXJhdGlvbiAo VEVQIGRpc2NvdmVyeSBpbmNsdWRlZCkgdG8gd29yay4NCj4gDQo+IEhlIGlzIHF1aXRlIGxpa2Vs eSB0byBub3QgZXZlbiB3YW50IHRvIGtub3cgaG93IGl0IHdvcmtzLCBoZSB3YW50cyBpdCB0bw0K PiB3b3JrLCBidXQgd2l0aG91dCBoYXZpbmcgaGlzIG5laWdoYm9yIGFuZCB0aGF0IEJyYXppbGlh biBraWQgYW5kIHRoZQ0KPiBidXJnbGFyIHdhdGNoaW5nIGhpcyBob3VzZSBmb3IgaGltIHRvby4u LiBvciBhcmUgeW91IGdvaW5nIHRvIGV4cGxhaW4NCj4gaGltIHdoYXQgc2VjdXJpdHkgaXM/IDsp DQo+IA0KPiBOZXh0IHRvIHRoYXQsIGltcGxlbWVudG9ycyBvZiBzbWFsbCBkZXZpY2VzIGRvbid0 IGxpa2UgdG8gaW1wbGVtZW50DQo+IG11bHRpcGxlIElQIHN0YWNrcyBhbmQgcmVwbGljYXRlIHdv cmsgd2hpY2ggc2hvdWxkIGJlIGRvbmUgYnkgb3RoZXINCj4gZXF1aXBtZW50LiBOb3RlIHRoYXQg YWxsIHRoZSBjdXJyZW50IElQdjYgdG95cyBhcmUgSVB2Ni1vbmx5IGFuZCBkbyBub3QNCj4gaGF2 ZSBhbnl0aGluZyB0byBkbyB3aXRoIElQdjQuIFRoZXJlIGlzIGEgcmVhc29uIGZvciB0aGlzOiB0 aGV5IGRvbid0DQo+IHdhbnQgdG8gYmUgYm90aGVyZWQgd2l0aCBJUHY0IGluIHRoZSBmaXJzdCBw bGFjZSBhcyB0aG9zZSBkZXZpY2VzIGNvdWxkDQo+IG5vdCBjb21tdW5pY2F0ZSBnbG9iYWxseSBp biB0aGUgZmlyc3QgcGxhY2UgYW5kIHRoZXkgd2hlcmUgc2ljayBvZg0KPiBidWlsZGluZyBOQVQg d29ya2Fyb3VuZHMuDQoNCldldGhlciBpbXBsZW1lbnRvcnMgaW1wbGVtZW50IGR1YWwgc3RhY2sg b3Igbm90IGl0IGRlcGVuZHMgdGhlIHN0YXR1cyBvZiB0aGUgbmF0aXZlIElQdjYgZGVwbG95bWVu dCBhbnQgd2hlbiB0aGV5IG9mZmVyIHRoZWlyIHByb2R1Y3RzIG9uIHRoZSBtYXJrZXQuIFdoeSBh cmUgdGhleSBnb2luZyB0byB0cnkgdG8gc2FsZSBJUHY2IG9ubHkgcHJvZHVjdHMgdG8gdXNlcnMg dGhhdCBkb24ndCBoYXZlIElQdjYgb24gdGhlaXIgYWNjZXNzIG5ldHdvcmtzIGFuZCBwcm92ZW4g dGhhdCBtb3N0IHVzZXJzIGRvbid0IHVzdWFsbHkga25vdyBob3cgdG8gY29uZmlndXJlIElQdjYg dHVubmVscyBvciBJUHY2IGdhdGV3YXlzPw0KDQpJdCBpcyBwcm9iYWJseSB0aGF0IGRldmVsb3Bl cnMgaW1wbGVtZW50IGR1YWwgc3RhY2sgKGF0IGxlYXN0IG9uIHRoZSBlYXJsaWVyIHN0YWdlcykg dG8gY29wZSB3aXRoIGJvdGggbWFya2V0cyBJUHY0IGFuZCBJUHY2IChuYXRpdmUgb25lIG9yIHdp dGggdHJhbnNpdGlvbiBtZWNoYW5pc21zKS4gQXQgbGVhc3QsIGl0IHdpbGwgZGVwZW5kIG9uIHRo ZSB0eXBlIG9mIHByb2R1Y3QuDQoNClJlZ2FyZHMNCk1pZ3VlbA0KDQoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQpNYWRyaWQgMjAwMyBHbG9iYWwgSVB2NiBTdW1taXQNClByZXNl bnRhdGlvbnMgYW5kIHZpZGVvcyBvbiBsaW5lIGF0Og0KaHR0cDovL3d3dy5pcHY2LWVzLmNvbQ0K DQpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkg YmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRl ZCB0byBiZSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZS4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNj bG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0 aGlzIGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0ZWQu DQoNCg0K --===============1852920895== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1852920895==-- From v6tc-bounces@ietf.org Wed Jan 19 03:37: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 DAA21485; Wed, 19 Jan 2005 03:37:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrBbA-0003Xn-3I; Wed, 19 Jan 2005 03:53:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBFy-0004gC-Vu; Wed, 19 Jan 2005 03:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBEM-00041q-6Z for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 03:30: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 DAA21058 for ; Wed, 19 Jan 2005 03:30:20 -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 1CrBTm-0003MZ-RW for v6tc@ietf.org; Wed, 19 Jan 2005 03:46:19 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000716306.msg for ; Wed, 19 Jan 2005 09:30:38 +0100 Message-ID: <01ca01c4fe01$26ac3960$1100a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <006d01c4fdf8$94b0fbc0$1100a8c0@consulintel.es> Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? Date: Wed, 19 Jan 2005 09:30:34 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Wed, 19 Jan 2005 09:30:43 +0100 X-MDAV-Processed: consulintel.es, Wed, 19 Jan 2005 09:30:43 +0100 X-Spam-Score: 2.2 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0855909756==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 --===============0855909756== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQoNCj4gT24gVHVlLCAyMDA1LTAxLTE4IGF0IDAzOjE4IC0wODAwLCBBbGFpbiBEdXJhbmQgd3Jv dGU6DQo+PiBPbiBKYW4gMTgsIDIwMDUsIGF0IDI6MzkgQU0sIE1pZ3VlbCBBbmdlbCBEaWF6IHdy b3RlOg0KPj4gDQo+PiA+DQo+PiA+DQo+PiA+PiBPbiBKYW4gMTgsIDIwMDUsIGF0IDE6MTcgQU0s IE1pZ3VlbCBBbmdlbCBEaWF6IHdyb3RlOg0KPj4gPj4NCj4+ID4+PiBIb3cgdG8gZmluZCBvdXQg eW91ciBJU1AgZG9tYWluIG5hbWU/IEl0IGlzIHNpbXBsZSwganVzdCB0eXBlOg0KPj4gPj4+DQo+ PiA+Pj4gZGlnIHNvYSAteCAxOTUuNjQuOTIuMTM2ICtub2FsbCArYXV0aG9yaXR5DQo+PiA+Pj4N Cj4+ID4+PiBhbmQgZXh0cmFjdCB0aGUgZG9tYWluIGZyb20gdGhlIGF1dGhvcml0YXRpdmUgRE5T IHNlcnZlcg0KPj4gPj4+IChucy5jaXN0cm9uLm5sKSAgOi0pDQo+PiA+Pg0KPj4gPj4gQ2FuIHlv dSB0ZWxsIHVzIGhvdyB0aGlzIHdpbGwgd29yayBmb3IgaG9zdCBiZWhpbmQgYSBOQVQgd2hpY2gg YWRkcmVzcw0KPj4gPj4gaXMgMTkyLjE2OC4xLjI/DQo+PiA+Pg0KPj4gPg0KPj4gPiBvZiBjb3Vy c2UsIHlvdSBmaXJzdCBoYXMgdG8ga25vdyB5b3VyIHB1YmxpYyBJUHY0IGFkZHJlc3MgOy0pIEl0 IA0KPj4gPiBkb2Vzbid0IG1hdHRlciBpZiB5b3UgaGF2ZSBvbmUgb3IgbW9yZSBOQVQgbGV2ZWxz LCB0aGUgb25seSB0aGluZyBpcyANCj4+ID4gdG8gZmluZCBvdXQgeW91ciBmaW5hbCBwdWJsaWMg YWRkcmVzcy4gVGhlcmUgYXJlIHNldmVyYWwgd2F5cyB0byBkbyBpdCANCj4+ID4gYW5kIG9uZSBv ZiB0aGUgbW9zdCB1c2VkIGlzIHRoZSBTVFVOIHByb3RvY29sLCBSRkMgMzQ4OS4NCj4+IA0KPj4g SSB3YXMgZXhwZWN0aW5nIHRoaXMgYW5zd2VyLiBDYW4geW91IG5vdyB0ZWxsIGhvdyB0byBkaXNj b3ZlciB3aGljaCANCj4+IHN0dW4gc2VydmVyIHRvIHVzZT8NCj4gDQo+IFRoYXQgaXMgd2h5IEkg b2ZmZXJlZCBoaW0gdGhlIHRyYWNlcm91dGUgb3B0aW9uLCB0byBhdCBsZWFzdCBnZXQgdGhlDQo+ IElQJ3MgYW5kIHRoZW4gdGhlIHJldmVyc2VzIG9mIHRoZSBJU1AsIG5vdCB0aGF0IGl0IHdvdWxk IGJlIHJlYWxseQ0KPiB2aXNpYmxlIGFuZCBxdWl0ZSBoYXJkIHRvIGZpbmQgb3V0IHRoZW4gd2hl cmUgYSkgdG8gdHJhY2UgdG8gYW5kIGIpDQo+IHdoaWNoIGhvcCBhY3R1YWxseSBiZWxvbmdzIHRv IHRoZSBJU1AsIGJ1dCBzdGlsbCA7KQ0KPiANCg0KV2l0aCB0cmFjZXJvdXRlIGl0IHdvdWxkIGJl IGV2ZW4gYmV0dGVyIHRvIGRpc2NvdmVyIHRoZSBJUCwgYXQgbGVhc3QgYW5kIHNvbWUgc2NuZXJp b3MNCg0KDQo+IEFsc28gbWlndWVsLCB5b3UgcmVhbGx5IHRoaW5rIHRoYXQgSSBkaWQgbm90IGhh dmUgYSBzcGVjaWFsIHJldmVyc2Ugb24NCj4gbXkgYm94PyBBdCBsZWFzdCBpbnRlcm5hbGx5IDE5 NS42NC45Mi4xMzYgaXMgYWxzbyBuaWNlbHkga25vd24gYXMNCj4gcHVyZ2F0b3J5LnVuZml4Lm9y ZyBhbmQgdGh1cyB0aGUgU09BIGlzIGFsc28gaW5zaWRlIHVuZml4Lm9yZywgdGhlIE5TDQo+IHJl Y29yZHMgYXJlIGF0IHB1cmdhdG9yeS51bmZpeC5vcmcgYW5kIG5zMS9uczIubWVkaWFkZXNpZ24u bmwuIERvZXMgdGhpcw0KPiBsZWFkIHlvdSB0byBjaXN0cm9uLm5sPw0KDQpTbyB0aGF0J3Mgb25l IGNhc2Ugd2hlcmUgdHJhY2VydG91ZSBtaWdodCBiZSBtb3JlIHVzZWZ1bGwgYmVjYXVzZSBpdCB3 b3VsZCBiZSB1c2VkIHRoZSBJUCBvZiB5b3VyIElTUCBkZWZhdWx0IGdhdGV3YXkgcmF0aGVyIHRo YW4geW91ciBvdXduIHB1YmxpYyBJUA0KDQoNCj4gDQo+IEkgYWxzbyBoYXZlIHRvIG5vdGUgdGhh dDoNCj4gLSBtYW55IElTUCdzIGRvbid0IGRvIHJldmVyc2UgYXQgYWxsDQoNClRoZSBtb3N0IG9m IElQIHRlc3RzIHdlJ3ZlIG1hZGUgc2hvd24gdGhlIG9wb3NpdGUuIEkgZ3Vlc3MgdGhhdCB0aGUg bW9zdCBvZiBJU1AgZG8gaXQuIEFueXdheSwgd2l0aCBkaXNjb3ZlcnkgYmFzZWQgb24gRE5TLCBJ U1Agd2lsbCBiZSBhZHZpY2VkIHRoYXQgcmV2ZXJzZSBpcyBhIG11c3QuDQoNCj4gLSB0aGUgSVNQ J3MgdGhhdCB1c3VhbGx5IGRvIG5vdCB1c2UgdGhlIHNhbWUgZG9tYWluIG5hbWUgYXMgdGhleQ0K PiAgIHVzZSBmb3IgdGhlaXIgc2VydmljZXMuDQoNCkFnYWluLCBJU1Agd2lsbCBiZSBhZHZpY2Vk IHRoYXQgdGhlIGRvbWFpbiB1c2VkIGZvciBkaXNjb3ZlcmluZyBzaG91bGQgYmUgdGhlIHNhbWUg dGhhdCB0aGUgb25lIHVzZW4gb24gcmV2ZXJzZQ0KDQo+IC0gY3VzdG9tIHJldmVyc2VzIGV4aXN0 IHRvby4NCg0KU28sIHRyeWluZyByZXZlcnNlIHdpdGggdGhlIGZpcnN0IGhvcCBvZiB0aGUgY3Vz dG9tZXIncyBuZXR3b3JrLCB0aGF0IGlzIHRoZSBJU1AgZ2F0ZXdheQ0Kd2lsbCBzb2x2ZSBpdC4N Cg0KUmVnYXJkcw0KTWlndWVsDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Ck1hZHJpZCAyMDAzIEdsb2JhbCBJUHY2IFN1bW1pdA0KUHJlc2VudGF0aW9ucyBhbmQgdmlkZW9z IG9uIGxpbmUgYXQ6DQpodHRwOi8vd3d3LmlwdjYtZXMuY29tDQoNClRoaXMgZWxlY3Ryb25pYyBt ZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNv bmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRp c3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGlu Y2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgcHJvaGliaXRlZC4NCg0KDQp= --===============0855909756== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============0855909756==-- From v6tc-bounces@ietf.org Wed Jan 19 03:38:29 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 DAA21514; Wed, 19 Jan 2005 03:38:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrBbf-0003YS-Ro; Wed, 19 Jan 2005 03:54:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBG0-0004gi-LO; Wed, 19 Jan 2005 03:32:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBES-00042S-UN for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 03:30: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 DAA21061 for ; Wed, 19 Jan 2005 03:30:27 -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 1CrBTt-0003Mb-La for v6tc@ietf.org; Wed, 19 Jan 2005 03:46:26 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000716311.msg for ; Wed, 19 Jan 2005 09:30:44 +0100 Message-ID: <01cb01c4fe01$28c97410$1100a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <00a801c4fdf8$c4921040$1100a8c0@consulintel.es> Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? Date: Wed, 19 Jan 2005 09:30:38 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Wed, 19 Jan 2005 09:30:50 +0100 X-MDAV-Processed: consulintel.es, Wed, 19 Jan 2005 09:30:50 +0100 X-Spam-Score: 2.2 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1894962521==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 --===============1894962521== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 PiBPbiBUdWUsIDIwMDUtMDEtMTggYXQgMDQ6MjEgLTA4MDAsIEFsYWluIER1cmFuZCB3cm90ZToN Cj4+IE9uIEphbiAxOCwgMjAwNSwgYXQgMzozNyBBTSwgTWlndWVsIEFuZ2VsIERpYXogd3JvdGU6 DQo+PiA+Pj4gb2YgY291cnNlLCB5b3UgZmlyc3QgaGFzIHRvIGtub3cgeW91ciBwdWJsaWMgSVB2 NCBhZGRyZXNzIDstKSBJdA0KPj4gPj4+IGRvZXNuJ3QgbWF0dGVyIGlmIHlvdSBoYXZlIG9uZSBv ciBtb3JlIE5BVCBsZXZlbHMsIHRoZSBvbmx5IHRoaW5nIGlzDQo+PiA+Pj4gdG8gZmluZCBvdXQg eW91ciBmaW5hbCBwdWJsaWMgYWRkcmVzcy4gVGhlcmUgYXJlIHNldmVyYWwgd2F5cyB0byBkbyAN Cj4+ID4+PiBpdA0KPj4gPj4+IGFuZCBvbmUgb2YgdGhlIG1vc3QgdXNlZCBpcyB0aGUgU1RVTiBw cm90b2NvbCwgUkZDIDM0ODkuDQo+PiA+Pg0KPj4gPj4gSSB3YXMgZXhwZWN0aW5nIHRoaXMgYW5z d2VyLiBDYW4geW91IG5vdyB0ZWxsIGhvdyB0byBkaXNjb3ZlciB3aGljaA0KPj4gPj4gc3R1biBz ZXJ2ZXIgdG8gdXNlPw0KPj4gPj4NCj4+ID4NCj4+ID4gSSBzZWUgd2hlcmUgeW91IHdhbnQgdG8g YXJyaXZlOiB0aGUgc3R1biBzZXJ2ZXIgZGlzY292ZXJ5IGlzIGFuIGlzc3VlIA0KPj4gPiBpdHNl bGYsIGJ1dCBjdXJyZW50bHkgdGhlcmUgYXJlIHNldmVyYWwgcHVibGljIHN0dW4gc2VydmVycyBk ZXBsb3llZCANCj4+ID4gYWxsIG92ZXIgdGhlIHdvcmxkIGFuZCB0aGV5IGFyZSBhdmFpbGFibGUg Zm9yIGZyZWUgdG8gYWxsIHRoZSB1c2Vycy4gDQo+PiA+IEp1c3Qgc29tZSBvZiB0aGVtOg0KPj4g Pg0KPj4gPiBzdHVuMDEuc2lwcGhvbmUuY29tLA0KPj4gPiBzdHVuLnZveGdyYXRpYS5vcmcsDQo+ PiA+IHN0dW4xLnZvdmlkYS5vcmcsDQo+PiA+IHN0dW4uZndkbmV0Lm5ldCwNCj4+ID4gc3R1bi5p bnRlcnZpdm8ubmV0DQo+PiA+DQo+PiA+IFdoeSBkb24ndCB1c2UgdGhlbT8NCj4+IA0KPj4gU2lt cGx5IGJlY2F1c2UgaGFyZGNvZGluZyBuYW1lcyBsaWtlIHRoYXQgaW4gaW1wbGVtZW50YXRpb25z IHRoYXQgbmVlZCANCj4+IHRvIGJlDQo+PiBtYWludGFpbmVkIGZvciAxMC0yMCB5ZWFycyBpcyBh IGJhZCB0aGluZy4NCj4gDQo+IE5vdCBldmVuIG1lbnRpb25pbmcgdGhlIGFidXNlIG9mIHJlc291 cmNlcyBwcm92aWRlZCBieSBvdGhlcnMuDQo+IA0KPiBBbmQgd2hhdCBpcyB0aGUgdXNlIG9mIHVz aW5nIGEgU1RVTiBpbiB0aGUgZmlyc3QgcGxhY2UsIGlmIGl0IGNhbm5vdCBiZQ0KPiByZWFjaGVk IHlvdSBhcmUgZGVhZCBpbiB0aGUgd2F0ZXIuDQoNCldpdGggcGluZ3Mgb3IgdHJhY2Vyb3V0ZXMg dGhlIFNUVU4gcHJvdG9jb2wgY291bGQgYmUgYXZvaWRlZC4gRXZlbiBiZXR0ZXIsIHRyeWluZyB0 byByZXZlcnNlIHRoZSBJUCBvZiB0aGUgSVNQIGdhdGV3YXkgKGZpcnN0IGhvcCBmcm9tIHRoZSBj dXN0b21lcidzIG5ldHdvcmspIHdvdWxkIGJlIGEgbmljZSBzb2x1dGlvbiB0byBkaXNjb3ZlciB0 aGUgSVNQJ3MgZG9tYWluIG5hbWUuDQoNClJlZ2FyZHMNCk1pZ3VlbA0KDQoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQpNYWRyaWQgMjAwMyBHbG9iYWwgSVB2NiBTdW1taXQNClBy ZXNlbnRhdGlvbnMgYW5kIHZpZGVvcyBvbiBsaW5lIGF0Og0KaHR0cDovL3d3dy5pcHY2LWVzLmNv bQ0KDQpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBt YXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRl bmRlZCB0byBiZSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZS4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBk aXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBv ZiB0aGlzIGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0 ZWQuDQoNCg0K --===============1894962521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1894962521==-- From v6tc-bounces@ietf.org Wed Jan 19 03:41: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 DAA21803; Wed, 19 Jan 2005 03:41:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrBeV-0003dA-O9; Wed, 19 Jan 2005 03:57:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBNj-0006aQ-BN; Wed, 19 Jan 2005 03:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBMX-0006C1-D9 for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 03:38: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 DAA21553 for ; Wed, 19 Jan 2005 03:38:47 -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 1CrBbx-0003YD-M6 for v6tc@ietf.org; Wed, 19 Jan 2005 03:54:46 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000716344.msg for ; Wed, 19 Jan 2005 09:39:04 +0100 Message-ID: <021301c4fe02$52027920$1100a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> <008e01c4fd52$1b678050$a100000a@consulintel.es> <7D435C3F-694B-11D9-9E6D-00039358A080@sun.com> Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? Date: Wed, 19 Jan 2005 09:38:56 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Wed, 19 Jan 2005 09:39:10 +0100 X-MDAV-Processed: consulintel.es, Wed, 19 Jan 2005 09:39:10 +0100 X-Spam-Score: 2.2 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1749845341==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca --===============1749845341== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQo+IA0KPiBPbiBKYW4gMTgsIDIwMDUsIGF0IDM6MzcgQU0sIE1pZ3VlbCBBbmdlbCBEaWF6IHdy b3RlOg0KPj4+PiBvZiBjb3Vyc2UsIHlvdSBmaXJzdCBoYXMgdG8ga25vdyB5b3VyIHB1YmxpYyBJ UHY0IGFkZHJlc3MgOy0pIEl0DQo+Pj4+IGRvZXNuJ3QgbWF0dGVyIGlmIHlvdSBoYXZlIG9uZSBv ciBtb3JlIE5BVCBsZXZlbHMsIHRoZSBvbmx5IHRoaW5nIGlzDQo+Pj4+IHRvIGZpbmQgb3V0IHlv dXIgZmluYWwgcHVibGljIGFkZHJlc3MuIFRoZXJlIGFyZSBzZXZlcmFsIHdheXMgdG8gZG8gDQo+ Pj4+IGl0DQo+Pj4+IGFuZCBvbmUgb2YgdGhlIG1vc3QgdXNlZCBpcyB0aGUgU1RVTiBwcm90b2Nv bCwgUkZDIDM0ODkuDQo+Pj4NCj4+PiBJIHdhcyBleHBlY3RpbmcgdGhpcyBhbnN3ZXIuIENhbiB5 b3Ugbm93IHRlbGwgaG93IHRvIGRpc2NvdmVyIHdoaWNoDQo+Pj4gc3R1biBzZXJ2ZXIgdG8gdXNl Pw0KPj4+DQo+Pg0KPj4gSSBzZWUgd2hlcmUgeW91IHdhbnQgdG8gYXJyaXZlOiB0aGUgc3R1biBz ZXJ2ZXIgZGlzY292ZXJ5IGlzIGFuIGlzc3VlIA0KPj4gaXRzZWxmLCBidXQgY3VycmVudGx5IHRo ZXJlIGFyZSBzZXZlcmFsIHB1YmxpYyBzdHVuIHNlcnZlcnMgZGVwbG95ZWQgDQo+PiBhbGwgb3Zl ciB0aGUgd29ybGQgYW5kIHRoZXkgYXJlIGF2YWlsYWJsZSBmb3IgZnJlZSB0byBhbGwgdGhlIHVz ZXJzLiANCj4+IEp1c3Qgc29tZSBvZiB0aGVtOg0KPj4NCj4+IHN0dW4wMS5zaXBwaG9uZS5jb20s DQo+PiBzdHVuLnZveGdyYXRpYS5vcmcsDQo+PiBzdHVuMS52b3ZpZGEub3JnLA0KPj4gc3R1bi5m d2RuZXQubmV0LA0KPj4gc3R1bi5pbnRlcnZpdm8ubmV0DQo+Pg0KPj4gV2h5IGRvbid0IHVzZSB0 aGVtPw0KPiANCj4gU2ltcGx5IGJlY2F1c2UgaGFyZGNvZGluZyBuYW1lcyBsaWtlIHRoYXQgaW4g aW1wbGVtZW50YXRpb25zIHRoYXQgbmVlZCANCj4gdG8gYmUNCj4gbWFpbnRhaW5lZCBmb3IgMTAt MjAgeWVhcnMgaXMgYSBiYWQgdGhpbmcuDQo+IA0KDQpTbyB0aGUgYXBwcm9hY2ggdGhhdCBKZXJv ZW4gbWVudGlvbmVkIGFib3V0IHVzaW5nIHRyYWNlcm91dGUgb3IgcGluZyB3b3VsZCBiZSBhbiBh bHRlcm5hdGl2ZS4gRnVydGhlcm1vcmUsIGJ5IHVzaW5nIHRoZSBJUCBvZiB0aGUgY3VzdG9tZXIn cyBkZWZhdWx0IGdhdGV3YXkgd291bGQgYmUgZXZlbiBiZXR0ZXIgYmVjYXVzZSBpdCBwcmV2ZW50 IHRoZSByZXZlcnNlIGRvbmUgYnkgc29tZSBjdXN0b21lcnMuDQoNClJlZ2FyZHMNCk1pZ3VlbA0K DQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KTWFkcmlkIDIwMDMgR2xv YmFsIElQdjYgU3VtbWl0DQpQcmVzZW50YXRpb25zIGFuZCB2aWRlb3Mgb24gbGluZSBhdDoNCmh0 dHA6Ly93d3cuaXB2Ni1lcy5jb20NCg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMg aW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUg aW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg YmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVz ZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVk IGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KDQoNCm== --===============1749845341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1749845341==-- From v6tc-bounces@ietf.org Wed Jan 19 03:55:17 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 DAA22556; Wed, 19 Jan 2005 03:55:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrBrv-00046D-Rh; Wed, 19 Jan 2005 04:11:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBbg-0000ue-1H; Wed, 19 Jan 2005 03:54:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBaR-0000aB-CS for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 03:53:11 -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 DAA22480 for ; Wed, 19 Jan 2005 03:53:09 -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 1CrBps-00042o-CI for v6tc@ietf.org; Wed, 19 Jan 2005 04:09:08 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000716437.msg for ; Wed, 19 Jan 2005 09:53:25 +0100 Message-ID: <022c01c4fe04$532192d0$1100a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <00bd01c4fdf8$d4292700$1100a8c0@consulintel.es> Subject: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automaticor manual? Date: Wed, 19 Jan 2005 09:53:18 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Wed, 19 Jan 2005 09:53:30 +0100 X-MDAV-Processed: consulintel.es, Wed, 19 Jan 2005 09:53:32 +0100 X-Spam-Score: 2.2 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0778637600==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca --===============0778637600== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQoNCj4gT24gVHVlLCAyMDA1LTAxLTE4IGF0IDA1OjUyIC0wODAwLCBBbGFpbiBEdXJhbmQgd3Jv dGU6DQo+PiBPbiBKYW4gMTgsIDIwMDUsIGF0IDQ6MjUgQU0sIFBla2thIFNhdm9sYSB3cm90ZToN Cj4+ID4gV2hhdCBzZWVtcyBsZWZ0IG9uIHRoZSB0YWJsZSBmcm9tIHRoZSBnZW5lcmljIHNvbHV0 aW9ucyBpcyBhbiBJUHY0IA0KPj4gPiBhbnljYXN0IGFkZHJlc3MuICBJdCBoYXMgc29tZSBwcm9i bGVtcywgYnV0IG1heWJlIHRoZXNlIHByb2JsZW1zIGFyZSANCj4+ID4gc21hbGxlciB0aGFuIHdp dGggb3RoZXJzLg0KPj4gDQo+PiBJIHRoaW5rIHRoZSBkaXNjdXNzaW9uIGZyb20gdGhlIGxhc3Qg ZmV3IGRheXMgaGFzIHNob3duIGZldyB0aGluZ3M6DQo+PiANCj4+IGEpIEROUyBiYXNlZCBzb2x1 dGlvbnMgKGZvcndhcmQgb3IgcmV2ZXJzZSkgZG8gbm90IHdvcmsgaW4gYWxsIA0KPj4gc2l0dWF0 aW9ucyBhbmQgaW4gcGFydGljdWxhciBkbyBub3Qgd29yayB3ZWxsIGluIHRoZSBjYXNlIHdoZXJl IGEgTkFUIGJveCBpcyANCj4+IHByZXNlbnQsIHdoaWNoIHNlZW1zIHRvIGJlIGEgc2hvdyBzdG9w cGVyLg0KDQpJIGRpc2FncmVlIHBhcnRpYWxseSB3aXRoIHRoYXQgYXNzZXJ0aW9uIGJlY2F1c2Ug YnkgdXNpbmcgcmV2ZXJzZStmb3J3YXJkIEROUyB3aXRoIGVpdGhlciB0aGUgcHVibGljIElQIG9m IHRoZSBjdXN0b21lciBvciB0aGUgY3VzdG9tZXIncyBkZWZhdWx0IGdhdGV3YXkgd291bGQgd29y ayBpbiB0aGUgbW9zdCBjYXNlcy4gT25seSB0d28gY29uZGl0aW9ucyBhcmUgbmVlZGVkOg0KDQot IElTUCBjb25maWd1cmVzIHByb3Blcmx5IHRoZSByZXZlcnNlIEROUw0KLSBJU1AgY29uZmlndXJl cyBwcm9wZXJseSB0aGUgRE5TIHNlcnZlciB0byBiZSBpbmNsdWRlZCBvbiB0aGUgcmV2ZXJzZSBk b21haW4gdGhlIG5hbWVzIGZvciB0aGUgZGlzY292ZXJ5IHNlcnZpY2VzLg0KDQpXaGl0IHRoaXMg YXNzdW1wdGlvbnMgZXZlbiB3aXRoIGxvY2FsIEROUyBzZXJ2ZXIgb24gdGhlIGN1c3RvbWVyIG5l dHdvcmssIHRoZSBkaXNjb3ZlcnkgYmFzZWQgb24gRE5TIHdpbGwgd29yay4NCg0KSG93IHRvIGZp bmQgb3V0IHRoZSBwdWJsaWMgSVAgaXMgbm90IHNvIGhhcmQgYXMgaXQgaGFzIHBvaW50ZWQgYmVm b3JlLiBTVFVOIGlzIG9ubHkgYW4gYWx0ZXJuYXRpdmUsIGJ1dCB0aGVyZSBpcyBvdGhlciBvbmVz IGV2ZW4gbXVjaCBiZXR0ZXIuDQoNClJlZ2FyZHMNCk1pZ3VlbA0KDQoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQpNYWRyaWQgMjAwMyBHbG9iYWwgSVB2NiBTdW1taXQNClByZXNl bnRhdGlvbnMgYW5kIHZpZGVvcyBvbiBsaW5lIGF0Og0KaHR0cDovL3d3dy5pcHY2LWVzLmNvbQ0K DQpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkg YmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRl ZCB0byBiZSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZS4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNj bG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0 aGlzIGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0ZWQu DQoNCg0K --===============0778637600== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============0778637600==-- From v6tc-bounces@ietf.org Wed Jan 19 04:04:10 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 EAA22999; Wed, 19 Jan 2005 04:04:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrC0X-0004HI-4Z; Wed, 19 Jan 2005 04:20:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBk0-0003ud-Vi; Wed, 19 Jan 2005 04:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBis-0003Hy-0R for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 04:01:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22853 for ; Wed, 19 Jan 2005 04:01:52 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrByH-0004ED-Ma for v6tc@ietf.org; Wed, 19 Jan 2005 04:17:51 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 07690C2247; Wed, 19 Jan 2005 10:01:47 +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 06738-05; Wed, 19 Jan 2005 10:01:46 +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 C093189D3E; Wed, 19 Jan 2005 10:01:43 +0100 (CET) Subject: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automaticor manual? From: Jeroen Massar To: miguelangel.diaz@consulintel.es In-Reply-To: <022c01c4fe04$532192d0$1100a8c0@consulintel.es> References: <00bd01c4fdf8$d4292700$1100a8c0@consulintel.es> <022c01c4fe04$532192d0$1100a8c0@consulintel.es> Organization: Unfix Date: Wed, 19 Jan 2005 10:01:11 +0100 Message-Id: <1106125271.18807.46.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0365810367==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --===============0365810367== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CDJMjU/88azyrkbZcS/4" --=-CDJMjU/88azyrkbZcS/4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-01-19 at 09:53 +0100, Miguel Angel Diaz wrote: >=20 > > On Tue, 2005-01-18 at 05:52 -0800, Alain Durand wrote: > >> On Jan 18, 2005, at 4:25 AM, Pekka Savola wrote: > >> > What seems left on the table from the generic solutions is an IPv4=20 > >> > anycast address. It has some problems, but maybe these problems are= =20 > >> > smaller than with others. > >>=20 > >> I think the discussion from the last few days has shown few things: > >>=20 > >> a) DNS based solutions (forward or reverse) do not work in all=20 > >> situations and in particular do not work well in the case where a NAT = box is=20 > >> present, which seems to be a show stopper. >=20 > I disagree partially with that assertion because by using reverse+forward= DNS > with either the public IP of the customer or the customer's default gatew= ay > would work in the most cases. Only two conditions are needed: >=20 > - ISP configures properly the reverse DNS > - ISP configures properly the DNS server to be included on the reverse do= main the names for the discovery services. ISP's should also configure ingress filtering, should also provide native IPv6, should not have open mail relays.... many other things that will not happen. Don't assume that they will magically appear for this all of a sudden. > Whit this assumptions even with local DNS server on the customer network,= the discovery based on DNS will work. With these assumptions it will work in only a few cases and not for most cases and thus it is completely useless for most people. The target was most people, not only a few. > How to find out the public IP is not so hard as it has pointed before. > STUN is only an alternative, but there is other ones even much better. And the 'better ones' are? Using http://www.whatismyip.com/ ? :) Greets, Jeroen --=-CDJMjU/88azyrkbZcS/4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB7iHXKaooUjM+fCMRAmIzAJ9grOBnZdZqZ/QcuYx1O3Ou/Vny4wCfWfKO BFXbiD0T5f5zVIykIFrI7p0= =ZZcS -----END PGP SIGNATURE----- --=-CDJMjU/88azyrkbZcS/4-- --===============0365810367== 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 --===============0365810367==-- From v6tc-bounces@ietf.org Wed Jan 19 04:06:10 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 EAA23100; Wed, 19 Jan 2005 04:06:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrC2S-0004Ja-CV; Wed, 19 Jan 2005 04:22:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBm5-00058X-9y; Wed, 19 Jan 2005 04:05:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBkw-0004cN-1c for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 04:04:02 -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 EAA22992 for ; Wed, 19 Jan 2005 04:04:00 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrC0N-0004Gv-3d for v6tc@ietf.org; Wed, 19 Jan 2005 04:19:59 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 826A4C2247; Wed, 19 Jan 2005 10:04:00 +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 06738-06; Wed, 19 Jan 2005 10:03:58 +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 3356B89D3E; Wed, 19 Jan 2005 10:03:38 +0100 (CET) Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery:automaticormanual? From: Jeroen Massar To: miguelangel.diaz@consulintel.es In-Reply-To: <01c901c4fe01$20892de0$1100a8c0@consulintel.es> References: <004601c4fdf8$65804b80$1100a8c0@consulintel.es> <01c901c4fe01$20892de0$1100a8c0@consulintel.es> Organization: Unfix Date: Wed, 19 Jan 2005 10:03:37 +0100 Message-Id: <1106125417.18807.50.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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="===============1509585581==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 --===============1509585581== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rHp1I+nNpkUJ2y77GCRX" --=-rHp1I+nNpkUJ2y77GCRX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-01-19 at 09:30 +0100, Miguel Angel Diaz wrote: > > On Tue, 2005-01-18 at 10:14 +0100, Miguel Angel Diaz wrote: > > Any real argument why these millions of users can't use Teredo accordin= g > > to you? > >=20 >=20 > I mean that currently only a few Teredo servers are deployed over the wor= ld, > being the most known the ones deployed by Microsoft which are the default > ones on Widows XP. It doesn't seem to be likely that only a few them can > manage thousands of connections cuncurrently. Isn't that a very logical conclusion which can be solved by doing what Microsoft is mentioning: deploy Teredo servers. And isn't this exactly what one has to do with every other solution? > Security is an issue not only with small devices on the network but also = on operating > systems running on the computers and I guess it doesn't depend on the dis= covery > mecanism used to get IPv6 connected :) But it is much easier to configure a firewall once than to configure your: - refrigerator - dish washer - washing machine - every lightbulb - dvd player - stereo equipment - house doors - jacuzzi - the list goes on... and thus everything separately, maybe turning the IPv6 knob on or off. Remember most people can't even program their VCR, you really expect them to figure out what IP is ? So simply keeping those components from there keeps people from having to configure it and thus forget it. Or do you like jacuzzi at 500 degrees?... Also which device are you more likely to check up on? The PC/router or the jacuzzi's internet connectivity? Keeping it central saves a lot of problems. There are a lot of people already having a lot of fun with Bluetooth for the same reasons, I don't like to see IPv6 getting the "insecure protocol" label slapped on. > > Next to that, implementors of small devices don't like to implement > > multiple IP stacks and replicate work which should be done by other > > equipment. Note that all the current IPv6 toys are IPv6-only and do not > > have anything to do with IPv4. There is a reason for this: they don't > > want to be bothered with IPv4 in the first place as those devices could > > not communicate globally in the first place and they where sick of > > building NAT workarounds. >=20 > Wether implementors implement dual stack or not it depends the status of > the native IPv6 deployment ant when they offer their products on the mark= et. > Why are they going to try to sale IPv6 only products to users that don't = have > IPv6 on their access networks and proven that most users don't usually kn= ow > how to configure IPv6 tunnels or IPv6 gateways? If somebody buys a "IPv6 Only Camera" they will make sure that they also get the connectivity for it if they want to have it connected to the global internet in the first place. XP + Teredo will automatically configure it for you, thus why bother with the fridge? (which would create multiple different prefixes, multiple security holes,...) Greets, Jeroen --=-rHp1I+nNpkUJ2y77GCRX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB7iJpKaooUjM+fCMRAmBjAJ41o/TXUoLk7XDSEeG1o3E/YTjC5ACcD8SO +1R4Tfov/UscVWE7I3tlYwA= =dNWc -----END PGP SIGNATURE----- --=-rHp1I+nNpkUJ2y77GCRX-- --===============1509585581== 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 --===============1509585581==-- From v6tc-bounces@ietf.org Wed Jan 19 04:07:29 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 EAA23136; Wed, 19 Jan 2005 04:07:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrC3j-0004LA-DY; Wed, 19 Jan 2005 04:23:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBmr-0005We-1m; Wed, 19 Jan 2005 04:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrBlu-00050a-MZ for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 04:05:02 -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 EAA23056 for ; Wed, 19 Jan 2005 04:05:01 -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 1CrC1L-0004Hd-Rq for v6tc@ietf.org; Wed, 19 Jan 2005 04:21:00 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000716496.msg for ; Wed, 19 Jan 2005 10:05:22 +0100 Message-ID: <031501c4fe06$007ae750$1100a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <00bd01c4fdf8$d4292700$1100a8c0@consulintel.es> Subject: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automaticor manual? Date: Wed, 19 Jan 2005 10:05:17 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Wed, 19 Jan 2005 10:05:24 +0100 X-MDAV-Processed: consulintel.es, Wed, 19 Jan 2005 10:05:24 +0100 X-Spam-Score: 2.2 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0359944257==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --===============0359944257== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpbLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi5dDQoNCj4+IGMpIEFueWNh c3QgYmFzZWQgc29sdXRpb24gYXJlIHdvcmthYmxlIGluIHRoZW9yeSBidXQgdGhlcmUgYXJlIA0K Pj4gb3BlcmF0aW9uYWwgY29uY2VybnMuDQo+PiBNb3JlIGZlZWRiYWNrIGZyb20gdGhlIElTUCBj b21tdW5pdHkgYW5kIHRoZSByZXN0IG9mIHRoZSBJRVRGIGlzIA0KPj4gbmVjZXNzYXJ5LiBJdCBt YXkgYmUgdGhlIGNhc2UgdGhhdCB0aGlzIHNob3VsZCBiZSB0aGUgZm9jdXMgb2YgYSBkZWRpY2F0 ZWQgd2cuDQo+IA0KDQpFdmVuIGFsdGhvdXRoIGFueWNhc3QgYmFzZWQgc29sdXRpb24gaXMgd29y a2FibGUgaW4gdGhlb3J5LCBvbmUgb25seSBhbnljYXN0IHByZWZpeCB0byBiZSB1c2VkIGJ5IGFs bCB0aGUga2luZCBvZiBURVBzICg2dG80LCB0ZXJlZG8sIGF5aXlhLCBldGMuKSB3aWxsIHJlcXVp cmUgYSBoYW5kc2hha2UgdG8ga25vdy9pbmZvcm0gdGhlIHJlcXVpcmVkIFRFUCwgd2hpY2ggZm9y Y2VzIElTUHMgdG8gd2FzdGUgbW9yZSByZXNvdXJjZXMgb24gdGhlIGRlcGxveW1lbnQuIFNhbWUg Zm9yIGltcGxlbWVudG9ycy4NCg0KUmVnYXJkcw0KTWlndWVsDQoNCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCk1hZHJpZCAyMDAzIEdsb2JhbCBJUHY2IFN1bW1pdA0KUHJlc2Vu dGF0aW9ucyBhbmQgdmlkZW9zIG9uIGxpbmUgYXQ6DQpodHRwOi8vd3d3LmlwdjYtZXMuY29tDQoN ClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBi ZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVk IHRvIGJlIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Ns b3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRo aXMgaW5mb3JtYXRpb24sIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgcHJvaGliaXRlZC4N Cg0KDQo= --===============0359944257== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============0359944257==-- From v6tc-bounces@ietf.org Wed Jan 19 04:25:07 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 EAA23848; Wed, 19 Jan 2005 04:25:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrCKo-0004ev-P8; Wed, 19 Jan 2005 04:41:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrC4c-0001TR-KV; Wed, 19 Jan 2005 04:24:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrC3H-0001FJ-G1 for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 04:22:59 -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 EAA23759 for ; Wed, 19 Jan 2005 04:22:57 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrCIi-0004br-Iy for v6tc@ietf.org; Wed, 19 Jan 2005 04:38:57 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id EEA33180907; Wed, 19 Jan 2005 10:22:57 +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 07659-03; Wed, 19 Jan 2005 10:22:57 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id 6135324044; Wed, 19 Jan 2005 10:22:57 +0100 (CET) Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: miguelangel.diaz@consulintel.es In-Reply-To: <01cb01c4fe01$28c97410$1100a8c0@consulintel.es> References: <00a801c4fdf8$c4921040$1100a8c0@consulintel.es> <01cb01c4fe01$28c97410$1100a8c0@consulintel.es> Organization: Unfix Date: Wed, 19 Jan 2005 10:22:56 +0100 Message-Id: <1106126576.18807.71.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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="===============1777528091==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 --===============1777528091== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QQLMOZ/7Mh2/TDkA51Sn" --=-QQLMOZ/7Mh2/TDkA51Sn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable [aggregating mails and please fix your mailer as you are misquoting people and that becomes a huge mess] On Wed, 2005-01-19 at 09:30 +0100, Miguel Angel Diaz wrote: > > On Tue, 2005-01-18 at 04:21 -0800, Alain Durand wrote: > >> On Jan 18, 2005, at 3:37 AM, Miguel Angel Diaz wrote: > >> > stun01.sipphone.com, > >> > stun.voxgratia.org, > >> > stun1.vovida.org, > >> > stun.fwdnet.net, > >> > stun.intervivo.net > >> > > >> > Why don't use them? > >>=20 > >> Simply because hardcoding names like that in implementations that need= =20 > >> to be > >> maintained for 10-20 years is a bad thing. > > Not even mentioning the abuse of resources provided by others. > >=20 > > And what is the use of using a STUN in the first place, if it cannot be > > reached you are dead in the water. >=20 > With pings or traceroutes the STUN protocol could be avoided. Even better= , > trying to reverse the IP of the ISP gateway (first hop from the customer'= s network) > would be a nice solution to discover the ISP's domain name. I can't even traceroute from most places because ICMP is blocked. And who says that the first hop from the current IP is the ISP's network? You might want to try full automated whois queries and how much intelligence are you wanting to put into it ? On Wed, 2005-01-19 at 09:30 +0100, Miguel Angel Diaz wrote:=20 > > On Tue, 2005-01-18 at 03:18 -0800, Alain Durand wrote: > >> On Jan 18, 2005, at 2:39 AM, Miguel Angel Diaz wrote: > >> >> On Jan 18, 2005, at 1:17 AM, Miguel Angel Diaz wrote: < this section was actually from me....> > > That is why I offered him the traceroute option, to at least get the > > IP's and then the reverses of the ISP, not that it would be really > > visible and quite hard to find out then where a) to trace to and b) > > which hop actually belongs to the ISP, but still ;) > >=20 >=20 > With traceroute it would be even better to discover the IP, at least and = some scnerios In *some* but not *all* or even *most*. > > Also miguel, you really think that I did not have a special reverse on > > my box? At least internally 195.64.92.136 is also nicely known as > > purgatory.unfix.org and thus the SOA is also inside unfix.org, the NS > > records are at purgatory.unfix.org and ns1/ns2.mediadesign.nl. Does thi= s > > lead you to cistron.nl? >=20 > So that's one case where tracertoue might be more usefull because it woul= d be > used the IP of your ISP default gateway rather than your ouwn public IP As mentioned before which of the zillion options are you going to try and h= ow sure are you that the option you pick is the best? And as my network actually consists out of: [laptop with XP] <---> [wireless router] <--> [dsl] <--> [dslam] <--> [ix/t= ransit] You would fail _again_. Oh and this is a common, not even "power user" scenario used by many with PPTP or PPPOE DSL connections. > >=20 > > I also have to note that: > > - many ISP's don't do reverse at all >=20 > The most of IP tests we've made shown the oposite. I guess that the most > of ISP do it. Anyway, with discovery based on DNS, ISP will be adviced th= at reverse is a must. "most IP tests", in which region? How much percentage of the IP space did y= ou 'test'? Reverse has been a "MUST", just like ingress filtering for over more than a= decade, but is it there yet? > > - the ISP's that usually do not use the same domain name as they > > use for their services. >=20 > Again, ISP will be adviced that the domain used for discovering should > be the same that the one usen on reverse You can write a document, but that does not mean people adhere to it. > > - custom reverses exist too. >=20 > So, trying reverse with the first hop of the customer's network, that is = the ISP gateway > will solve it. And again, how do you know what is the first hop or not? You do not know this. You can guess and in some cases you might be right but in most you will not. Also, ever heared of ICMP/UDP filtering? Then you will not be able to traceroute at all. And from a third mail: > Miguel Angel Diaz wrote: > > Alain Durand wrote: > > c) Anycast based solution are workable in theory but there are=20 > > operational concerns. > > More feedback from the ISP community and the rest of the IETF is=20 > > necessary. It may be the case that this should be the focus of a dedica= ted wg. > >=20 >=20 > Even althouth anycast based solution is workable in theory, one only anyc= ast prefix > to be used by all the kind of TEPs (6to4, teredo, ayiya, etc.) will requi= re a handshake > to know/inform the required TEP, which forces ISPs to waste more resource= s on the deployment. > Same for implementors. Very easy solution that is <1 hour work for most implementors: Setup a DNS server on 2001:db8::53 or 192.0.2.53. This DNS server has a DNS zone: .service containing eg: _teredo._udp.service. CNAME teredo.example.com. _6to4._proto41.service. A 192.88.99.1 Works over UDP, no 'handshakes' nothing... Now what was the problem again? And if the client wants to know what possibilities there are it could simply AXFR the .service zone, tada. Funny that you are actually worried about handshakes, while you are trying to involve: traceroutes (icmp/udp) + reverse DNS and a hell lot of other false assumptions. =46rom rom a fourth mail: > Miguel Angel Diaz wrote: > > Alain Durand wrote: > > Simply because hardcoding names like that in implementations that > > need to be > > maintained for 10-20 years is a bad thing. > >=20 >=20 > So the approach that Jeroen mentioned about using traceroute > or ping would be an alternative. Furthermore, by using the IP > of the customer's default gateway would be even better because > it prevent the reverse done by some customers. I said that it is *NOT* an alternative. I actually said that was one of the silly things you would probably opt for next ;) You cannot read the 'default customer gateway' as there is quite likely no way to even look into the router at all. Or are you expecting that suddenly everybody builds in some magic there? The magic would then be building IPv6 in the router, not anything else. Greets, Jeroen --=-QQLMOZ/7Mh2/TDkA51Sn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB7ibwKaooUjM+fCMRAl6zAJ9AeE9DRoWZdwVDnUZim/e3WMVENwCfRbYF 1IjbjywdYysshIuoUK+d9PY= =h+FB -----END PGP SIGNATURE----- --=-QQLMOZ/7Mh2/TDkA51Sn-- --===============1777528091== 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 --===============1777528091==-- From v6tc-bounces@ietf.org Wed Jan 19 04:40:54 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 EAA24845; Wed, 19 Jan 2005 04:40:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrCa5-0004zl-BO; Wed, 19 Jan 2005 04:56:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrCJ3-0005Do-Ui; Wed, 19 Jan 2005 04:39:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrCGM-0004XP-IG for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 04:36: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 EAA24524 for ; Wed, 19 Jan 2005 04:36:28 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrCVm-0004ru-JR for v6tc@ietf.org; Wed, 19 Jan 2005 04:52:28 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0J9Zbw05371; Wed, 19 Jan 2005 11:35:39 +0200 Date: Wed, 19 Jan 2005 11:35:37 +0200 (EET) From: Pekka Savola To: Jeroen Massar Subject: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-Reply-To: <1106121160.18807.3.camel@firenze.zurich.ibm.com> Message-ID: References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> <326DFB69-6958-11D9-9E6D-00039358A080@sun.com> <1106063368.14179.149.camel@firenze.zurich.ibm.com> <1106121160.18807.3.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: 9466e0365fc95844abaf7c3f15a05c7d Cc: Alain Durand , v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Wed, 19 Jan 2005, Jeroen Massar wrote: >> So, while "you can use 6to4 in that scenario" is an answer, it is not >> a complete answer. > > Ack. Isn't the best and already working route Teredo then: > - NAT capable if needed > - uses providers prefix > - automatically configured > > The only piece missing is the anycast prefix... Uhh, Teredo does not use provider's prefix. (Though I'm not 100% sure whether a provider, by allocating a /32, could provide an "internal" Teredo prefix). The anycast prefix was felt to be a big problem in Teredo, so 2 years (or so) ago the spec was revamped not to use it. Of course, the v4 anycast prefix could be used just for discovery purposes (and then use a unicast address; see draft-ietf-mboned-auto-multicast-03.txt for example), but I'm not sure how much that would help. Teredo also cannot be used by routers. -- 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 Jan 19 04:48:14 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 EAA25644; Wed, 19 Jan 2005 04:48:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrChB-0005Cu-KH; Wed, 19 Jan 2005 05:04:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrCQu-0007OP-Np; Wed, 19 Jan 2005 04:47:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrCN3-0006Bn-37 for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 04:43: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 EAA25017 for ; Wed, 19 Jan 2005 04:43:23 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrCcU-000538-Fz for v6tc@ietf.org; Wed, 19 Jan 2005 04:59:22 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id A1470C2249; Wed, 19 Jan 2005 10:43:23 +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 08355-10; Wed, 19 Jan 2005 10:43:23 +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 05B61C2248; Wed, 19 Jan 2005 10:43:22 +0100 (CET) Subject: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: Pekka Savola In-Reply-To: References: <00c201c4fd30$705a2530$1100a8c0@consulintel.es> <013801c4fd3e$7ac38490$1100a8c0@consulintel.es> <66E788C6-6936-11D9-91AD-00039358A080@sun.com> <002401c4fd49$f062e730$a100000a@consulintel.es> <326DFB69-6958-11D9-9E6D-00039358A080@sun.com> <1106063368.14179.149.camel@firenze.zurich.ibm.com> <1106121160.18807.3.camel@firenze.zurich.ibm.com> Organization: Unfix Date: Wed, 19 Jan 2005 10:43:21 +0100 Message-Id: <1106127801.18807.80.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Alain Durand , v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1257052197==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f --===============1257052197== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ycntUa3Rx4er6dFi7Nft" --=-ycntUa3Rx4er6dFi7Nft Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-01-19 at 11:35 +0200, Pekka Savola wrote: > On Wed, 19 Jan 2005, Jeroen Massar wrote: > >> So, while "you can use 6to4 in that scenario" is an answer, it is not > >> a complete answer. > > > > Ack. Isn't the best and already working route Teredo then: > > - NAT capable if needed > > - uses providers prefix > > - automatically configured > > > > The only piece missing is the anycast prefix... >=20 > Uhh, Teredo does not use provider's prefix. (Though I'm not 100% sure=20 > whether a provider, by allocating a /32, could provide an "internal"=20 > Teredo prefix). Last time I checked it did: http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-04.txt 8<------------------------------------------------------------------------- 4 Teredo Addresses =20 The Teredo addresses are composed of 5 components: =20 +-------------+-------------+-------+------+-------------+ | Prefix | Server IPv4 | Flags | Port | Client IPv4 | +-------------+-------------+-------+------+-------------+ =20 - Prefix: the 32 bit Teredo service prefix. - Server IPv4: the IPv4 address of a Teredo server. - Flags: a set of 16 bits that document type of address and NAT. - Port: the obfuscated "mapped UDP port" of the Teredo service at the client - Client IPv4: the obfuscated "mapped IPv4 address" of the client ------------------------------------------------------------------------->8 And I am quite sure that Microsoft is using their 6bone prefix to fill in t= he first 32 bits... What else could they use? 6to4? > The anycast prefix was felt to be a big problem in Teredo, so 2 years=20 > (or so) ago the spec was revamped not to use it. But after all, it is nice to have, which was why it was in there. I'll need to read up on all the negative aspects though why it was revamped though. I recall it having to do a lot with anti-MS and ingress filtering not being present and the latter thus causing security problems. > Of course, the v4 anycast prefix could be used just for discovery=20 > purposes (and then use a unicast address; see=20 > draft-ietf-mboned-auto-multicast-03.txt for example), but I'm not sure=20 > how much that would help. > Teredo also cannot be used by routers. Indeed only 1 host per address. In the beginning of, then silkworm, Christian wanted 2003::/16 for this purpose, but that was rejected because of a lot of anti-MS people shouting at the top of their lungs. Not that 16 bits extra would give one much space for EUI-64. Greets, Jeroen --=-ycntUa3Rx4er6dFi7Nft Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD4DBQBB7iu5KaooUjM+fCMRAgXYAJdS8ki5K9BhPg1AgEpJ6Fw/GhnMAJ9AgQno wKWKIoOwwtFrXq9aQXfvig== =Ziyq -----END PGP SIGNATURE----- --=-ycntUa3Rx4er6dFi7Nft-- --===============1257052197== 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 --===============1257052197==-- From v6tc-bounces@ietf.org Wed Jan 19 06:11: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 GAA01489; Wed, 19 Jan 2005 06:11:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrDzQ-0007Cw-TJ; Wed, 19 Jan 2005 06:27:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrDjU-0006Bw-5W; Wed, 19 Jan 2005 06:10:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrDcZ-0005Qm-Qb for v6tc@megatron.ietf.org; Wed, 19 Jan 2005 06:03: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 GAA00997 for ; Wed, 19 Jan 2005 06:03:29 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrDs1-000729-Rb for v6tc@ietf.org; Wed, 19 Jan 2005 06:19:30 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0JB3GO09870; Wed, 19 Jan 2005 13:03:17 +0200 (EET) X-Scanned: Wed, 19 Jan 2005 13:11:13 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0JBBDaA007273; Wed, 19 Jan 2005 13:11:13 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00yymTLR; Wed, 19 Jan 2005 13:05:53 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0JAtdU01401; Wed, 19 Jan 2005 12:55:39 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 19 Jan 2005 12:53:27 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 19 Jan 2005 12:53:25 +0200 Received: from 172.21.224.18 ([172.21.224.18]) by esebe100.NOE.Nokia.com ([172.21.138.118]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Jan 2005 10:53:25 +0000 Received: from essat-vlan154-2-22418.ntc.nokia.com by ESEBE100.noe.nokia.com; 19 Jan 2005 12:53:25 +0200 Subject: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automaticor manual? From: "Soininen Jonne (Nokia-NET/Helsinki)" To: miguelangel.diaz@consulintel.es In-Reply-To: <022c01c4fe04$532192d0$1100a8c0@consulintel.es> References: <00bd01c4fdf8$d4292700$1100a8c0@consulintel.es> <022c01c4fe04$532192d0$1100a8c0@consulintel.es> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1106132004.4713.36.camel@essat-vlan154-2-22418.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 19 Jan 2005 12:53:25 +0200 X-OriginalArrivalTime: 19 Jan 2005 10:53:25.0982 (UTC) FILETIME=[1A2817E0:01C4FE15] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Miguel, On Wed, 2005-01-19 at 10:53, ext Miguel Angel Diaz wrote: > > On Tue, 2005-01-18 at 05:52 -0800, Alain Durand wrote: > >> On Jan 18, 2005, at 4:25 AM, Pekka Savola wrote: > >> > What seems left on the table from the generic solutions is an IPv4 > >> > anycast address. It has some problems, but maybe these problems are > >> > smaller than with others. > >> > >> I think the discussion from the last few days has shown few things: > >> > >> a) DNS based solutions (forward or reverse) do not work in all > >> situations and in particular do not work well in the case where a NAT box is > >> present, which seems to be a show stopper. > > I disagree partially with that assertion because by using reverse+forward DNS with either the public IP of the customer or the customer's default gateway would work in the most cases. Only two conditions are needed: > > - ISP configures properly the reverse DNS > - ISP configures properly the DNS server to be included on the reverse domain the names for the discovery services. > > Whit this assumptions even with local DNS server on the customer network, the discovery based on DNS will work. > > How to find out the public IP is not so hard as it has pointed before. STUN is only an alternative, but there is other ones even much better. I think there has been now some discussion on this. The problem with your proposal really is that expect something to happen, which boils down to the same problems as the original problem: Finding the server that can give you your the public IP address. In addition, your solutions sadly need a certain kind of network deployment that might or might not be true always. Expecting that the ISP has deployed the network in a certain special way or even worse assuming something from the user's home network leads to broken assumptions. Cheers, Jonne. > > Regards > Miguel > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > ______________________________________________________________________ > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Jan 21 03:24:33 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 DAA17885; Fri, 21 Jan 2005 03:24:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CruLh-0003or-Jl; Fri, 21 Jan 2005 03:40:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cru1V-0004Za-1z; Fri, 21 Jan 2005 03:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cru0f-0004SB-B6 for v6tc@megatron.ietf.org; Fri, 21 Jan 2005 03:19: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 DAA17646 for ; Fri, 21 Jan 2005 03:19:12 -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 1CruGV-0003in-MH for v6tc@ietf.org; Fri, 21 Jan 2005 03:35:36 -0500 Received: from [172.19.99.137] ([80.25.193.196]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000721306.msg for ; Fri, 21 Jan 2005 09:19:31 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 21 Jan 2005 09:18:20 +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: 80.25.193.196 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, Fri, 21 Jan 2005 09:19:36 +0100 X-MDAV-Processed: consulintel.es, Fri, 21 Jan 2005 09:19:37 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [v6tc] BoF ? X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Hi all, I wonder if we are finally going for a BoF, even if in principle was considered in the last meeting as not needed, but have not seen any movement from the IESG ... Thomas ? Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Jan 21 03:58:11 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 DAA19883; Fri, 21 Jan 2005 03:58:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrusF-0004lH-CZ; Fri, 21 Jan 2005 04:14:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CruaN-00088l-2l; Fri, 21 Jan 2005 03:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CruR0-0007Y9-Ma for v6tc@megatron.ietf.org; Fri, 21 Jan 2005 03:46: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 DAA19476 for ; Fri, 21 Jan 2005 03:46:25 -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 1Crugr-0004RA-1t for v6tc@ietf.org; Fri, 21 Jan 2005 04:02:49 -0500 Received: from [172.19.99.137] ([80.25.193.196]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000721472.msg for ; Fri, 21 Jan 2005 09:46:22 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 21 Jan 2005 09:45:10 +0100 Subject: Re:Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 80.25.193.196 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, Fri, 21 Jan 2005 09:46:45 +0100 X-MDAV-Processed: consulintel.es, Fri, 21 Jan 2005 09:46:46 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Hi Pekka, If my memory doesn't fails, I recall when I asked to Christian about why anycast was not there anymore, he mention some complain from the IESG review, but he also mention that using anycast just for the discovery. I think this is the right way, not just for Teredo, but in general for any protocol which requires a previous discovery process, and this is the reason why we suggest it as a backup solution when you're not attached to the "home ISP". If we don't trust in that, then we should deprecate 6to4 ;-), which obviously I don't think is the right thing to do ! Regards, Jordi > De: Pekka Savola > Responder a: > Fecha: Wed, 19 Jan 2005 11:35:37 +0200 (EET) > Para: Jeroen Massar > CC: Alain Durand , > Asunto: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or > manual? > > On Wed, 19 Jan 2005, Jeroen Massar wrote: >>> So, while "you can use 6to4 in that scenario" is an answer, it is not >>> a complete answer. >> >> Ack. Isn't the best and already working route Teredo then: >> - NAT capable if needed >> - uses providers prefix >> - automatically configured >> >> The only piece missing is the anycast prefix... > > Uhh, Teredo does not use provider's prefix. (Though I'm not 100% sure > whether a provider, by allocating a /32, could provide an "internal" > Teredo prefix). > > The anycast prefix was felt to be a big problem in Teredo, so 2 years > (or so) ago the spec was revamped not to use it. > > Of course, the v4 anycast prefix could be used just for discovery > purposes (and then use a unicast address; see > draft-ietf-mboned-auto-multicast-03.txt for example), but I'm not sure > how much that would help. > > Teredo also cannot be used by routers. > > -- > 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 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Sun Jan 23 01:30:14 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 BAA08073; Sun, 23 Jan 2005 01:30:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsbWY-000875-Kp; Sun, 23 Jan 2005 01:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsbF9-0001DT-LN; Sun, 23 Jan 2005 01:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsbCa-0000vZ-2i for v6tc@megatron.ietf.org; Sun, 23 Jan 2005 01:26:25 -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 BAA07964 for ; Sun, 23 Jan 2005 01:26:22 -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 1CsbSo-00084c-7Z for v6tc@ietf.org; Sun, 23 Jan 2005 01:43:11 -0500 Received: from [216.244.152.70] ([216.244.152.70]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000724242.msg for ; Sun, 23 Jan 2005 07:26:45 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 22 Jan 2005 23:30:30 +0100 Subject: Re:Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <1106121160.18807.3.camel@firenze.zurich.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-MDRemoteIP: 216.244.152.70 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.3 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Sun, 23 Jan 2005 07:26:49 +0100 X-MDAV-Processed: consulintel.es, Sun, 23 Jan 2005 07:26:49 +0100 X-Spam-Score: 0.6 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Partially agree, Teredo is missing the anycast bit, that's why our proposed work started providing a solution for ALL the existing mechanism, not just for TBs. The other issue with Teredo is that doesn't work with all kind of NATs, so this is once more a reason to be able to choose the most appropriate encapsulation. Regards, Jordi > De: Jeroen Massar > Organizaci=F3n: Unfix > Responder a: > Fecha: Wed, 19 Jan 2005 08:52:40 +0100 > Para: Pekka Savola > CC: Alain Durand , > Asunto: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or > manual? >=20 > On Tue, 2005-01-18 at 21:17 +0200, Pekka Savola wrote: >> On Tue, 18 Jan 2005, Jeroen Massar wrote: >>> On Tue, 2005-01-18 at 05:52 -0800, Alain Durand wrote: >>>> On Jan 18, 2005, at 4:25 AM, Pekka Savola wrote: >>>>> What seems left on the table from the generic solutions is an IPv4 >>>>> anycast address. It has some problems, but maybe these problems are >>>>> smaller than with others. >>>>=20 >>>> I think the discussion from the last few days has shown few things: >>>>=20 >>>> a) DNS based solutions (forward or reverse) do not work in all >>>> situations and in particular do not work well in the case where a NAT box >>>> is >>>> present, which seems to be a show stopper. >>>=20 >>> Especially when thinking of the fact that without a NAT box one can >>> easily use 6to4, this 'solution' is really unnecessary. >>=20 >> You can use 6to4 in this situation, yes, but you cannot use IPv6 >> addresses from your service provider's v6 prefix. 6to4's return-path >> quality is always a bit questionable, and v6tc might allow one to get >> a stable prefix when 6to4 prefix could be dynamic. >>=20 >> So, while "you can use 6to4 in that scenario" is an answer, it is not >> a complete answer. >=20 > Ack. Isn't the best and already working route Teredo then: > - NAT capable if needed > - uses providers prefix > - automatically configured >=20 > The only piece missing is the anycast prefix... >=20 > Greets, > Jeroen >=20 > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Sun Jan 23 01:31:35 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 BAA08122; Sun, 23 Jan 2005 01:31:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsbXr-00088r-Rq; Sun, 23 Jan 2005 01:48:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsbF9-0001DY-SQ; Sun, 23 Jan 2005 01:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsbCa-0000va-2i for v6tc@megatron.ietf.org; Sun, 23 Jan 2005 01:26:24 -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 BAA07967 for ; Sun, 23 Jan 2005 01:26:22 -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 1CsbSo-00084a-1d for v6tc@ietf.org; Sun, 23 Jan 2005 01:43:11 -0500 Received: from [216.244.152.70] ([216.244.152.70]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000724240.msg for ; Sun, 23 Jan 2005 07:26:40 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 22 Jan 2005 23:24:40 +0100 Subject: Re:refocusing: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 216.244.152.70 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.3 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Sun, 23 Jan 2005 07:26:48 +0100 X-MDAV-Processed: consulintel.es, Sun, 23 Jan 2005 07:26:48 +0100 X-Spam-Score: 0.6 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit I guess that here we clearly disagree ... I think the purpose of this work, at least when we started it, was discovering the TEP in any circumstance, not just within the AS. Otherwise, we may not need it, just say the user when register to the ISP: "install this software and it comes with the correct setup already". And just to clarify, for me a TEP is the tunnel end point of ANY transition mechanism which uses tunneling (whatever encapsulation is being used, as UDP is for me only the last resort if for example 6in4 can be used). I mean, doesn't restrict it to a TB. Regards, Jordi > De: Florent Parent > Responder a: > Fecha: Sun, 16 Jan 2005 22:30:45 -0500 > Para: > Asunto: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automatic or > manual? > > > > -- On Friday, January 14, 2005 05:45:13 -0800, Alain Durand wrote: > >> Well, the discussion on this topic has a bit rat-holing into anycast >> deployment issues, >> when the question I intended to discuss was: >> >>> In other words, could we live with a solution where the user will have >>> to manually >>> input on its v6 host or router an address of the form v6TEP.myISP.com >>> in the relevant >>> form? (provided that would be the ONLY thing to input) >> >> ... or do we absolutely require an automatic discovery mechanism? >> >> I would like to invite those who haven't expressed themselves on >> this very point to participate in the debate. >> >> - Alain. > > Automatic discovery should be focused within an "autonomous system" > (enterprise/ISP/etc.). For example, if anycast is used, such address should > be confined to the autonomous system routing system. How it's done > (anycast, DNS, etc.) is left to be defined. > > I think automatic discovery should be done in order to cover the zero-conf. > tunneling goals. > > In the roaming scenario (or getting service across an IPv4 only ISP), some > manually configured parameter would be required from the user (e.g. tunnel > service FQDN of your IPv6 provider). This manual configuration isn't alien > to users and is done in many client software. > > Florent > > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Sun Jan 23 01:32:26 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 BAA08172; Sun, 23 Jan 2005 01:32:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsbYg-00089P-7Y; Sun, 23 Jan 2005 01:49:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsbFA-0001Df-3w; Sun, 23 Jan 2005 01:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsbCa-0000vb-7r for v6tc@megatron.ietf.org; Sun, 23 Jan 2005 01:26:24 -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 BAA07968 for ; Sun, 23 Jan 2005 01:26: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 1CsbSn-00084b-UM for v6tc@ietf.org; Sun, 23 Jan 2005 01:43:11 -0500 Received: from [216.244.152.70] ([216.244.152.70]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000724241.msg for ; Sun, 23 Jan 2005 07:26:45 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 22 Jan 2005 23:27:17 +0100 Subject: Re:Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <20050118161813.GL11621@login.ecs.soton.ac.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 216.244.152.70 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.3 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Sun, 23 Jan 2005 07:26:48 +0100 X-MDAV-Processed: consulintel.es, Sun, 23 Jan 2005 07:26:49 +0100 X-Spam-Score: 0.6 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Agree also ;-) I insisted even that we need to keep the encapsulation selection as part of the protocol, but at that time, it was not clear that others support my suggestion on this. I think it will be pretty idiot to make a protocol that only supports a single encapsulation, while almost the same protocol can support even 4in6 to cover scenarios that even when still not clearly described in v6ops, are already in operational phase with real customers ! Regards, Jordi > De: Tim Chown > Responder a: > Fecha: Tue, 18 Jan 2005 16:18:13 +0000 > Para: > Asunto: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or > manual? > > I agree with Jeroen. > > I think though that originally we left the tunnelling protocol itself > out of scope, i.e. v6tc is tunnel *configuration* ? > > Tim > > On Tue, Jan 18, 2005 at 04:49:28PM +0100, Jeroen Massar wrote: >> On Tue, 2005-01-18 at 05:52 -0800, Alain Durand wrote: >>> On Jan 18, 2005, at 4:25 AM, Pekka Savola wrote: >>>> What seems left on the table from the generic solutions is an IPv4 >>>> anycast address. It has some problems, but maybe these problems are >>>> smaller than with others. >>> >>> I think the discussion from the last few days has shown few things: >>> >>> a) DNS based solutions (forward or reverse) do not work in all >>> situations and in particular do not work well in the case where a NAT box is >>> present, which seems to be a show stopper. >> >> Especially when thinking of the fact that without a NAT box one can >> easily use 6to4, this 'solution' is really unnecessary. >> >>> b) Some have pointed that it is ok if particular solutions do not work >>> in some cases, as those concern allegedly "power user" who do not need help >>> to >>> set up tunnels... I disagree deeply with this assertion. Whatever we will do >>> will be >>> in use for many years, and things have to be done right and just works in >>> any kind of >>> environments. >> >> As long as there is a 'knob' to turn automatic on/off, or at least a >> simple 'if there is IPv6 on the wire don't do a thing' this should be >> fine with most if not all people. It should work in most (nearing 99%) >> of the situations of course. >> >>> Relying on strong assumptions on how things are configured at >>> customers place is, IMHO, a recipe for failure. >> >> This is indeed the biggest point to learn from it all. There is simply >> no way one can assume that a certain setup is available. We thus can >> only assume there is IP and that we can send packets from A to B. >> >>> c) Anycast based solution are workable in theory but there are >>> operational concerns. >>> More feedback from the ISP community and the rest of the IETF is >>> necessary. It may be the case that this should be the focus of a dedicated >>> wg. >> >> Splitting up this, not even really started* WG into another WG is a bit >> silly isn't it ? :) (especially when counting the number of _active_ >> participants) >> >>> It seems, to me at least, that the logical conclusion is that we need >>> to dissociate this service discovery mechanism from the rest of the >>> discussions and, >>> for now, consider that there is an out-of-band mechanism to find out the >>> tunnel >>> end points. >> >> Thus, if I am correct, the focus of this WG should be (in short): >> - the fully automatic discovery of the best possible TEP >> - the configuration of the addresses of the tunnel >> - the protocol used for the transport of the IPv6 packets over IPv4. >> >> Maybe thus have 3 topics? >> - Endpoint Discovery >> - Configuration >> - Tunneling >> >> Though I think that the discovery and the configuration could sometimes >> come together. Though usage of eg DHCP and other standard methods could >> solve these issues. Do note that there is little vendor support for >> this. >> >> Thus maybe simple prefix subjects with correct part (T,C,E) and done? >> >> Greets, >> Jeroen >> >> * = there is still no official IETF WG charter.... >> > > > >> _______________________________________________ >> v6tc mailing list >> v6tc@ietf.org >> https://www1.ietf.org/mailman/listinfo/v6tc > > > -- > Tim > > > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Sun Jan 23 01:33:32 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 BAA08204; Sun, 23 Jan 2005 01:33:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsbZk-00089y-6h; Sun, 23 Jan 2005 01:50:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsbFA-0001Dm-BP; Sun, 23 Jan 2005 01:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsbCd-0000vf-Tp for v6tc@megatron.ietf.org; Sun, 23 Jan 2005 01:26:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07974 for ; Sun, 23 Jan 2005 01:26:27 -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 1CsbSs-00084d-GV for v6tc@ietf.org; Sun, 23 Jan 2005 01:43:15 -0500 Received: from [216.244.152.70] ([216.244.152.70]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000724243.msg for ; Sun, 23 Jan 2005 07:26:50 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 22 Jan 2005 23:36:24 +0100 Subject: Re:refocusing: Re: [v6tc] Issue 2: service discovery:automaticormanual? From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <01c901c4fe01$20892de0$1100a8c0@consulintel.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 216.244.152.70 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.3 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Sun, 23 Jan 2005 07:26:54 +0100 X-MDAV-Processed: consulintel.es, Sun, 23 Jan 2005 07:26:55 +0100 X-Spam-Score: 0.6 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Content-Transfer-Encoding: 7bit X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Content-Transfer-Encoding: 7bit Agree, the situation right now and I foresee for a long time, is that all those devices implement dual stack (and indeed is my recommendation to makers when they ask me, as this avoids any need for using translation - which is the worst we can do IMHO - mechanisms when the other end only talks IPv4, for example). Also, the reason why the devices need to come with transition mechanisms right now is because most of the CPEs don't have it. The situation may change in the future, but is not right now. So you may need to create different tunnels for the same home. In my own case, where I've lots of IPv6 devices for home automation in my home, obviously I setup a machine to act as "the" IPv6 router, but I know how to do it. Again, this is not the usual case. Regards, Jordi > De: Miguel Angel Diaz > Responder a: > Fecha: Wed, 19 Jan 2005 09:30:24 +0100 > Para: > Asunto: Re: refocusing: Re: [v6tc] Issue 2: service > discovery:automaticormanual? > >> On Tue, 2005-01-18 at 10:14 +0100, Miguel Angel Diaz wrote: >>>>> IMHO if we wish a broad and fast deployment of IPv6 the answer is that an >>>>> automatic discovery mechanism is definitively required. >>>> >>>> There is already Teredo and 6to4, what more is needed? >>>> Teredo on it's own already solves most if not all problems. >>>> The only issue with Teredo _could_ be that one does not get the most >>>> local relay. But I think M$ can be easily pursuade to add a update to >>>> windowsupdate that will reconfigure the default teredoserver to an >>>> anycast address. >>>> >>> >>> Thousands (even millions) of users over the world can't use the >>> current servers that M$ has pre-configured for 6to4 and Teredo >>> implementations on the OS, which are 6to4.ipv6.microsoft.com and >>> teredo.ipv6.microsoft.com. >> >> Did you notice the following: >> 6to4.ipv6.microsoft.com has address 192.88.99.1 >> 6to4.ipv6.microsoft.com has address 131.107.33.60 >> 6to4.ipv6.microsoft.com has IPv6 address 2002:836b:213c:1:e0:8f08:f020:8 >> >> If it isn't known, that first one is the 6to4 anycast address, which is >> also the first thing that XP tries, after that it might fall back to the >> microsoft provided relay. >> >> They (6to4 and Teredo) work perfectly fine from the several places where >> I have tried them. The only thing was the latency and throughput, which >> is logical as the Teredo box is hosted in the US, which is not where I >> am, but fortunately it uses those nice bubbles to locate a more local >> server which then causes the traffic to be optimized a bit. >> >> Any real argument why these millions of users can't use Teredo according >> to you? >> > > I mean that currently only a few Teredo servers are deployed over the world, > being the most known the ones deployed by Microsoft which are the default ones > on Widows XP. It doesn't seem to be likely that only a few them can manage > thousands of connections cuncurrently. > > >>> It is assumed that every ISP willing to offer IPv6 services to their >>> customers will deploy a TEP infrastructure on its own network, either >>> Teredo, >>> 6to4, or whatever. The TEP discovery on the ISP network is the point. >> >> Of course they want that, just like this is expected from 6to4. >> There is a very simple solution if you want this: anycast prefix for >> Teredo. Does not require any weird mechanisms, no weird stuff in DNS >> nothing. But to call this 'discovery', why bother with that ? >> >>>> Now if I would live in Tokio I could live with this assumption, but >>>> unfortunately, unless I go to Akibara myself or import the stuff I will >>>> not be able to buy these cool toys (yet). >>>> >>>> Also, the router in the house should provide this, not the camera, that >>>> should simply RA. Next to that does the word 'security' say anything? >>> >>> The point is that "today" we are working on the networks for "tomorrow" and >>> in the near future, >> >> In the future there will be native IPv6 to the home, today there is need >> for some tunneling. But in ~5 years it will be mostly native. >> >>> I think we all are agree that many home devices will support IPv6. Such >>> devices could implement >>> methods to work with IPv6 even although only IPv4 (so not RA available) is >>> available on the >>> home network during the early deployments. In this scenario an automatic >>> discovery method is required. >> >> Thus you want every small device to implement tunneling and thus create >> how many security holes in how many places? >> > > Security is an issue not only with small devices on the network but also on > operating systems running on the computers and I guess it doesn't depend on > the discovery mecanism used to get IPv6 connected :) > > >> You'd better start writing the security section of the draft like 3 >> years ago if you want to cover all the possible problems you will be >> creating here. >> >> Remember the following very simple thing: There will most likely be at >> least one computer (XP, BSD, Linux, other 'router') that supports IPv6 >> in such networks. These are more than capable handling this and are also >> way easier to make centrally secure/firewalled. >> >> If you really want that you can plug in a IPv6 camera, which will then >> also do IPv4 for the tunneling even though it is a IPv6-only cam, then >> also remember the security problems. >> >>>>> So, IMHO the answer is that we can't live with methods that require users >>>>> to enter any URL or data. >>>> >>>> I know of almost 3500 happy users who lived with this perfectly fine and >>>> there are a number of other organizations who claim to have way more >>>> users. >>>> >>> >>> I guess we are thinking of different type of users. I sure that expert users >>> (at least with some >>> technical knowledge) are happy with that situation, but I'm thinking of >>> thousands of users that >>> aren't TI experts. >> >> I am quite sure that most of those happy users are completely clueless >> in what they are doing and just followed that nice article they found on >> the internet or in that Computing Magazine For Dumbo's and are happily >> downloading the newest movies/music and other warez they can find. >> This is where the internet is used for and this already works. >> >>> My father might be a good example: he likes just plug-and-play devices >>> because >>> he has no technical knowledge at all, so he would like just plug its IPv6 >>> camera (with transition >>> mechanisms implemented) on the home network (IPv4) and see its house while >>> traveling around the world. >>> He wants that the camera itself is in charge of all the required >>> configuration (TEP discovery included) to work. >> >> He is quite likely to not even want to know how it works, he wants it to >> work, but without having his neighbor and that Brazilian kid and the >> burglar watching his house for him too... or are you going to explain >> him what security is? ;) >> >> Next to that, implementors of small devices don't like to implement >> multiple IP stacks and replicate work which should be done by other >> equipment. Note that all the current IPv6 toys are IPv6-only and do not >> have anything to do with IPv4. There is a reason for this: they don't >> want to be bothered with IPv4 in the first place as those devices could >> not communicate globally in the first place and they where sick of >> building NAT workarounds. > > Wether implementors implement dual stack or not it depends the status of the > native IPv6 deployment ant when they offer their products on the market. Why > are they going to try to sale IPv6 only products to users that don't have IPv6 > on their access networks and proven that most users don't usually know how to > configure IPv6 tunnels or IPv6 gateways? > > It is probably that developers implement dual stack (at least on the earlier > stages) to cope with both markets IPv4 and IPv6 (native one or with transition > mechanisms). At least, it will depend on the type of product. > > Regards > Miguel > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Mon Jan 24 05:35:20 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 FAA24663; Mon, 24 Jan 2005 05:35:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct1pZ-0006bJ-IR; Mon, 24 Jan 2005 05:52:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct1Q3-00048b-9D; Mon, 24 Jan 2005 05:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct1PP-00042s-Uj for v6tc@megatron.ietf.org; Mon, 24 Jan 2005 05:25:24 -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 FAA24158 for ; Mon, 24 Jan 2005 05:25:21 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct1ft-0006Mp-0A for v6tc@ietf.org; Mon, 24 Jan 2005 05:42:26 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0OAPKVu016794 for ; Mon, 24 Jan 2005 03:25:20 -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 <0IAT00LB0GY7RY@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Mon, 24 Jan 2005 03:25:19 -0700 (MST) Received: from [192.168.1.2] ([129.150.117.84]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAT00HJ5GY3VC@mail.sun.net> for v6tc@ietf.org; Mon, 24 Jan 2005 03:25:19 -0700 (MST) Date: Mon, 24 Jan 2005 02:25:09 -0800 From: Alain Durand Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automatic or manual? In-reply-to: To: jordi.palet@consulintel.es Message-id: <39108948-6DF2-11D9-B664-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7BIT On Jan 22, 2005, at 2:24 PM, JORDI PALET MARTINEZ wrote: > I guess that here we clearly disagree ... > > I think the purpose of this work, at least when we started it, was > discovering the TEP in any circumstance, not just within the AS. I think we have to agree we disagree here. > > Otherwise, we may not need it, just say the user when register to the > ISP: > "install this software and it comes with the correct setup already". This is the question I have been asking. Why is this not enough? > And just to clarify, for me a TEP is the tunnel end point of ANY > transition > mechanism which uses tunneling (whatever encapsulation is being used, > as UDP > is for me only the last resort if for example 6in4 can be used). I > mean, > doesn't restrict it to a TB. By focusing on TB, we have a good chance of success. Focusing on finding any TEP in the Internet for any transition mechanism is a much larger problem, much harder, and the chances of success do not look very good to me. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Mon Jan 24 06:32: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 GAA28132; Mon, 24 Jan 2005 06:32:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct2iY-000838-FP; Mon, 24 Jan 2005 06:49:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct2RB-00008G-H5; Mon, 24 Jan 2005 06:31:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct2Om-0008Lp-9c for v6tc@megatron.ietf.org; Mon, 24 Jan 2005 06:28:48 -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 GAA27918 for ; Mon, 24 Jan 2005 06:28:45 -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 1Ct2fF-0007vy-9c for v6tc@ietf.org; Mon, 24 Jan 2005 06:45:51 -0500 Received: from [216.244.152.69] ([216.244.152.69]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000725600.msg for ; Mon, 24 Jan 2005 12:29:01 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 24 Jan 2005 06:27:37 -0500 Subject: Re:refocusing: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <39108948-6DF2-11D9-B664-00039358A080@sun.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 216.244.152.69 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, 24 Jan 2005 12:29:05 +0100 X-MDAV-Processed: consulintel.es, Mon, 24 Jan 2005 12:29:06 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Hi, My reply below, in-line. Regards, Jordi > De: Alain Durand > Responder a: > Fecha: Mon, 24 Jan 2005 02:25:09 -0800 > Para: > CC: > Asunto: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automatic or > manual? > > > On Jan 22, 2005, at 2:24 PM, JORDI PALET MARTINEZ wrote: > >> I guess that here we clearly disagree ... >> >> I think the purpose of this work, at least when we started it, was >> discovering the TEP in any circumstance, not just within the AS. > > I think we have to agree we disagree here. > >> >> Otherwise, we may not need it, just say the user when register to the >> ISP: >> "install this software and it comes with the correct setup already". > > This is the question I have been asking. Why is this not enough? Because this will only work if the service is only available from your ISP ... but doesn't work when you want to discover for example free TBs or other free transition mechanisms. > >> And just to clarify, for me a TEP is the tunnel end point of ANY >> transition >> mechanism which uses tunneling (whatever encapsulation is being used, >> as UDP >> is for me only the last resort if for example 6in4 can be used). I >> mean, >> doesn't restrict it to a TB. > > By focusing on TB, we have a good chance of success. Focusing > on finding any TEP in the Internet for any transition mechanism > is a much larger problem, much harder, and the chances of success > do not look very good to me. I don't agree here, it may see a much larger problem but looking into the proposed solutions (that's why we did a so exhaustive and long analysis document !), the problem is only 1% more harder (versus only TB). The way we described the solution, even if we (for example), finally decide to go only for anycast, it works transparently for all the transition mechanism, even w/o the need to modify them. Instead the OS look for the right TEP and parses what has been discovered using anycast to the mechanism. Of course, it depends on the final solution, for example if we go for anycast, the simpler way to make it olnly a 1% more harder problem is to have one anycast prefix for every transition mechanism. So my point of view is that we don't need to close this decision right now, until we move on to fix the possible solutions (may be there are others better than our, but which only solve the problem for TB and those solutions are much harder, as you say, to cover the "any" transition TEP). > > - Alain. > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Mon Jan 24 08:24: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 IAA07211; Mon, 24 Jan 2005 08:24:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct4Sw-0002rs-8g; Mon, 24 Jan 2005 08:41:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct48R-00055Q-Vt; Mon, 24 Jan 2005 08:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct3xD-0003h7-8w for v6tc@megatron.ietf.org; Mon, 24 Jan 2005 08:08:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05702 for ; Mon, 24 Jan 2005 08:08:21 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct4De-0002IY-BH for v6tc@ietf.org; Mon, 24 Jan 2005 08:25:26 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id AB44124011; Mon, 24 Jan 2005 14:08:11 +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 26803-09; Mon, 24 Jan 2005 14:08:11 +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 EC4C224003; Mon, 24 Jan 2005 14:08:10 +0100 (CET) Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automatic or manual? From: Jeroen Massar To: Jordi Palet In-Reply-To: <39108948-6DF2-11D9-B664-00039358A080@sun.com> References: <39108948-6DF2-11D9-B664-00039358A080@sun.com> Organization: Unfix Date: Mon, 24 Jan 2005 14:08:09 +0100 Message-Id: <1106572089.16930.62.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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="===============0508869644==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 --===============0508869644== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/pYU8ko1xyr6B2sbP00P" --=-/pYU8ko1xyr6B2sbP00P Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-01-24 at 02:25 -0800, Alain Durand wrote: > On Jan 22, 2005, at 2:24 PM, JORDI PALET MARTINEZ wrote: > > Otherwise, we may not need it, just say the user when register to the=20 > > ISP: > > "install this software and it comes with the correct setup already". >=20 > This is the question I have been asking. Why is this not enough? Also this is extremely easy to deploy (couple of binaries on the website and let them click). It works always* in every scenario, unless some stupid firewall blocks some protocol or port of course. But with UDP this should be quite safe in most situations and where it is not you can't get out of there easily anyway and the IETF should not be trying to circumvent administrative barriers. I can already hear the admins screaming "Hey they opened my network wide open"... * I have to note that it is a lot of fun making a tool which actually can configure routing etc automatically, especially when the user has been either playing around with the ipv6 settings before without knowing what was being done, it was done automatically or that this person preconfigured it with knowledge and wants to keep it. That said, one can define a number of great protocols and have long discussions about this, but if nobody (wants to) make an implementation one is dead in the water anyway... > > And just to clarify, for me a TEP is the tunnel end point of ANY=20 > > transition > > mechanism which uses tunneling (whatever encapsulation is being used,=20 > > as UDP > > is for me only the last resort if for example 6in4 can be used). I=20 > > mean, > > doesn't restrict it to a TB. >=20 > By focusing on TB, we have a good chance of success. Focusing > on finding any TEP in the Internet for any transition mechanism > is a much larger problem, much harder, and the chances of success > do not look very good to me. One could have an anycast prefix announcing where to find the closest TB. But as mentioned this would then have that TB announce itself and will involve some kind of business advantages/disadvantages, though I can't see any competition in this kind of business, at least at the moment, even though this is the IETF, this will be weighed in by several people. As I have mentioned before quite a number of times there are already a number of openly deployed solutions for these problems. Probably the best one is TSP, being included in most linux distributions and like mentioned above downloadable from some places, preconfigured to do what they want. And also takes care of the number of requirements mentioned in the various threads which came up. For that matter, what is the use of defining this all again, while it is being used already? Why not try to define the bottlenecks and deficiencies in the tools that are out there and try to fix those? Having a list of these is good anyway because that can, and no the large solution/analysis documents don't make sense and they don't even cover them correctly. Fun to see a lot of letters, but they don't contain anything useful IMHO. > JORDI PALET MARTINEZ wrote: > > Alain Durand > > This is the question I have been asking. Why is this not enough? >=20 > Because this will only work if the service is only available from your IS= P What is bad with that? You *pay* your ISP and thus demand them to give you = service. > ... but doesn't work when you want to discover for example free TBs or ot= her > free transition mechanisms. I would not want to use a free anything if I am paying my ISP who should be= doing it. Next to that DNS would fail completely in this case as there is no way to d= iscover a 'free' something because it is unrelated to any form of DNS you can think= of. Anycast could work, getting you the closest one, but does one really want t= o use them? The download and be done with it method works perfectly fine here. People w= ho currently don't know what IPv6 is, use Teredo or 6to4 automatically, people who want = a choice can use the various tools which are available already, for free in most cases. > the problem is only 1% more harder (versus only TB). I wonder how you can express something undefined in percentages, even expre= ssing defined things in percentages is silly, this is protocol work, not banking ;) > The way we > described the solution, even if we (for example), finally decide to go on= ly > for anycast, it works transparently for all the transition mechanism, eve= n > w/o the need to modify them. Instead the OS look for the right TEP and > parses what has been discovered using anycast to the mechanism. What does this gain over the currently deployed solutions? Next to that the OS doesn't do a thing, a tool in the distribution might. Did I mention 'dig @192.0.2.53 ipv6.tep.service txt' ? ;) > Of course, it depends on the final solution, for example if we go for > anycast, the simpler way to make it olnly a 1% more harder problem is to > have one anycast prefix for every transition mechanism. Where does this 1% come from? And how is *the* solution going to pick *the* perfect transition mechanism? What if the position of the moon changes? > So my point of view is that we don't need to close this decision right no= w, > until we move on to fix the possible solutions (may be there are others > better than our, but which only solve the problem for TB and those soluti= ons > are much harder, as you say, to cover the "any" transition TEP). Did someone present a (possibly) working solution already? The exact requir= ements have not even been formulated yet. Greets, Jeroen --=-/pYU8ko1xyr6B2sbP00P Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBB9PM5KaooUjM+fCMRAhE5AJ0S1DO2pbp1yQxF3c8jvunFgr0UpwCghb/+ 5I2qHwb2wg3IZUeX0cBUd5k= =RJeU -----END PGP SIGNATURE----- --=-/pYU8ko1xyr6B2sbP00P-- --===============0508869644== 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 --===============0508869644==-- From v6tc-bounces@ietf.org Mon Jan 24 16:56:47 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 QAA06052; Mon, 24 Jan 2005 16:56:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCT7-0000iX-9R; Mon, 24 Jan 2005 17:13:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBwV-0004n4-Id; Mon, 24 Jan 2005 16:40:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBnN-0007Jb-Vm for v6tc@megatron.ietf.org; Mon, 24 Jan 2005 16:30: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 QAA01592 for ; Mon, 24 Jan 2005 16:30:47 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtC3w-0007MG-7u for v6tc@ietf.org; Mon, 24 Jan 2005 16:47:57 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0OLUDu24950 for ; Mon, 24 Jan 2005 23:30:13 +0200 Date: Mon, 24 Jan 2005 23:30:13 +0200 (EET) From: Pekka Savola To: v6tc@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [v6tc] Web archives working again 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: b19722fc8d3865b147c75ae2495625f2 Hi, Finally, Foretec has succeeded in repairing the web archives. See: https://www1.ietf.org/mailman/listinfo/v6tc ---------- Forwarded message ---------- Date: Fri, 17 Dec 2004 12:35:15 +0200 (EET) From: Pekka Savola To: Jeroen Massar Cc: Alain Durand , v6tc@ietf.org Subject: Re: [v6tc] Issue 1: Could we live with UDP encapsulation always on? [...] > PS: The mailinglist archives don't work... Thanks for pointing that out. I'll raise it with the IETF secretariat. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Mon Jan 24 16:57: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 QAA06197; Mon, 24 Jan 2005 16:57:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCU4-0000ko-2F; Mon, 24 Jan 2005 17:14:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtC2i-0007ig-5s; Mon, 24 Jan 2005 16:46:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBqW-0000kk-Gy for v6tc@megatron.ietf.org; Mon, 24 Jan 2005 16:34:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02006 for ; Mon, 24 Jan 2005 16:34:01 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtC76-0007Ws-9B for v6tc@ietf.org; Mon, 24 Jan 2005 16:51:12 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0OLXVj25060 for ; Mon, 24 Jan 2005 23:33:31 +0200 Date: Mon, 24 Jan 2005 23:33:31 +0200 (EET) From: Pekka Savola To: v6tc@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd) 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: 0fa76816851382eb71b0a882ccdc29ac Hi, 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