From owner-v6ops@ops.ietf.org Wed Dec 1 04:40:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07951 for ; Wed, 1 Dec 2004 04:40:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZQwI-0008N8-92 for v6ops-data@psg.com; Wed, 01 Dec 2004 09:38:22 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CZQwH-0008Mk-8J for v6ops@ops.ietf.org; Wed, 01 Dec 2004 09:38:21 +0000 Received: (qmail 17218 invoked by uid 417); 1 Dec 2004 09:38:20 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 1 Dec 2004 09:38:20 -0000 Received: from XPNERICK ([193.17.42.1]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Wed, 01 Dec 2004 02:38:17 -0700 Message-ID: <001701c4d789$5aef4c60$08091eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <4.3.2.7.2.20041119133905.023cd410@fruitpie.cisco.com> <4.3.2.7.2.20041130154225.02ee6718@ce-nfs-1.cisco.com> Subject: Re: Need a suggestion ... Date: Wed, 1 Dec 2004 11:37:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I prefer the one draft method. Multiple drafts may mean more hits, but it will mean having to look at multiple drafts if you are utilizing different technologies (as many ISPs are) or worse trying to use one for multiple technologies. Eric ----- Original Message ----- From: "Salman Asadullah" To: Cc: "Ciprian Popoviciu" ; "adeel Ahmed" ; "Patrick Grossetete" Sent: 01 December, 2004 1:47 AM Subject: Need a suggestion ... > Hello All, > > We would like to take a quick poll from the group regarding structure of > our following draft, ISP IPv6 Deployment Scenarios in Broadband Access > Networks: > > http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-01.txt > > Currently this draft is ~ 60 pages long, we would like to know if we should > keep it the way it is or split it into 4 different drafts (~15-20 pages > each) based on technology (DSL, Cable, ETTH, Wireless). > > We are hearing two opinions: > > 1. We should keep it the way it is, its long but complete and acts as a > "one stop shop". Reader can choose the section of interest easily. > > 2. We should split the draft, it would result in a smaller technology > specific draft and eventually more hits. If we split the draft, there > could be two options of doing it. > > Option 2A: Section 1,2,3,4,5 (these are general section and pretty much > applies to every BB technology) will be replicated in all 4 drafts. So, we > will have 4 drafts in total. > > Option 2B: Section 1,2,3,4,5 is part of a "general draft" followed by one > paragraph for each technology where we refer the reader to the new > technology specific draft. So, we will have 5 drafts in total (1 general + > 4 technology specific). > > Please let us know your thoughts, which route we should take. > > Thank you all. > > Regards, > Salman > > From owner-v6ops@ops.ietf.org Wed Dec 1 05:00:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08775 for ; Wed, 1 Dec 2004 05:00:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZRGt-000C5h-SQ for v6ops-data@psg.com; Wed, 01 Dec 2004 09:59:39 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZRGs-000C5I-OX for v6ops@ops.ietf.org; Wed, 01 Dec 2004 09:59:39 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iB19xbi3006401 for ; Wed, 1 Dec 2004 09:59:37 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA14740 for ; Wed, 1 Dec 2004 09:59:36 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iB19xaM21937 for v6ops@ops.ietf.org; Wed, 1 Dec 2004 09:59:36 GMT Date: Wed, 1 Dec 2004 09:59:36 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Need a suggestion ... Message-ID: <20041201095936.GA21885@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <4.3.2.7.2.20041119133905.023cd410@fruitpie.cisco.com> <4.3.2.7.2.20041130154225.02ee6718@ce-nfs-1.cisco.com> <001701c4d789$5aef4c60$08091eac@ttitelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001701c4d789$5aef4c60$08091eac@ttitelecom.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-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Keep one. On Wed, Dec 01, 2004 at 11:37:19AM +0200, EricLKlein wrote: > I prefer the one draft method. Multiple drafts may mean more hits, but it > will mean having to look at multiple drafts if you are utilizing different > technologies (as many ISPs are) or worse trying to use one for multiple > technologies. > > Eric > > ----- Original Message ----- > From: "Salman Asadullah" > To: > Cc: "Ciprian Popoviciu" ; "adeel Ahmed" > ; "Patrick Grossetete" > Sent: 01 December, 2004 1:47 AM > Subject: Need a suggestion ... > > > > Hello All, > > > > We would like to take a quick poll from the group regarding structure of > > our following draft, ISP IPv6 Deployment Scenarios in Broadband Access > > Networks: > > > > > http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-01.txt > > > > Currently this draft is ~ 60 pages long, we would like to know if we > should > > keep it the way it is or split it into 4 different drafts (~15-20 pages > > each) based on technology (DSL, Cable, ETTH, Wireless). > > > > We are hearing two opinions: > > > > 1. We should keep it the way it is, its long but complete and acts as a > > "one stop shop". Reader can choose the section of interest easily. > > > > 2. We should split the draft, it would result in a smaller technology > > specific draft and eventually more hits. If we split the draft, there > > could be two options of doing it. > > > > Option 2A: Section 1,2,3,4,5 (these are general section and pretty much > > applies to every BB technology) will be replicated in all 4 drafts. So, we > > will have 4 drafts in total. > > > > Option 2B: Section 1,2,3,4,5 is part of a "general draft" followed by one > > paragraph for each technology where we refer the reader to the new > > technology specific draft. So, we will have 5 drafts in total (1 general > + > > 4 technology specific). > > > > Please let us know your thoughts, which route we should take. > > > > Thank you all. > > > > Regards, > > Salman > > > > > > -- Tim From owner-v6ops@ops.ietf.org Wed Dec 1 05:44:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11234 for ; Wed, 1 Dec 2004 05:44:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZRwz-000Jk9-QF for v6ops-data@psg.com; Wed, 01 Dec 2004 10:43:09 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZRwy-000Jjs-QR for v6ops@ops.ietf.org; Wed, 01 Dec 2004 10:43:09 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id iB1Ah5ug134920 for ; Wed, 1 Dec 2004 10:43:05 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB1Ah1aI105354 for ; Wed, 1 Dec 2004 11:43:01 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB1Ah5RC001731 for ; Wed, 1 Dec 2004 11:43:05 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB1Ah44D001704; Wed, 1 Dec 2004 11:43:04 +0100 Received: from zurich.ibm.com (sig-9-145-249-118.de.ibm.com [9.145.249.118]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA31506; Wed, 1 Dec 2004 11:43:03 +0100 Message-ID: <41ADA03D.1010701@zurich.ibm.com> Date: Wed, 01 Dec 2004 11:43:09 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Salman Asadullah CC: v6ops@ops.ietf.org, Ciprian Popoviciu , adeel Ahmed , Patrick Grossetete Subject: Re: Need a suggestion ... References: <4.3.2.7.2.20041119133905.023cd410@fruitpie.cisco.com> <4.3.2.7.2.20041130154225.02ee6718@ce-nfs-1.cisco.com> In-Reply-To: <4.3.2.7.2.20041130154225.02ee6718@ce-nfs-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 1. We should keep it the way it is, its long but complete and acts as a "one stop shop". Reader can choose the section of interest easily. I prefer this. Brian From owner-v6ops@ops.ietf.org Wed Dec 1 05:44:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11272 for ; Wed, 1 Dec 2004 05:44:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZRyX-000K8y-A9 for v6ops-data@psg.com; Wed, 01 Dec 2004 10:44:45 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZRyW-000K8h-8q for v6ops@ops.ietf.org; Wed, 01 Dec 2004 10:44:44 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 8F8713606; Wed, 1 Dec 2004 11:44:43 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 19470-10; Wed, 1 Dec 2004 11:44:42 +0100 (CET) Received: from james (james.public.iu-bremen.de [212.201.47.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id A3FC435F4; Wed, 1 Dec 2004 11:44:42 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CZRyV-0000cX-Ts; Wed, 01 Dec 2004 11:44:43 +0100 Date: Wed, 1 Dec 2004 11:44:43 +0100 From: Juergen Schoenwaelder To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: Take VLAN usage as WG document? Message-ID: <20041201104443.GA2254@james> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Pekka Savola , v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Nov 29, 2004 at 08:22:21AM +0200, Pekka Savola wrote: > The author has asked if the document describing usage of VLANs > for IPv6 deployed could be taken as a WG document: > > http://www.ietf.org/internet-drafts/draft-chown-v6ops-vlan-usage-02.txt > > This is in the charter, and useful as an Informational document. > > Please say what you think. Silence DOES NOT indicate consent. If new > work items are to be adopted, there must be active support for doing > it, and there must be people willing to review and work on the draft. I just read the document. While the general approach is more or less obvious once you think about the problem space (done this exercise about a year ago), this document has the potential to clearly document the benefits and pitfalls so that others have less to think about and are likely getting a reasonable setup. What I like to see is more discussion of the trade-offs between the alternatives that do exist. One specific item which I think needs more consideration is the IPv6 addressing plan. My experience was that working out an addressing plan is actually more controversial and time consuming than getting an IPv6 router hocked up into the network. So a more complete list of the various approaches for addressing plans together with their advantages and disadvantages would be much appreciated and add real value to the document. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From owner-v6ops@ops.ietf.org Wed Dec 1 08:19:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26298 for ; Wed, 1 Dec 2004 08:19:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZUME-000Gdw-IU for v6ops-data@psg.com; Wed, 01 Dec 2004 13:17:22 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZUMD-000Gdh-KT for v6ops@ops.ietf.org; Wed, 01 Dec 2004 13:17:21 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iB1DHDi3011579; Wed, 1 Dec 2004 13:17:13 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 NAA01235; Wed, 1 Dec 2004 13:17:12 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iB1DHBe26205; Wed, 1 Dec 2004 13:17:11 GMT Date: Wed, 1 Dec 2004 13:17:11 +0000 From: Tim Chown To: v6ops@ops.ietf.org Cc: Pekka Savola Subject: Re: Take VLAN usage as WG document? Message-ID: <20041201131711.GD25955@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org, Pekka Savola References: <20041201104443.GA2254@james> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041201104443.GA2254@james> 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-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Dec 01, 2004 at 11:44:43AM +0100, Juergen Schoenwaelder wrote: > > What I like to see is more discussion of the trade-offs between the > alternatives that do exist. One specific item which I think needs > more consideration is the IPv6 addressing plan. My experience was > that working out an addressing plan is actually more controversial > and time consuming than getting an IPv6 router hocked up into the > network. So a more complete list of the various approaches for > addressing plans together with their advantages and disadvantages > would be much appreciated and add real value to the document. Hi, We are working on a separate draft on addressing plans for end sites, from experiences in 6NET. I don't think we want to cloud the "how you deploy dual stack via a parallel infrastructure" issue with "how you address the IPv6 network". So I would prefer to keep the two as separate texts. We expect to release a first draft in 2-3 weeks. Input is welcome; we have three authors to date. Tim From owner-v6ops@ops.ietf.org Wed Dec 1 08:22:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26540 for ; Wed, 1 Dec 2004 08:22:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZUR2-000H5i-8m for v6ops-data@psg.com; Wed, 01 Dec 2004 13:22:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZUR1-000H5T-3j for v6ops@ops.ietf.org; Wed, 01 Dec 2004 13:22:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iB1DMEb06012; Wed, 1 Dec 2004 15:22:14 +0200 Date: Wed, 1 Dec 2004 15:22:14 +0200 (EET) From: Pekka Savola To: Salman Asadullah cc: v6ops@ops.ietf.org, Ciprian Popoviciu , adeel Ahmed , Patrick Grossetete Subject: Re: Need a suggestion ... In-Reply-To: <4.3.2.7.2.20041130154225.02ee6718@ce-nfs-1.cisco.com> Message-ID: References: <4.3.2.7.2.20041119133905.023cd410@fruitpie.cisco.com> <4.3.2.7.2.20041130154225.02ee6718@ce-nfs-1.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 30 Nov 2004, Salman Asadullah wrote: > 1. We should keep it the way it is, its long but complete and acts > as a "one stop shop". Reader can choose the section of interest > easily. > > 2. We should split the draft, it would result in a smaller technology > specific draft and eventually more hits. If we split the draft, there could > be two options of doing it. > > Option 2B: Section 1,2,3,4,5 is part of a "general draft" followed by one > paragraph for each technology where we refer the reader to the new technology > specific draft. So, we will have 5 drafts in total (1 general + 4 technology > specific). Personally, I'd prefer either option 1 or option 2b. 2a creates too much redundant text. The benefit of 2b is being able to evolve the documents separately, e.g., if there is more interest in the WG participants in one document; the documents are also shorter and easier to read. The benefit of 1 is that all you need is in one draft. The drawback is that the doc is loooong, and it might discourage people from looking at it. I may be slightly biased toward 2b, but 1 is OK with me as well, as the others seem to be favoring that approach. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Dec 1 09:08:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00660 for ; Wed, 1 Dec 2004 09:08:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZV8o-000NHY-6J for v6ops-data@psg.com; Wed, 01 Dec 2004 14:07:34 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZV8n-000NH8-45 for v6ops@ops.ietf.org; Wed, 01 Dec 2004 14:07:33 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6A2A03612; Wed, 1 Dec 2004 15:07:32 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 00397-04; Wed, 1 Dec 2004 15:07:31 +0100 (CET) Received: from james (james.public.iu-bremen.de [212.201.47.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 7C10E35F3; Wed, 1 Dec 2004 15:07:31 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CZV8n-0001NG-17; Wed, 01 Dec 2004 15:07:33 +0100 Date: Wed, 1 Dec 2004 15:07:32 +0100 From: Juergen Schoenwaelder To: v6ops@ops.ietf.org, Pekka Savola Subject: Re: Take VLAN usage as WG document? Message-ID: <20041201140732.GB4111@james> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: v6ops@ops.ietf.org, Pekka Savola References: <20041201104443.GA2254@james> <20041201131711.GD25955@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041201131711.GD25955@login.ecs.soton.ac.uk> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Dec 01, 2004 at 01:17:11PM +0000, Tim Chown wrote: > We are working on a separate draft on addressing plans for end sites, > from experiences in 6NET. I don't think we want to cloud the "how you > deploy dual stack via a parallel infrastructure" issue with "how you > address the IPv6 network". So I would prefer to keep the two as > separate texts. > > We expect to release a first draft in 2-3 weeks. Input is welcome; we > have three authors to date. So I am looking forward to see that document. From my perspective, this addressing plan document might be more important than the other one. Right now, we use several internal tunnels for non-technical reasons, so we do not follow , even though we considered the same ideas. But we like to implement an addressing plan which is flexible and allows us to gradually transition easily towards native v6 support within the network without much pain. Personally, I have no strong opinion whether you want to go for many clearly focussed short documents that cross-reference each other or a more monolythic bible which covers all the important things in one place. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From owner-v6ops@ops.ietf.org Sun Dec 5 10:52:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17040 for ; Sun, 5 Dec 2004 10:52:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Caybn-0002Nf-OZ for v6ops-data@psg.com; Sun, 05 Dec 2004 15:47:35 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Caybm-0002NL-CG for v6ops@ops.ietf.org; Sun, 05 Dec 2004 15:47:34 +0000 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 215428; Sun, 05 Dec 2004 10:40:50 -0500 Mime-Version: 1.0 Message-Id: Date: Sun, 5 Dec 2004 10:47:09 -0500 To: ericlklein@softhome.net, henrik@levkowetz.com, karen.e.nielsen@ericsson.com, Francis.Dupont@enst-bretagne.fr, Markku.Ala-Vannesluoma@nokia.com, Jonathan Rosenberg From: Margaret Wasserman Subject: draft-huitema-v6ops-teredo-03.txt Cc: v6ops@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Eric, Henrik, Karen, Francis, Markku and Jonathan, There is a new version of the Teredo draft available at: http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-03.txt Could you check whether this version addresses the issues that you raised during IETF LC? It would be best if you could review this document and return any feedback by this Thursday, 9-Dec-04. If there are no further objections, I will place this draft on the IESG agenda for consideration on our 16-Dec-04 telechat. Thanks! Margaret From owner-v6ops@ops.ietf.org Sun Dec 5 11:13:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18299 for ; Sun, 5 Dec 2004 11:13:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cayzf-0005QI-Cp for v6ops-data@psg.com; Sun, 05 Dec 2004 16:12:15 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1Cayzc-0005Q2-5w for v6ops@ops.ietf.org; Sun, 05 Dec 2004 16:12:12 +0000 Received: (qmail 31667 invoked by uid 417); 5 Dec 2004 16:12:11 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 5 Dec 2004 16:12:11 -0000 Received: from XPNERICK ([193.17.42.1]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Sun, 05 Dec 2004 09:12:09 -0700 Message-ID: <004601c4dae5$088cfd00$08091eac@ttitelecom.com> From: "EricLKlein" To: henrik@levkowetz.com, karen.e.nielsen@ericsson.com, Francis.Dupont@enst-bretagne.fr, Markku.Ala-Vannesluoma@nokia.com, "Jonathan Rosenberg" , "Margaret Wasserman" Cc: v6ops@ops.ietf.org References: Subject: Re: draft-huitema-v6ops-teredo-03.txt Date: Sun, 5 Dec 2004 18:11:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret, I am still a little uncomfortable about the fact that there is no explicit statement that "teredo is needed because NAT was deprecated in IPv6 so teredo is needed to allow IPv6 nodes to communicate with IPv4 nodes in a domain that utilizes NAT." This is still true in section 3.2.4 Automatic sunset. Some how this whole section scares me as it seems to imply that there is a way to turn an IPv4 NAT into an IPv6 Router while maintaining the NAT like functionality. As stated above, NAT is not part of IPv6 (NAP is but is still not mentioned in this document). Eric ----- Original Message ----- From: "Margaret Wasserman" To: ; ; ; ; ; "Jonathan Rosenberg" Cc: Sent: 05 December, 2004 5:47 PM Subject: draft-huitema-v6ops-teredo-03.txt > > Hi Eric, Henrik, Karen, Francis, Markku and Jonathan, > > There is a new version of the Teredo draft available at: > > http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-03.txt > > Could you check whether this version addresses the issues that you > raised during IETF LC? It would be best if you could review this > document and return any feedback by this Thursday, 9-Dec-04. > > If there are no further objections, I will place this draft on the > IESG agenda for consideration on our 16-Dec-04 telechat. > > Thanks! > > Margaret > > From owner-v6ops@ops.ietf.org Mon Dec 6 00:56:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16908 for ; Mon, 6 Dec 2004 00:56:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CbBn8-000C6q-3F for v6ops-data@psg.com; Mon, 06 Dec 2004 05:52:10 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CbBn6-000C5W-Oz for v6ops@ops.ietf.org; Mon, 06 Dec 2004 05:52:09 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iB65q8Vu010325 for ; Sun, 5 Dec 2004 22:52:08 -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 <0I8A00MHZDMVXX@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Sun, 05 Dec 2004 22:52:07 -0700 (MST) Received: from [192.168.1.101] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I8A007R8DMTOP@mail.sun.net> for v6ops@ops.ietf.org; Sun, 05 Dec 2004 22:52:06 -0700 (MST) Date: Sun, 05 Dec 2004 21:52:05 -0800 From: Alain Durand Subject: Re: draft-huitema-v6ops-teredo-03.txt In-reply-to: <004601c4dae5$088cfd00$08091eac@ttitelecom.com> To: EricLKlein Cc: Markku.Ala-Vannesluoma@nokia.com, Francis.Dupont@enst-bretagne.fr, Margaret Wasserman , Jonathan Rosenberg , henrik@levkowetz.com, v6ops@ops.ietf.org, karen.e.nielsen@ericsson.com 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: <004601c4dae5$088cfd00$08091eac@ttitelecom.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Dec 5, 2004, at 8:11 AM, EricLKlein wrote: > Margaret, > > I am still a little uncomfortable about the fact that there is no > explicit > statement that "teredo is needed because NAT was deprecated in IPv6 I have never seen any such statement in any RFC defining IPv6. > so > teredo is needed to allow IPv6 nodes to communicate with IPv4 nodes in > a > domain that utilizes NAT." > > This is still true in section 3.2.4 Automatic sunset. > Some how this whole section scares me as it seems to imply that there > is a > way to turn an IPv4 NAT into an IPv6 Router while maintaining the NAT > like > functionality. As stated above, NAT is not part of IPv6 (NAP is but is > still > not mentioned in this document). 3 points: a) nothing will ever prevent anyone from inventing/using IPv6 NAT one day b) when the v4 NAT gets upgraded to do also v6, it still does v4 NAT... this functionality does not go away... c) The only (minor) point I have with section 3.2.4 is with the sentence: "upgrading the Internet connection used by the NAT to a native IPv6 service," If the 'upgraded' NAT provides v6 connectivity via a configured tunnel (maybe using the tunnel set up protocol we want to design in v6tc) teredo will also detect it (by seeing a native RA on the internal network) and turn itself off. So I would suggest to simply remove the work 'native' from the above sentence. - Alain, From owner-v6ops@ops.ietf.org Mon Dec 6 03:25:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11275 for ; Mon, 6 Dec 2004 03:25:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CbE9O-0001x7-3y for v6ops-data@psg.com; Mon, 06 Dec 2004 08:23:18 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CbE9M-0001wk-Qx for v6ops@ops.ietf.org; Mon, 06 Dec 2004 08:23:17 +0000 Received: (qmail 31467 invoked by uid 417); 6 Dec 2004 08:23:16 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 6 Dec 2004 08:23:16 -0000 Received: from XPNERICK ([193.17.42.1]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Mon, 06 Dec 2004 01:23:13 -0700 Message-ID: <01e301c4db6c$afb01540$08091eac@ttitelecom.com> From: "EricLKlein" To: "Alain Durand" Cc: Markku.Ala-Vannesluoma@nokia.com, Francis.Dupont@enst-bretagne.fr, "Margaret Wasserman" , "Jonathan Rosenberg" , henrik@levkowetz.com, v6ops@ops.ietf.org, karen.e.nielsen@ericsson.com References: <004601c4dae5$088cfd00$08091eac@ttitelecom.com> Subject: Re: draft-huitema-v6ops-teredo-03.txt Date: Mon, 6 Dec 2004 10:21:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From Alain > > I am still a little uncomfortable about the fact that there is no > > explicit > > statement that "teredo is needed because NAT was deprecated in IPv6 > > I have never seen any such statement in any RFC defining IPv6. > The very conecpt of unique addressable addresses negates NAT. As it is there will be problems created as people try to use the 10 net addresses fro mtheir IPv4 network on the IPv6 network as those addresses going to pop up in lots of places. Also, there was a large discussion on depreciating NAT last year. I was against depreciating as too many people would resist. This was why draft-vandevelde-v6ops-nap-01_draft1.txt was written. > > > so > > teredo is needed to allow IPv6 nodes to communicate with IPv4 nodes in > > a > > domain that utilizes NAT." > > > > This is still true in section 3.2.4 Automatic sunset. > > Some how this whole section scares me as it seems to imply that there > > is a > > way to turn an IPv4 NAT into an IPv6 Router while maintaining the NAT > > like > > functionality. As stated above, NAT is not part of IPv6 (NAP is but is > > still > > not mentioned in this document). > > 3 points: > > a) nothing will ever prevent anyone from inventing/using IPv6 NAT one > day > You are correct, explicit RFCs stating that NAT is not permitted will have a limited effect, and as you said these have not been published. RFC 3879 Deprecating Site Local Addresses explains why private addresses (like the 10 net) are not good and why they should not be used. > b) when the v4 NAT gets upgraded to do also v6, it still does v4 NAT... > this functionality does not go away... That is correct, the concept goes away. Unique addressable addresses and NAT are mutually exclusive concepts. > c) The only (minor) point I have with section 3.2.4 is with the > sentence: > "upgrading the > Internet connection used by the NAT to a native IPv6 service," > > If the 'upgraded' NAT provides v6 connectivity via a configured tunnel > (maybe using the tunnel set up protocol we want to design in v6tc) > teredo will also detect it (by seeing a native RA on the internal > network) > and turn itself off. > > So I would suggest to simply remove the work 'native' from the above > sentence. The point is that "native IPv4" vs "native IPv6" was added because of the working group's decision to do away with NAT. We had a defined "private" address space in the original IPv6 RFCs, but this was removed in RFC 3879 Deprecating Site Local Addresses. Given this the WG has been working towards preventing IPv6 NAT. Eric From owner-v6ops@ops.ietf.org Mon Dec 6 06:53:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27754 for ; Mon, 6 Dec 2004 06:53:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CbHOx-000OY9-4c for v6ops-data@psg.com; Mon, 06 Dec 2004 11:51:35 +0000 Received: from [194.250.197.211] (helo=proxy.6wind.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CbHOs-000OXY-Vl for v6ops@ops.ietf.org; Mon, 06 Dec 2004 11:51:31 +0000 Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 7DE205260D2; Mon, 6 Dec 2004 12:51:29 +0100 (CET) Received: from 6WIND.com (jardin.dev.6wind.com [10.16.0.239]) by intranet.6wind.com (Postfix) with ESMTP id D6AF8849; Mon, 6 Dec 2004 12:51:27 +0100 (CET) Message-ID: <41B447C3.9070500@6WIND.com> Date: Mon, 06 Dec 2004 12:51:31 +0100 From: Vincent Jardin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman Cc: ericlklein@softhome.net, henrik@levkowetz.com, karen.e.nielsen@ericsson.com, Francis.Dupont@enst-bretagne.fr, Markku.Ala-Vannesluoma@nokia.com, Jonathan Rosenberg , v6ops@ops.ietf.org Subject: Re: draft-huitema-v6ops-teredo-03.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit About the workaround for the symetric NATs: >5.2.10 Working around symmetric NAT > >[...] > In many cases, it is possible to work around the limitations of > these NAT by explicitly reserving a UDP port for Teredo service on a > client, using a function often called "DMZ" in the NAT's manual. > This port will become the "service port" used by the Teredo hosts. > The implementers of Teredo functions in hosts must make sure that > the value of the service port can be explicitly provisioned, so that > user can provision the same value in the host and in the NAT. > > The reservation procedure guarantees that the port mapping will > remain the same for all destinations. After the explicit > reservation, the qualification algorithm in section 5.2.1 will > succeed, and the Teredo client will behave as if behind a "cone > NAT". > We have been testing this for a long time, see the last section from http://www-rp.lip6.fr/teredo/ It is just a workaround, but it is not enough for many reasons. In fact, the proper solution would be to allow Teredo traffic even when a symmetric NAT is detected by the client. Then, all these Teredo packets, that are sent to the hosts behind the symmetric NAT, must be forwarded thru their Teredo relay. I understand that it will lead to a lot of traffic, but it should not be so much (about 24 % of the NAT do not support hole punching) because there are few symmetric NATs, however it is a simple solution that helps Teredo to be fully reliable. Best regards, Vincent Margaret Wasserman wrote: > > Hi Eric, Henrik, Karen, Francis, Markku and Jonathan, > > There is a new version of the Teredo draft available at: > > http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-03.txt > > Could you check whether this version addresses the issues that you > raised during IETF LC? It would be best if you could review this > document and return any feedback by this Thursday, 9-Dec-04. > > If there are no further objections, I will place this draft on the > IESG agenda for consideration on our 16-Dec-04 telechat. > > Thanks! > > Margaret > From owner-v6ops@ops.ietf.org Mon Dec 6 07:17:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00388 for ; Mon, 6 Dec 2004 07:17:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CbHnE-0001fJ-Ad for v6ops-data@psg.com; Mon, 06 Dec 2004 12:16:40 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CbHn4-0001dS-RQ for v6ops@ops.ietf.org; Mon, 06 Dec 2004 12:16:31 +0000 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 215638; Mon, 06 Dec 2004 07:09:47 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <004601c4dae5$088cfd00$08091eac@ttitelecom.com> References: <004601c4dae5$088cfd00$08091eac@ttitelecom.com> Date: Mon, 6 Dec 2004 07:16:21 -0500 To: "EricLKlein" , henrik@levkowetz.com, karen.e.nielsen@ericsson.com, Francis.Dupont@enst-bretagne.fr, Markku.Ala-Vannesluoma@nokia.com, "Jonathan Rosenberg" From: Margaret Wasserman Subject: Re: draft-huitema-v6ops-teredo-03.txt Cc: v6ops@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Eric, I am not quite sure how to respond to your post, because I am not sure that parts of it are applicable to Teredo at all... At 6:11 PM +0200 12/5/04, EricLKlein wrote: >I am still a little uncomfortable about the fact that there is no explicit >statement that "teredo is needed because NAT was deprecated in IPv6 so >teredo is needed to allow IPv6 nodes to communicate with IPv4 nodes in a >domain that utilizes NAT." While we can certainly hope that IPv6<=>IPv6 NAT is never necessary, it is not possible for the IETF to "deprecate NAT in IPv6". If administrators ever have a reason to use NAT in IPv6, there is nothing we can do to stop them. Or are you talking about NAT-PT (Network Address Translation with Protocol Translation) that translates between IPv4 and IPv6? If you are talking about NAT-PT, then I still don't understand your point. Teredo allows access to the IPv6 Internet for IPv6-capable nodes that are located behind an IPv4 NAT on networks where their ISP does not provide native IPv6 service. Those nodes cannot tunnel to the IPv6 Internet using other defined methods (i.e. 6to4) because those methods don't work through an IPv4 NAT. Teredo is merely a mechanism to set-up the tunnel through an IPv4 NAT, so that IPv6 connectivity can be obtained. Teredo really doesn't have anything to do with IPv6<=>IPv6 NAT or NAT-PT. >This is still true in section 3.2.4 Automatic sunset. >Some how this whole section scares me as it seems to imply that there is a >way to turn an IPv4 NAT into an IPv6 Router while maintaining the NAT like >functionality. As stated above, NAT is not part of IPv6 (NAP is but is still >not mentioned in this document). In time, I actually expect that there will be home gateways that provide IPv4 NAT and IPv6 routing with a stateful firewall for protection. At least, I hope so. If I have a router like that _AND_ my ISP offers native IPv6 connectivity, then I won't need Teredo. That's what the sunset clause is all about... Why is that scary? Margaret From owner-v6ops@ops.ietf.org Mon Dec 6 07:39:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06377 for ; Mon, 6 Dec 2004 07:39:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CbI8v-0003vs-Cs for v6ops-data@psg.com; Mon, 06 Dec 2004 12:39:05 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CbI8t-0003va-Vi for v6ops@ops.ietf.org; Mon, 06 Dec 2004 12:39:04 +0000 Received: (qmail 6395 invoked by uid 417); 6 Dec 2004 12:39:03 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 6 Dec 2004 12:39:03 -0000 Received: from XPNERICK ([193.17.42.1]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Mon, 06 Dec 2004 05:39:00 -0700 Message-ID: <022801c4db90$6b85a230$08091eac@ttitelecom.com> From: "EricLKlein" To: henrik@levkowetz.com, karen.e.nielsen@ericsson.com, Francis.Dupont@enst-bretagne.fr, Markku.Ala-Vannesluoma@nokia.com, "Jonathan Rosenberg" , "Margaret Wasserman" Cc: v6ops@ops.ietf.org References: <004601c4dae5$088cfd00$08091eac@ttitelecom.com> Subject: Re: draft-huitema-v6ops-teredo-03.txt Date: Mon, 6 Dec 2004 14:37:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret, My concerns are based on the out come of one of the IETF meetings last year when it was decided by the working group, and then confirmed by the mailing list, that privet addresses (FEC0 etc) were "a bad thing" and were removed from IPv6. At the time I argued that private addresses would need to be used or we would have another case of address space being co-opted like was eventually done in RFC 1918. This long discussion on the list resulted after I responded to a request for those private addresses during the meeting (which I had not attended). After the flame war ended there was a vote in the WG mailing list to depreciate private address spaces. Eventually this lead to the various drafts about doing away with NAT (for example draft-vandevelde-v6ops-nap-01). My concerns with this teredo document is that it seems to indicate that there may be a way to provide NAT on a private address space in IPv6. All I am asking for is wording that shows that the NAT is still IPv4 and is not IPv6 after the router is "upgraded" and not that there is a transition from IPv4 to IPv6. My understanding is that this is a work around to connect IPv6 hosts to IPv4 hosts that "NATted". This is fine. It makes sense to me as there are going to be IPv4 networks around for quite a while and the interconnection is necessary. But please don't create false impressions that private address spaces or NAT will exist in the IPv6 space, or change the WG ruling and put private addresses and NAT back. I am sure that there are people who would prefer it that way (mostly network administrators) and those who don't want to bring them back (mostly hardware and software developers). All I want is a consistent message to go out from this WG as to the status of private addresses and NAT. Eric ----- Original Message ----- From: "Margaret Wasserman" > > Hi Eric, > > I am not quite sure how to respond to your post, because I am not > sure that parts of it are applicable to Teredo at all... From owner-v6ops@ops.ietf.org Mon Dec 6 07:54:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09101 for ; Mon, 6 Dec 2004 07:54:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CbIMF-0005TX-4e for v6ops-data@psg.com; Mon, 06 Dec 2004 12:52:51 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CbIM9-0005Sr-53 for v6ops@ops.ietf.org; Mon, 06 Dec 2004 12:52:45 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iB6CqiR2001206 for ; Mon, 6 Dec 2004 13:52:44 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Dec 2004 13:52:43 +0100 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id YLNK1WB4; Mon, 6 Dec 2004 13:52:43 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Dec 2004 13:52:43 +0100 Message-ID: X-Sybari-Trust: a9d67b9e 96d33411 d321a55e 00000138 From: "Karen E. Nielsen (AH/LMD)" To: "'Margaret Wasserman'" , "'Christian Huitema'" Cc: v6ops@ops.ietf.org Subject: RE: draft-huitema-v6ops-teredo-03.txt Date: Mon, 6 Dec 2004 13:52:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 06 Dec 2004 12:52:43.0959 (UTC) FILETIME=[7A77B470:01C4DB92] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Margaret, Christian, The issues I raised have been addressed in the new version to the extend that the text in section 5.4 now seems complete. Based on the assumption that "there is no trusted entry" in 2) and 3) of Section 5.4 means: "there exists no valid entry OR there exists an un-trusted valid entry". I do have one follow-up question however: The Teredo Relay in some aspects compares to a standard last hop IPv6 router and the list of recent Teredo peers (as well as the operational procedures in this respect) in many aspect compares to the Neighbour Cache and the NUD operation that should be maintained by such a router. Routers send Destination Unreachable back to origin when address resolution fails, which may be performed by the router whenever a NC entry doesn't exists (initially or after the time out and consequent erase of a NC entry) Assuming that we are in the situation where no valid Teredo peer entry exists, then here it seems: i) In case 2) a peer entry in trusted state is created without confirming the reachability of the peer. ii) Reachability of the peer is verified while the packet is queued. When "unreachable" no entry is created/ existing entries are deleted. I may understand the difference in between these two cases from the Teredo perspective, i.e., cone NAT or not. The question I would like to raise is to what extend we are concerned with trying to emulate the NUD based black hole detection performed by standard last hop routers - Were we to be very concerned with that then, as I think Christian has pointed out on the list at some point, it could make sense for a Teredo Relay: 2a) In case of no valid entry and cone NAT (Case 2): To queue packets while rechability is being verified. Do not create entry and Send back Destination Unreachable when reachability cannot be ascertained. 3a) (Case 3): Send back Destination Unreachable when reachability cannot be ascertained. Even, if we do not want to mandate (SHOULD) the above behaviour, I wonder whether it wouldn't be valuable to add some text discussing this. Additionally but somewhat similar, then I wonder how the "silently discard" in the last paragraph of Section 5.4.2 compares with the standard Ipv6 redirect behaviour. BR, Karen > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Sunday, December 05, 2004 4:47 PM > To: ericlklein@softhome.net; henrik@levkowetz.com; Karen E. Nielsen > (AH/LMD); Francis.Dupont@enst-bretagne.fr; > Markku.Ala-Vannesluoma@nokia.com; Jonathan Rosenberg > Cc: v6ops@ops.ietf.org > Subject: draft-huitema-v6ops-teredo-03.txt > > > > Hi Eric, Henrik, Karen, Francis, Markku and Jonathan, > > There is a new version of the Teredo draft available at: > > http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-03.txt > > Could you check whether this version addresses the issues that you > raised during IETF LC? It would be best if you could review this > document and return any feedback by this Thursday, 9-Dec-04. > > If there are no further objections, I will place this draft on the > IESG agenda for consideration on our 16-Dec-04 telechat. > > Thanks! > > Margaret > From owner-v6ops@ops.ietf.org Mon Dec 6 07:56:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09544 for ; Mon, 6 Dec 2004 07:56:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CbIQ2-00067N-KS for v6ops-data@psg.com; Mon, 06 Dec 2004 12:56:46 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CbIPt-000662-De for v6ops@ops.ietf.org; Mon, 06 Dec 2004 12:56:37 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iB6Cuai3004102 for ; Mon, 6 Dec 2004 12:56:36 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 MAA13634 for ; Mon, 6 Dec 2004 12:56:23 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iB6CuN201940 for v6ops@ops.ietf.org; Mon, 6 Dec 2004 12:56:23 GMT Date: Mon, 6 Dec 2004 12:56:23 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft-huitema-v6ops-teredo-03.txt Message-ID: <20041206125623.GH1395@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <004601c4dae5$088cfd00$08091eac@ttitelecom.com> <022801c4db90$6b85a230$08091eac@ttitelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <022801c4db90$6b85a230$08091eac@ttitelecom.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-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Dec 06, 2004 at 02:37:10PM +0200, EricLKlein wrote: > > All I want is a consistent message to go out from this WG as to the status > of private addresses and NAT. I'm confused from what you write Eric. Private addresses exist in IPv6, as ULAs or CA ULAs. "Site locals" were deprecated, but ULAs are different (reducing the ambiguity issue) and CA ULAs different again (in theory removing the ambiguity issue). NAT could be used for IPv6, but anyone doing so is shooting themselves in the foot and should just stick with IPv4+NAT. Many sites will use IPv4+NAT alongside IPv6 (without NAT). They can then use IPv6 for more advanced p2p and inter-site applications, and use IPv4 for legacy apps like mail and web browsing. Tim From owner-v6ops@ops.ietf.org Mon Dec 6 08:22:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13017 for ; Mon, 6 Dec 2004 08:22:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CbIoJ-0009FC-KB for v6ops-data@psg.com; Mon, 06 Dec 2004 13:21:51 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CbIoI-0009Ex-Ha for v6ops@ops.ietf.org; Mon, 06 Dec 2004 13:21:50 +0000 Received: (qmail 17488 invoked by uid 417); 6 Dec 2004 13:21:50 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 6 Dec 2004 13:21:50 -0000 Received: from XPNERICK ([193.17.42.1]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Mon, 06 Dec 2004 06:21:48 -0700 Message-ID: <024901c4db96$668d7360$08091eac@ttitelecom.com> From: "EricLKlein" To: "Tim Chown" , v6ops@ops.ietf.org References: <004601c4dae5$088cfd00$08091eac@ttitelecom.com> <022801c4db90$6b85a230$08091eac@ttitelecom.com> <20041206125623.GH1395@login.ecs.soton.ac.uk> Subject: Re: draft-huitema-v6ops-teredo-03.txt Date: Mon, 6 Dec 2004 15:20:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim, > > > > All I want is a consistent message to go out from this WG as to the status > > of private addresses and NAT. > > I'm confused from what you write Eric. > > Private addresses exist in IPv6, as ULAs or CA ULAs. "Site locals" were > deprecated, but ULAs are different (reducing the ambiguity issue) and > CA ULAs different again (in theory removing the ambiguity issue). A ULA is not truly the same as private addresses. Private addresses are those "un-routable" addresses codified in RFC 1918 for IPv4 and were originally defined as FEC0:: through FEC8:: in IPv6. These were basically removed because they were not unique. ULAs by defination are unique (hence that first U). > NAT could be used for IPv6, but anyone doing so is shooting themselves in the > foot and should just stick with IPv4+NAT. Agreed, not to mention that they would be going against the spirit of unique addressable. > Many sites will use IPv4+NAT alongside IPv6 (without NAT). They can then > use IPv6 for more advanced p2p and inter-site applications, and use IPv4 > for legacy apps like mail and web browsing. > I agree with this and I anticipate that it will remain this way for may years to come. Eric From owner-v6ops@ops.ietf.org Mon Dec 6 08:28:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13389 for ; Mon, 6 Dec 2004 08:28:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CbIu9-0009zj-Ff for v6ops-data@psg.com; Mon, 06 Dec 2004 13:27:53 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CbIu8-0009xb-99 for v6ops@ops.ietf.org; Mon, 06 Dec 2004 13:27:52 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iB6DRpi3004591 for ; Mon, 6 Dec 2004 13:27:51 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 NAA15263 for ; Mon, 6 Dec 2004 13:27:35 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iB6DRZM02488 for v6ops@ops.ietf.org; Mon, 6 Dec 2004 13:27:35 GMT Date: Mon, 6 Dec 2004 13:27:35 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft-huitema-v6ops-teredo-03.txt Message-ID: <20041206132735.GL1395@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <004601c4dae5$088cfd00$08091eac@ttitelecom.com> <022801c4db90$6b85a230$08091eac@ttitelecom.com> <20041206125623.GH1395@login.ecs.soton.ac.uk> <024901c4db96$668d7360$08091eac@ttitelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024901c4db96$668d7360$08091eac@ttitelecom.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-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Dec 06, 2004 at 03:20:03PM +0200, EricLKlein wrote: > > A ULA is not truly the same as private addresses. Private addresses are > those "un-routable" addresses codified in RFC 1918 for IPv4 and were > originally defined as FEC0:: through FEC8:: in IPv6. These were basically > removed because they were not unique. ULAs by defination are unique (hence > that first U). So why do we then have CA ULAs? ;) ULA space is just private address space where bets are off on ambiguity, but mainly if your "random"" number generator throws up 40 or 41 zeroes... as many will. Tim From owner-v6ops@ops.ietf.org Tue Dec 7 04:47:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06605 for ; Tue, 7 Dec 2004 04:47:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cbbsn-000LKh-E6 for v6ops-data@psg.com; Tue, 07 Dec 2004 09:43:45 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1Cbbsm-000LKD-3V for v6ops@ops.ietf.org; Tue, 07 Dec 2004 09:43:44 +0000 Received: (qmail 31435 invoked by uid 417); 7 Dec 2004 09:43:43 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 7 Dec 2004 09:43:43 -0000 Received: from XPNERICK ([193.17.42.1]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Tue, 07 Dec 2004 02:43:39 -0700 Message-ID: <001701c4dc41$16cb1750$08091eac@ttitelecom.com> From: "EricLKlein" To: "=?iso-8859-1?Q?R=E9mi_Despr=E9s?=" , "Margaret Wasserman" , "Jonathan Rosenberg" , Markku.Ala-Vannesluoma@nokia.com, Francis.Dupont@enst-bretagne.fr, karen.e.nielsen@ericsson.com, henrik@levkowetz.com Cc: "Christian Huitema" , v6ops@ops.ietf.org References: <003e01c4dc3f$3762f8e0$0200a8c0@Rmi> Subject: Re: draft-huitema-v6ops-teredo-03.txt Date: Tue, 7 Dec 2004 11:42:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit From: "Rémi Després" > 2. NAT definition > > The document neither includes a definition of NATs, nor refers to a document > which does it. > > It would help if the scope of NATs considered in the document would be > concisely delimited, e.g. with the definition: > > "NATs referred to in this document are the IPv4-only mechanism which, at > least for some restricted applications, provide access to the IPv4 global > address space from IPv4 private address spaces, and which use for this > stateful address translation and possibly stateful port number translation." > This text would resolve my concerns as well. Eric From owner-v6ops@ops.ietf.org Wed Dec 8 13:55:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23856 for ; Wed, 8 Dec 2004 13:55:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cc6vw-000I54-5D for v6ops-data@psg.com; Wed, 08 Dec 2004 18:53:04 +0000 Received: from [193.252.22.29] (helo=smtp2.wanadoo.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cc6vs-000I4M-4o for v6ops@ops.ietf.org; Wed, 08 Dec 2004 18:53:00 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0201.wanadoo.fr (SMTP Server) with SMTP id 300F01C00477; Wed, 8 Dec 2004 19:52:59 +0100 (CET) Received: from Rmi (APuteaux-105-1-3-162.w80-11.abo.wanadoo.fr [80.11.85.162]) by mwinf0201.wanadoo.fr (SMTP Server) with ESMTP id C35D31C00448; Wed, 8 Dec 2004 19:52:58 +0100 (CET) Message-ID: <00c301c4dd57$2336be60$0200a8c0@Rmi> From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= To: "Margaret Wasserman" Cc: "v6ops" References: Subject: Re: draft-huitema-v6ops-teredo-03.txt Date: Wed, 8 Dec 2004 19:52:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Three points: 1. Teredo Client definition The current definition "A node that has some access to the IPv4 Internet and wants to gain access to the IPv6 Internet" is IMHO much too large. It could advantageously be become something like: "A node that has some access to the IPv4 Internet via an IPv4-only node where NAT is operational, and that wants to gain access to the IPv6 Internet" 2. NAT definition The document neither includes a definition of NATs, nor refers to a document which does it. It would help if the scope of NATs considered in the document would be concisely delimited, e.g. with a definition like: "NATs referred to in this document are IPv4-only mechanisms which, at least for some restricted applications, provide access to the IPv4 global address space from some IPv4 private address spaces. They use for this stateful translation of addresses and possibly of port numbers ." 3. Page numbers. In the table of contents page numbers exceed by 1 the appropriate values. Fixing it would improve the document. Rémi (These points were made in a mail already answered by Eric Klein but, sent from an unregistered address, didn't appear in the mailin list.) ----- Original Message ----- From: "Margaret Wasserman" To: ; ; ; ; ; "Jonathan Rosenberg" Cc: Sent: Sunday, December 05, 2004 4:47 PM Subject: draft-huitema-v6ops-teredo-03.txt > > Hi Eric, Henrik, Karen, Francis, Markku and Jonathan, > > There is a new version of the Teredo draft available at: > > http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-03.txt > > Could you check whether this version addresses the issues that you > raised during IETF LC? It would be best if you could review this > document and return any feedback by this Thursday, 9-Dec-04. > > If there are no further objections, I will place this draft on the > IESG agenda for consideration on our 16-Dec-04 telechat. > > Thanks! > > Margaret > > > From owner-v6ops@ops.ietf.org Fri Dec 10 14:55:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10934 for ; Fri, 10 Dec 2004 14:55:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Ccqob-000Os0-ST for v6ops-data@psg.com; Fri, 10 Dec 2004 19:52:33 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CaL0a-00094k-EB for v6ops@ops.ietf.org; Fri, 03 Dec 2004 21:30:32 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iB3LTiQ12227; Fri, 3 Dec 2004 13:29:44 -0800 (PST) Message-Id: <200412032129.iB3LTiQ12227@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 3964 on Security Considerations for 6to4 Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 03 Dec 2004 13:29:44 -0800 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3964 Title: Security Considerations for 6to4 Author(s): P. Savola, C. Patel Status: Informational Date: December 2004 Mailbox: psavola@funet.fi, chirayu@chirayu.org Pages: 41 Characters: 83360 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-6to4-security-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3964.txt The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. This document is a product of the IPv6 Operations Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <041203132753.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3964 --OtherAccess Content-Type: Message/External-body; name="rfc3964.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <041203132753.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Dec 10 21:17:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23159 for ; Fri, 10 Dec 2004 21:17:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CcwmU-000HEm-Kn for v6ops-data@psg.com; Sat, 11 Dec 2004 02:14:46 +0000 Received: from [66.218.79.74] (helo=web80504.mail.yahoo.com) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CcwmT-000HE8-La for v6ops@ops.ietf.org; Sat, 11 Dec 2004 02:14:45 +0000 Message-ID: <20041211021445.56511.qmail@web80504.mail.yahoo.com> Received: from [12.172.242.223] by web80504.mail.yahoo.com via HTTP; Fri, 10 Dec 2004 18:14:45 PST Date: Fri, 10 Dec 2004 18:14:45 -0800 (PST) From: Fred Templin Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt To: v6ops@ops.ietf.org, ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1817587277-1102731285=:52498" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_40_50, HTML_MESSAGE,RCVD_IN_SORBS_WEB autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1817587277-1102731285=:52498 Content-Type: text/plain; charset=us-ascii I am declaring myself as ready and willing to resume the reins as lead author for this document; please let me know how to proceed. Fred L. Templin osprey67@yahoo.com --0-1817587277-1102731285=:52498 Content-Type: text/html; charset=us-ascii
I am declaring myself as ready and willing to resume the reins as
lead author for this document; please let me know how to proceed.
 
Fred L. Templin
 
--0-1817587277-1102731285=:52498-- From owner-v6ops@ops.ietf.org Mon Dec 13 13:30:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06745 for ; Mon, 13 Dec 2004 13:30:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cduu5-000NHy-8S for v6ops-data@psg.com; Mon, 13 Dec 2004 18:26:37 +0000 Received: from [66.218.79.82] (helo=web80512.mail.yahoo.com) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1Cdutu-000NHO-PN for v6ops@ops.ietf.org; Mon, 13 Dec 2004 18:26:26 +0000 Message-ID: <20041213182624.21683.qmail@web80512.mail.yahoo.com> Received: from [63.197.18.101] by web80512.mail.yahoo.com via HTTP; Mon, 13 Dec 2004 10:26:24 PST Date: Mon, 13 Dec 2004 10:26:24 -0800 (PST) From: "Fred L. Templin" Subject: Re: draft-huitema-v6ops-teredo-03.txt To: v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-546555358-1102962384=:20065" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,HTML_20_30, HTML_MESSAGE autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-546555358-1102962384=:20065 Content-Type: text/plain; charset=us-ascii I have a higher-level concern about Teredo than I have seen discussed here. Up to now, I have been approaching these discussions from a theoretical standpoint, but now I have some operational experience. Let's suppose Teredo is published as a standard, and companies start building the Teredo client, server, and host-specific relay functions into their products. Lets also suppose that unsuspecting users beging deploying those products behind vanilla NATs that allow the Teredo UDPs through. Now, suppose some evil vendor (perhaps controlled in some way by a terrorist organization) were to build some sort of function into a product (e.g., a cell phone, a pacemaker, etc.) that allowed the product to "call home" to the vendor or - even worse - allowed the vendor to call out to its deployed devices and take control of them without the owner's explicit consent. This seems like a recipe for global destruction by terrorist organizations - "Automatic Sunset" indeed! Could "teredo" possibly be more aptly named? People and assets need protection. Small groups are necessary for integrity, accountability, and information sharing. Privacy still needs to be supported and respected, but not to the extent that it allows corruption and perversion to flourish without the caring safeguards of local groups of interest, e.g., communities, schools, churches, synagogues, temples, mosques, etc. etc. (Too much privacy is what gave us crimes against society like the 9/11 disaster, the Unabomber, etc.) The answer is in small groups. Not perfect groups, but groups that are accountable for the actions of individual members. Groups that can respect the individuals' privacy, but also provide a central base for healing if any of them embers goes astray. Surely there must be a way to make this work out - and the way has to involve close cooperatrion with a numbre or technologies - not just Teredo alone. Fred L. Templin cktflt@pacbell.net --0-546555358-1102962384=:20065 Content-Type: text/html; charset=us-ascii
I have a higher-level concern about Teredo than I have seen discussed
here. Up to now, I have been approaching these discussions from a
theoretical standpoint, but now I have some operational experience.
 
Let's suppose Teredo is published as a standard, and companies start
building the Teredo client, server, and host-specific relay functions into
their products. Lets also suppose that unsuspecting users beging deploying
those products behind vanilla NATs that allow the Teredo UDPs through.
 
Now, suppose some evil vendor (perhaps controlled in some way by a
terrorist organization) were to build some sort of function into a product
(e.g., a cell phone, a pacemaker, etc.) that allowed the product to "call home"
to the vendor or - even worse - allowed the vendor to call out to its deployed
devices and take control of them without the owner's explicit consent.
This seems like a recipe for global destruction by terrorist organizations -
"Automatic Sunset" indeed! Could "teredo" possibly be more aptly named?
 
People and assets need protection. Small groups are necessary for integrity,
accountability, and information sharing. Privacy still needs to be supported and
respected, but not to the extent that it allows corruption and perversion to flourish
without the caring safeguards of local groups of interest, e.g., communities, schools,
churches, synagogues, temples, mosques, etc. etc. (Too much privacy is
what gave us crimes against society like the 9/11 disaster, the Unabomber,
etc.)
 
The answer is in small groups. Not perfect groups, but groups that are
accountable for the actions of individual members. Groups that can respect
the individuals' privacy, but also provide a central base for healing if any of
them embers goes astray. Surely there must be a way to make this work
out - and the way has to involve close cooperatrion with a numbre or
technologies - not just Teredo alone.
 
Fred L. Templin
   
--0-546555358-1102962384=:20065-- From owner-v6ops@ops.ietf.org Mon Dec 13 13:45:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07796 for ; Mon, 13 Dec 2004 13:45:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CdvBw-000Pbm-PV for v6ops-data@psg.com; Mon, 13 Dec 2004 18:45:04 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CdvBl-000PYW-VP for v6ops@ops.ietf.org; Mon, 13 Dec 2004 18:44:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBDIiq925620 for ; Mon, 13 Dec 2004 20:44:52 +0200 Date: Mon, 13 Dec 2004 20:44:52 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: Take VLAN usage as WG document? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) There seem to be at least 5 people supporting this, with no opposition. Tim, please publish the latest version as a WG I-D at the start of January unless there are substantial comments before that. (hat off) On Mon, 29 Nov 2004, Pekka Savola wrote: > Hi, > > (co-chair hat on) > > The author has asked if the document describing usage of VLANs for IPv6 > deployed could be taken as a WG document: > > http://www.ietf.org/internet-drafts/draft-chown-v6ops-vlan-usage-02.txt > > This is in the charter, and useful as an Informational document. > > Please say what you think. Silence DOES NOT indicate consent. If new work > items are to be adopted, there must be active support for doing it, and there > must be people willing to review and work on the draft. > > The deadline for comments is in about 1.5 weeks, on December 8th. > > (hat off) > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Dec 13 15:02:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12513 for ; Mon, 13 Dec 2004 15:02:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CdwMw-0008hp-5C for v6ops-data@psg.com; Mon, 13 Dec 2004 20:00:30 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CdwMl-0008fu-Cz for v6ops@ops.ietf.org; Mon, 13 Dec 2004 20:00:19 +0000 Received: from [10.0.0.58] ([217.86.138.31]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.1.R) with ESMTP id md50000646587.msg for ; Mon, 13 Dec 2004 21:06:43 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 13 Dec 2004 21:00:09 +0100 Subject: Re:Take VLAN usage as WG document? 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: 217.86.138.31 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Mon, 13 Dec 2004 21:06:45 +0100 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You have one more now (we used this since 3 or more years in some deployments), sorry, I was unable to follow the list all the time last weeks. Regards, Jordi > De: Pekka Savola > Responder a: > Fecha: Mon, 13 Dec 2004 20:44:52 +0200 (EET) > Para: > Asunto: Re: Take VLAN usage as WG document? > > Hi, > > (co-chair hat on) > > There seem to be at least 5 people supporting this, with no > opposition. > > Tim, please publish the latest version as a WG I-D at the start of > January unless there are substantial comments before that. > > (hat off) > > On Mon, 29 Nov 2004, Pekka Savola wrote: > >> Hi, >> >> (co-chair hat on) >> >> The author has asked if the document describing usage of VLANs for IPv6 >> deployed could be taken as a WG document: >> >> http://www.ietf.org/internet-drafts/draft-chown-v6ops-vlan-usage-02.txt >> >> This is in the charter, and useful as an Informational document. >> >> Please say what you think. Silence DOES NOT indicate consent. If new work >> items are to be adopted, there must be active support for doing it, and there >> must be people willing to review and work on the draft. >> >> The deadline for comments is in about 1.5 weeks, on December 8th. >> >> (hat off) >> >> > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Dec 13 15:28:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15929 for ; Mon, 13 Dec 2004 15:28:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cdwn5-000BUF-AM for v6ops-data@psg.com; Mon, 13 Dec 2004 20:27:31 +0000 Received: from [66.218.79.71] (helo=web80501.mail.yahoo.com) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1Cdwmu-000BT9-T3 for v6ops@ops.ietf.org; Mon, 13 Dec 2004 20:27:20 +0000 Message-ID: <20041213202720.26381.qmail@web80501.mail.yahoo.com> Received: from [63.197.18.101] by web80501.mail.yahoo.com via HTTP; Mon, 13 Dec 2004 12:27:20 PST Date: Mon, 13 Dec 2004 12:27:20 -0800 (PST) From: "Fred L. Templin" Subject: Re: draft-huitema-v6ops-teredo-03.txt To: "Fred L. Templin" , v6ops@ops.ietf.org In-Reply-To: <20041213182624.21683.qmail@web80512.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1339599971-1102969640=:24965" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,HTML_20_30, HTML_MESSAGE autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1339599971-1102969640=:24965 Content-Type: text/plain; charset=us-ascii This is ab it incomplete; not only are small groups needed, but there also needs to be ways to track the accountability of the small groups. Hierarchical organizations, are needed from the top-down level. For example, the US goverment is organized as a hierarchy of federal, state, county, and local communities with accountability feeding from the lower levels up the chain. This is NOT to say there should be a "big brother" wacthing over everyone - only that a consistent and fair manner of governing the small groups through hierarchies be in place - with the ability for goverment to step in if and only if groups or individuals go astray. A hybrid bridge/router/firewall approach with the ISATP router as the point of demarcation for communications destined to the local group and bridging for VLANs passing through to other local groups supports this hierarchy. The ISATP router is alsot the correct location for a just-in-time firewall before any harmful communicatins can reach an unprotected final destination. Fred L. Templin cktflt@pacbell.net "Fred L. Templin" wrote: The answer is in small groups. Not perfect groups, but groups that are accountable for the actions of individual members. Groups that can respect the individuals' privacy, but also provide a central base for healing if any of them embers goes astray. Surely there must be a way to make this work out - and the way has to involve close cooperatrion with a numbre or technologies - not just Teredo alone. Fred L. Templin cktflt@pacbell.net --0-1339599971-1102969640=:24965 Content-Type: text/html; charset=us-ascii
This is ab it incomplete; not only are small groups needed, but there
also needs to be ways to track the accountability of the small groups.
Hierarchical organizations, are needed from the top-down level. For
example, the US goverment is organized as a hierarchy of federal,
state, county, and local communities with accountability feeding
from the lower levels up the chain. This is NOT to say there should
be a "big brother" wacthing over everyone - only that a consistent
and fair manner of governing the small groups through hierarchies
be in place - with the ability for goverment to step in if and only
if groups or individuals go astray.
 
A hybrid bridge/router/firewall approach with the ISATP router as the point of
demarcation for communications destined to the local group and bridging
for VLANs passing through to other local groups supports this hierarchy.
The ISATP router is alsot the correct location for a just-in-time firewall
before any harmful communicatins can reach an unprotected final
destination.
 
Fred L. Templin
  

"Fred L. Templin" <cktflt@pacbell.net> wrote:
The answer is in small groups. Not perfect groups, but groups that are
accountable for the actions of individual members. Groups that can respect
the individuals' privacy, but also provide a central base for healing if any of
them embers goes astray. Surely there must be a way to make this work
out - and the way has to involve close cooperatrion with a numbre or
technologies - not just Teredo alone.
 
Fred L. Templin
   
--0-1339599971-1102969640=:24965-- From owner-v6ops@ops.ietf.org Tue Dec 14 15:43:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15510 for ; Tue, 14 Dec 2004 15:43:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CeJRX-00028k-Td for v6ops-data@psg.com; Tue, 14 Dec 2004 20:38:47 +0000 Received: from [66.218.79.75] (helo=web80505.mail.yahoo.com) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CeJRS-00027u-N6 for v6ops@ops.ietf.org; Tue, 14 Dec 2004 20:38:42 +0000 Message-ID: <20041214203837.265.qmail@web80505.mail.yahoo.com> Received: from [63.197.18.101] by web80505.mail.yahoo.com via HTTP; Tue, 14 Dec 2004 12:38:37 PST Date: Tue, 14 Dec 2004 12:38:37 -0800 (PST) From: "Fred L. Templin" Subject: Re: draft-huitema-v6ops-teredo-03.txt To: huitema@microsoft.com, v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1752083718-1103056717=:98385" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,HTML_20_30, HTML_MESSAGE autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1752083718-1103056717=:98385 Content-Type: text/plain; charset=us-ascii Christain, Based on what you are saying, if terrorists can already exploit the NATs I don't see what good it will do to roll out a red carpet for them by providing a standardiazed tool. What really needs to happen is to fix the NATs themselves. As I said before, a NAT that is also a hybrid bridge/router/firewall can support the security model users expect and still provide the new functionality Ispoke of in the message about governments. etc. The problem is not that the NATs themselves are broken, but rather they are incomplete. The trick comes down to how do we deploy the full functionality across all NATs in a flag day fashion so that people and assets can be protected. And, not just some people, but all people across the world who care to connect to the internet through a NAT. The missing pieces are firewall (with pinhole capabilities) and ISATAP. But, the world itself needs to be ready for this model and understand it completely before moving forward. Fred L. Templin cktflt@pacbell.net --0-1752083718-1103056717=:98385 Content-Type: text/html; charset=us-ascii
Christain,
 
Based on what you are saying, if terrorists can already exploit the NATs I
don't see what good it will do to roll out a red carpet for them by providing
a standardiazed tool. What really needs to happen is to fix the NATs
themselves. As I said before, a NAT that is also a hybrid bridge/router/firewall
can support the security model users expect and still provide the new
functionality Ispoke of in the message about governments. etc. The problem
is not that the NATs themselves are broken, but rather they are incomplete.
The trick comes down to how do we deploy the full functionality across all
NATs in a flag day fashion so that people and assets can be protected. And,
not just some people, but all people across the world who care to connect
to the internet through a NAT. The missing pieces are firewall (with pinhole
capabilities) and ISATAP. But, the world itself needs to be ready for this
model and understand it completely before moving forward.
 
Fred L. Templin
 
--0-1752083718-1103056717=:98385-- From owner-v6ops@ops.ietf.org Tue Dec 14 23:24:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25494 for ; Tue, 14 Dec 2004 23:24:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CeQej-000Pve-5l for v6ops-data@psg.com; Wed, 15 Dec 2004 04:20:53 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CeQei-000PvQ-45 for v6ops@ops.ietf.org; Wed, 15 Dec 2004 04:20:52 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iBF4Kor26669 for ; Wed, 15 Dec 2004 06:20:51 +0200 (EET) X-Scanned: Wed, 15 Dec 2004 06:25:52 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iBF4Pqqk016289 for ; Wed, 15 Dec 2004 06:25:52 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00bw80VG; Wed, 15 Dec 2004 06:25:51 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iBF4KYD23863 for ; Wed, 15 Dec 2004 06:20:34 +0200 (EET) Received: from dadhcp-172019068136.americas.nokia.com ([10.162.252.148]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Dec 2004 06:20:17 +0200 Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068136.americas.nokia.com (8.12.11/8.12.11) with ESMTP id iBF4KD0a013271 for ; Tue, 14 Dec 2004 20:20:15 -0800 Received: (from david@localhost) by dadhcp-172019068136.americas.nokia.com (8.12.11/8.12.11/Submit) id iBF4KCk3013270 for v6ops@ops.ietf.org; Tue, 14 Dec 2004 20:20:12 -0800 Date: Tue, 14 Dec 2004 20:20:11 -0800 From: David Kessens To: v6ops@ops.ietf.org Subject: Request for review: draft-huston-ip6-iana-registry-01.txt Message-ID: <20041215042010.GF4764@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 15 Dec 2004 04:20:18.0142 (UTC) FILETIME=[624017E0:01C4E25D] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I would like to draw your attention to the following draft: draft-huston-ip6-iana-registry-01.txt This draft was recently written by Geoff Huston with the assistance of Kurt Lindqvist, Thomas Narten, Paul Wilson, David Kessens, Bob Hinden and Brian Haberman. The document proposes a revised format for the IANA IPv6 address registry. The proposed format brings the address registry into alignment with the current IPv6 Address Architecture specification, as well as aligning it to the format used for the IPv4 address registry. We would very much welcome your comments to improve this document. Thanks, David Kessens --- From owner-v6ops@ops.ietf.org Wed Dec 15 03:57:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12815 for ; Wed, 15 Dec 2004 03:57:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CeUuZ-000AHP-3b for v6ops-data@psg.com; Wed, 15 Dec 2004 08:53:31 +0000 Received: from [213.197.29.32] (helo=noc.sixxs.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CeUuY-000AH8-7x for v6ops@ops.ietf.org; Wed, 15 Dec 2004 08:53:30 +0000 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id E21D32408E; Wed, 15 Dec 2004 09:53:29 +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 17269-09; Wed, 15 Dec 2004 09:53: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 435BA24087; Wed, 15 Dec 2004 09:53:28 +0100 (CET) Subject: Re: Request for review: draft-huston-ip6-iana-registry-01.txt From: Jeroen Massar To: David Kessens Cc: v6ops@ops.ietf.org In-Reply-To: <20041215042010.GF4764@nokia.com> References: <20041215042010.GF4764@nokia.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-gomDh/9dE7eTyexv4XBp" Organization: Unfix Date: Wed, 15 Dec 2004 09:53:27 +0100 Message-Id: <1103100807.20370.5.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-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-gomDh/9dE7eTyexv4XBp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-12-14 at 20:20 -0800, David Kessens wrote: > I would like to draw your attention to the following draft: >=20 > draft-huston-ip6-iana-registry-01.txt Good idea, flipping through it quickly doesn't reveal any issues either. One thing that might be a good idea though is that IANA offers a whois service which gives a referral to the real whois registry for that prefix. This would allow one to simply have a client that does something in the form of: 8<------------------------------------------ $ whois -h whois.iana.org 2001:db8::1 inet6num: 2001:0DB8::/32 remarks: RIR: APNIC remarks: RFC: RFC 3849 referral: whois.apnic.net ------------------------------------------>8 The huge advantage: client implementors won't ever have to update their clients again, because the question can be asked to the central registry which only outputs a few lines, thus should not be a huge load either. Greets, Jeroen --=-gomDh/9dE7eTyexv4XBp 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/ iD8DBQBBv/uGKaooUjM+fCMRApKzAKCul0o8DSkPG8HJRe+4ZGJ44X7VuwCgtFdc ZPHjJBKEs4ZpgFvoq2E0PcE= =9Bi4 -----END PGP SIGNATURE----- --=-gomDh/9dE7eTyexv4XBp-- From owner-v6ops@ops.ietf.org Wed Dec 15 06:52:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22962 for ; Wed, 15 Dec 2004 06:52:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CeXfn-0008CZ-HE for v6ops-data@psg.com; Wed, 15 Dec 2004 11:50:27 +0000 Received: from [217.32.164.150] (helo=smtp2.smtp.bt.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CeXfm-0008CH-Pp for v6ops@ops.ietf.org; Wed, 15 Dec 2004 11:50:26 +0000 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Wed, 15 Dec 2004 11:51:12 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Dec 2004 11:51:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Request for review: draft-huston-ip6-iana-registry-01.txt Date: Wed, 15 Dec 2004 11:51:10 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A700BE19988@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: Request for review: draft-huston-ip6-iana-registry-01.txt Thread-Index: AcTiYOCDUw7lldfYSESI7e2UnZx8KgAOx9aQ From: To: Cc: X-OriginalArrivalTime: 15 Dec 2004 11:51:10.0716 (UTC) FILETIME=[5ED74BC0:01C4E29C] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On 15 December 2004 04:20, owner-v6ops@ops.ietf.org () wrote: > draft-huston-ip6-iana-registry-01.txt > We would very much welcome your comments to improve this document. Overall this document looks good to me, and it is certainly needed. A few comments: "[3] The IPv6 Unicast space encompasses the entire IPv6 address range with the exception of FF00::/8." ... and FE80::/10, and soon to be FC00::/7 - might be easier to remove this sentence altogether.=20 "The proposed registry format for Global Unicast IPv6 address block allocations is indicated in Figure 2 (Figure 1)." - I guess this should read "(Figure 2)." "[4] The is an experimental allocation to the 6BONE [RFC2471]. Per [RFC3701] this prefix will be returned to the unassigned address pool on the 6th June 2006." - replace "The" with "3FFE::/16" " o The registry continuation lines with three full stops have been removed." - replace "three full stops" with "ellipsis" Regards, Mat From owner-v6ops@ops.ietf.org Wed Dec 15 09:24:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03225 for ; Wed, 15 Dec 2004 09:24:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cea2v-0001c1-FR for v6ops-data@psg.com; Wed, 15 Dec 2004 14:22:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cea2u-0001bn-ED for v6ops@ops.ietf.org; Wed, 15 Dec 2004 14:22:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBFEMSi27982 for ; Wed, 15 Dec 2004 16:22:28 +0200 Date: Wed, 15 Dec 2004 16:22:28 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: Request for review: draft-huston-ip6-iana-registry-01.txt In-Reply-To: <20041215042010.GF4764@nokia.com> Message-ID: References: <20041215042010.GF4764@nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (co-chair hat on) Folks, This is a very short document (a couple of pages only), so if you have comments, please provide them before the start of the holiday season, within about a week. (hat off) On Tue, 14 Dec 2004, David Kessens wrote: > I would like to draw your attention to the following draft: > > draft-huston-ip6-iana-registry-01.txt > > This draft was recently written by Geoff Huston with the assistance of > Kurt Lindqvist, Thomas Narten, Paul Wilson, David Kessens, Bob Hinden > and Brian Haberman. > > The document proposes a revised format for the IANA IPv6 address > registry. The proposed format brings the address registry into > alignment with the current IPv6 Address Architecture specification, as > well as aligning it to the format used for the IPv4 address registry. > > We would very much welcome your comments to improve this document. > > Thanks, > > David Kessens > --- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Dec 16 09:09:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24712 for ; Thu, 16 Dec 2004 09:09:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CewGF-000Bd6-GE for v6ops-data@psg.com; Thu, 16 Dec 2004 14:05:43 +0000 Received: from [66.218.79.73] (helo=web80503.mail.yahoo.com) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CewGE-000Bcq-46 for v6ops@ops.ietf.org; Thu, 16 Dec 2004 14:05:42 +0000 Message-ID: <20041216140541.39988.qmail@web80503.mail.yahoo.com> Received: from [63.197.18.101] by web80503.mail.yahoo.com via HTTP; Thu, 16 Dec 2004 06:05:41 PST Date: Thu, 16 Dec 2004 06:05:41 -0800 (PST) From: "Fred L. Templin" Subject: Re: draft-huitema-v6ops-teredo-03.txt To: huitema@microsoft.com, v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-599950206-1103205941=:37663" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,HTML_20_30, HTML_MESSAGE autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-599950206-1103205941=:37663 Content-Type: text/plain; charset=us-ascii Christian, I am seeing the other side of the coin on this issue now. If teredo provides a tool that a terrorist might like to try using for exploitation, it also provides a means for back-trakcing terrorist activities. So, it comes down to the greater good will of the people of the world to refrain from using it for evil purposes. I have faith in the greater good will of the people of the world and faith also in a God and higher power that people of the earth can acknowledge in their own way. I think teredo should move forward. Freed L. Templin cktflt@pacbell.net Christain, Based on what you are saying, if terrorists can already exploit the NATs I don't see what good it will do to roll out a red carpet for them by providing a standardiazed tool. What really needs to happen is to fix the NATs themselves. As I said before, a NAT that is also a hybrid bridge/router/firewall can support the security model users expect and still provide the new functionality Ispoke of in the message about governments. etc. The problem is not that the NATs themselves are broken, but rather they are incomplete. The trick comes down to how do we deploy the full functionality across all NATs in a flag day fashion so that people and assets can be protected. And, not just some people, but all people across the world who care to connect to the internet through a NAT. The missing pieces are firewall (with pinhole capabilities) and ISATAP. But, the world itself needs to be ready for this model and understand it completely before moving forward. Fred L. Templin cktflt@pacbell.net --0-599950206-1103205941=:37663 Content-Type: text/html; charset=us-ascii
Christian,
 
I am seeing the other side of the coin on this issue now. If teredo provides
a tool that a terrorist might like to try using for exploitation, it also provides
a means for back-trakcing terrorist activities. So, it comes down to the
greater good will of the people of the world to refrain from using it for evil
purposes. I have faith in the greater good will of the people of the world
and faith also in a God and higher power that people of the earth can
acknowledge in their own way. I think teredo should move forward.
 
Freed L. Templin
 
 
 
 
Christain,
 
Based on what you are saying, if terrorists can already exploit the NATs I
don't see what good it will do to roll out a red carpet for them by providing
a standardiazed tool. What really needs to happen is to fix the NATs
themselves. As I said before, a NAT that is also a hybrid bridge/router/firewall
can support the security model users expect and still provide the new
functionality Ispoke of in the message about governments. etc. The problem
is not that the NATs themselves are broken, but rather they are incomplete.
The trick comes down to how do we deploy the full functionality across all
NATs in a flag day fashion so that people and assets can be protected. And,
not just some people, but all people across the world who care to connect
to the internet through a NAT. The missing pieces are firewall (with pinhole
capabilities) and ISATAP. But, the world itself needs to be ready for this
model and understand it completely before moving forward.
 
Fred L. Templin
--0-599950206-1103205941=:37663-- From owner-v6ops@ops.ietf.org Fri Dec 17 03:14:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21956 for ; Fri, 17 Dec 2004 03:13:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CfDCW-000KxS-NW for v6ops-data@psg.com; Fri, 17 Dec 2004 08:11:00 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CfDCS-000Kwt-Cx for v6ops@ops.ietf.org; Fri, 17 Dec 2004 08:10:56 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iBH8Atdt025374 for ; Fri, 17 Dec 2004 01:10:56 -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 <0I8U0010FXE7YI@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 17 Dec 2004 01:10:55 -0700 (MST) Received: from [192.168.1.2] ([83.197.0.197]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I8U00KC3XE45E@mail.sun.net> for v6ops@ops.ietf.org; Fri, 17 Dec 2004 01:10:55 -0700 (MST) Date: Fri, 17 Dec 2004 00:10:52 -0800 From: Alain Durand Subject: Re: Request for review: draft-huston-ip6-iana-registry-01.txt In-reply-to: <20041215042010.GF4764@nokia.com> To: David Kessens Cc: v6ops@ops.ietf.org Message-id: <2B8AEC18-5003-11D9-81E4-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20041215042010.GF4764@nokia.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Dec 14, 2004, at 8:20 PM, David Kessens wrote: > > I would like to draw your attention to the following draft: > > draft-huston-ip6-iana-registry-01.txt > > [3] The IPv6 Unicast space encompasses the entire IPv6 address range with the exception of FF00::/8. This note is good, but I think it might help if in the table in section 2 it was made very clear that the 'Reserved by IETF' allocations were global unicast addresses and not something unspecified. - Alain. From owner-v6ops@ops.ietf.org Fri Dec 17 05:25:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02050 for ; Fri, 17 Dec 2004 05:25:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CfFH2-000Isi-9k for v6ops-data@psg.com; Fri, 17 Dec 2004 10:23:48 +0000 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CfFGw-000Irk-0p for v6ops@ops.ietf.org; Fri, 17 Dec 2004 10:23:42 +0000 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Fri, 17 Dec 2004 10:25:00 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Dec 2004 10:24:59 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Request for review: draft-huston-ip6-iana-registry-01.txt Date: Fri, 17 Dec 2004 10:24:59 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A700BEE4CDC@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: Request for review: draft-huston-ip6-iana-registry-01.txt Thread-Index: AcTiYOCDUw7lldfYSESI7e2UnZx8KgAOx9aQAGGQN0A= From: To: Cc: X-OriginalArrivalTime: 17 Dec 2004 10:24:59.0805 (UTC) FILETIME=[A99064D0:01C4E422] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On 15 December 2004 11:51, owner-v6ops@ops.ietf.org () wrote: > "[3] The IPv6 Unicast space encompasses the entire IPv6 address range > with the exception of FF00::/8." >=20 > ... and FE80::/10, and soon to be FC00::/7 - might be easier to > remove this sentence altogether.=20 Having looked at this again I now realise I was misreading 'IPv6 Unicast' as 'IPv6 Global Unicast' - sorry for the confusion, my comment can be ignored. Mat From owner-v6ops@ops.ietf.org Mon Dec 20 16:25:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09583 for ; Mon, 20 Dec 2004 16:25:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CgUy0-0001pi-Nq for v6ops-data@psg.com; Mon, 20 Dec 2004 21:21:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CgUxw-0001pJ-9x for v6ops@ops.ietf.org; Mon, 20 Dec 2004 21:21:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBKLLEP04429 for ; Mon, 20 Dec 2004 23:21:14 +0200 Date: Mon, 20 Dec 2004 23:21:14 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: I-D ACTION:draft-tschofenig-v6ops-secure-tunnels-03.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI. ---------- Forwarded message ---------- Date: Mon, 20 Dec 2004 15:52:59 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-tschofenig-v6ops-secure-tunnels-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using IPsec to Secure IPv6-over-IPv4 Tunnels Author(s) : H. Tschofenig, et al. Filename : draft-tschofenig-v6ops-secure-tunnels-03.txt Pages : 22 Date : 2004-12-20 This document gives guidance on securing IPv6-in-IPv4 tunnels using IPsec. No additional protocol extensions are described beyond those available with the IPsec framework. This document describes packet formats, IPsec security policy database for various scenarios, address configuration procedures, and the usage of the Extensible Authentication Procotol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-v6ops-secure-tunnels-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-tschofenig-v6ops-secure-tunnels-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-tschofenig-v6ops-secure-tunnels-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Tue Dec 21 04:22:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18685 for ; Tue, 21 Dec 2004 04:22:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cgg9t-0004W7-Fz for v6ops-data@psg.com; Tue, 21 Dec 2004 09:18:21 +0000 Received: from [193.252.22.25] (helo=smtp6.wanadoo.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cgg9m-0004Vh-BR for v6ops@ops.ietf.org; Tue, 21 Dec 2004 09:18:14 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0602.wanadoo.fr (SMTP Server) with SMTP id 773E21C00197; Tue, 21 Dec 2004 10:18:13 +0100 (CET) Received: from Rmi (APuteaux-105-1-1-146.w217-128.abo.wanadoo.fr [217.128.54.146]) by mwinf0602.wanadoo.fr (SMTP Server) with ESMTP id 9AD201C00169; Tue, 21 Dec 2004 10:18:12 +0100 (CET) Message-ID: <026d01c4e73e$00623040$0500a8c0@Rmi> From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Cc: "v6ops" Subject: Re: draft-huitema-v6ops-teredo-03.txt Date: Tue, 21 Dec 2004 10:18:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0268_01C4E746.5EBB0BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,HTML_30_40, HTML_MESSAGE,RCVD_IN_NJABL_PROXY autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0268_01C4E746.5EBB0BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oops! Point 3 below is just an unfortunate mistake. Thanks for ingnoring it. My apologies to authors and to the group. Points 1 and 2 on the other hand relmain valid in my view. R=E9mi ----- Original Message ----- From: "R=E9mi Despr=E9s" To: "Margaret Wasserman" Cc: "v6ops" Sent: Wednesday, December 08, 2004 7:52 PM Subject: Re: draft-huitema-v6ops-teredo-03.txt > Hi, > > > Three points: > > 1. Teredo Client definition > The current definition "A node that has some access to the IPv4 = Internet > and wants to gain access to the IPv6 Internet" is IMHO much too large. > It could advantageously be become something like: > "A node that has some access to the IPv4 Internet via an IPv4-only = node > where NAT is operational, and that wants to gain access to the IPv6 > Internet" > > 2. NAT definition > The document neither includes a definition of NATs, nor refers to a > document which does it. > It would help if the scope of NATs considered in the document would = be > concisely delimited, e.g. with a definition like: "NATs referred to = in this > document are IPv4-only mechanisms which, at least for some restricted > applications, provide access to the IPv4 global address space from = some IPv4 > private address spaces. They use for this stateful translation of addresses > and possibly of port numbers ." > > 3. Page numbers. > In the table of contents page numbers exceed by 1 the appropriate values. > Fixing it would improve the document. > > R=E9mi > (These points were made in a mail already answered by Eric Klein but, = sent > from an unregistered address, didn't appear in the mailin list.) > > > ----- Original Message ----- > From: "Margaret Wasserman" > To: ; ; > ; ; > ; "Jonathan Rosenberg" > > Cc: > Sent: Sunday, December 05, 2004 4:47 PM > Subject: draft-huitema-v6ops-teredo-03.txt > > > > > > Hi Eric, Henrik, Karen, Francis, Markku and Jonathan, > > > > There is a new version of the Teredo draft available at: > > > > = http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-03.txt > > > > Could you check whether this version addresses the issues that you > > raised during IETF LC? It would be best if you could review this > > document and return any feedback by this Thursday, 9-Dec-04. > > > > If there are no further objections, I will place this draft on the > > IESG agenda for consideration on our 16-Dec-04 telechat. > > > > Thanks! > > > > Margaret > > > > > > > > > > ------=_NextPart_000_0268_01C4E746.5EBB0BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Oops! Point 3 below is just an unfortunate mistake.
Thanks for = ingnoring=20 it.
My apologies to authors and to the group.

Points 1 and 2 = on the=20 other hand relmain valid in my view.

R=E9mi


----- = Original=20 Message -----
From: "R=E9mi Despr=E9s" <remi.despres@wanadoo.fr>To:=20 "Margaret Wasserman" <margaret@thingmagic.com>Cc:=20 "v6ops" <v6ops@ops.ietf.org>
Sent: = Wednesday,=20 December 08, 2004 7:52 PM
Subject: Re:=20 draft-huitema-v6ops-teredo-03.txt


> = Hi,
>
>
>=20 Three points:
>
> 1. Teredo Client = definition
>  =20 The current definition "A node that has some access to the IPv4 = Internet
>=20 and wants to gain access to the IPv6 Internet" is IMHO much too=20 large.
>   It could advantageously be become something=20 like:
>   "A node that has some access to the IPv4 = Internet via=20 an IPv4-only node
> where NAT is operational, and that wants to = gain=20 access to the IPv6
> Internet"
>
>  2. NAT=20 definition
>   The document neither includes a = definition of=20 NATs, nor refers to a
> document which does = it.
>   It=20 would help if the scope of NATs considered in the document would = be
>=20 concisely delimited, e.g. with a definition like:  "NATs referred = to=20 in
this
> document are IPv4-only mechanisms which, at least for = some=20 restricted
> applications, provide access to the IPv4 global = address space=20 from some
IPv4
> private address spaces. They use for this = stateful=20 translation of
addresses
> and possibly of port numbers=20 ."
>
>  3. Page numbers.
>   In the = table of=20 contents page numbers exceed by 1 the appropriate
values.
> = Fixing it=20 would improve the document.
>
> R=E9mi
> (These points = were made=20 in a mail already answered by Eric Klein but, sent
> from an = unregistered=20 address, didn't appear in  the mailin = list.)
>
>
> -----=20 Original Message -----
> From: "Margaret Wasserman" <margaret@thingmagic.com>>=20 To: <ericlklein@softhome.net>; = <henrik@levkowetz.com>;
>= ; <karen.e.nielsen@ericsson.com= >;=20 <Francis.Dupont@enst-breta= gne.fr>;
>=20 <Markku.Ala-Vannesluoma@n= okia.com>;=20 "Jonathan Rosenberg"
> <jdrosen@dynamicsoft.com>>=20 Cc: <v6ops@ops.ietf.org>
>=20 Sent: Sunday, December 05, 2004 4:47 PM
> Subject:=20 draft-huitema-v6ops-teredo-03.txt
>
>
> >
> = > Hi=20 Eric, Henrik, Karen, Francis, Markku and Jonathan,
> >
> = >=20 There is a new version of the Teredo draft available at:
> = >
>=20 > http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-03.t= xt
>=20 >
> > Could you check whether this version addresses the = issues that=20 you
> > raised during IETF LC?  It would be best if you = could=20 review this
> > document and return any feedback by this = Thursday,=20 9-Dec-04.
> >
> > If there are no further objections, = I will=20 place this draft on the
> > IESG agenda for consideration on = our=20 16-Dec-04 telechat.
> >
> > Thanks!
> = >
> >=20 Margaret
> >
> >
>=20 >
>
>
>
>

------=_NextPart_000_0268_01C4E746.5EBB0BA0-- From owner-v6ops@ops.ietf.org Tue Dec 21 06:43:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28234 for ; Tue, 21 Dec 2004 06:43:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CgiO7-000JoB-IW for v6ops-data@psg.com; Tue, 21 Dec 2004 11:41:11 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CgiO2-000Jnh-To for v6ops@ops.ietf.org; Tue, 21 Dec 2004 11:41:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBLBf5S21154 for ; Tue, 21 Dec 2004 13:41:05 +0200 Date: Tue, 21 Dec 2004 13:41:05 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: v6ops draft charter Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) The following draft charter was put forward for pre-review of the IESG and IAB a couple of weeks ago. At the start of January, our AD will re-evaluate it and possibly send it to IETF-wide review, or request changes. So, if you have final comments on the charter, please raise try to raise them in about two weeks or so (by 3-4 January). (hat off) ==== Description of Working Group: The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring addressing and connectivity for all IPv4 and IPv6 nodes. The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides guidance for network operators on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations. The main focus of the v6ops WG is to look at the immediate deployment issues; more advanced stages of deployment and transition are a lower priority. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts. This work should primarily be conducted by those areas and WGs which are responsible and best fit to analyze these problems, but v6ops may also cooperate in focusing such work. 2. Publish Informational or BCP RFCs that identify potential security risks in the operation of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or working groups. 3. As a particular instance of (1) and (2), provide feedback to the IPv6 WG regarding portions of the IPv6 specifications that cause, or are likely to cause, operational or security concerns, and work with the IPv6 WG to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs. 4. Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, such as ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks), Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks. These documents should serve as useful guides to network operators and users on possible ways how to deploy IPv6 within their existing IPv4 networks, as well as in new network installations. These documents should not be normative guides for IPv6 deployment, and the primary intent is not capture the needs for new solutions, but rather describe which approaches work and which do not. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops WG may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems. Specifying any protocols or transition mechanisms is out of scope of the WG. Goals and Milestones: Nov 04 Adopt document describing how to use IPsec with draft-ietf-v6ops-mech-v2 as WG item Nov 04 Adopt document describing issues with NAT-PT as WG item Dec 04 Adopt IPv6 Security Overview as WG item Dec 04 Adopt IPv6 deployment using VLANs as WG item Jan 05 Adopt ISP IPv6 Deployment Scenarios in Broadband Access Networks as WG item Jan 05 Adopt IPv6 Network Architecture Protection as WG item Feb 05 Ensure draft-ietf-v6ops-v6onbydefault keeps going forward for RFC publication Feb 05 Submit IPv6 deployment using VLANs to IESG for Info Mar 05 Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG for Info Mar 05 Submit document describing issues with NAT-PT to IESG for Info Apr 05 Submit Enterprise Deployment Analysis to IESG for Info Apr 05 Submit IPv6 Network Architecture Protection to IESG for Info May 05 Submit IPv6 Security Overview to IESG for Info May 05 Submit ISP IPv6 Deployment Scenarios in Broadband Access Networks to IESG for Info ======== From owner-v6ops@ops.ietf.org Wed Dec 22 21:09:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27406 for ; Wed, 22 Dec 2004 21:09:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1ChIMi-000DWl-AH for v6ops-data@psg.com; Thu, 23 Dec 2004 02:06:08 +0000 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1ChIMb-000DUa-Mx for v6ops@ops.ietf.org; Thu, 23 Dec 2004 02:06:02 +0000 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id iBN1xthi005191 for ; Thu, 23 Dec 2004 10:00:10 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Thu Dec 23 10:05:13 2004 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Dec 2004 10:05:08 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: TCP/UDP relay vs. SOCKS64 Date: Thu, 23 Dec 2004 10:01:30 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205EE05@bellnet-mail3.sbell.com.cn> Thread-Topic: TCP/UDP relay vs. SOCKS64 Thread-Index: AcTok1GtXsDMeiukRr2pmUDMmpnHFw== From: "CTO YAN Renxiang" To: X-OriginalArrivalTime: 23 Dec 2004 02:05:08.0699 (UTC) FILETIME=[D3F34AB0:01C4E893] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, all, Both TCP/UDP relay and SOCKS64 are implemented by forwarding connection = to a relay server. TCP/UDP relay is forwarded by router, and relay in relay server.=20 SOCKS64 is forwarded in source host, and relay in SOCKS64 server. Does anyone can tell the essential differences between this two = mechanism? They can be used in which kind of different cases? Another issue is:=20 In RFC 3142, it states:=20 TRT is designed to require no extra modification on IPv6-only initiating hosts, nor that on IPv4-only destination hosts.=20 but in fact, the host is required modification, e.g. DNS resolver.=20 -Renxiang=20 From owner-v6ops@ops.ietf.org Thu Dec 23 03:24:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17665 for ; Thu, 23 Dec 2004 03:24:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1ChOEu-0003is-Lz for v6ops-data@psg.com; Thu, 23 Dec 2004 08:22:28 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1ChOEp-0003iL-TG for v6ops@ops.ietf.org; Thu, 23 Dec 2004 08:22:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBN8L9h18797; Thu, 23 Dec 2004 10:21:12 +0200 Date: Thu, 23 Dec 2004 10:21:09 +0200 (EET) From: Pekka Savola To: CTO YAN Renxiang cc: v6ops@ops.ietf.org Subject: Re: TCP/UDP relay vs. SOCKS64 In-Reply-To: <8634B809B90D6E4AACA4AB0562A1F07205EE05@bellnet-mail3.sbell.com.cn> Message-ID: References: <8634B809B90D6E4AACA4AB0562A1F07205EE05@bellnet-mail3.sbell.com.cn> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 23 Dec 2004, CTO YAN Renxiang wrote: > Both TCP/UDP relay and SOCKS64 are implemented by forwarding connection to a relay server. > TCP/UDP relay is forwarded by router, and relay in relay server. > SOCKS64 is forwarded in source host, and relay in SOCKS64 server. > > Does anyone can tell the essential differences between this two mechanism? > They can be used in which kind of different cases? The most fundamental difference is that socks requires the application to be "socksified" by a modification or a library. TCP/UDP does not. > Another issue is: > > In RFC 3142, it states: > > TRT is designed to require no extra modification on IPv6-only > initiating hosts, nor that on IPv4-only destination hosts. > > but in fact, the host is required modification, e.g. DNS resolver. Modification is not needed on the *host* _itself_, it can also be done in the DNS resolver. And there is no change needed if TRT is used for specific services only, i.e., the IPv6 addresses of the services are entered in the DNS manually. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Dec 23 19:45:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13142 for ; Thu, 23 Dec 2004 19:45:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1ChdWl-000Edz-Ik for v6ops-data@psg.com; Fri, 24 Dec 2004 00:41:55 +0000 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1ChdWd-000EdF-8H for v6ops@ops.ietf.org; Fri, 24 Dec 2004 00:41:49 +0000 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id iBO0Zshi027882 for ; Fri, 24 Dec 2004 08:36:10 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Dec 24 08:41:08 2004 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Fri, 24 Dec 2004 08:40:03 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: re: TCP/UDP relay vs. SOCKS64 Date: Fri, 24 Dec 2004 08:35:30 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205EE09@bellnet-mail3.sbell.com.cn> Thread-Topic: TCP/UDP relay vs. SOCKS64 Thread-Index: AcTo0EV0jZOVPOUBR8unsFpbChqBGwAf10ng From: "CTO YAN Renxiang" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 24 Dec 2004 00:40:03.0570 (UTC) FILETIME=[1B782D20:01C4E951] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On Fri, 24 Dec 2004, Pekka Savola [mailto:pekkas@netcore.fi] wrote: >=20 >=20 > On Thu, 23 Dec 2004, CTO YAN Renxiang wrote: > > Both TCP/UDP relay and SOCKS64 are implemented by=20 > forwarding connection to a relay server. > > TCP/UDP relay is forwarded by router, and relay in relay server. > > SOCKS64 is forwarded in source host, and relay in SOCKS64 server. > > > > Does anyone can tell the essential differences between this=20 > two mechanism? > > They can be used in which kind of different cases? >=20 > The most fundamental difference is that socks requires the=20 > application to be "socksified" by a modification or a library. = TCP/UDP does not. Yes, but what's the most important between "socksified" connection and = "non-socksified" connection? When do we need a "socksifed" connection and when does not? For the = security only? >=20 > > Another issue is: > > > > In RFC 3142, it states: > > > > TRT is designed to require no extra modification on IPv6-only > > initiating hosts, nor that on IPv4-only destination hosts. > > > > but in fact, the host is required modification, e.g. DNS resolver. >=20 > Modification is not needed on the *host* _itself_, it can=20 > also be done in the DNS resolver. What did you mean by " *host* _itself_"?=20 >=20 > And there is no change needed if TRT is used for specific services=20 > only, i.e., the IPv6 addresses of the services are entered in the DNS=20 > manually. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 From owner-v6ops@ops.ietf.org Thu Dec 23 20:45:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16962 for ; Thu, 23 Dec 2004 20:45:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CheV8-000MuM-MA for v6ops-data@psg.com; Fri, 24 Dec 2004 01:44:18 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CheV4-000Mu2-1i for v6ops@ops.ietf.org; Fri, 24 Dec 2004 01:44:14 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id F40101C063; Fri, 24 Dec 2004 10:44:12 +0900 (JST) To: Renxiang.Yan@alcatel-sbell.com.cn Cc: v6ops@ops.ietf.org Subject: Re: TCP/UDP relay vs. SOCKS64 In-Reply-To: Your message of "Thu, 23 Dec 2004 10:01:30 +0800" <8634B809B90D6E4AACA4AB0562A1F07205EE05@bellnet-mail3.sbell.com.cn> References: <8634B809B90D6E4AACA4AB0562A1F07205EE05@bellnet-mail3.sbell.com.cn> X-Mailer: Cue version 0.8 (041028-1221/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20041224014412.F40101C063@coconut.itojun.org> Date: Fri, 24 Dec 2004 10:44:12 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > In RFC 3142, it states: > > TRT is designed to require no extra modification on IPv6-only > initiating hosts, nor that on IPv4-only destination hosts. > > but in fact, the host is required modification, e.g. DNS resolver. nope. DNS resolver does not need to be modified. cache DNS server needs to synthesize records, and clients need to use specific cache DNS server (which does synthesize). itojun From owner-v6ops@ops.ietf.org Tue Dec 28 19:39:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18041 for ; Tue, 28 Dec 2004 19:39:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CjRov-00080R-Fz for v6ops-data@psg.com; Wed, 29 Dec 2004 00:36:09 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CjRor-0007zc-Ad for v6ops@ops.ietf.org; Wed, 29 Dec 2004 00:36:05 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 28 Dec 2004 16:36:51 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from sasad-w2k01.cisco.com (sjc-vpn1-505.cisco.com [10.21.97.249]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iBT0a2ID023439; Tue, 28 Dec 2004 16:36:02 -0800 (PST) Message-Id: <4.3.2.7.2.20041228162354.03588ac0@ce-nfs-1.cisco.com> X-Sender: sasad@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Dec 2004 16:34:48 -0800 To: v6ops@ops.ietf.org From: Salman Asadullah Subject: Letest revision of "ISP IPv6 Deployment Scenarios in BB Access Networks" Cc: adahmed@cisco.com, sasad@cisco.com, cpopovic@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_285753631==_.ALT" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_285753631==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hello All, Based on the feedback from WG, we have kept the draft as a single document. http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-02.txt In this latest version we integrated all the comments/suggestions we received from several individuals. A "Gap Analysis" section was added summarizing some of the deployment constraints and issues that require further investigation which are also identified throughout the document. A "Contributors" section is added as well. We would appreciate any further comments/suggestions to improve this work. A big thanks to every one for their valuable feedback. Happy Holidays ! Regards, Salman --=====================_285753631==_.ALT Content-Type: text/html; charset="us-ascii" Hello All,

Based on the feedback from WG, we have kept the draft as a single document.

http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-02.txt

In this latest version we integrated all the comments/suggestions we received from several individuals.

A "Gap Analysis" section was added summarizing some of the deployment constraints and issues that require further
investigation which are also identified throughout the document.  A "Contributors" section is added as well.

We would appreciate any further comments/suggestions to improve this work.

A big thanks to every one for their valuable feedback.

Happy Holidays !

Regards,
Salman

--=====================_285753631==_.ALT--