From owner-v6ops@ops.ietf.org Thu Jun 5 07:46:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16413 for ; Thu, 5 Jun 2003 07:46:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Nt81-0009YE-00 for v6ops-data@psg.com; Thu, 05 Jun 2003 11:41:57 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19Nt7y-0009Wz-00 for v6ops@ops.ietf.org; Thu, 05 Jun 2003 11:41:54 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16129; Thu, 5 Jun 2003 07:41:53 -0400 (EDT) Message-Id: <200306051141.HAA16129@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-unman-scenarios-01.txt Date: Thu, 05 Jun 2003 07:41:53 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Unmanaged Networks IPv6 Transition Scenarios Author(s) : C. Huitema, R. Austein, S. Satapati, R. van der Pol Filename : draft-ietf-v6ops-unman-scenarios-01.txt Pages : 19 Date : 2003-6-4 In order to evaluate the suitability of IPv6 transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the 'unmanaged network', which typically corresponds to a home or small office network. The scenarios are specific to single link subnet, and are defined in terms of IP connectivity supported by the home gateway and the ISP. We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-unman-scenarios-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-unman-scenarios-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-4143558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-unman-scenarios-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-unman-scenarios-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-4143558.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jun 5 17:46:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18432 for ; Thu, 5 Jun 2003 17:46:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19O2XF-000GkQ-00 for v6ops-data@psg.com; Thu, 05 Jun 2003 21:44:37 +0000 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 19O2XC-000Gk7-00 for v6ops@ops.ietf.org; Thu, 05 Jun 2003 21:44:34 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 5 Jun 2003 14:44:33 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 5 Jun 2003 14:44:31 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Jun 2003 14:44:31 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 5 Jun 2003 14:44:30 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Jun 2003 14:44:30 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 5 Jun 2003 14:44:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: I-D ACTION:draft-ietf-v6ops-unman-scenarios-01.txt Date: Thu, 5 Jun 2003 14:44:29 -0700 Message-ID: Thread-Topic: I-D ACTION:draft-ietf-v6ops-unman-scenarios-01.txt Thread-Index: AcMrWxITrfbFX9LUQVG7TXKf7xkZXQAUAdwA From: "Christian Huitema" To: X-OriginalArrivalTime: 05 Jun 2003 21:44:30.0512 (UTC) FILETIME=[A50ED300:01C32BAB] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA18432 The draft "draft-ietf-v6ops-uman-scenarios-01.txt" into account the comments received during the V6OPS WG last call for draft-ietf-v6ops-uman-scenarios-00.txt. The authors believe that this document addresses the last call comments. A list of these comments and the way they were addressed is available at: http://www.huitema.net/ipv6/Unman-Scenarios-Issues.htm The main changes fall in three categories: 1) Change the topology section to explain exactly why we did not consider the multiple subnet case (i.e., with today's technology, such networks are not unmanaged); 2) Change several of the case description scenarios to remove the more-or-less implicit assumption that there is always a NAT in IPv4 deployments; 3) Fix a number of editorial issues, notably the abstract, the introduction, the wording of references to DNS issues, and a split of references between normative and informative. -- Christian Huitema From owner-v6ops@ops.ietf.org Fri Jun 6 10:20:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25716 for ; Fri, 6 Jun 2003 10:20:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OI1c-000HNx-00 for v6ops-data@psg.com; Fri, 06 Jun 2003 14:17:00 +0000 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 19OI1Z-000HNl-00 for v6ops@ops.ietf.org; Fri, 06 Jun 2003 14:16:57 +0000 Received: from IDLEWYLDE.windriver.com ([147.11.233.26]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA29394 for ; Fri, 6 Jun 2003 07:16:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20030606100533.047af1e0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Jun 2003 10:12:41 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: RE: I-D ACTION:draft-ietf-v6ops-unman-scenarios-01.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-25.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, Please review the changes to this document, and let us know if all of your last call issues were adequately resolved. If there are no remaining issues, we hope to forward this document to the IESG by the middle of next week. Thanks, Margaret At 02:44 PM 6/5/2003 -0700, Christian Huitema wrote: >The draft "draft-ietf-v6ops-uman-scenarios-01.txt" into account the >comments received during the V6OPS WG last call for >draft-ietf-v6ops-uman-scenarios-00.txt. The authors believe that this >document addresses the last call comments. A list of these comments and >the way they were addressed is available at: > > http://www.huitema.net/ipv6/Unman-Scenarios-Issues.htm > >The main changes fall in three categories: > >1) Change the topology section to explain exactly why we did not >consider the multiple subnet case (i.e., with today's technology, such >networks are not unmanaged); > >2) Change several of the case description scenarios to remove the >more-or-less implicit assumption that there is always a NAT in IPv4 >deployments; > >3) Fix a number of editorial issues, notably the abstract, the >introduction, the wording of references to DNS issues, and a split of >references between normative and informative. > >-- Christian Huitema From owner-v6ops@ops.ietf.org Fri Jun 6 11:45:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29118 for ; Fri, 6 Jun 2003 11:45:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OJNe-000NmN-00 for v6ops-data@psg.com; Fri, 06 Jun 2003 15:43:50 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19OJNa-000Nlw-00 for v6ops@ops.ietf.org; Fri, 06 Jun 2003 15:43:46 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA17391; Fri, 6 Jun 2003 08:43:45 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h56FhiZ19926; Fri, 6 Jun 2003 08:43:44 -0700 X-mProtect: <200306061543> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmjdnUM; Fri, 06 Jun 2003 08:43:42 PDT Message-ID: <3EE0B6E8.5000503@iprg.nokia.com> Date: Fri, 06 Jun 2003 08:44:40 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-unman-scenarios-01.txt References: <5.1.0.14.2.20030606100533.047af1e0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-36.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret, Not wanting to hold up process, but I'm afraid I do see one item in the changes that somehow escaped my attention earlier. In the abstract, the following new text appears: "The scenarios are specific to single link subnet" In this context, the phrase "single link subnet" seems too restrictive by its inclusion of the word "link". Everywhere else in the document, we see the phrase expressed as "single subnet", and I do agree with this usage. Suggest changing the phrase in the abstract to: "The scenarios are specific to a single subnet" While I'm on the subject, there were a few minor editorial comments: 1) In section 5.2.2, first sentence of the second paragraph, the phrase "NAT will not be in use" appears twice. 2) Section 5.3, end of second sentence should be: "to hosts.", not "the hosts." 3) Section 5.4.2, first sentence of the second paragraph, change: "dual stack host" to "dual stack hosts". Fred ftemplin@iprg.nokia.com Margaret Wasserman wrote: > > Hi All, > > Please review the changes to this document, and let us know if all > of your last call issues were adequately resolved. If there are no > remaining issues, we hope to forward this document to the IESG by > the middle of next week. > > Thanks, > Margaret > > > At 02:44 PM 6/5/2003 -0700, Christian Huitema wrote: > >> The draft "draft-ietf-v6ops-uman-scenarios-01.txt" into account the >> comments received during the V6OPS WG last call for >> draft-ietf-v6ops-uman-scenarios-00.txt. The authors believe that this >> document addresses the last call comments. A list of these comments and >> the way they were addressed is available at: >> >> http://www.huitema.net/ipv6/Unman-Scenarios-Issues.htm >> >> The main changes fall in three categories: >> >> 1) Change the topology section to explain exactly why we did not >> consider the multiple subnet case (i.e., with today's technology, such >> networks are not unmanaged); >> >> 2) Change several of the case description scenarios to remove the >> more-or-less implicit assumption that there is always a NAT in IPv4 >> deployments; >> >> 3) Fix a number of editorial issues, notably the abstract, the >> introduction, the wording of references to DNS issues, and a split of >> references between normative and informative. >> >> -- Christian Huitema > > > > From owner-v6ops@ops.ietf.org Mon Jun 9 12:21:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10373 for ; Mon, 9 Jun 2003 12:21:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PPIm-0004Tq-00 for v6ops-data@psg.com; Mon, 09 Jun 2003 16:15:20 +0000 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19PPIk-0004TQ-00 for v6ops@ops.ietf.org; Mon, 09 Jun 2003 16:15:18 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 05D74437A; Mon, 9 Jun 2003 12:15:15 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 12:15:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-v6ops-unman-scenarios-01.txt Date: Mon, 9 Jun 2003 12:15:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0428491D@tayexc13.americas.cpqcorp.net> Thread-Topic: I-D ACTION:draft-ietf-v6ops-unman-scenarios-01.txt Thread-Index: AcMsN0SLzxGw8vIzQ8uQXnHTWfXT8gCaugKw From: "Bound, Jim" To: "Margaret Wasserman" , X-OriginalArrivalTime: 09 Jun 2003 16:15:15.0656 (UTC) FILETIME=[4FE60480:01C32EA2] X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10373 All my issues are resolved. I think it should go to the IESG. thanks /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Friday, June 06, 2003 10:13 AM > To: v6ops@ops.ietf.org > Subject: RE: I-D ACTION:draft-ietf-v6ops-unman-scenarios-01.txt > > > > Hi All, > > Please review the changes to this document, and let us know > if all of your last call issues were adequately resolved. If > there are no remaining issues, we hope to forward this > document to the IESG by the middle of next week. > > Thanks, > Margaret > > > At 02:44 PM 6/5/2003 -0700, Christian Huitema wrote: > >The draft "draft-ietf-v6ops-uman-scenarios-01.txt" into account the > >comments received during the V6OPS WG last call for > >draft-ietf-v6ops-uman-scenarios-00.txt. The authors believe > that this > >document addresses the last call comments. A list of these > comments and > >the way they were addressed is available at: > > > > http://www.huitema.net/ipv6/Unman-Scenarios-Issues.htm > > > >The main changes fall in three categories: > > > >1) Change the topology section to explain exactly why we did not > >consider the multiple subnet case (i.e., with today's > technology, such > >networks are not unmanaged); > > > >2) Change several of the case description scenarios to remove the > >more-or-less implicit assumption that there is always a NAT in IPv4 > >deployments; > > > >3) Fix a number of editorial issues, notably the abstract, the > >introduction, the wording of references to DNS issues, and a > split of > >references between normative and informative. > > > >-- Christian Huitema > > > > From owner-v6ops@ops.ietf.org Tue Jun 10 07:53:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21816 for ; Tue, 10 Jun 2003 07:53:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Phed-0007Os-00 for v6ops-data@psg.com; Tue, 10 Jun 2003 11:51:07 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19Phea-0007Oe-00 for v6ops@ops.ietf.org; Tue, 10 Jun 2003 11:51:05 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21419; Tue, 10 Jun 2003 07:51:03 -0400 (EDT) Message-Id: <200306101151.HAA21419@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-lee-v6ops-natpt-mobility-00.txt Date: Tue, 10 Jun 2003 07:51:02 -0400 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_20,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Considerations for Mobility Support in NAT-PT Author(s) : M. Shin, J. Lee Filename : draft-lee-v6ops-natpt-mobility-00.txt Pages : 7 Date : 2003-6-9 The document specifies considerations for mobility support in NAT- PT (RFC-2766) [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-v6ops-natpt-mobility-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-lee-v6ops-natpt-mobility-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lee-v6ops-natpt-mobility-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-9150833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lee-v6ops-natpt-mobility-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lee-v6ops-natpt-mobility-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-9150833.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Jun 10 10:09:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01449 for ; Tue, 10 Jun 2003 10:09:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Pjn2-000DKK-00 for v6ops-data@psg.com; Tue, 10 Jun 2003 14:07:56 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19Pjn0-000DK8-00 for v6ops@ops.ietf.org; Tue, 10 Jun 2003 14:07:54 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01208; Tue, 10 Jun 2003 10:07:51 -0400 (EDT) Message-Id: <200306101407.KAA01208@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-huitema-v6ops-teredo-00.txt Date: Tue, 10 Jun 2003 10:07:50 -0400 X-Spam-Status: No, hits=1.5 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Teredo: Tunneling IPv6 over UDP through NATs Author(s) : C. Huitema Filename : draft-huitema-v6ops-teredo-00.txt Pages : 58 Date : 2003-6-9 We propose here a service that enables nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of 'Teredo servers' and 'Teredo relays'; the Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the 'native' IPv6 Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-huitema-v6ops-teredo-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-huitema-v6ops-teredo-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-9151019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-huitema-v6ops-teredo-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-huitema-v6ops-teredo-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-9151019.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Jun 10 11:12:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04916 for ; Tue, 10 Jun 2003 11:12:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Pkks-000GJu-00 for v6ops-data@psg.com; Tue, 10 Jun 2003 15:09:46 +0000 Received: from h000.c001.snv.cp.net ([209.228.32.114] helo=c001.snv.cp.net) by psg.com with smtp (Exim 3.36 #1) id 19Pkkp-000GJi-00 for v6ops@ops.ietf.org; Tue, 10 Jun 2003 15:09:43 +0000 Received: (cpmta 1327 invoked from network); 10 Jun 2003 08:09:41 -0700 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.114) with SMTP; 10 Jun 2003 08:09:41 -0700 X-Sent: 10 Jun 2003 15:09:41 GMT Message-ID: <004f01c32f62$4a548760$03051eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <200306101407.KAA01208@ietf.org> Subject: Re: I-D ACTION:draft-huitema-v6ops-teredo-00.txt Date: Tue, 10 Jun 2003 18:09:27 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-17.6 required=5.0 tests=BAYES_30,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am not sure that I like the idea that traffic originating as IPv4 TCP traffic will be transported by UDP across tunnels to obtain IPv6 connectivity. This requires that the tredo "server" will know to ask for retransmits should anything fail to reach it's destination. Sounds a bit iffy to me, especially as people are looking for more quality of service guarantees and commitments. Eric ----- Original Message ----- From: To: Cc: Sent: Tuesday, June 10, 2003 5:07 PM Subject: I-D ACTION:draft-huitema-v6ops-teredo-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Teredo: Tunneling IPv6 over UDP through NATs > Author(s) : C. Huitema > Filename : draft-huitema-v6ops-teredo-00.txt > Pages : 58 > Date : 2003-6-9 > > We propose here a service that enables nodes located behind one or > several IPv4 NATs to obtain IPv6 connectivity by tunneling packets > over UDP; we call this the Teredo service. Running the service > requires the help of 'Teredo servers' and 'Teredo relays'; the > Teredo servers are stateless, and only have to manage a small > fraction of the traffic between Teredo clients; the Teredo relays > act as IPv6 routers between the Teredo service and the 'native' IPv6 > Internet. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-00.txt From owner-v6ops@ops.ietf.org Tue Jun 10 11:51:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06330 for ; Tue, 10 Jun 2003 11:51:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PlOa-000IOE-00 for v6ops-data@psg.com; Tue, 10 Jun 2003 15:50:48 +0000 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 19PlOW-000INr-00 for v6ops@ops.ietf.org; Tue, 10 Jun 2003 15:50:44 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 10 Jun 2003 08:50:43 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Jun 2003 08:50:42 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Jun 2003 08:50:43 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Jun 2003 08:50:42 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 10 Jun 2003 08:50:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-huitema-v6ops-teredo-00.txt Date: Tue, 10 Jun 2003 08:50:41 -0700 Message-ID: Thread-Topic: I-D ACTION:draft-huitema-v6ops-teredo-00.txt Thread-Index: AcMvZF+2psCqy8QlQKi7bOucU4MG/wAA1ymw From: "Christian Huitema" To: "EricLKlein" , X-OriginalArrivalTime: 10 Jun 2003 15:50:42.0280 (UTC) FILETIME=[0C1C6E80:01C32F68] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA06330 > I am not sure that I like the idea that traffic originating as IPv4 TCP > traffic will be transported by UDP across tunnels to obtain IPv6 > connectivity. > > This requires that the tredo "server" will know to ask for retransmits > should anything fail to reach it's destination. Did you actually read the draft? The stack would be (transport)/IPv6/UDP/IPv4, which gives by and large the same kind of reliability as (transport)/IPv6/IPv4, i.e. the other form of tunneling. Also, only a small fraction of the packets actually go through the server. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Jun 10 12:55:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09024 for ; Tue, 10 Jun 2003 12:55:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PmMh-000Lbk-00 for v6ops-data@psg.com; Tue, 10 Jun 2003 16:52:55 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19PmMd-000Lac-00 for v6ops@ops.ietf.org; Tue, 10 Jun 2003 16:52:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5AGqia24712; Tue, 10 Jun 2003 19:52:44 +0300 Date: Tue, 10 Jun 2003 19:52:44 +0300 (EEST) From: Pekka Savola To: Christian Huitema cc: EricLKlein , Subject: RE: I-D ACTION:draft-huitema-v6ops-teredo-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 10 Jun 2003, Christian Huitema wrote: [...] > Also, only a small fraction of the packets actually go through the > server. One thing to note here: in addition to "Server", the Teredo architecture also includes "Relay". And while only a small fraction of packets go through the server (AFAIR), a large number of them could go through Relay (which are probably often one and the same). So, in practical purposes I believe Eric's comment about "server" can be generalized to be "server or relay". In that vein, please remember that people MAY NOT deploy Teredo as some may envision it, to be used mainly between Teredo hosts only -- but between the hosts and *the rest of the IPv6 Internet*. If you want to deploy IPv6 Internet and IPv6 Teredo Internet separately, you're certainly correct: few packets pass through servers/relays. I do not have that deployment scenario in mind; quite the opposite :-). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Jun 10 13:21:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09807 for ; Tue, 10 Jun 2003 13:21:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Pmnn-000N3F-00 for v6ops-data@psg.com; Tue, 10 Jun 2003 17:20:55 +0000 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #1) id 19Pmnj-000N2Q-00 for v6ops@ops.ietf.org; Tue, 10 Jun 2003 17:20:51 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 10 Jun 2003 10:20:51 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Jun 2003 10:20:51 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Jun 2003 10:20:51 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Jun 2003 10:20:50 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 10 Jun 2003 10:20:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-huitema-v6ops-teredo-00.txt Date: Tue, 10 Jun 2003 10:20:46 -0700 Message-ID: Thread-Topic: I-D ACTION:draft-huitema-v6ops-teredo-00.txt Thread-Index: AcMvcMR+iarViavHTSeZv2DGTcZ1wwAAT1Lw From: "Christian Huitema" To: "Pekka Savola" Cc: "EricLKlein" , X-OriginalArrivalTime: 10 Jun 2003 17:20:50.0072 (UTC) FILETIME=[A3680180:01C32F74] X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA09807 > One thing to note here: in addition to "Server", the Teredo architecture > also includes "Relay". And while only a small fraction of packets go > through the server (AFAIR), a large number of them could go through Relay > (which are probably often one and the same). The traffic between a Teredo host and a native IPv6 host will go through the relay closest to the native IPv6 host. This relay does not have to be the same as the Teredo server. In fact, in our beta deployment, no relay traffic whatsoever goes through the server. In the beta deployment, the native IPv6 hosts are dual stack, and they use their IPv4 connection to send UDP packets directly to the Teredo hosts, using what we call a "host specific relay". Now, there are cases where native hosts cannot run a "host specific relay". Maybe they don't have adequate IPv4 connectivity, e.g. because they are located behind a firewall, or maybe their stack cannot be upgraded to include host specific relay. In these cases, the IPv6 traffic to Teredo hosts will be sent to the closest IPv6 router that advertises a route to the Teredo prefix (3FFE:831F::/32 in the experimental deployment). The traffic will be carried over UDP between the Teredo host and that router, in both directions. > So, in practical purposes I believe Eric's comment about "server" can be > generalized to be "server or relay". The comment was about reliability of the transmission. Reliability is assured end-to-end, e.g. using TCP. > In that vein, please remember that people MAY NOT deploy Teredo as some > may envision it, to be used mainly between Teredo hosts only -- but > between the hosts and *the rest of the IPv6 Internet*. There may be some misunderstanding here. Even in the beta deployment of the Three Degrees application, at least half the hosts are getting IPv6 connectivity using 6to4 or native services. The desired outcome is the deployment of a large number of Teredo relays at locations close to the native IPv6 users, to avoid dog leg routing through remote servers. I expect each of these relays to serve only a small community, i.e. the networks to which they advertise the route to the Teredo prefix. In the Teredo design, a relay only has to accept Teredo traffic from the IPv4 addresses to which it has recently sent Teredo traffic; the relay could in fact implement a form of stateful filtering. > If you want to deploy IPv6 Internet and IPv6 Teredo Internet separately, > you're certainly correct: few packets pass through servers/relays. > > I do not have that deployment scenario in mind; quite the opposite :-). Neither do I. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Jun 10 16:08:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15608 for ; Tue, 10 Jun 2003 16:08:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PpO8-0005b7-00 for v6ops-data@psg.com; Tue, 10 Jun 2003 20:06:36 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19PpO6-0005av-00 for v6ops@ops.ietf.org; Tue, 10 Jun 2003 20:06:34 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA22122; Tue, 10 Jun 2003 13:06:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5AK6WD24809; Tue, 10 Jun 2003 13:06:32 -0700 X-mProtect: <200306102006> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdL2JEp1; Tue, 10 Jun 2003 13:06:30 PDT Message-ID: <3EE63A99.2050303@iprg.nokia.com> Date: Tue, 10 Jun 2003 13:07:53 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-huitema-v6ops-teredo-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian, In the new draft, I see the addition of a new section entitled: "IAB considerations". Other than that, have there been any substantive changes since the previous draft version? (In the future, a changelog would be helpful). Thanks, Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Jun 10 16:20:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16024 for ; Tue, 10 Jun 2003 16:20:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ppaa-0006E0-00 for v6ops-data@psg.com; Tue, 10 Jun 2003 20:19:28 +0000 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #1) id 19PpaX-0006Dl-00 for v6ops@ops.ietf.org; Tue, 10 Jun 2003 20:19:25 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 10 Jun 2003 13:19:24 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 10 Jun 2003 13:19:24 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Jun 2003 13:19:24 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Jun 2003 13:19:24 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Jun 2003 13:19:21 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 10 Jun 2003 13:19:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-huitema-v6ops-teredo-00.txt Date: Tue, 10 Jun 2003 13:19:21 -0700 Message-ID: Thread-Topic: I-D ACTION:draft-huitema-v6ops-teredo-00.txt Thread-Index: AcMvi8PAEclR9sg8Qd+zGh7mt96jPwAAQdQA From: "Christian Huitema" To: "Fred Templin" Cc: X-OriginalArrivalTime: 10 Jun 2003 20:19:22.0628 (UTC) FILETIME=[94965440:01C32F8D] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA16024 > In the new draft, I see the addition of a new section entitled: > "IAB considerations". Other than that, have there been any > substantive changes since the previous draft version? (In > the future, a changelog would be helpful). There are two substantial changes: documenting the IPv4 multicast address used in the local connectivity procedure; and documenting some changes in the local connectivity procedures. The change in local connectivity procedure is to require a unicast bubble as well as a multicast one. The old write up was: if a host receives a multicast bubble from another host, then it can send Teredo packets to the local address. This fails in the "stacked NAT" scenario, e.g. when the local network includes a wireless access point that is also a NAT. (These types of NAT do not decrement the TTL value in IP packets, so multicast works...) It fails because the multicast packet does not refresh the NAT mapping often enough. So, in the new procedure, the hosts send multicast bubbles to discover each other, but they also send unicast bubbles to confirm connectivity when needed. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Jun 10 17:26:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18787 for ; Tue, 10 Jun 2003 17:26:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Pqbi-0009r6-00 for v6ops-data@psg.com; Tue, 10 Jun 2003 21:24:42 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19Pqbd-0009qt-00 for v6ops@ops.ietf.org; Tue, 10 Jun 2003 21:24:38 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA26094 for ; Tue, 10 Jun 2003 14:24:34 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5ALOXe26540 for ; Tue, 10 Jun 2003 14:24:33 -0700 X-mProtect: <200306102124> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnN3uEO; Tue, 10 Jun 2003 14:24:31 PDT Message-ID: <3EE64CE2.1000202@iprg.nokia.com> Date: Tue, 10 Jun 2003 14:25:54 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: question on 'draft-huitema-v6ops-unmaneval-00.txt' References: <5.1.0.14.2.20030528110217.044149b8@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I had one question relative to this document. Is there any reason why an analysis of isatap is not included in section 4.1? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Jun 10 18:35:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21642 for ; Tue, 10 Jun 2003 18:35:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Prh3-000DSo-00 for v6ops-data@psg.com; Tue, 10 Jun 2003 22:34:17 +0000 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #1) id 19Prh1-000DSb-00 for v6ops@ops.ietf.org; Tue, 10 Jun 2003 22:34:15 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 10 Jun 2003 15:34:14 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Jun 2003 15:34:14 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Jun 2003 15:34:14 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Jun 2003 15:34:13 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 10 Jun 2003 15:34:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: question on 'draft-huitema-v6ops-unmaneval-00.txt' Date: Tue, 10 Jun 2003 15:34:15 -0700 Message-ID: Thread-Topic: question on 'draft-huitema-v6ops-unmaneval-00.txt' Thread-Index: AcMvmHcGpSd5myMwRbWoZDN8eoLr8wABviAA From: "Christian Huitema" To: "Fred Templin" , X-OriginalArrivalTime: 10 Jun 2003 22:34:13.0271 (UTC) FILETIME=[6AFC7A70:01C32FA0] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA21642 > I had one question relative to this document. Is there any reason why an > analysis of isatap is not included in section 4.1? No reason in particular. ISATAP would be midway between the two other solutions, 6to4 and tunnel broker. Will fix that in next release. From owner-v6ops@ops.ietf.org Tue Jun 10 19:23:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22632 for ; Tue, 10 Jun 2003 19:23:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PsRS-000G1m-00 for v6ops-data@psg.com; Tue, 10 Jun 2003 23:22:14 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19PsRQ-000G1a-00 for v6ops@ops.ietf.org; Tue, 10 Jun 2003 23:22:12 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA02035; Tue, 10 Jun 2003 16:22:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5ANMBn23742; Tue, 10 Jun 2003 16:22:11 -0700 X-mProtect: <200306102322> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGfVpAj; Tue, 10 Jun 2003 16:22:10 PDT Message-ID: <3EE66875.3080000@iprg.nokia.com> Date: Tue, 10 Jun 2003 16:23:33 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: v6ops@ops.ietf.org Subject: Re: question on 'draft-huitema-v6ops-unmaneval-00.txt' References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This matches my understanding; thanks Christian, Fred ftemplin@iprg.nokia.com Christian Huitema wrote: >>I had one question relative to this document. Is there any reason why >> >> >an > > >>analysis of isatap is not included in section 4.1? >> >> > >No reason in particular. ISATAP would be midway between the two other >solutions, 6to4 and tunnel broker. Will fix that in next release. > From owner-v6ops@ops.ietf.org Tue Jun 10 20:28:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24113 for ; Tue, 10 Jun 2003 20:28:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PtSP-000Jr2-00 for v6ops-data@psg.com; Wed, 11 Jun 2003 00:27:17 +0000 Received: from cms3.etri.re.kr ([129.254.16.13]) by psg.com with esmtp (Exim 3.36 #1) id 19PtSM-000Jql-00 for v6ops@ops.ietf.org; Wed, 11 Jun 2003 00:27:15 +0000 Received: from runic (rune.etri.re.kr [129.254.112.180]) by cms3.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MJXPYB5T; Wed, 11 Jun 2003 09:27:44 +0900 From: "Joo-Chul Lee" To: Cc: "???" Subject: FW: I-D ACTION:draft-lee-v6ops-natpt-mobility-00.txt Date: Wed, 11 Jun 2003 09:26:16 +0900 Message-ID: <010601c32fb0$130a7d70$b470fe81@runic> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0107_01C32FFB.82F22570" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Status: No, hits=-10.9 required=5.0 tests=BAYES_10,ORIGINAL_MESSAGE,RCVD_IN_RFCI version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0107_01C32FFB.82F22570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Folks, I have submitted a new draft on considerations for mobility support in NAT-PT. In SF, we discussed the need for an applicability statement for NAT-PT. I think there is a consideration in NAT-PT when IPv6 end-nodes move and this issues should be also mentioned in the applicability statement. (3GPP scenario and analysis drafts mention that there is a need for transltors, such as NAT-PT, but in this case, current RFC-2766 does not support IPv6 mobile nodes.) This draft can help with working on a NAT-PT applicability document. Thanks, Joo-Chul Lee -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, June 10, 2003 8:51 PM To: IETF-Announce: Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-lee-v6ops-natpt-mobility-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Considerations for Mobility Support in NAT-PT Author(s) : M. Shin, J. Lee Filename : draft-lee-v6ops-natpt-mobility-00.txt Pages : 7 Date : 2003-6-9 The document specifies considerations for mobility support in NAT- PT (RFC-2766) [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-v6ops-natpt-mobility-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-lee-v6ops-natpt-mobility-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lee-v6ops-natpt-mobility-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0107_01C32FFB.82F22570 Content-Type: Message/External-body; name="ATT00043.dat" Content-Disposition: attachment; filename="ATT00043.dat" Content-Transfer-Encoding: 7bit Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-9150833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lee-v6ops-natpt-mobility-00.txt ------=_NextPart_000_0107_01C32FFB.82F22570 Content-Type: Message/External-body; name="draft-lee-v6ops-natpt-mobility-00.txt" Content-Disposition: attachment; filename="draft-lee-v6ops-natpt-mobility-00.txt" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0107_01C32FFB.82F22570-- From owner-v6ops@ops.ietf.org Wed Jun 11 01:19:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29473 for ; Wed, 11 Jun 2003 01:19:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PxzX-00088E-00 for v6ops-data@psg.com; Wed, 11 Jun 2003 05:17:47 +0000 Received: from proxy1.addr.com ([209.249.147.28]) by psg.com with esmtp (Exim 3.36 #1) id 19PxzV-00087w-00 for v6ops@ops.ietf.org; Wed, 11 Jun 2003 05:17:45 +0000 Received: from Downieville.thefinks.com ([66.81.111.138]) by proxy1.addr.com (8.12.8/8.12.8/Submit) with ESMTP id h5B5HXVv013691; Tue, 10 Jun 2003 22:17:34 -0700 (PDT) Message-Id: <5.2.0.9.0.20030610180944.02aef1e0@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 10 Jun 2003 18:22:12 -0700 To: v6ops@ops.ietf.org From: Bob Fink Subject: 6bone phaseout plan for your comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_10,DATE_IN_PAST_03_06,MSG_ID_ADDED_BY_MTA_3 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk v6ops wg Folk, As many of you may know, Bob Hinden and I have been developing a 6bone-phaseout plan since January of this year. Mostly the discussions have taken place on the 6bone list, with the RIRs and at a BOF meeting at the San Francisco IETF. The general consensus is to now ask for it to be published as an RFC to finalize it. I have asked Randy Bush, as Operations AD for IPv6 transition, to process it through the IESG/IETF processes for BCP. I would also encourage any review comments you may have. The ID is at: Thanks, Bob Fink From owner-v6ops@ops.ietf.org Wed Jun 11 03:28:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28262 for ; Wed, 11 Jun 2003 03:28:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Pzzw-000EWY-00 for v6ops-data@psg.com; Wed, 11 Jun 2003 07:26:20 +0000 Received: from h021.c001.snv.cp.net ([209.228.32.135] helo=c001.snv.cp.net) by psg.com with smtp (Exim 3.36 #1) id 19Pzzu-000EWM-00 for v6ops@ops.ietf.org; Wed, 11 Jun 2003 07:26:18 +0000 Received: (cpmta 8741 invoked from network); 11 Jun 2003 00:26:16 -0700 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.135) with SMTP; 11 Jun 2003 00:26:16 -0700 X-Sent: 11 Jun 2003 07:26:16 GMT Message-ID: <005401c32fea$b7aa2620$03051eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: Subject: Re: I-D ACTION:draft-huitema-v6ops-teredo-00.txt Date: Wed, 11 Jun 2003 10:26:02 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I am not sure that I like the idea that traffic originating as IPv4 TCP > traffic will be transported by UDP across tunnels to obtain IPv6 > connectivity. > > This requires that the tredo "server" will know to ask for retransmits > should anything fail to reach it's destination. From: "Christian Huitema" Did you actually read the draft? The stack would be (transport)/IPv6/UDP/IPv4, which gives by and large the same kind of reliability as (transport)/IPv6/IPv4, i.e. the other form of tunneling. Also, only a small fraction of the packets actually go through the server. Yes i did read through the RFC, but as pointed out by Robert Elz : > Reachability is one thing, but you may have to wait for TCP timeouts. > RFC1122, section 4.2.3.5 TCP Connection Failures > Says that the initial SYN has to wait at least 3 minutes... > Note that I've seen some implementation ignoring this > MUST and setting the timer to 12 or 25 seconds, > but never to 100ms. If I am running a TCP connection over IPv4 the retransmit functionality is built into the TCP protocol stack. But if I am then transporting this across a UDP tunnel who handles the TCP retransmits on timeout? The originating TCP application is expecting a response from the distant end host, as that host sees only the UDP it will never know to retransmit. Thus you have a few possibilities: 1. The packets are never acknowledged by the end host so are retransmitted even if they got through and then you get low through put and high bandwidth consumption as everything is always retransmitted. 2. The teredo server handles the acknowledgement as it puts the packet in the tunnel and then you never know if it really made it or not, i.e. your TCP is now really acting as UDP. 3. The end host sends the acknowledgement and thus your UDP is acting like TCP (unlikely option as it is UDP transport). 4. All applications that will use this will have at the application layer acknowledgement / retransmit functionality built into them as the protocol stack by definition does not (also unlikely as it would mean rewriting all applications to check the transport to know if they need to acknowledge or would double acknowledge when using true TCP). Again looking at the applications of this I am most concerned with those applications that are very time sensitive. Think about the problems related voice over IP, it is by default UDP. So if a packet is lost you get a pause or dead air in the conversation. This is fine, but as we start to add more complex applications over IP we will have interconnections between IPv4 and IPv6 (as described in this draft) for quite a while. I would hate to have a telemedicine application running over TCP crossing one of these tunnels. Eric From owner-v6ops@ops.ietf.org Wed Jun 11 03:57:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28762 for ; Wed, 11 Jun 2003 03:57:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Q0TN-000G3c-00 for v6ops-data@psg.com; Wed, 11 Jun 2003 07:56:45 +0000 Received: from moebius2.space.net ([195.30.1.100]) by psg.com with smtp (Exim 3.36 #1) id 19Q0TL-000G3P-00 for v6ops@ops.ietf.org; Wed, 11 Jun 2003 07:56:43 +0000 Received: (qmail 91925 invoked by uid 1007); 11 Jun 2003 07:56:41 -0000 Date: Wed, 11 Jun 2003 09:56:41 +0200 From: Gert Doering To: EricLKlein Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-huitema-v6ops-teredo-00.txt Message-ID: <20030611095641.C67740@Space.Net> References: <005401c32fea$b7aa2620$03051eac@ttitelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <005401c32fea$b7aa2620$03051eac@ttitelecom.com>; from ericlklein@softhome.net on Wed, Jun 11, 2003 at 10:26:02AM +0300 X-NCC-RegID: de.space X-Spam-Status: No, hits=-35.4 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Wed, Jun 11, 2003 at 10:26:02AM +0300, EricLKlein wrote: > If I am running a TCP connection over IPv4 the retransmit functionality is > built into the TCP protocol stack. But if I am then transporting this across > a UDP tunnel who handles the TCP retransmits on timeout? The originating TCP > application is expecting a response from the distant end host, as that host > sees only the UDP it will never know to retransmit. Nah, that's wrong. There is *still* a TCP packet inside the UDP, so the TCP protocol works as usual. It's no different from any other possibly unreliable transport, and especially doesn't mean "TCP mysteriously turns into UDP and looses reliability". Before worrying too much, try to understand "tunneling". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55295 (54837) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Wed Jun 11 06:39:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01894 for ; Wed, 11 Jun 2003 06:39:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Q2zW-000LWJ-00 for v6ops-data@psg.com; Wed, 11 Jun 2003 10:38:06 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19Q2zS-000LVo-00 for v6ops@ops.ietf.org; Wed, 11 Jun 2003 10:38:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5BAbx231770; Wed, 11 Jun 2003 13:37:59 +0300 Date: Wed, 11 Jun 2003 13:37:58 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: Christian Huitema Subject: RE: I-D ACTION:draft-ietf-v6ops-unman-scenarios-01.txt In-Reply-To: <5.1.0.14.2.20030606100533.047af1e0@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, A few issues that I came across while quick-reading through it. I'm not really confortable with the separation to different cases, but by a bit more text I think it would be of sufficient clarity. substantial: ------------ I fear that the unusual cases have not been sufficiently addressed yet; a mention has been added in section 5, but *at least* the same thing should be repeated when going through the cases, so that the reader will not forget the case also includes some (perhaps non-obvious) cases. In the end, I believe most of these issues stem from the definition of "Gateway". Maybe separation to more cases would have been better.. Oh well. Let's see: 5.2 Case B, IPv6 connectivity with provider support In this case the ISP and gateway are both dual stack. The gateway can use native IPv6 connectivity to the ISP and can use an IPv6 prefix allocated by the ISP. ==> add discussion on: - bridge mode CPE's and dual-stack ISP ( - route mode dual stack CPE's which give private IPv4 addresses to hosts is not that interesting IMO) Say, for example: In this case the ISP and gateway are both dual stack. The gateway can use native IPv6 connectivity to the ISP and can use an IPv6 prefix allocated by the ISP. Please note that if the gateway does not need to be aware of IPv6 if it is operating in the bridging mode. (IMO that wording is a bit bad but gives the impression..) 5.3 Case C, IPv6 connectivity without provider support In this case the gateway is dual stack, but the ISP is not. The gateway has been upgraded and offers both IPv4 and IPv6 connectivity the hosts. It cannot rely on the ISP for IPv6 connectivity, because the ISP does not offer ISP connectivity yet. ==> add discussion on: - bridged CPE while the customer does not provide IPv6 support - (routed CPE w/o IPv6 support + global addresses) Say, for example: In this case the gateway is dual stack, but the ISP is not. The gateway has been upgraded and offers both IPv4 and IPv6 connectivity the hosts. It cannot rely on the ISP for IPv6 connectivity, because the ISP does not offer ISP connectivity yet. Please note that when the gateway is operating in the bridging mode, it cannot effectively function as a dual-stack gateway: the hosts in the unmanaged network, often using global IPv4 addresses, will have to obtain IPv6 connectivity directly (A bit bad but again, gives the impression..) The upgraded gateway will behave as an IPv6 router; it will continue ==> note that "router" may not be applicable when bridging is being used.. 5.4 Case D, ISP stops providing native IPv4 connectivity In this case the ISP is IPv6-only, so the gateway loses IPv4 connectivity, and is faced with an IPv6-only service provider. The gateway itself is dual stack, and the unmanaged network includes IPv4 only, IPv6-only and dual stack hosts. Any interaction between hosts in the unmanaged network and IPv4 hosts on the Internet will require the provision of some inter-protocol services by the ISP. ==> bridging considerations..? Replace e.g. with: In this case the ISP is IPv6-only, so the gateway loses IPv4 connectivity, and is faced with an IPv6-only service provider. The gateway itself is dual stack, and the unmanaged network includes IPv4 only, IPv6-only and dual stack hosts. Any interaction between hosts in the unmanaged network and IPv4 hosts on the Internet will require the provision of some inter-protocol services by the ISP. In the case that the gateway is operating in the bridging mode, it cannot provide any IP-level services such as being an IPv4-over-IPv6 tunnel endpoint, or acting as a recursive DNS name server. (or something to that effect.) semi-substantial/editorial: --------------------------- Between the subnet and the ISP access link is a gateway, which may or may not perform NAT and firewall function. A key point of this configuration is that the gateway is typically not "managed". In most cases, it is a simple "appliance", which incorporates some static policies. However, there are many cases in which the gateway is procured and configured by the ISP, and there are also some common cases in which we find two gateways back to back, one managed by the ISP and the other added by the owner of the unmanaged network. ==> reword and add considerations for bridging operation; maybe like: Between the subnet and the ISP access link is a gateway, which may or may not perform NAT and firewall function. A key point of this configuration is that the gateway is typically not "managed". In most cases, it is a simple "appliance", which incorporates some static policies. However, there are many cases in which the gateway is procured and configured by the ISP, and there are also some common cases in which we find two gateways back to back, one managed by the ISP and the other added by the owner of the unmanaged network. Gateways may also function in a bridging mode, making them invisible in the IP layer. .... corresponds to a home or small office network. The scenarios are specific to single link subnet, and are defined in terms of IP connectivity supported by the home gateway and the ISP. We first ==> it might be appropriate to reword "home gateway", because homes are not the only targets here.. ==> same in the beginning of section 5 Local applications typically use ad hoc naming systems. Many of these systems are proprietary; an example of a standard system is the service location protocol (SLP). ==> is the adhoc naming systems really true? I mean, I certainly use DNS at home, but I'm not sure if my home is a typical unmanaged network :-). Randomization of the addresses is not sufficient to guarantee privacy. Usage can be tracked by a variety of other means, from application level "cookies" to complex techniques involving data mining and traffic analysis. However, just because privacy can be breached by other means is not a sufficient reason to enable additional tracking through IPv6 addresses. ==> I have hard time parsing the last sentence? What does it mean, really? "enable additional tracking through IPv6 addresses"? Does this refer to all-out use of RFC3041 or something more? Randomization of the host identifier has some cost: the address management in hosts is more complex for the hosts and the gateway may have to maintain a larger cache of neighbor addresses; however, experience from existing implementation shows that these costs are not overwhelming. Given the limited benefits, it would be unreasonable to require that all hosts use privacy addresses; however, given the limited costs, it is reasonable to require that all unmanaged networks allow use of privacy addresses by those hosts that choose to do so. ==> Also note that this adds a cost if reverse DNS is used (which is written down as a requirement at least under case D). similarly, the case in which the CPE is a router but is not a NAT maps either to case B or case C depending on what the CPE router supports. ==> replace with: similarly, the case in which the CPE is a router but is not a NAT typically maps to case C; when CPE is dual stack, it doesn't really matter whether IPv4 addresses used are private or public. (or even omit after ';') We also observe that providing both IPv4 and IPv6 connectivity in an unmanaged network is not particularly difficult: we have a fair amount of experience using IPv4 in unmanaged networks in parallel with other protocols such as, for example, IPX. ==> this is a bit dubious argument, because such protocols (IPX, NetBEUI) are not routed, but IPv4/IPv6 is. 6 Security Considerations The security solutions currently used in IPv4 networks include a combination of firewall functions in the gateway, authentication and authorization functions in the applications, encryption and authentication services provides by IP security, Transport Layer Security and application specific services, and host-based security products such as anti-virus software, and host firewalls. The applicability of these tools in IPv6 unmanaged networks will be studied in a companion document. ==> I'm not sure if this is good enough, may come against some resistance.. at least, something concrete must be available before the Solutions document can be pushed to the IESG. k to keep it as is for now. editorial: ---------- Between the subnet and the ISP access link is a gateway, which may or may not perform NAT and firewall function. A key point of this ==> s/function/functions/ (?) these systems are proprietary; an example of a standard system is the service location protocol (SLP). ==> add an informative reference here? manages a static IPv4 address; in both case, the IPv4 address or the ==> s/case/cases/ Many of these systems are proprietary; an example of a standard system is the session invitation protocol (SIP) ==> add informative reference to some SIP document? In order to get some clarity, we distinguish three entities involved ==> split from beginning of this sentence to a separate paragraph? maps either to case B or case C depending on what the CPE router ==> s/the CPE /the CPE/ relays such as HTTP proxies, or by network level services such as NAT-PT. Application relays pose several operational problems: first, ==> add informational ref to NAT-PT. In some networks, NAT will not be in use and the local hosts will actually obtain global IPv4 addresses NAT will not be in use. We ==> s/NAT will not be in use// (the latter one) On Fri, 6 Jun 2003, Margaret Wasserman wrote: > Please review the changes to this document, and let us know if all > of your last call issues were adequately resolved. If there are no > remaining issues, we hope to forward this document to the IESG by > the middle of next week. > > Thanks, > Margaret > > > At 02:44 PM 6/5/2003 -0700, Christian Huitema wrote: > >The draft "draft-ietf-v6ops-uman-scenarios-01.txt" into account the > >comments received during the V6OPS WG last call for > >draft-ietf-v6ops-uman-scenarios-00.txt. The authors believe that this > >document addresses the last call comments. A list of these comments and > >the way they were addressed is available at: > > > > http://www.huitema.net/ipv6/Unman-Scenarios-Issues.htm > > > >The main changes fall in three categories: > > > >1) Change the topology section to explain exactly why we did not > >consider the multiple subnet case (i.e., with today's technology, such > >networks are not unmanaged); > > > >2) Change several of the case description scenarios to remove the > >more-or-less implicit assumption that there is always a NAT in IPv4 > >deployments; > > > >3) Fix a number of editorial issues, notably the abstract, the > >introduction, the wording of references to DNS issues, and a split of > >references between normative and informative. > > > >-- Christian Huitema > > > -- 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 Jun 11 06:54:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02102 for ; Wed, 11 Jun 2003 06:54:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Q3FH-000LxJ-00 for v6ops-data@psg.com; Wed, 11 Jun 2003 10:54:23 +0000 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 19Q3FF-000Lx6-00 for v6ops@ops.ietf.org; Wed, 11 Jun 2003 10:54:21 +0000 Received: from consulintel02 ([127.0.0.1]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.9.R) for ; Wed, 11 Jun 2003 12:55:25 +0200 Message-ID: <0f4a01c33007$f48ef620$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <5.2.0.9.0.20030610180944.02aef1e0@mail.addr.com> Subject: Re: 6bone phaseout plan for your comments Date: Wed, 11 Jun 2003 12:55:21 +0200 Organization: Consulintel 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MDRemoteIP: 127.0.0.1 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm ok with this. Regards, Jordi ----- Original Message ----- From: "Bob Fink" To: Sent: Wednesday, June 11, 2003 3:22 AM Subject: 6bone phaseout plan for your comments > v6ops wg Folk, > > As many of you may know, Bob Hinden and I have been developing a > 6bone-phaseout plan since January of this year. Mostly the discussions have > taken place on the 6bone list, with the RIRs and at a BOF meeting at the > San Francisco IETF. The general consensus is to now ask for it to be > published as an RFC to finalize it. > > I have asked Randy Bush, as Operations AD for IPv6 transition, to process > it through the IESG/IETF processes for BCP. I would also encourage any > review comments you may have. > > The ID is at: > > > > > Thanks, > > Bob Fink > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Wed Jun 11 07:56:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03993 for ; Wed, 11 Jun 2003 07:56:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Q4BH-000Nrx-00 for v6ops-data@psg.com; Wed, 11 Jun 2003 11:54:19 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19Q4BE-000Nrl-00 for v6ops@ops.ietf.org; Wed, 11 Jun 2003 11:54:16 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03740; Wed, 11 Jun 2003 07:54:14 -0400 (EDT) Message-Id: <200306111154.HAA03740@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shirasaki-dualstack-service-01.txt Date: Wed, 11 Jun 2003 07:54:14 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Model of IPv6/IPv4 Dual Stack Internet Access Service Author(s) : Y. Shirasaki et al. Filename : draft-shirasaki-dualstack-service-01.txt Pages : 9 Date : 2003-6-10 This memo shows an example of how to provide IPv6 / IPv4 dual stack services to home users. In order to simplify user setup, these service should have mechanism to configure IPv6 specific parameters automatically. We focus on two basic parameters, prefix and addresses of IPv6 DNS servers, and specify the way to deliver them to Customer Premises Equipments (CPE) automatically. This memo is a digest of the user network interface specification of NTT communications' dual stack ADSL access service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shirasaki-dualstack-service-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-shirasaki-dualstack-service-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shirasaki-dualstack-service-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-10110910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shirasaki-dualstack-service-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-shirasaki-dualstack-service-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-10110910.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jun 11 08:17:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04703 for ; Wed, 11 Jun 2003 08:17:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Q4Wl-000Ocy-00 for v6ops-data@psg.com; Wed, 11 Jun 2003 12:16:31 +0000 Received: from [193.72.156.161] (helo=mercury.telscom.ch) by psg.com with esmtp (Exim 3.36 #1) id 19Q4Wj-000Ocm-00 for v6ops@ops.ietf.org; Wed, 11 Jun 2003 12:16:29 +0000 Received: from vaiooo (193.72.156.77) by mercury.telscom.ch with MERCUR-SMTP/POP3/IMAP4-Server (v3.30.09 AS-2621446) for ; Wed, 11 Jun 2003 14:09:36 +0200 From: "Marcin Michalak" Organization: Telscom To: v6ops@ops.ietf.org Date: Wed, 11 Jun 2003 14:15:29 +0200 MIME-Version: 1.0 Subject: Re: 6bone phaseout plan for your comments Message-ID: <3EE73981.23319.2A231980@localhost> In-reply-to: <5.2.0.9.0.20030610180944.02aef1e0@mail.addr.com> X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Reply-To: marcin@telscom.ch X-Spam-Status: No, hits=-22.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On 10 Jun 2003 at 18:22, Bob Fink wrote: > v6ops wg Folk, > > As many of you may know, Bob Hinden and I have been developing a > 6bone-phaseout plan since January of this year. Mostly the discussions have > taken place on the 6bone list, with the RIRs and at a BOF meeting at the > San Francisco IETF. The general consensus is to now ask for it to be > published as an RFC to finalize it. > > I have asked Randy Bush, as Operations AD for IPv6 transition, to process > it through the IESG/IETF processes for BCP. I would also encourage any > review comments you may have. > > The ID is at: > > > > > Thanks, > > Bob Fink Hi, Just small typo: page 2: 'TEST=NEW' should be 'TEST-NEW'. Otherwise - good and concise :-) Regards, Marcin ---------------------------------------------------------- Marcin Michalak Research Engineer Mobile: +41 79 330 83 51 Telscom AG From owner-v6ops@ops.ietf.org Wed Jun 11 10:45:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11938 for ; Wed, 11 Jun 2003 10:45:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Q6ow-0003sD-00 for v6ops-data@psg.com; Wed, 11 Jun 2003 14:43:26 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by psg.com with esmtp (Exim 3.36 #1) id 19Q6ot-0003rz-00 for v6ops@ops.ietf.org; Wed, 11 Jun 2003 14:43:23 +0000 Received: from chuegen-sjcvpn-5.cisco.com (chuegen-sjcvpn-5.cisco.com [10.25.2.102]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5BEhLI3026089; Wed, 11 Jun 2003 07:43:21 -0700 (PDT) Date: Wed, 11 Jun 2003 09:43:20 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Bob Fink cc: v6ops@ops.ietf.org Subject: Re: 6bone phaseout plan for your comments In-Reply-To: <5.2.0.9.0.20030610180944.02aef1e0@mail.addr.com> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This looks good, Bob. /cah On Tue, 10 Jun 2003, Bob Fink wrote: > v6ops wg Folk, > > As many of you may know, Bob Hinden and I have been developing a > 6bone-phaseout plan since January of this year. Mostly the discussions have > taken place on the 6bone list, with the RIRs and at a BOF meeting at the > San Francisco IETF. The general consensus is to now ask for it to be > published as an RFC to finalize it. > > I have asked Randy Bush, as Operations AD for IPv6 transition, to process > it through the IESG/IETF processes for BCP. I would also encourage any > review comments you may have. > > The ID is at: > > > > > Thanks, > > Bob Fink > > -- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-v6ops@ops.ietf.org Wed Jun 11 12:38:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16589 for ; Wed, 11 Jun 2003 12:38:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Q8b6-000902-00 for v6ops-data@psg.com; Wed, 11 Jun 2003 16:37:16 +0000 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19Q8b4-0008zq-00 for v6ops@ops.ietf.org; Wed, 11 Jun 2003 16:37:14 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 4118782AA; Wed, 11 Jun 2003 12:37:11 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 11 Jun 2003 12:37:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-huitema-v6ops-teredo-00.txt Date: Wed, 11 Jun 2003 12:37:06 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042849D0@tayexc13.americas.cpqcorp.net> Thread-Topic: I-D ACTION:draft-huitema-v6ops-teredo-00.txt Thread-Index: AcMvcV8+25TxlzgARPq5DpsDq+j/zQAxgUiQ From: "Bound, Jim" To: "Pekka Savola" , "Christian Huitema" Cc: "EricLKlein" , X-OriginalArrivalTime: 11 Jun 2003 16:37:06.0967 (UTC) FILETIME=[B253B270:01C33037] X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16589 > On Tue, 10 Jun 2003, Christian Huitema wrote: > [...] > > Also, only a small fraction of the packets actually go through the > > server. > > One thing to note here: in addition to "Server", the Teredo > architecture also includes "Relay". And while only a small > fraction of packets go through the server (AFAIR), a large > number of them could go through Relay (which are probably > often one and the same). > > So, in practical purposes I believe Eric's comment about > "server" can be > generalized to be "server or relay". I don't agree. There is a significant difference between the Teredo Server role and the relay. Relays simply forward packets and that is not an issue for us here. > > In that vein, please remember that people MAY NOT deploy > Teredo as some may envision it, to be used mainly between > Teredo hosts only -- but > between the hosts and *the rest of the IPv6 Internet*. This is not our concern and cannot be what we have to do is build specs that work for the task at hand. In the applicability statement that can be done on all specs as health warning. > > If you want to deploy IPv6 Internet and IPv6 Teredo Internet > separately, > you're certainly correct: few packets pass through servers/relays. > > I do not have that deployment scenario in mind; quite the > opposite :-). > > -- > 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 Jun 11 15:55:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08937 for ; Wed, 11 Jun 2003 15:55:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QBe7-000HOq-00 for v6ops-data@psg.com; Wed, 11 Jun 2003 19:52:35 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19QBe5-000HOR-00 for v6ops@ops.ietf.org; Wed, 11 Jun 2003 19:52:33 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19QBdW-000JSZ-H0 for v6ops@ops.ietf.org; Thu, 12 Jun 2003 04:51:58 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 12 Jun 2003 04:51:57 +0900 To: v6ops@ops.ietf.org Subject: RE: draft-ietf-multi6-multihoming-requirements-06.txt Message-Id: X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit An Ops-Dir reviewer had the appended comments. excuse the droll phrasing. any chance we could address them? randy --- Let's see: load balancing is not a realistic requirement. For the architecture to be automatic, we have to be dynamic and we've proven that we don't know how to do that yet. Even to give people some tools seems to lead to abuse. Who controls the balancing? The source? The destination? Don't say 'both'. No packet can serve two masters. Performance. Exact same arguments since the only way to affect performance is to load balance. Policy: so ill stated as to be meaningless. If this is a call for policy routing, that's fine, but it has nothing to do with multihoming. Simplicity: motherhood, apple pie and chevrolet. Transport survivability: Well, ok, but this is just a refinement of the redundancy requirement. How about we remove the redundant redundancy requirement? Compatible with DNS: meaningless Packet filtering: meaningless Scalability: see simplicity routers: create a new architecture, but don't change the routers, change the hosts hosts: create a new architecture, but don't change the hosts, change the routers Interaction between hosts & routers: tighter coupling between subsystems has never been an architectural good idea. So let's do that and change both. O&M: see pie, apple. multiple solutions: please don't give us one size fits all, that's not confusing enough security: don't break security Net: The real requirements are: - Provide multihoming - Provide scalable routing - Transport survivability From owner-v6ops@ops.ietf.org Wed Jun 11 15:55:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09579 for ; Wed, 11 Jun 2003 15:55:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QBg7-000HTs-00 for v6ops-data@psg.com; Wed, 11 Jun 2003 19:54:39 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19QBg3-000HTe-00 for v6ops@ops.ietf.org; Wed, 11 Jun 2003 19:54:37 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19QBfw-000JTO-28 for v6ops@ops.ietf.org; Thu, 12 Jun 2003 04:54:28 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 12 Jun 2003 04:54:27 +0900 To: v6ops@ops.ietf.org Subject: RE: draft-ietf-multi6-multihoming-requirements-06.txt Message-Id: X-Spam-Status: No, hits=-8.9 required=5.0 tests=BAYES_10,NO_FEE,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > An Ops-Dir reviewer had the appended comments. excuse the droll > phrasing. any chance we could address them? excuse posting to the wrong wg. no coffee yet. randy From owner-v6ops@ops.ietf.org Thu Jun 12 19:28:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01326 for ; Thu, 12 Jun 2003 19:28:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QbPN-00077g-00 for v6ops-data@psg.com; Thu, 12 Jun 2003 23:23:05 +0000 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 19QbPK-00077U-00 for v6ops@ops.ietf.org; Thu, 12 Jun 2003 23:23:02 +0000 Received: from esunmail ([129.147.58.120]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5CNN2ep007917 for ; Thu, 12 Jun 2003 17:23:02 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGE000526ADF4@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 12 Jun 2003 17:23:02 -0600 (MDT) Received: from sun.com ([129.146.10.24]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGE00BAU6A88C@mail.sun.net> for v6ops@ops.ietf.org; Thu, 12 Jun 2003 17:22:57 -0600 (MDT) Date: Thu, 12 Jun 2003 16:22:56 -0700 From: Alain Durand Subject: Re: 6bone phaseout plan for your comments To: Bob Fink , v6ops@ops.ietf.org Message-id: <3EE90B50.90305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <5.2.0.9.0.20030610180944.02aef1e0@mail.addr.com> X-Spam-Status: No, hits=-32.1 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Just read the -04. Comments: Address prefixes from the 3FFE::/16 allocation, using a set of 6bone routing practice rules specified in [GUIDE], and later refined to 6Bone backbone routing guidelines in [PRACTICE] ==> Chronologically, [PRACTICE, RFC 2546] was produced before [GUIDE, RFC 2772] It is anticipated that under this phaseout plan the 6bone will cease to operate by June 6, 2006, with all 6bone prefixes fully reclaimed by the IANA. ==> There is something diabolic about this date! Thus after the 6bone phaseout date June 6, 2006, it is the intent that no 6bone 3FFE prefixes, of any size/length, be used on the Internet in any form. Network operators may filter 3FFE prefixes on their borders to ensure these prefixes are not misused. This is contradictory to There is experience from the IPv4 world that such filters may not be removed promptly should this address space be reallocated, and it is recommended that the IANA bears this in mind before reallocating it in a manner that would require it to be routed globally within the current Internet. The prefix belongs to IANA. The 6bone is returning it to IANA, it is up to IANA to do whatever they want with it. We may recommend not to re-attribute it in the near future, but the sentence: "it is the intent that no 6bone 3FFE prefixes, of any size/length, be used on the Internet in any form." implies that the prefix 3ffe::/16 would die forever. I'd rather like to see a sentence like "the 3ffe::/16 prefix SHOULD not be used and MUST NOT be reallocated until 1/1/2012. Network operator MAY filter 3FFE prefixes on their border until 1/1/2012 to ensure these prefixes are not misused." After 1/1/2012, the prefix would return to the global pool of aggregatable addresses - Alain. Bob Fink wrote: > v6ops wg Folk, > > As many of you may know, Bob Hinden and I have been developing a > 6bone-phaseout plan since January of this year. Mostly the discussions > have taken place on the 6bone list, with the RIRs and at a BOF meeting > at the San Francisco IETF. The general consensus is to now ask for it > to be published as an RFC to finalize it. > > I have asked Randy Bush, as Operations AD for IPv6 transition, to > process it through the IESG/IETF processes for BCP. I would also > encourage any review comments you may have. > > The ID is at: > > > > > Thanks, > > Bob Fink > > From owner-v6ops@ops.ietf.org Thu Jun 12 22:22:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05506 for ; Thu, 12 Jun 2003 22:22:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QeB7-000E3M-00 for v6ops-data@psg.com; Fri, 13 Jun 2003 02:20:33 +0000 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 19QeB2-000E2P-00 for v6ops@ops.ietf.org; Fri, 13 Jun 2003 02:20:28 +0000 Received: from blrcsv.china.bell-labs.com (h135-252-19-200.lucent.com [135.252.19.200]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5D2KOg23473 for ; Thu, 12 Jun 2003 21:20:25 -0500 (CDT) Received: from zhanghaofneg (unknown [135.252.18.115]) by blrcsv.china.bell-labs.com (Postfix) with SMTP id 1CDA18689 for ; Fri, 13 Jun 2003 10:02:23 +0800 (CST) From: "zhanghf@blrcsv.china.bell-labs.com" To: "v6ops@ops.ietf.org" Subject: A little bug of Teredo Specification? X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Date: Fri, 13 Jun 2003 10:20:34 +0800 Message-Id: <20030613020223.1CDA18689@blrcsv.china.bell-labs.com> X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_01,TO_ADDRESS_EQ_REAL version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, In draft-huitema-v6ops-teredo-00, sec5.2.1 Qulification procedure, page 24, if the Cone bit is 1, then teredo client can draw the conclusion that it's located in a CONE NAT. So the C == 0 field in the diagram should be " C == 1", I think. Best wishes. lyon Jun 13th. From owner-v6ops@ops.ietf.org Sun Jun 15 14:06:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06584 for ; Sun, 15 Jun 2003 14:06:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19RbpU-000Owh-00 for v6ops-data@psg.com; Sun, 15 Jun 2003 18:02:12 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19RbpS-000OvF-00 for v6ops@ops.ietf.org; Sun, 15 Jun 2003 18:02:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5FI27s12561 for ; Sun, 15 Jun 2003 21:02:07 +0300 Date: Sun, 15 Jun 2003 21:02:07 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: Request to Advance "Transition Scenarios for 3GPP Networks" In-Reply-To: <5.1.0.14.2.20030528092911.04429e68@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI, The document has been approved by the IESG. Thanks for everybody, especially the team, for hard work! On Wed, 28 May 2003, Margaret Wasserman wrote: > On behalf of the v6ops WG, we request that the following document be > published as an Informational RFC: > > Title : Transition Scenarios for 3GPP Networks > Editor : J. Soininen > Filename : draft-ietf-v6ops-3gpp-cases-03.txt > Date : March 2003 > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-03.txt > > A working group last call for this document was completed on 2 March > 2003, and this draft resolves the issues raised during last call. This > document was also reviewed and endorsed by the 3GPP SA2 group in May > 2003 and has been endorsed by 3GPP. > > Thanks, > Bob Fink, Pekka Savola and Margaret Wasserman > v6ops Working Group Chairs > > > -- 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 Jun 16 07:57:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09308 for ; Mon, 16 Jun 2003 07:57:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Rsah-0005CA-00 for v6ops-data@psg.com; Mon, 16 Jun 2003 11:56:03 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19Rsae-0005By-00 for v6ops@ops.ietf.org; Mon, 16 Jun 2003 11:56:00 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09108; Mon, 16 Jun 2003 07:55:58 -0400 (EDT) Message-Id: <200306161155.HAA09108@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-04.txt Date: Mon, 16 Jun 2003 07:55:58 -0400 X-Spam-Status: No, hits=3.1 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Analysis on IPv6 Transition in 3GPP Networks Author(s) : J. Wiljakka Filename : draft-ietf-v6ops-3gpp-analysis-04.txt Pages : 20 Date : 2003-6-13 This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-3gpp-analysis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-16080840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-analysis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-16080840.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Jun 16 15:42:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27947 for ; Mon, 16 Jun 2003 15:42:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Rzok-000LBZ-00 for v6ops-data@psg.com; Mon, 16 Jun 2003 19:39:02 +0000 Received: from ran.psg.com ([209.20.253.166]) by psg.com with esmtp (Exim 3.36 #1) id 19Rzoh-000LBG-00 for v6ops@ops.ietf.org; Mon, 16 Jun 2003 19:38:59 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19Rzoh-000JCc-D0 for v6ops@ops.ietf.org; Mon, 16 Jun 2003 12:38:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200306161934.PAA27704@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , v6ops@ops.ietf.org From: The IESG Subject: Document Action: Transition Scenarios for 3GPP Networks to Informational Date: Mon, 16 Jun 2003 15:34:51 -0400 X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the Internet-Draft 'Transition Scenarios for 3GPP Networks' as an Informational RFC. This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Randy Bush and Bert Wijnen. From owner-v6ops@ops.ietf.org Wed Jun 18 06:22:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26029 for ; Wed, 18 Jun 2003 06:22:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SZyt-000Pl9-Cg for v6ops-data@psg.com; Wed, 18 Jun 2003 10:15:55 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19SZyr-000Pkw-6K for v6ops@ops.ietf.org; Wed, 18 Jun 2003 10:15:53 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5IAFpg06669; Wed, 18 Jun 2003 13:15:51 +0300 Date: Wed, 18 Jun 2003 13:15:50 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: mrw@windriver.com, Subject: Soliciting IPv4 Survey area-specific editors Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, We'd like to solicit volunteers from the WG to help in editing the IPv4 survery documents: draft-ietf-v6ops-ipv4survey-apps-00.txt draft-ietf-v6ops-ipv4survey-int-00.txt draft-ietf-v6ops-ipv4survey-intro-00.txt (generic information) draft-ietf-v6ops-ipv4survey-ops-00.txt draft-ietf-v6ops-ipv4survey-routing-00.txt draft-ietf-v6ops-ipv4survey-sec-00.txt draft-ietf-v6ops-ipv4survey-subip-00.txt draft-ietf-v6ops-ipv4survey-trans-00.txt (note: general area will not be changed.) We've already compiled a list of desirable changes at this point. (Of course, it may be possible to edit them further but that's not necessary, at least now.) It would be preferable to have some kind of knowledge of pertinent areas, but that isn't really necessary. Could people who are willing to spend a little time editing one (or more) of these documents please send mail to me, Margaret and Bob as soon as possible, but preferably by Friday (Jun 20th)? We'd like to be able to revise the documents slightly before the Jun 30th cut-off data, so that we could introduce the documents formally in their respective areas. Pekka, Margaret & Bob -- 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 Jun 18 07:54:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28520 for ; Wed, 18 Jun 2003 07:54:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SbVH-0003hq-P4 for v6ops-data@psg.com; Wed, 18 Jun 2003 11:53:27 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19SbVE-0003ha-OF for v6ops@ops.ietf.org; Wed, 18 Jun 2003 11:53:24 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28201; Wed, 18 Jun 2003 07:53:23 -0400 (EDT) Message-Id: <200306181153.HAA28201@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-unman-scenarios-02.txt Date: Wed, 18 Jun 2003 07:53:23 -0400 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_20,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Unmanaged Networks IPv6 Transition Scenarios Author(s) : C. Huitema, R. Austein, S. Satapati, R. van der Pol Filename : draft-ietf-v6ops-unman-scenarios-02.txt Pages : 19 Date : 2003-6-17 In order to evaluate the suitability of IPv6 transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the 'unmanaged network', which typically corresponds to a home or small office network. The scenarios are specific to single link subnet, and are defined in terms of IP connectivity supported by the home gateway and the ISP. We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-unman-scenarios-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-unman-scenarios-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17144543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-unman-scenarios-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-unman-scenarios-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17144543.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jun 18 08:27:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29620 for ; Wed, 18 Jun 2003 08:27:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Sc1k-0005oN-9D for v6ops-data@psg.com; Wed, 18 Jun 2003 12:27:00 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19Sc1h-0005o6-Vl; Wed, 18 Jun 2003 12:26:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5ICQta07459; Wed, 18 Jun 2003 15:26:55 +0300 Date: Wed, 18 Jun 2003 15:26:54 +0300 (EEST) From: Pekka Savola To: Randy Bush , Bert Wijnen cc: v6ops@ops.ietf.org, Subject: Request to Advance "Unmanaged Networks IPv6 Transition Scenarios" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On behalf of the v6ops WG, we request that the following document be published as an Informational RFC: Title : Unmanaged Networks IPv6 Transition Scenarios Author(s) : C. Huitema, R. Austein, S. Satapati, R. van der Pol Filename : draft-ietf-v6ops-unman-scenarios-02.txt Pages : 19 Date : 2003-6-17 A working group last call for this document was completed on March 2nd, 2003, and the two subsequent revisions of the draft have resolved the issues raised during the last call. Thanks, Pekka, Margaret & Bob v6ops WG co-chairs From owner-v6ops@ops.ietf.org Thu Jun 19 01:07:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15895 for ; Thu, 19 Jun 2003 01:07:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SraZ-000PVt-Ie for v6ops-data@psg.com; Thu, 19 Jun 2003 05:03:59 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19SraW-000PVh-SS for v6ops@ops.ietf.org; Thu, 19 Jun 2003 05:03:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5J53qa14912; Thu, 19 Jun 2003 08:03:52 +0300 Date: Thu, 19 Jun 2003 08:03:52 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: Margaret Wasserman , Bob Fink Subject: Re: NAT-PT Applicability In-Reply-To: <5.1.0.14.2.20030514184503.04741eb0@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 14 May 2003, Margaret Wasserman wrote: > In SF, we discussed the need for an applicability statement > for NAT-PT. There was consensus of the WG to produce this > applicability statement, and many people said that they > were willing to work on it. > > The chairs would like to spin up this effort before Vienna. > > Could people who are willing to spend time working on a > NAT-PT applicability document please send mail to me, Pekka > and Bob by next Wednesday (May 21st)? We'll then put > together a design team to do this work. Sorry for the delay on this issue. The NAT-PT DT is lead by Suresh Satapati. Other members are, at this point, Senthil Sivakumar, Karim El-Malki, Satomi Okazaki, Peter Barany and Hao Wang. Thanks for everybody who volunteered to the effort; only a small team could be picked, with different kinds of expertise, but I'm sure the rest of the WG will continue to contribute to the effort as soon as there is a draft on the table. Pekka, Margaret & Bob From owner-v6ops@ops.ietf.org Thu Jun 19 05:48:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06384 for ; Thu, 19 Jun 2003 05:48:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Sw0F-000BLW-FZ for v6ops-data@psg.com; Thu, 19 Jun 2003 09:46:47 +0000 Received: from [193.180.251.52] (helo=falcon.al.sw.ericsson.se) by psg.com with esmtp (Exim 4.14) id 19Sw0C-000BLK-5H for v6ops@ops.ietf.org; Thu, 19 Jun 2003 09:46:44 +0000 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5J9lZcv028386 for ; Thu, 19 Jun 2003 11:47:35 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 19 Jun 2003 11:46:39 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28B67@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: v6ops@ops.ietf.org Subject: FW: I-D ACTION:draft-elmalki-v6ops-3gpp-translator-00.txt Date: Thu, 19 Jun 2003 11:46:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi This is a companion draft to draft-ietf-v6ops-3gpp-analysis. The focus is on translator solutions for 3GPP networks and in particular SIP-based IPv6 IMS. We'd like to know what the v6ops wg thinks about the approach in the draft. We will also be seeking comments from the sipping wg. Thanks /Karim > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : IPv6-IPv4 Translators in 3GPP Networks > Author(s) : K. El Malki et al. > Filename : draft-elmalki-v6ops-3gpp-translator-00.txt > Pages : 16 > Date : 2003-6-17 > > There have been discussions on the v6ops mailing list and at IETF > meetings regarding the suitability of translators (e.g. NAT-PT) as > mechanisms for IPv4 to IPv6 transition. It has often been > stated that > NAT-PT is not a mechanism to be recommended in general to solve the > IPv6-IPv4 transition problem and some modifications to NAT-PT have > been proposed. However there have also been discussions regarding > special scenarios where some form of translators could be > deployed if > their use is documented appropriately. The aim of this draft is to > document the rationale for using translators in 3GPP networks, in > particular for IPv6-only IMS (IP Multimedia Subsystem) and to > describe possible solutions to the problem and the interactions with > SIP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-elmalki-v6ops-3gpp- > translator-00.txt > > To remove yourself from the IETF Announcement list, send a > message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > 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-elmalki-v6ops-3gpp-translator-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-elmalki-v6ops-3gpp-translator-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > From owner-v6ops@ops.ietf.org Thu Jun 19 13:25:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02509 for ; Thu, 19 Jun 2003 13:25:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T35P-000FfM-9R for v6ops-data@psg.com; Thu, 19 Jun 2003 17:20:35 +0000 Received: from [3ffe:501:100f::35] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.14) id 19T35J-000Ff2-IP for v6ops@ops.ietf.org; Thu, 19 Jun 2003 17:20:29 +0000 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1994C15248; Fri, 20 Jun 2003 02:20:22 +0900 (JST) Date: Fri, 20 Jun 2003 02:20:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dnsop@cafax.se Cc: v6ops@ops.ietf.org Subject: a new draft on AAAA queries User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. In-Reply-To: <200306181151.HAA27829@ietf.org> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Fri_Jun_20_02:20:18_2003-1" X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,IN_REP_TO,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Multipart_Fri_Jun_20_02:20:18_2003-1 Content-Type: text/plain; charset=US-ASCII In response to a discussion in the v6ops wg, we submitted a new individual draft (see below) that discusses problematics issues wrt AAAA queries. Though the background of the draft is a v6ops discussion, we authors believe we can get nice feedback from dnsop because the issues are basically general DNS topics. The draft may still be incomplete or even be incorrect in some points, so any comments, corrections, or additional cases would be highly appreciated. Thanks in advance, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Fri_Jun_20_02:20:18_2003-1 Content-Type: message/rfc822 Return-Path: X-Mail-Format-Warning: Bad RFC2822 header formatting in >From jinmei Wed Jun 18 21:31:38 2003 Return-Path: X-Original-To: jinmei@shuttle.wide.toshiba.co.jp Delivered-To: jinmei@shuttle.wide.toshiba.co.jp Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-6.1.0) for jinmei@localhost (single-drop); Wed, 18 Jun 2003 22:30:45 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 160DB1525C for ; Wed, 18 Jun 2003 21:31:38 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.12.9/8.12.9) with ESMTP id h5ICVbfP018068; Wed, 18 Jun 2003 21:31:37 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id VAA08513; Wed, 18 Jun 2003 21:31:37 +0900 (JST) Received: from mx2.toshiba.co.jp (mx2.toshiba.co.jp [133.199.160.163]) by isl.rdc.toshiba.co.jp (8.11.7/8.11.6/1.4) with ESMTP id h5ICVab09037; Wed, 18 Jun 2003 21:31:36 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id VAA16647; Wed, 18 Jun 2003 21:31:35 +0900 (JST) Received: from inet-tsb5.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id h5ICVYBF028987; Wed, 18 Jun 2003 21:31:34 +0900 (JST) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by inet-tsb5.toshiba.co.jp with ESMTP id h5ICVOhW025180; Wed, 18 Jun 2003 21:31:25 +0900 (JST) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19SbZN-0005yR-8W for ietf-announce-list@asgard.ietf.org; Wed, 18 Jun 2003 07:57:41 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19SbTV-0005jo-JE for all-ietf@asgard.ietf.org; Wed, 18 Jun 2003 07:51:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27829 for ; Wed, 18 Jun 2003 07:51:36 -0400 (EDT) Message-Id: <200306181151.HAA27829@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-morishita-dnsop-misbehavior-against-aaaa-00.txt Date: Wed, 18 Jun 2003 07:51:36 -0400 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-UIDL: "H""!d~?"!"G3"!NpK!! X-Spam-Status: No, hits=2.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Common Misbehavior against DNS Queries for IPv6 Addresses Author(s) : Y. Morishita, T. Jinmei Filename : draft-morishita-dnsop-misbehavior-against-aaaa-00.txt Pages : 7 Date : 2003-6-17 There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication which should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of the known cases and discusses the effect. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-morishita-dnsop-misbehavior-against-aaaa-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-morishita-dnsop-misbehavior-against-aaaa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-morishita-dnsop-misbehavior-against-aaaa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17144214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-morishita-dnsop-misbehavior-against-aaaa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-morishita-dnsop-misbehavior-against-aaaa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17144214.I-D@ietf.org> --OtherAccess-- --NextPart-- --Multipart_Fri_Jun_20_02:20:18_2003-1-- From owner-v6ops@ops.ietf.org Fri Jun 20 04:30:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21358 for ; Fri, 20 Jun 2003 04:30:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19THFW-0003t9-JC for v6ops-data@psg.com; Fri, 20 Jun 2003 08:27:58 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19THFT-0003sf-27 for v6ops@ops.ietf.org; Fri, 20 Jun 2003 08:27:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5K8Rpm27949; Fri, 20 Jun 2003 11:27:51 +0300 Date: Fri, 20 Jun 2003 11:27:51 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: mrw@windriver.com, Subject: Draft v6ops agenda for Vienna IETF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Find below a tentative v6ops agenda for Vienna. We've scheduled for two 2 hour sessions. The intention is to discuss the scenarios/analysis work in detail, while preserving the other session completely for other very important work we should be doing. Please send us corrections, suggestions or requests for addition. Thanks, Pekka, Margaret & Bob ============= v6ops draft agenda IETF-57 Vienna MONDAY, July 14, 2003 1545-1645 Afternoon Sessions III OPS v6ops IPv6 Operations WG 1700-1800 Afternoon Sessions IV OPS v6ops IPv6 Operations WG === agenda bashing - 5 mins === current status - 10 mins, Margaret/Pekka === UNMAN Analysis discussion - 30 mins, Christian Huitema === ISP Scenarios - 45 mins, Mikael Lind === ENT Scenarios - 45 mins, Yanick Pouffary/Jim Bound ============== meeting slot 2 WEDNESDAY, July 16, 2003 1530-1730 Afternoon Sessions II OPS v6ops IPv6 Operations WG === v6-on-by-default - 25 mins, Alain Durand 5-10 mins presentation, remainder discussion === threedegrees - 10 mins, Christian Huitema (if willing, applicable etc.) === other operational presentations 10-15 mins === Security - discussion of what we should be doing - 30-45 mins, Margaret/Pekka === NAT-PT Applicability Statement - report, 10-15 mins, Suresh Satapati (or someone else) === writing IPv6 Applications report - 15 mins, someone from team From owner-v6ops@ops.ietf.org Fri Jun 20 04:32:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21439 for ; Fri, 20 Jun 2003 04:32:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19THKD-000447-Fj for v6ops-data@psg.com; Fri, 20 Jun 2003 08:32:49 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19THKB-00043t-Cb for v6ops@ops.ietf.org; Fri, 20 Jun 2003 08:32:47 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5K8WjZ28011 for ; Fri, 20 Jun 2003 11:32:45 +0300 Date: Fri, 20 Jun 2003 11:32:45 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: drafty IPv6 security overview draft submitted Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, I just submitted a draft on IPv6 security overview. It's quite raw and badly structured, but I ran out of time (and I'm off for a few days, back on Wednesday or so). I've tried to describe at least briefly all the aspects relating to IPv6 and IPv6 transition/co-existence I could quickly think of. This could be one basis for the security discussion in Vienna. Please have a look at it at some point and send feedback. Prior to it being formally posted, it can be read from: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-security-overview-00.txt Abstract The transition/co-existance from IPv4 to IPv4/IPv6 causes one to consider the security considerations of such a process. In this memo, I try to give an overview of different aspects relating to IPv6: the notion of increased end-to-end transparency, implications of tunneling, the use of IPv4-mapped addresses, the considerations of IPv6 service piloting without firewalls, IPv6 protocol-specific issues, IPv6 transition/co-existence mechanism -specific issues, consequences of enabling IPv6 by default, and operational security issues when enabling IPv6 in the network infrastructure. It's only about 8 pages or so :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jun 20 11:30:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12597 for ; Fri, 20 Jun 2003 11:30:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TNnx-000JKv-9M for v6ops-data@psg.com; Fri, 20 Jun 2003 15:27:57 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19TNnt-000JKM-Mo for v6ops@ops.ietf.org; Fri, 20 Jun 2003 15:27:53 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19TNns-000GYh-IU for v6ops@ops.ietf.org; Fri, 20 Jun 2003 08:27:52 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE837CF2D@TMS031MB.tcad.telia.se> Thread-Topic: I-D ACTION:draft-lind-v6ops-isp-scenarios-00.txt Thread-Index: AcM1l7ZJeNgNIa1NTuO4wVAINKT2WwBftM2q Subject: FW: I-D ACTION:draft-lind-v6ops-isp-scenarios-00.txt Date: Fri, 20 Jun 2003 13:01:29 +0200 From: To: X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_01,NO_REAL_NAME version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12597 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi, This is the first draft for the ISP scenarios which is taking a bit different approach to the problem than before. The document only has a high level description of the ISP networks and leaves all the network details for the following solutions document. Instead of describing the different network types the document tries to describe scenarios for the introduction of IPv6 in an ISP network. These scenarios will then be applied to different network types in the solutions document. This will also allow a split of the solutions document in multiple parts to speed up the work but that is a future question. The reason for all of these changes is to get the work going in the ISP team and one way of doing this is to try to minimize the scenarios document and put more effort in to the solutions document. Since this is a rather big change it will be interesting to see if will get the support from the v6ops wg that we need to continue on this track. Thanks, Mikael Lind -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wed 2003-06-18 13:52 To: Cc: Subject: I-D ACTION:draft-lind-v6ops-isp-scenarios-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Scenarios for Introducing IPv6 into ISP Networks Author(s) : M. Lind Filename : draft-lind-v6ops-isp-scenarios-00.txt Pages : 9 Date : 2003-6-17 This document describes different scenarios for the introduction of IPv6 in an IPv4 ISP network. The goal is the addition of a native IPv6 service to the already existing IPv4 service without interruption of the IPv4 service. During the IPv6 introduction the network can go through 4 different stages including the initial IPv4 only stage. To move between the stages there will be some form of transition that can be defined in different transition scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lind-v6ops-isp-scenarios-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-lind-v6ops-isp-scenarios-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lind-v6ops-isp-scenarios-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Fri Jun 20 14:30:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24156 for ; Fri, 20 Jun 2003 14:30:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TQcA-0006JU-2E for v6ops-data@psg.com; Fri, 20 Jun 2003 18:27:58 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19TQc7-0006JI-Jh for v6ops@ops.ietf.org; Fri, 20 Jun 2003 18:27:55 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23357; Fri, 20 Jun 2003 14:27:53 -0400 (EDT) Message-Id: <200306201827.OAA23357@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-savola-v6ops-security-overview-00.txt Date: Fri, 20 Jun 2003 14:27:53 -0400 X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_01,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Transition/Co-existence Security Considerations Author(s) : P. Savola Filename : draft-savola-v6ops-security-overview-00.txt Pages : 9 Date : 2003-6-20 The transition/co-existance from IPv4 to IPv4/IPv6 causes one to consider the security considerations of such a process. In this memo, I try to give an overview of different aspects relating to IPv6: the notion of increased end-to-end transparency, implications of tunneling, the use of IPv4-mapped addresses, the considerations of IPv6 service piloting without firewalls, IPv6 protocol-specific issues, IPv6 transition/co-existence mechanism -specific issues, consequences of enabling IPv6 by default, and operational security issues when enabling IPv6 in the network infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-security-overview-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-savola-v6ops-security-overview-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-v6ops-security-overview-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-20140407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-savola-v6ops-security-overview-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-savola-v6ops-security-overview-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-20140407.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Jun 20 19:25:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14294 for ; Fri, 20 Jun 2003 19:25:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TVDN-000LiX-Ed for v6ops-data@psg.com; Fri, 20 Jun 2003 23:22:41 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19TVDJ-000LiJ-B7 for v6ops@ops.ietf.org; Fri, 20 Jun 2003 23:22:37 +0000 Received: from esunmail ([129.147.58.120]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5KNMa7U019290 for ; Fri, 20 Jun 2003 17:22:36 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGS00MT4ZLN0N@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 20 Jun 2003 17:22:36 -0600 (MDT) Received: from sun.com ([129.146.18.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGS00CPBZLMMR@mail.sun.net> for v6ops@ops.ietf.org; Fri, 20 Jun 2003 17:22:35 -0600 (MDT) Date: Fri, 20 Jun 2003 16:22:34 -0700 From: Alain Durand Subject: Re: drafty IPv6 security overview draft submitted To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: <3EF3973A.7080208@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Pekka, Thanks for starting this effort. A couple points: 1- You do not talk about the tunneling/open relay issues, like the abuse of 6to4. those were discussed elsewhere, but I think it would be worth it mentionning them here. 2- I came across an interesinting issue when playing with VPN: I use an IPv4 VPN to connect to my office network. My DNS resolution is done over IPv4. When I'm looking for my server, the DNS (over IPv4 over VPN) returns both A and AAAA records. When my laptop is on an IPv6 enable link, it will use IPv6 to try to connec to my server. However, the VPN does not know about IPv6, and it let the packets go on the local network. Anybody on the local link can intercept those packets by pretending to have the IPv6 address of my server (thanks to neighbor discovery, it does not even have to compromise any router...). This may be a bug in my VPN, bit I wonder how many VPNs share the same behavior... - Alain. Pekka Savola wrote: >Hello all, > >I just submitted a draft on IPv6 security overview. It's quite raw >and badly structured, but I ran out of time (and I'm off for a few >days, back on Wednesday or so). > >I've tried to describe at least briefly all the aspects relating to IPv6 >and IPv6 transition/co-existence I could quickly think of. This could be >one basis for the security discussion in Vienna. > >Please have a look at it at some point and send feedback. > >Prior to it being formally posted, it can be read from: > >http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-security-overview-00.txt > >Abstract > > The transition/co-existance from IPv4 to IPv4/IPv6 causes one to > consider the security considerations of such a process. In this > memo, I try to give an overview of different aspects relating to > IPv6: the notion of increased end-to-end transparency, implications > of tunneling, the use of IPv4-mapped addresses, the considerations of > IPv6 service piloting without firewalls, IPv6 protocol-specific > issues, IPv6 transition/co-existence mechanism -specific issues, > consequences of enabling IPv6 by default, and operational security > issues when enabling IPv6 in the network infrastructure. > > >It's only about 8 pages or so :-) > > > From owner-v6ops@ops.ietf.org Sat Jun 21 08:38:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06925 for ; Sat, 21 Jun 2003 08:38:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ThZG-0001v8-Kg for v6ops-data@psg.com; Sat, 21 Jun 2003 12:34:06 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19ThZB-0001tg-5I for v6ops@ops.ietf.org; Sat, 21 Jun 2003 12:34:01 +0000 Received: from consulintel02 ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.0.R) with ESMTP id 19-md50000000125.tmp for ; Sat, 21 Jun 2003 14:34:42 +0200 Message-ID: <048101c337f1$7c1a72e0$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: draft-palet-v6ops-proto41-nat-00.txt Date: Sat, 21 Jun 2003 14:34:36 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Sat, 21 Jun 2003 14:34:42 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, We just submitted a draft on usage of Protocol 41 over NAT boxes. The document can be read before is formally posted at http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-proto41-nat-00.txt. Please, take a look and provide your feedback. Thanks in advance ! Abstract Some NAT boxes/routers allow the establishment of IPv6 tunnels from systems in the private LAN (using private IPv4 addresses) to routers or tunnel servers in the public Internet. As far as we know this is not a common way of use IPv6 tunnels; the usual way is to finish the tunnel directly in a device with an IPv4 public address. This behavior provides a big opportunity to rapidly deploy a huge number of IPv6 nodes and networks, without the need of new transition mechanism. This option is very important to facilitate the IPv6 deployment. This document describes this behavior and provides hints that should be applied in the NAT boxes and tunnel brokers to facilitate it. Regards, Jordi ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Mon Jun 23 06:00:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14513 for ; Mon, 23 Jun 2003 06:00:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UO5u-000Gho-6b for v6ops-data@psg.com; Mon, 23 Jun 2003 09:58:38 +0000 Received: from [194.250.197.211] (helo=proxy.6wind.com) by psg.com with esmtp (Exim 4.14) id 19UO5r-000GgI-UW for v6ops@ops.ietf.org; Mon, 23 Jun 2003 09:58:36 +0000 Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id BD0AB6A2; Mon, 23 Jun 2003 11:58:34 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id B1C0D3F8; Mon, 23 Jun 2003 11:58:34 +0200 (CEST) Message-ID: <3EF6D004.1040900@6wind.com> Date: Mon, 23 Jun 2003 12:01:40 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JORDI PALET MARTINEZ Cc: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-00.txt References: In-Reply-To: X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-20.8 required=5.0 tests=BAYES_10,IN_REP_TO,NO_REAL_NAME,REFERENCES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > Hi all, > > We just submitted a draft on usage of Protocol 41 over NAT boxes. > I have some question about this draft. You propose : v4 v4 X ---- NAT-box ----- Tunnel Serveur -- v6 world * * ************************* 6in4 tunnel 1) OK, but if the NAT-box dosen't support proto 41, it will need a firmware update. As to proceed with such an update wouldn't it be more safe, to have th NAT-box be IPv6 compliant, hence allowing dual v4 X ---- NAT-box ----- Tunnel Serveur -- v6 world * * ************** 6in4 tunnel hence removing the need for proto 41 support ! 2) in case of NAT-box wih proto 41 support, how does it work, when - several Host/routers want to have 6in4 tunnel towards the same tunnel serveur - the NAT-box a only ONE public address because proto 41 doesn't provide ports as in UDP/TCP or ID as in the ping, for additional multiplexing level. 3) do you have an estimation (like the one Christian Huitema gave in his NAT classification) about how may NAT support proto 41 and how many don't ? 4) anyway, if there is a NAT we don't known about in the way and that does not support proto 41, all we can see is that eh! this tunnel doesn't work !! don't you feel it to be risky for a tunnel broker to provide solution that don't work in some case, he can't even predict ? Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-v6ops@ops.ietf.org Mon Jun 23 06:00:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14511 for ; Mon, 23 Jun 2003 06:00:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UO3p-000Gd7-7b for v6ops-data@psg.com; Mon, 23 Jun 2003 09:56:29 +0000 Received: from [194.250.197.211] (helo=proxy.6wind.com) by psg.com with esmtp (Exim 4.14) id 19UO3m-000Gcs-DH for v6ops@ops.ietf.org; Mon, 23 Jun 2003 09:56:26 +0000 Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 397256F9; Mon, 23 Jun 2003 11:56:25 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 06D116B8; Mon, 23 Jun 2003 11:56:25 +0200 (CEST) Message-ID: <3EF6CF82.3040008@6wind.com> Date: Mon, 23 Jun 2003 11:59:30 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JORDI PALET MARTINEZ Cc: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-00.txt References: In-Reply-To: X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-16.6 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,REFERENCES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > Hi all, > > We just submitted a draft on usage of Protocol 41 over NAT boxes. > I have some question about this draft. You propose : v4 v4 X ---- NAT-box ----- Tunnel Serveur -- v6 world * * ************************* 6in4 tunnel 1) OK, but if the NAT-box dosen't support proto 41, it will need a firmware update. As to proceed with such an update wouldn't it be more safe, to have th NAT-box be IPv6 compliant, hence allowing dual v4 X ---- NAT-box ----- Tunnel Serveur -- v6 world * * ************** 6in4 tunnel hence removing the need for proto 41 support ! 2) in case of NAT-box wih proto 41 support, how does it work, when - several Host/routers want to have 6in4 tunnel towards the same tunnel serveur - the NAT-box a only ONE public address because proto 41 doesn't provide ports as in UDP/TCP or ID as in the ping, for additional multiplexing level. 3) do you have an estimation (like the one Christian Huitema gave in his NAT classification) about how may NAT support proto 41 and how many don't ? 4) anyway, if there is a NAT we don't known about in the way and that does not support proto 41, all we can see is that eh! this tunnel doesn't work !! don't you feel it to be risky for a tunnel broker to provide solution that don't work in some case, he can't even predict ? Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-v6ops@ops.ietf.org Mon Jun 23 11:33:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25067 for ; Mon, 23 Jun 2003 11:33:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UTGB-000Fii-Ub for v6ops-data@psg.com; Mon, 23 Jun 2003 15:29:35 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with smtp (Exim 4.14) id 19UTG8-000FTK-SQ for v6ops@ops.ietf.org; Mon, 23 Jun 2003 15:29:33 +0000 Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail2 with InterScan Messaging Security Suite; Mon, 23 Jun 2003 17:29:23 +0200 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Jun 2003 17:28:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: drafty IPv6 security overview draft submitted Date: Mon, 23 Jun 2003 17:28:48 +0200 Message-ID: Thread-Topic: drafty IPv6 security overview draft submitted Thread-Index: AcM3BwxEMtgtsR4tShaHKFhU1dkNeACkWUug From: "BAUDOT Alain FTRD/DMI/CAE" To: "Pekka Savola" , X-OriginalArrivalTime: 23 Jun 2003 15:28:49.0454 (UTC) FILETIME=[24F9D4E0:01C3399C] X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, I think it is very valuable to point out such concrete and operational issues, one may face thinking about how to deploy IPv6 securely and safely (without disrupting existing services), as well. =20 It seems actually that there 3 types of issues : issues due to the protocol itself, issues due to transition/co-existence tools, and issues due to the deployement that may be adopted. And I guess each type of issue should have specic kind of answer. Regards, Alain. > -----Message d'origine----- > De : Pekka Savola [mailto:pekkas@netcore.fi] > Envoye : vendredi 20 juin 2003 10:33 > A : v6ops@ops.ietf.org > Objet : drafty IPv6 security overview draft submitted >=20 >=20 > Hello all, >=20 > I just submitted a draft on IPv6 security overview. It's quite raw=20 > and badly structured, but I ran out of time (and I'm off for a few=20 > days, back on Wednesday or so). >=20 > I've tried to describe at least briefly all the aspects=20 > relating to IPv6=20 > and IPv6 transition/co-existence I could quickly think of. =20 > This could be=20 > one basis for the security discussion in Vienna. >=20 > Please have a look at it at some point and send feedback. >=20 > Prior to it being formally posted, it can be read from: >=20 > http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-security- overview-00.txt Abstract The transition/co-existance from IPv4 to IPv4/IPv6 causes one to consider the security considerations of such a process. In this memo, I try to give an overview of different aspects relating to IPv6: the notion of increased end-to-end transparency, implications of tunneling, the use of IPv4-mapped addresses, the considerations of IPv6 service piloting without firewalls, IPv6 protocol-specific issues, IPv6 transition/co-existence mechanism -specific issues, consequences of enabling IPv6 by default, and operational security issues when enabling IPv6 in the network infrastructure. It's only about 8 pages or so :-) --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Jun 24 07:23:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12015 for ; Tue, 24 Jun 2003 07:23:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UlqL-0009Wy-K6 for v6ops-data@psg.com; Tue, 24 Jun 2003 11:20:09 +0000 Received: from [138.4.2.7] (helo=mail.dit.upm.es ident=[xa9O0Cb4ctVJCSWqAxxYnvSZWGmaKhoi]) by psg.com with esmtp (Exim 4.14) id 19UlqA-0009Ve-Pj for v6ops@ops.ietf.org; Tue, 24 Jun 2003 11:19:58 +0000 Received: from greco.dit.upm.es (greco-fw.dit.upm.es [138.4.2.194]) by mail.dit.upm.es (8.11.6/8.9.3) with ESMTP id h5OBJv618580; Tue, 24 Jun 2003 13:19:57 +0200 Received: from obelix (obelix.dit.upm.es [138.4.3.150]) by greco.dit.upm.es (8.11.6/8.9.3) with ESMTP id h5OBJsi05941; Tue, 24 Jun 2003 13:19:54 +0200 From: =?iso-8859-1?Q?David_Fern=E1ndez?= To: Cc: Subject: RE: draft-palet-v6ops-proto41-nat-00.txt Date: Tue, 24 Jun 2003 13:19:53 +0200 Message-ID: <001c01c33a42$8a97c2c0$9603048a@obelix> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3EF6CF82.3040008@6wind.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Alain, > -----Mensaje original----- > De: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] En nombre de=20 > alain.ritoux@6wind.com > Enviado el: lunes, 23 de junio de 2003 12:00 > Para: JORDI PALET MARTINEZ > CC: v6ops@ops.ietf.org > Asunto: Re: draft-palet-v6ops-proto41-nat-00.txt >=20 >=20 > Hi, >=20 > > Hi all, > > > > We just submitted a draft on usage of Protocol 41 over=20 > NAT boxes. > >=20 > I have some question about this draft. > You propose : > v4 v4 > X ---- NAT-box ----- Tunnel Serveur -- v6 world > * * > ************************* > 6in4 tunnel >=20 > 1) OK, but if the NAT-box dosen't support proto 41, it=20 > will need a firmware update. As to proceed with such an=20 > update wouldn't it be more safe, to have th NAT-box be=20 > IPv6 compliant, hence allowing > dual v4 > X ---- NAT-box ----- Tunnel Serveur -- v6 world > * * > ************** > 6in4 tunnel > hence removing the need for proto 41 support ! Yes, but adding support for 6in4 tunnels means adding IPv6 support to = the NAT box which is not a simple modification. On the contrary, adding = proto 41 forwarding to a NAT implementation can be simple: most of the code is already available and the box does not even need to know about IPv6.=20 > 2) in case of NAT-box wih proto 41 support, how does it > work, when > - several Host/routers want to have 6in4 tunnel towards the > same tunnel serveur > - the NAT-box a only ONE public address > because proto 41 doesn't provide ports as in UDP/TCP or ID=20 > as in the ping, for additional multiplexing level. Only one tunnel is allowed per public address and per tunnel server.=20 The main problem here is that the firts machine in the private network sending IPv6 over Ipv4 traffic to the tunnel server will "catch" the = proto 41 entry on the NAT table. Later trials from other machines will fail.=20 That is why it would be very useful to add a new command to NAT boxes in order to define a default machine in the private network to receive = proto 41 packets. This can be done at present for specific TCP/UDP ports or for = all ports, but not for specific protocols. In this way you will have the flexibility to use different machines for external services (NAT entries = for www, mail, etc ports) and IPv6 tunnels (NAT entry for proto 41), as well = as avoiding other private machines to "steal" the proto 41 NAT entry. > 3) do you have an estimation (like the one Christian=20 > Huitema gave in his NAT classification) about how may NAT=20 > support proto 41 and how many don't ? Not yet. We have tested several NAT-routers but we do not have by now = such estimation nor the capacity to test a significant number of router models/vendors. That is why Jordi sent a message to this list asking for collaboration. > 4) anyway, if there is a NAT we don't known about in the=20 > way and that does not support proto 41, all we can see is that > eh! this tunnel doesn't work !! You can make a simple test by sending and IPv6 over IPv4 packet to an external test system (the tunnel broker for example). If it arrives, = then the NAT is capable of forwarding proto 41. It could also be tested in = the opposite direction. Anyway, this should be further investigated to see = if it is viable for common operating systems. > don't you feel it to be risky for a tunnel broker to=20 > provide solution that don't work in some case, he can't=20 > even predict ? As it seems no unique mechanism will be available to traverse NAT, = tunnel brokers could make a predifiened set of tests in order to evaluate which = one can be used (proto 41 forwarding, UDP, etc). Best regards, ------------------------------------------------------------------ Dr. David Fernandez Cambronero =20 Associate Professor Dpto. Ingenier=EDa de Sistemas Telematicos E.T.S.I. Telecomunicacion =20 Ciudad Universitaria =20 E-28040 MADRID =20 tel: +34 91 5495700 x.432 fax: +34 91 3367333 e-mail: david@dit.upm.es ------------------------------------------------------------------=20 From owner-v6ops@ops.ietf.org Tue Jun 24 15:34:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06486 for ; Tue, 24 Jun 2003 15:34:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UtVl-0001wE-6g for v6ops-data@psg.com; Tue, 24 Jun 2003 19:31:25 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19UtVe-0001tS-T4 for v6ops@ops.ietf.org; Tue, 24 Jun 2003 19:31:19 +0000 Received: from consulintel02 ([146.244.21.26]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.0.R) with ESMTP id 61-md50000000023.tmp for ; Tue, 24 Jun 2003 21:32:01 +0200 Message-ID: <095101c33a87$415cc2a0$d76a8640@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <001c01c33a42$8a97c2c0$9603048a@obelix> Subject: Re: draft-palet-v6ops-proto41-nat-00.txt Date: Tue, 24 Jun 2003 12:31:00 -0700 Organization: Consulintel 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Tue, 24 Jun 2003 21:32:01 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 146.244.21.26 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-13.1 required=5.0 tests=BAYES_01,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Just one more comment to what David already replied. I did a small survey, and my guess is that about 80%-85% of the routers in the market support this. That's why I believe is so important to facilitate with an http interface, for example, the usage. Big router manufacturers confirmed to me that their equipment support it, and several of them have a bigger piece in the market. It will be good if other vendors can speak up, or tell me in private, if they prefer not disclose any specific information. I the survey, I will not use vendor names to facilitate it. Regards, Jordi ----- Original Message ----- From: "David Fernández" To: Cc: Sent: Tuesday, June 24, 2003 4:19 AM Subject: RE: draft-palet-v6ops-proto41-nat-00.txt Hi Alain, > -----Mensaje original----- > De: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] En nombre de > alain.ritoux@6wind.com > Enviado el: lunes, 23 de junio de 2003 12:00 > Para: JORDI PALET MARTINEZ > CC: v6ops@ops.ietf.org > Asunto: Re: draft-palet-v6ops-proto41-nat-00.txt > > > Hi, > > > Hi all, > > > > We just submitted a draft on usage of Protocol 41 over > NAT boxes. > > > I have some question about this draft. > You propose : > v4 v4 > X ---- NAT-box ----- Tunnel Serveur -- v6 world > * * > ************************* > 6in4 tunnel > > 1) OK, but if the NAT-box dosen't support proto 41, it > will need a firmware update. As to proceed with such an > update wouldn't it be more safe, to have th NAT-box be > IPv6 compliant, hence allowing > dual v4 > X ---- NAT-box ----- Tunnel Serveur -- v6 world > * * > ************** > 6in4 tunnel > hence removing the need for proto 41 support ! Yes, but adding support for 6in4 tunnels means adding IPv6 support to the NAT box which is not a simple modification. On the contrary, adding proto 41 forwarding to a NAT implementation can be simple: most of the code is already available and the box does not even need to know about IPv6. > 2) in case of NAT-box wih proto 41 support, how does it > work, when > - several Host/routers want to have 6in4 tunnel towards the > same tunnel serveur > - the NAT-box a only ONE public address > because proto 41 doesn't provide ports as in UDP/TCP or ID > as in the ping, for additional multiplexing level. Only one tunnel is allowed per public address and per tunnel server. The main problem here is that the firts machine in the private network sending IPv6 over Ipv4 traffic to the tunnel server will "catch" the proto 41 entry on the NAT table. Later trials from other machines will fail. That is why it would be very useful to add a new command to NAT boxes in order to define a default machine in the private network to receive proto 41 packets. This can be done at present for specific TCP/UDP ports or for all ports, but not for specific protocols. In this way you will have the flexibility to use different machines for external services (NAT entries for www, mail, etc ports) and IPv6 tunnels (NAT entry for proto 41), as well as avoiding other private machines to "steal" the proto 41 NAT entry. > 3) do you have an estimation (like the one Christian > Huitema gave in his NAT classification) about how may NAT > support proto 41 and how many don't ? Not yet. We have tested several NAT-routers but we do not have by now such estimation nor the capacity to test a significant number of router models/vendors. That is why Jordi sent a message to this list asking for collaboration. > 4) anyway, if there is a NAT we don't known about in the > way and that does not support proto 41, all we can see is that > eh! this tunnel doesn't work !! You can make a simple test by sending and IPv6 over IPv4 packet to an external test system (the tunnel broker for example). If it arrives, then the NAT is capable of forwarding proto 41. It could also be tested in the opposite direction. Anyway, this should be further investigated to see if it is viable for common operating systems. > don't you feel it to be risky for a tunnel broker to > provide solution that don't work in some case, he can't > even predict ? As it seems no unique mechanism will be available to traverse NAT, tunnel brokers could make a predifiened set of tests in order to evaluate which one can be used (proto 41 forwarding, UDP, etc). Best regards, ------------------------------------------------------------------ Dr. David Fernandez Cambronero Associate Professor Dpto. Ingeniería de Sistemas Telematicos E.T.S.I. Telecomunicacion Ciudad Universitaria E-28040 MADRID tel: +34 91 5495700 x.432 fax: +34 91 3367333 e-mail: david@dit.upm.es ------------------------------------------------------------------ ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Thu Jun 26 11:58:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05971 for ; Thu, 26 Jun 2003 11:58:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19VZ2O-000KRD-AN for v6ops-data@psg.com; Thu, 26 Jun 2003 15:51:52 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19VZ2L-000KQh-3k for v6ops@ops.ietf.org; Thu, 26 Jun 2003 15:51:49 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19VZ2K-0004Mk-CQ for v6ops@ops.ietf.org; Thu, 26 Jun 2003 08:51:48 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 26 Jun 2003 08:51:47 -0700 To: v6ops@ops.ietf.org Subject: draft-ietf-v6ops-unman-scenarios-02.txt Message-Id: X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit in today's iesg call, draft-ietf-v6ops-unman-scenarios-02.txt was reviewed. there were two comments, one of which is written up now and is appended. the other will be coming shortly. i believe that these comments will need a new rev of the docuemnt. randy --- The Security Considerations of this document largely say that security will be covered in a companion document, but there is a short list of topics covered in this document. This list should add one that is very important to the unmanaged scenarios (related to the recommendation in Section 5.1.2): Security considerations are discussed as part of the applications' requirements. They include: - the guarantee that local applications are only used locally, - the protection of the privacy of clients - the requirement that peer-to-peer connections are only used by authorized peers. Applications in the unmanaged scenarios also need to be protected from risks associated with the transition tools, for example, access to their net through an opportunistic tunnel if the IPv6-over-UDP service is not well-designed. So I think that it would be reasonable to add to Section 5.1.2 and to the Security Considerations some statement about securing the recommended tunneling approaches. Here's some suggested words for the Security Considerations: - the requirement that tunneling protocols used for IPv6 access over IPv4 be designed for secure use; the related requirement that servers in in the infrastructure supporting this tunneling be designed not to be vulnerable to abuse. (Or something like that). Nit: In practice, updating the DNS can be slow, which implies that server applications will have a better chance of being deployed if the IPv6 addresses remain stable for a long period. Oversimplified operational statement. Does it belong in this document? -30- From owner-v6ops@ops.ietf.org Fri Jun 27 10:16:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28871 for ; Fri, 27 Jun 2003 10:16:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19VtyH-000JcU-0g for v6ops-data@psg.com; Fri, 27 Jun 2003 14:13:01 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19VtyC-000JcG-RC for v6ops@ops.ietf.org; Fri, 27 Jun 2003 14:12:57 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28483; Fri, 27 Jun 2003 10:12:38 -0400 (EDT) Message-Id: <200306271412.KAA28483@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-unmaneval-00.txt Date: Fri, 27 Jun 2003 10:12:22 -0400 X-Spam-Status: No, hits=1.5 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Evaluation of Transition Mechanisms for Unmanaged Networks Author(s) : C. Huitema et al. Filename : draft-ietf-v6ops-unmaneval-00.txt Pages : 16 Date : 2003-6-26 In a companion paper we defined the A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-unmaneval-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-unmaneval-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-27081207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-unmaneval-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-unmaneval-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27081207.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Jun 27 12:52:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07229 for ; Fri, 27 Jun 2003 12:52:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19VwP8-000PQd-Rb for v6ops-data@psg.com; Fri, 27 Jun 2003 16:48:54 +0000 Received: from [205.226.5.12] (helo=mailhost.iprg.nokia.com) by psg.com with esmtp (Exim 4.14) id 19VwP4-000POp-CK for v6ops@ops.ietf.org; Fri, 27 Jun 2003 16:48:50 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA18141; Fri, 27 Jun 2003 09:48:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5RGmIs14344; Fri, 27 Jun 2003 09:48:18 -0700 X-mProtect: <200306271648> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpqJFLO; Fri, 27 Jun 2003 09:48:17 PDT Message-ID: <3EFC7606.4000904@iprg.nokia.com> Date: Fri, 27 Jun 2003 09:51:18 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org CC: Christian Huitema Subject: Re: I-D ACTION:draft-ietf-v6ops-unmaneval-00.txt References: <200306271412.KAA28483@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.1 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian et al., As per our earlier discussion, thank you for providing the analysis of isatap in section 4.1.3 of this document update. Unfortunately, I must point out that the analysis is incomplete in the case of isatap being used to provide IPv6 connectivity to the gateway. In this case, the isatap-enabled gateway can receive explicit prefix delegation(s) from the provider (as described in section 3.1.2 of the document) and advertise the prefix(es) to an arbitrarily large number of native IPv6 hosts on the unmanaged network. So, it is indeed not true that: "isatap can thus only be used in the degenerate case when the unmanaged network consists of a single host" as stated in the current analysis. Fred Templin ftemplin@iprg.nokia.com Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Evaluation of Transition Mechanisms for Unmanaged > Networks > Author(s) : C. Huitema et al. > Filename : draft-ietf-v6ops-unmaneval-00.txt > Pages : 16 > Date : 2003-6-26 > >In a companion paper we defined the > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-v6ops-unmaneval-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-unmaneval-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >